JIP

[Espectro]

Will we be able to turn off JIP in ArmA?

I see OFP:E doesn't have this feature, so im interested in hearing if it will be able to turn it off?
Not only by scripting, but will you create a lobby, where people can stay if the mission designer doesn't want people to observe the mission?

[wheres my rabbit ?]

JIP would seriously change coop gameplay.. i hope it can be disabled

[Zerg]

Just lock the server.

[AUS_Twisted]

Good luck getting a official answer for that lol.

[Suma]

Will we be able to turn off JIP in ArmA?

Not only by scripting, but will you create a lobby, where people can stay if the mission designer doesn't want people to observe the mission?
The question is: should this be something determined by mission designer, or by game host / server admin, or by players currently playing the game?

Each of this requires different approach to implementation.

[Dowie100]

server admin

[Berghoff]

This would be nice if ArmA has this feature. Mission Designer and Admin should control these settings as some missions won't allow respawning as for players hmm maybe by a vote or something.. ._.

[wheres my rabbit ?]

Will we be able to turn off JIP in ArmA?

Not only by scripting, but will you create a lobby, where people can stay if the mission designer doesn't want people to observe the mission?
The question is: should this be something determined by mission designer, or by game host / server admin, or by players currently playing the game?

Each of this requires different approach to implementation.
i reckon mission editor ..kind of like the respawn options..
some like it some dont
i reckon people should still be able to join the server while people are playing..it would be rude to completely lock them out of the server..
join and spectate would be ace for coop http://forums.bistudio.com/oldsmileys/wink_o.gif

[Norsu]

I would like to see few choices for admin:

-Full JIP
-Limited JIP (spectate only)
-Lobby screen only (what we have now in PC OFP)
-Lock server

Admin should also be able to change these setting during game. For example a coop mission with spectate setting could be quickly changed to full JIP to give "reinforcements" in tough situations. Also an option for admin to make global channel work only for those in lobby or spectate mode.

[colossus]

I would find it normal that the mission designer AND the
server admin can change this setting. I would think that
mission designers wouldn't like to have JIP on in there coop
missions, because it sort of wrecks the realism.

When it comes to CTF, TDM, DM and C&H you might consider
that JIP is an ideal thing to have, since you have to complete
the whole mission until you can bring in new players.
People don't have the whole day to wait for one server to
finish and people normaly want to play where there is a great
deal of players already. This again can cause less servers
online since everyone is sticking to the same servers,
because there is more people on that specific server.

But to make a it a bit of a free choice I think server admins
also needs to get this ability to turn on and off JIP, and not
only the mission designers.

I fear that JIP might cause a greater risk of spammers and
cheaters because they can just log on, spam or cheat, leave
and then back again. So I really hope a better anti-
spam/cheat system has been made.

I think I've made my point http://img.photobucket.com/albums/v290/colossus/there.gif
I hope...

[.kju [PvPscene]]

determined by mission designer

as he can offer different possibilities to admins (and players sort of) by implementing it as a mission param !

[Dinger]

Quote[/b] ]
The question is: should this be something determined by mission designer, or by game host / server admin, or by players currently playing the game?


Three options:
A) Mission Designer
B) Admin
C) Players in game.

If you're looking at B) or C) as opposed to A), then yes, it requires different implementation. If you make it A), then the mission designer will be able to support or not to support B) and C). How the MD supports it depends on implementation.
If it's implemented as a description.ext value, like the current Respawn, then the MD builds separate missions, with and without, and thus implements B). C) can be brought in with some fancy handlers/scripting to make joined-in-progress players in a non-JIP game "Spectators"

[svendejong]

Quote[/b] ]JIP would seriously change coop gameplay.. i hope it can be disabled

Jip could be a great addition to serious coop play.

With the kind of missions we play on zeus in mind a mission design with incorperates a system where players that JIP spawn in a base from with they could be transported to the front every 5 or 10 minutes by ai or human players(to function as fresh cannon fodder).
Would you be afraid to get players ingame that dont want to adjust to the gameplay needed for the played mission you can always pw the server.

I know for sure that Jip would save many folks from frustration about the many reassigns.

[KeyCat]

The question is: should this be something determined by mission designer, or by game host / server admin, or by players currently playing the game?

Each of this requires different approach to implementation.
Letting the game host/server admin control this would suffice for our group...

Just my 0.20 SEK

/Christer (a.k.a KeyCat)

[brataccas]

I hope this JIP doesnt make a wee blip every time someone joins I think its americas army or something, I do not want to see every time my game blip and end up gettin shot because of it http://forums.bistudio.com/oldsmileys/whistle.gif

[WhoCares]

Generally, I would agree with the suggestion of others before me:
3. Mission
2. Server
1. Player/Admin

The mission gets the least significance, as if it would be predominant, we would end with n numbers of copies of the same mission with edited JIP functionality. (hehe, I already said that in the Multiplayer thread of the Game 2 Suggestion forum 2.5years ago)
Server and Player/Admin are more or less equivalent from my point of view. What interest has a server admin or clan how the games are played on their server while they are not logged in? So the server setting would probably just define a default setting for the toggle which can be flipped by the currently active players/Admin.

However, what has also to be defined is the kind of spawn of players with JIP.
Thinking of COOP and similar missions like Attack&Defend, Server and Admin enabled JIP can only work if spawned into already present AI. Spawns at the original start point are impossible in OFP, just think about a mission that starts on an island with the insertion by choppers. Spawns in the vincinity of other players could end in TK orgies...

Mission controlled JIP on the other hand could be quite nicely integrated in the form of objective based reinfocements. The mission design could even go further and define new objectives and strength of opposition depending on the number of spawning players.
E.g. a mission where the initial mission is to take two villages with the proposition of potential aid of another squad for a two-pronged attack on the second village.
If JIP is enabled the second squad could spawn after the first objective was taken and join the attack on the second target.
If JIP is disabled (by server or players decision) the original squad would have to attack alone, maybe against weaker defences...

Last but not least, different missions might require different kinds of respawns, thinking about Deathmatch, CTI or COOP...


Might actually be generally a good idea to read the first pages of the Multiplayer Suggestions for Game 2 - a lot of good suggestions and discussions on JIP can be found there...

[InqWiper]

I think it should be determined by the missionmaker. It would be nice if the admin could lock the server when the game has already started, that way he can limit JIP. I think that when a player joins a server and there is JIP it would be smooth if he could select what he wants to spawn into with a screen that looks the way the setup screen looks when you pick slots. This way the player can choose what side/group/class he wants assuming the missionmaker allows respawn in more than one side/group/class. If the missionmaker has enabled the ability to join as seagul or spawn at base then there could be a slot on the civilian side called seagul and on each side there could be a base slot at the top.

Example image, copy and paste (not so great):
http://inqwiper.sphosting.com/example.JPG

[Lupus[WD]]

It would also be nice that the JIP system allows someone who's crashed or disconnected to re-join the server and resume the game he was in even if JIP is not enabled per se on a specific server or mission. Something like using player's ID to reassign him in his AI avatar as long as it is alive for instance in non-respawn coops.

[granQ]

Mission designer.. if have to choose one.

Lets say in description.ext

respawn=base
respawndelay=4

and then just

JIP= enabled


and it will copy the same as default "player" are, would be good enough in most COOP..

but also give the tools for more advance stuff by a script like:

onJIP.sqs


server admin stuff (this if more energy is put on cti, ctf type of missions) should be like..
LockAfterGameStart = true
AutoTeamBalance = false


the "goal" should be that a mission designer can do a "battlefield" mod, you can choose side, class.. alot of stuff and at the same time that with little to no codning outside the editor can make a coop with join in progress.

Like todays mission, one trigger and a few units you got a mission, or put alot of scripts and you got a very dynamic mission.

Provide the tools/options for advance stuff, but dont make it too hard.

thats how i want it.

[bl00k]

JIP in COOP would be great imho.

I think people are getting JIP confused with Respawn.

In COOP you have a team of 8 but only 6 people are playing, so the extra 2 guys are run by AI. So if we had JIP in COOP someone could join and take over one of those AI team members. What is the big deal with that? I think that would be sweet.

There is no "join back at base" or "reinforcements" because they are joining as that team member that was there from the start, they were just being run by the computer and now they are a real person.

In DM, TDM, C&H, etc where there is respawn then of course it makes sense to have JIP back at the spawn point, but not in a COOP mission.

I can't wait for this. I'm really excited for ArmA and JIP is one of the features I'm most looking forward to.

[Lupus[WD]]

There is no "join back at base" or "reinforcements" because they are joining as that team member that was there from the start, they were just being run by the computer and now they are a real person.
oh yes, you know better than them what people need for their coops !
If you don't need to be able to manage newly joined players for your coop missions, so good for you, WE (at Zeus) and others would like and need it and this would give a whole new dimension to mission making. If the only way for you is Coop with AI and no respawn let us envision better alternatives to our tastes, like managed respawns (not instant ones) that are annoying and long enough to be dissuasive but wouldnt let players wait for literally HOURS that a mission ends. In the same spirit, managing new comers clearance to join at mission level will also ensure that most people will prefer to join at start if possible and really attend the briefing, or, they'll have to be managed as respawned ones (recruits/reinforcement that need that someone assign a transport to take them to the front line for instance)

[Major Fubar]

It would be nice if a player who lost the connection (for whatever reason) could rejoin and take over his character again.

I would imagine JIP would be pretty mission dependant - there would be some missions where JIP would be fantastic, and others where it would be totally inappropriate...

[AUS_Twisted]

I think JIP is most needed for the longer CTI games in co-op or vs, also good for DM or CTF like all the FPS have, hopefully if someone has a problem mid game and crashes for whatever reason then they can come back in and play again instead of waiting for hours and hours.

[Espectro]

determined by mission designer

as he can offer different possibilities to admins (and players sort of) by implementing it as a mission param !
Nice idea! That is exactly what we would want!

[Heatseeker]

Server and admin controled for adversarial but no JIP in coop maps, the players that conected after the mission started should only be able to spectate.

In a no respawn coop map JIP would defeat the purpose plus there would be the usual joe joining the game, TKing or screwing up the mission and leave, JIP could seriously ruin serious coop games...

For adversarial JIP will be a good thing, despite the idiots that will join a game just to tk their team and screw things up then leave the server but for coop i dont like it and i think spectate only would be much better http://forums.bistudio.com/oldsmileys/smile_o.gif .

Spectating settings could be implemented has map design options, seagull mode, spectate other players (good to see if they cheat), maybe even spectate has other ground animals http://forums.bistudio.com/oldsmileys/wink_o.gif ... Good spectating options would ease the wait http://forums.bistudio.com/oldsmileys/smile_o.gif .

[Dwarden]

most simple is mission and server options (where server can over-ride the mission one) ...

players can vote about ...

this way mission maker decide what's good "default" mode and server owner / admin decide if they want change it and players can vote about if they disagree ...

this made all happy (except some nubs whining about optionable settings)

[Kegetys]

Maybe something like OnPlayerJoin.sqf, that gets called by the server when a player is joining, and this function can return either an unit or false. If it returns false the player is put into the "Game in progress" screen. If it returns an unit the player is given control of this unit (So the script could return an AI unit or create a new unit and return that). Like the current scripts, this script could be in the mission pbo, or in the scripts.pbo (Which could have some default handling, like a spectating script, for missions that do not have their own handling).

Also there should also be a new lock mode for server admin that would always put joining players to the "game in progress" screen (that can be changed in game with a chat command).

[lwlooz]

I think it should be an option for the mission designer and the server admin.The mission designer determines how JIP works in the mission and the server admin decides if JIP works at all(kinda like locking and unlocking the server midgame).As for the mission designer,maybe it could be handled like respawns in the desc.ext.
JIP = 0 -> No Jip possible
JIP = 1 -> Players can join into already existing AI which were set to playable.Additonally to that I would like to see a modified CreateUnit-command with which you could create Playable-Units with Scripting midgame. Players then connect to the server and get and Assignment-Screen like the one of Inqwiper and can select playable slots.Once they click on Ready,they get to the briefing and then join the game.At that point I would like to give OFP a message to all players that a new player joined and an extra one to the leader of the player.Just so he can mentally prepare himself for whatever lunatic joined his squad. "D3ltaSniper-Marine joined your squad" "Argh.. shit".
Maybe there also needs to be a command that can change non-playable units to playable ones and the other way round.

And to all who say JIP isnt good for coops,well you never played a 3h long operation then.It is kinda not nice if squad leaders disconnect and you lose parts of your fighting force http://forums.bistudio.com/oldsmileys/sad_o.gif

Edit: Maybe also add a Eventhandler "Joining" that runs everytime a player joins(obviously). Example:You add a join-eventhandler to a playable unit that calls a command that sets the player in a heli somewhere.

[Killswitch]

Edit: Maybe also add a Eventhandler "Joining" that runs everytime a player joins(obviously). Example:You add a join-eventhandler to a playable unit that calls a command that sets the player in a heli somewhere.
Edit2: Thats kinda what Kegetys said I think
Agree - having a new per-entity event (I'd call it "join" or possibly "joined", keeping with the current event type naming convention) would complement the per-mission onPlayerJoin.{sqs|sqf} system nicely and I can see uses for both.

For comparison, consider how OFP allows you to use a (per-mission) onFlare.sqs script that detects flares being fired in a mission. This complements the (per-entity) "fired" event quite nicely.

I will second the suggestion of being able to add playable units during a mission. (Say, by way of extending the createUnit command). That&#39;d be just great. "Sir, we need reinforcements" "Ok, coming up" <Mission/side CO opens a dialog and adds a couple of squads, each led by a playable unit>

Food for thought: currently, OFP uses certain markers (eg "respawn_east") to decide where people respawn. Imagine the optional "reinforce_west<number>" markers to designate the places where you may enter the game world after the mission has started.

Oh man, the possibilities...

[lwlooz]

Just had another idea concerning this:
Instead of people disconnecting,they first get to the Assignment Screen.That way people ingame could abort it and select another role if necessary.To prevent abuse maybe use JipDelay to let the mission designer select a waiting-time until you can play again.

Also on Respawns & Jip: I think it doesnt matter what respawn the units use.As long as unit is alive is playable and no other player plays it,you can join it,no matter how many times he respawned (that of course only goes for respawn-on-spot and respawn-at-base as only that has multiple respawn of a unit)

[Jinef]

What would be nice is designation respawn.

Where section leaders, platoon leaders or company commanders select where players go. Or just have an auto-assign option.

I would always stick late comers in a rifleman position for example, as they have not heard the brief etc.

[EiZei]

What would be nice is designation respawn.

Where section leaders, platoon leaders or company commanders select where players go. Or just have an auto-assign option.
Or just give the boot for the people thick enough not to listen to their CO. http://forums.bistudio.com/oldsmileys/tounge2.gif

[metallicAL]

With JIP it would be possible to allow spectate? till the round ends, this i think would be awsome.

[Kode]

there are no things like rounds, it&#39;s not counterstrike http://forums.bistudio.com/oldsmileys/rofl.gif

Join in progress means you can join in anytime, and if you are dead, you are just dead till you respawn. I hope they don&#39;t allow to spectate, as it would ruin a part of MP...

[metallicAL]

I play in a coop community and we use the term "rounds" to describe mission.
When someone joins the server its a pain the a** because we have to re-allocate or roles in selection menu, else they have to wait in this boring window with just the names of the people to look at. OK so you can use OFP watch to tell you when the round/mission ends but it would be nice to watch.
i really enjoy watching my teammates with kegetys specator script after i die.
Im not saying that i want players to just spawn halfway through a mission and catch up but if they could specate till the mission ends that would a nice little feature http://forums.bistudio.com/oldsmileys/smile_o.gif

[Commando84]

i think there should be more than one way to go, like spectating , non spectating, everything that is stuff that the mission editor and server admin can edit before start or something like that. I think its boring to just watch the name list, it would be more fun to spectate, but it could be optional maybe. If the risc of ruining a match then they could make it so that in that kind of settings before the mission starts spectators can chat but their messages can&#39;t bee seen by the players only by the other spectators http://forums.bistudio.com/oldsmileys/smile_o.gif
would solve problems maybe http://forums.bistudio.com/oldsmileys/biggrin_o.gif

[armandobronca]

I think a password protected jip option could be good too, i don&#39;t want to see a player connecting to a cti game ,destroying the mhq and then disconnect.

I think mission maker and admins must have the option to enable or disable jip.

[EddyBoy]

password the server perhaps?

[zyklone]

This has to be up to the mission designer.

Complex missions with huge client side arrays have to be coded to support join in progress.

Synchronizing all those correctly when a new player connects would be very tricky. So it has to be possible to disable JIP for missions that&#39;ll break with it.

[hoz]

In observing the characteristics of OFP:E, the client doesn&#39;t receive all the mission like in PC OFP. The client has a template or the mission already on dvd. The server sends an update to the client when they join, the update would consist of different changes the user has made in the ofp editor for that particular template.

I would really like to have a spectating mode when there is no respawn. The seagul can be slow in getting you to the battle if you die along was away.

hoz

[snoops_213]

The question is: should this be something determined by mission designer, or by game host / server admin, or by players currently playing the game?

Each of this requires different approach to implementation.
Sorry, are you asking us what we want? I take it that this part of the code has yet to be implemented then? Hmmmmmmm this may or may not be good news http://forums.bistudio.com/oldsmileys/whistle.gif

"Each of this requires different approach to implementation"

Is there a way that all 3 options can be implemented, if so then thats probably the way to go as everyone would be happy. However saying that I do realize that this may not be an option as the question would not have been asked if it was.

If not possible to have all 3 options then JIP should be managed by the Sever/Admin, with ALL multiplayer missions incorperating JIP natively. Obviously somepeople like the idea that the mission designer should make the choice, but somepeople would want it on anyway. If it was done on the Sever then mission designers could "suggest" the best way to play, but leave ultimate decision upto Severs/players. If mission designers didnt want JIP in the mission then there should be a way that when JIP is enable a penalty should be incurred to ALL players on the server, that way people would be "Forced" to go to servers that disable JIP for that mission so no penatlies are incurred. Penalties would also be upto the mission designer.


What ever you decide to do it can&#39;t be worse than what we have now. Look forward to seeing which way you end up going with this, and some updates http://forums.bistudio.com/oldsmileys/whistle.gif http://forums.bistudio.com/oldsmileys/biggrin_o.gif

[Espectro]

As i see it, there are only 2 different ways.

Either the mission designer can do it, or the admin can do it. The players shouldnt have an option, since they can just ask the admin for it.

Like someone else said... Let the mission designer choose, and then make an param for admin to turn it off. This way, if the mission designer doesnt want JIP in his mission, he can simply code it this way. If he want it to make it both ways, he can just put it in as a parameter, so the admin can choose.

If he want it in, he will just code it that way. So all in all, its the mission designer who chooses how his mission will be played (like now).

I assume that mos mission designers would make it like a parameter then, since thats probably the ones that will be uploaded and therefor played the most on the servers.

If they allready coded the MP JIP, it shouldnt be so hard with an on/off button for JIP... So im sure they are allready done implementing that section (i hope so anyway)

[hoz]

I think with JIP there are some logistics to consider, such as if its JIP does the server send the entire mission to the client as in the ofp:PC or is the mission streamed to the client when the client requires the information. Do you want the server to be consumed by sending the whole mission package at once like sounds and scripts,etc?

[InqWiper]

I think with JIP there are some logistics to consider, such as if its JIP does the server send the entire mission to the client as in the ofp:PC or is the mission streamed to the client when the client requires the information. Do you want the server to be consumed by sending the whole mission package at once like sounds and scripts,etc?
I think it would work nicely if the whole mission was downloaded before it starts but the server prioritizes keeping the current game stable.

[Kode]

I wonder if they also added the possibility to download needed addons from the server, this would be nice so you don&#39;t have to look for the addons. Of course, this should be optional for the servers.

[imported_bör]

I wonder if they also added the possibility to download needed addons from the server, this would be nice so you don&#39;t have to look for the addons. Of course, this should be optional for the servers.
In enemy territory the admin can add a source on a http or ftp server, so that the joining players who miss an addon don&#39;t dl from the server and screw the ping, but rather get the addon faster from another source. Perfect imho.

[Necromancer-]

In enemy territory the admin can add a source on a http or ftp server, so that the joining players who miss an addon don&#39;t dl from the server and screw the ping, but rather get the addon faster from another source. Perfect imho.
It would also be nice if you could copy/paste the adress or double-click on it, so the game will minimize and a browser will pop-up. http://forums.bistudio.com/oldsmileys/smile_o.gif

[armandobronca]

Edit: deleted

[Dwarden]

yes url forward and ingame downloader for addons will be excelent addition ... (UE2/2.5/3.0 support this, Source support this, both of course only for non full scale modifications (let say you need just this vehicle, so it will be autodownloaded and placed to cache) etc.)

[Victrix]

i dont understand whats the big deal in joining and spectating? instead of having the black screen to look at....oh and gotta love when everyone is ready but then someone&#39;s friend from the clan joins in the last minute and we gotta restart the roles again....or lets say someone with a slower internet connection is downloading the mission but some people dont like to wait and there for will start without him....

if you dont want anyone to join in just lock the server....thats all you dont need the option to disable the JIP

[maxqubit]

In Elite i played mainly co-op (own made) missions on XBL.

JIP typically works like this:

I start a mission for 6 soldiers. Mission takes avg 30-60 minutes I&#39;m starting with 1 XBL friend, the other 4 are AI.

Now if DURING the mission another XBL friend joins (e.g. by my invite ... XBL is excellent stuff;) he/she take the place of one AI soldier, so in fact he/she jumps directly into the action.

Good stuff esp. if you just want to have a good co-op time with friends and don&#39;t want to restart all the time.

Btw, this JIP is in fact a way to have respawns&#33;&#33;&#33; I could do above mission all by myself and everytime i die i take the place of a still living AI soldier (until of course they all have died)

[Stendac]

Since we&#39;ll have JIP now, we must also have the ability to kick people in-game now right? I just don&#39;t remember if they said it.

[Chipper]

Since we&#39;ll have JIP now, we must also have the ability to kick people in-game now right?  I just don&#39;t remember if they said it.
We already could kick people in-game.

#kick Stendac

[Hadrian_21VB]

Mission designer &#33;

Hopefully or I can see a lot of mission-setups go down the drain.

[CameronMcDonald]

Of course there&#39;s a mission designer. Also known as the editor.

@<hidden> - http://forums.bistudio.com/oldsmileys/rofl.gif For some reason that #kick comment set me off.

[Hadrian_21VB]

#reassign

As the topic suggest I was talking about JIP and not mission design possibilities in general.

What I ment was:

The mission designer (person, not software) should be able to enable/ disable JIP after my opnion.

[stegman]

I think, as others have said, Join In Play should initaly be down to the mission designer.  He/she specifies to dissable fully or allow.

If Dissabled, then no JIP

Else
The server administrator has the option to;
   Allow;
      JIP allowed as specified by designer
   Dissable
      No Join in Play at all.
I think thats the best way to go about it.
BIS, I tell you what, why not release a MP demo and a few patches to alter the JIP and we&#39;ll let you know soon enough what we think...
http://forums.bistudio.com/oldsmileys/wink_o.gif

[SWAT_CDN]

Ok,

I am not sure how many people that replied here actually run a dedicated server for OFP, our Gaming Group does, here is our opinion.

We feel that JIP will definatley attract more people to the game as waiting in the lobby has been one of the biggest dissapointments of the game for many players.

We in our Gaming Group believe that the Server Admin should make the decision if JIP is available to players.

The Server Admin usually confers with the players of an existing game for a #reassign anyhow and should make the final decision if the mission being played could handle a person joining part wat through the mission.

[stegman]

The Server Admin ... should make the final decision if the mission being played could handle a person joining part wat through the mission.
Surely thats for the mission designer to decide.

I still think the best way is for the designer to allow it or not then, if it is allowed, the server administrator can decide to allow it in that sesion.

[wamingo]

Stegman - Why would you let the mission designer have the ability to stop people from JIP into remaining Living Playable AI&#39;s?
Juding by ofp:elite and what people have said here, you&#39;ll be stuck in lobby if there are no more living playable ai&#39;s.

[the unknown]

Well we want to do that in some cases since it could ruine the story or some other ting like mabey a script.

The Unknown

[seany1212]

well what M.D. should do is have respawn point FAR from battle field then have a transport doing a loop so that they hop in and join the battle like reinforcements.

[SWAT_CDN]

@<hidden>
As we think that OFP is a special type of Game for Special type of Players, (no comparison to some of the others I.e. BF, RVS....), the Server Admin would be able to make the best decision regarding a mission being able to handle JIP, also most present dedicated servers run with people who sort of know each other anyhow. (From our experince with OFP)

Therefore there would or could be a full option of "No JIP", "Partial (password protected) option" or "Full open, whom ever JIP"

Also, I would think that a standard would be automatically set as to how missions would be written and Mission Hosts (servers) would not have to worry about: Is this or that mission JIP compatible).

I think we already have enough issues with Mission and Addon conflicts.

If or should I say when JIP is made available, having it as a core part of the Game would eliminate any potential future problems.

In closing I think the Mission developers have enough to work on, never mind trying to figure out: Can this guy be replaced in game or not?

Humm, after writing the above I admit that with Objective based type missions JIP there might be an issue.
I was thinking more on the lines of Vs or Coop type Missions such as CTI.

Oh well I guess we will find out shortly. http://forums.bistudio.com/oldsmileys/xmas_o.gif

[Victrix]

@<hidden>
As we think that OFP is a special type of Game for Special type of Players, (no comparison to some of the others I.e. BF, RVS....), the Server Admin would be able to make the best decision regarding a mission being able to handle JIP, also most present dedicated servers run with people who sort of know each other anyhow. (From our experince with OFP)

Therefore there would or could be a full option of "No JIP", "Partial (password protected) option" or "Full open, whom ever JIP"
 
Also, I would think that a standard would be automatically set as to how missions would be written and Mission Hosts (servers) would not have to worry about: Is this or that mission JIP compatible).

I think we already have enough issues with Mission and Addon conflicts.

If or should I say when JIP is made available, having it as a core part of the Game would eliminate any potential future problems.

In closing I think the Mission developers have enough to work on, never mind trying to figure out: Can this guy be replaced in game or not?

Humm, after writing the above I admit that with Objective based type missions JIP there might be an issue.
I was thinking more on the lines of Vs or Coop type Missions such as CTI.

Oh well I guess we will find out shortly.  http://forums.bistudio.com/oldsmileys/xmas_o.gif
Well its not OFP is it....and why limit the game for "special players" thats not the way to make buisness http://forums.bistudio.com/oldsmileys/confused_o.gif

I dont think you udnerstand what JIP is....simply join in while the mission has already started without waiting 45 minutes till its done...or refreshing mission when someone else joins in.

[Hadrian_21VB]

Sometimes we use the far respawn -> loop setup.. normally on bigger missions (manouvres).

On small squad misions behind enemy lines, it is not a good idea to have respawn as it shotens the replay-abillity lenght of the mission and therefore puts pressure on the MD to produce produce produce.

BIS have made nice possibilities for non-respawn, Base respawn and Group respawn I hope that that they just make a new string for desciption.ext alike

[stegman]

In closing I think the Mission developers have enough to work on, never mind trying to figure out: Can this guy be replaced in game or not?

Humm, after writing the above I admit that with Objective based type missions JIP there might be an issue.
I was thinking more on the lines of Vs or Coop type Missions such as CTI.

Yes with CTI style missions players should join in at any time, while objective driven missions should be down to the Mission editor, who will have more of an idea if a man should be respawnable.

I don’t think you understand what JIP is....simply join in while the mission has already started without waiting 45 minutes till its done...or refreshing mission when someone else joins in.
We do understand. I just think that on certain types of missions, the mission editor would be in a better position to decide if would adversely affect the mission.



Oh well I guess we will find out shortly.

Quite right. I&#39;m sure it&#39;ll be done very profesionally. http://forums.bistudio.com/oldsmileys/smile_o.gif

[wamingo]

I just think that on certain types of missions, the mission editor would be in a better position to decide if would adversely affect the mission.
I ask again, how would it affect the mission? You don&#39;t recieve a respawn point because of JIP or anything.

[stegman]

I ask again, how would it affect the mission? You don&#39;t recieve a respawn point because of JIP or anything.
Hmmm...How do I explain this...?

Some great mission designer makes a black op for three players.  If no human takes the place of one of the available slots, the AI will not take the role.  
Say you and me set up a server and want to play together.  We pick our guys and guns and head off to make trouble...after forgetting to lock the server..
There we are sneaking around, planting explosives and coordinating our attack.  Then, after 2 hours, suddenly, Punk@<hidden> joins in&#33; Some little 13 year old n00b.  He starts running around shooting at every thing (maybe even us), setting of our charges, making a right bloody mess of things and destroying all our hard playing&#33;

In Ofp there was a feature to disable any unused playable characters.  In JIP, if the mission editor doesn’t enable this feature punk@<hidden> n00b could spoil loads of games.

Or maybe, me as a kick ass mission editor wants to be a right barsteward and make the players decision to go in with half a team irreversible (no PMing your buddies on MSN for help).

Now on a CTI style mission, then yes one guy could start it, he&#39;s playing around for a while then another player joins in. Then another and another.  This is a great idea.  Or even on a death match setup, CYF or other traditional mP game.  But on the above examples I think the mission editor should have the first say if his mission will feature JIP.  If he allows it, then the server admin can decide

[Frederf]

That&#39;s why you have 1: passworded servers 2: have the group leader choose when to accept the new player into the squad.

Does anyone know if one were to join a server and want to "occupy" an existing AI character, what does the selection menu look like?

[Big Dawg KS]

Some great mission designer makes a black op for three players.  If no human takes the place of one of the available slots, the AI will not take the role.  
Say you and me set up a server and want to play together.  We pick our guys and guns and head off to make trouble...after forgetting to lock the server..
There we are sneaking around, planting explosives and coordinating our attack.  Then, after 2 hours, suddenly, Punk@<hidden> joins in&#33; Some little 13 year old n00b.  He starts running around shooting at every thing (maybe even us), setting of our charges, making a right bloody mess of things and destroying all our hard playing&#33;
What&#39;s the difference weather he joins during the mission or ahead of time?

[Frederf]

If he goes bananas and starts tking right away you haven&#39;t invested all that time. You can, #kick, and #restart. If you are on hour 2 or 200, it&#39;s more time invested.

[stegman]

Some great mission designer makes a black op for three players.  If no human takes the place of one of the available slots, the AI will not take the role.  
Say you and me set up a server and want to play together.  We pick our guys and guns and head off to make trouble...after forgetting to lock the server..
There we are sneaking around, planting explosives and coordinating our attack.  Then, after 2 hours, suddenly, Punk@<hidden> joins in&#33; Some little 13 year old n00b.  He starts running around shooting at every thing (maybe even us), setting of our charges, making a right bloody mess of things and destroying all our hard playing&#33;
What&#39;s the difference weather he joins during the mission or ahead of time?
in the example i gave, we forgot to lock it and didn&#39;t only wanted to play with two of us.

So you can see no ocation when you wouldn&#39;t want a random player to join you?

[Frederf]

You want random people to JIP and be able to play but you don&#39;t want random people to JIP? Make sense. What do you want.

[stegman]

You want random people to JIP and be able to play but you don&#39;t want random people to JIP? Make sense. What do you want.
Read it again.  
Some missions will suite it, others wont.

[Big Dawg KS]

Regardless of whether it suites the mission or not, JIP should always be enabled for when things get messy and people drop out in the middle of that same mission that took so much effort, so that they may reconnect and enjoy finishing it.

[Chipper]

Regardless of whether it suites the mission or not, JIP should always be enabled for when things get messy and people drop out in the middle of that same mission that took so much effort, so that they may reconnect and enjoy finishing it.
Totally Agree&#33; http://forums.bistudio.com/oldsmileys/thumbs-up.gif

[deanosbeano]

im kinda hoping we can do a little, name player in list = jip ok
type thing to allow for the above situations. http://forums.bistudio.com/oldsmileys/smile_o.gif
oops, why not password ? well because sometimes people who have password join but theres only enough ai ,for the guy who just
discon ,so it would stop any need to reassign . cruel but stops any messin about http://forums.bistudio.com/oldsmileys/smile_o.gif.

[whisper]

im kinda hoping we can do a little, name player in list = jip ok
type thing to allow for the above situations. http://forums.bistudio.com/oldsmileys/smile_o.gif
oops, why not password ? well because sometimes people who have password join but theres only enough ai ,for the guy who just
discon ,so it would stop any need to reassign . cruel but stops any messin about http://forums.bistudio.com/oldsmileys/smile_o.gif.
Something we could, I hope, do, is no pass on server, admin select s the mission, people chose their positions, admin launch the game, and the first thing players see is a box asking for a user/passwd to set for the current game.
This way, any1 using JiP to join after needs to fill an existing user/passwd to be put back in his original squad. If it&#39;s some1 joining but who was not there initially, he&#39;s put somewhere useless, without anything to do or see. Or, if there&#39;s a command to do it, he&#39;s disconnected.
That way, only people present at mission start (ie who have set a user/passwd for their position) can rejoin in progress if they have a connection issues, etc...
Most of this could be done with scripts, I think.

[Big Dawg KS]

im kinda hoping we can do a little, name player in list = jip ok
type thing to allow for the above situations. http://forums.bistudio.com/oldsmileys/smile_o.gif
oops, why not password ? well because sometimes people who have password join but theres only enough ai ,for the guy who just
discon ,so it would stop any need to reassign . cruel but stops any messin about http://forums.bistudio.com/oldsmileys/smile_o.gif.
Something we could, I hope, do, is no pass on server, admin select s the mission, people chose their positions, admin launch the game, and the first thing players see is a box asking for a user/passwd to set for the current game.
This way, any1 using JiP to join after needs to fill an existing user/passwd to be put back in his original squad. If it&#39;s some1 joining but who was not there initially, he&#39;s put somewhere useless, without anything to do or see. Or, if there&#39;s a command to do it, he&#39;s disconnected.
That way, only people present at mission start (ie who have set a user/passwd for their position) can rejoin in progress if they have a connection issues, etc...
Most of this could be done with scripts, I think.
Why not simply let the admin decide? If it&#39;s not someone they want to join, kick them off. It&#39;s a lot simpler with human componants. http://forums.bistudio.com/oldsmileys/wink_o.gif

[deanosbeano]

Quote[/b] ]Why not simply let the admin decide? If it&#39;s not someone they want to join, kick them off. It&#39;s a lot simpler with human componants
have you ever been on a public serever with voted admins ?
also with the above ways , it eliminates pressure to reassign for little reason http://forums.bistudio.com/oldsmileys/smile_o.gif.thus eliminates "reasiiiiiiiiiiiigggggggnnnn" type idiots.
who of course can be eliminated earlier by simply spotting there "go go go go" type statements

[Big Dawg KS]

have you ever been on a public serever with voted admins ?
Yes, usually the first players there vote themselves in, and the "noobish" types don&#39;t strike me as the type to join empty servers. That&#39;s also why it&#39;s a vote, let the rest of the players decide who they want to be admin.

[UNN]

Quote[/b] ]This way, any1 using JiP to join after needs to fill an existing user/passwd to be put back in his original squad. If it&#39;s some1 joining but who was not there initially, he&#39;s put somewhere useless, without anything to do or see. Or, if there&#39;s a command to do it, he&#39;s disconnected.

I don&#39;t see much in the way of new Arma commands, to do this sort of thing? Which is a shame. Perhaps if some of those nifty create config file commands make their way from VBS to Arma http://forums.bistudio.com/oldsmileys/whistle.gif But I&#39;m sure someone will come up with a suite of scripts to get the most out of JIP.

As for enabling&#92;disabling JIP, I don&#39;t see what’s wrong with giving the server admin the option? But either way, it&#39;s not the end of the world. Looks like you can do enough with mission params and the two JIP commands currently posted on the wiki, to cover most of the issues mentioned here. But there are definitely scenarios where you would want to stop lots of people connecting to your server. Lets hope that can be done by setting the number of playable units or something.

[stegman]

Quote[/b] ]This way, any1 using JiP to join after needs to fill an existing user/passwd to be put back in his original squad. If it&#39;s some1 joining but who was not there initially, he&#39;s put somewhere useless, without anything to do or see. Or, if there&#39;s a command to do it, he&#39;s disconnected.

I don&#39;t see much in the way of new Arma commands, to do this sort of thing? Which is a shame. Perhaps if some of those nifty create config file commands make their way from VBS to Arma http://forums.bistudio.com/oldsmileys/whistle.gif But I&#39;m sure someone will come up with a suite of scripts to get the most out of JIP.

As for enabling&#92;disabling JIP, I don&#39;t see what’s wrong with giving the server admin the option? But either way, it&#39;s not the end of the world. Looks like you can do enough with mission params and the two JIP commands currently posted on the wiki, to cover most of the issues mentioned here. But there are definitely scenarios where you would want to stop lots of people connecting to your server. Lets hope that can be done by setting the number of playable units or something.
Amen. http://forums.bistudio.com/oldsmileys/notworthy.gif

[lwlooz]

A combination of JIP and selectPlayer and some dialogs should like make PW-joining specific groups in a running mission no problem?

Like,you have 10 Civilian JIP slots,once you join a dialog pops up,you enter you squad and a PW and boom ,selectPlayer to leader of said squad.

With "SetPlayable false" which currently isnt avaible,you also could like shut off squads for JIP that have disconnected players which would be of some use.

Edit:Change SetPlayer to proper command-name "SelectPlayer" .What a silly name that is

[UNN]

Quote[/b] ]A combination of JIP and setPlayer and some dialogs should like make PW-joining specific groups in a running mission no problem?

I&#39;m not that familiar with the MP side of things, so even simple tasks like reserving a slot for given time period, so people are allowed to return to a game if they CTD or something. Seems a little complicated.

Add to that, if you can package addons with a mission along with music e.t.c as mentioned in another thread. What kind of load will it put on a server, if every five minutes someone new is connecting and loading the mission? You really want something that kicks in before they start to load the bulk of the mission.pbo, but thats probably asking to much atm. Seen as the true implications of JIP will only be realised once Arma is up and running online, for a few months.

I would not blame BIS if they wanted to keep things simple, for the time being. A basic on&#92;off switch for JIP would certainly do that.

[Londoner]

Not being able to JIP on OFP is at best the most annoying feature of the game.


I don&#39;t want to wait in the lobby for 45min, and I don&#39;t want to wait around for a team of people on a pub server to fill up.

JIP work&#39;s on most multiplayer games, COD, RO, ET, UO BF2 etc..

You need to attract people to this game, and make it easy for them to get in and play.

Those who want hyper realistic games can have their servers locked down, but I&#39;m sure most people would like the ability to jump in and play

[Dwarden]

this debate is funny ...

i think i said that already that best solutions are simple ones http://forums.bistudio.com/oldsmileys/wink_o.gif

1. mission maker select "preferable" option (default choice w/o server admin interfere)

2. server owner select "WHAT he WANT" in other words JIP is either ON or OFF (HE own/control the server HE decide what,how,why is played) ...

problem solved, absolute freedom on variety ...

not interested in people who join later via JIP ?
simple lock server by password

want more?
demand function to "refuse" JIP request (e.g. in case of COOP games) for game admins / squad leaders / squad vote etc. ....

[bravo 6]

<span style='font-size:21pt;line-height:100%'>Negative side:</span>

Im kinda afraid of this new feature (Join In Progress).. because we only have small information about it. We need more info.

At the moment i think of it as a possible respawn/cheat, or another way that people have to respawn to continue the mission if the respawn script is not enable.

I would like to post some ideas i read:

"In addition, when you add respawns to a game then you take away the value of life in the game, and in so doing, you take away the realism. Peel back the respawns to one life only, and suddenly the game takes a giant step towards realism. Points mean nothing - survival and being the last man standing, thereby winning, does."
source: Lightspeed (http://www.armedassault.eu/forum/viewthread.php?forum_id=14&thread_id=549&rowstart=40)

<span style='font-size:21pt;line-height:100%'>Positive side:</span>

In other hand the JIP can also be very inspiring for the mission makers, it could work as a reenforcement of friendly units to the field giving the mission more taste.
With this new JIP feature opens the possibility to make missions even more active, durable by extending them making them more interesting with a positive point of view.
As BIS said missions could now take days, weeks etc.
Thats positive in my opinion but if its used for "respawn" it will suck big time and i as a mission maker will not use it.

ps- I really hope BIS think a good and fair way to implement this JIP (Join In Progress).

[zyklone]

Regardless of whether it suites the mission or not, JIP should always be enabled for when things get messy and people drop out in the middle of that same mission that took so much effort, so that they may reconnect and enjoy finishing it.
The way JIP appears to be implemented in Elite this just isn&#39;t possible.

You need to actually code missions to support JIP which can be tricky.
If your mission doesn&#39;t support JIP then the newly connected player will miss any information on things that already happened.

Luckily in Elite there is a hook that&#39;s exectued when a player connects that can be used to update the newly connected player on what has happened so far.
But forcing missions to be something other than what the mission designer coded it to be will just never work.

[UNN]

Thanks salisan, didn&#39;t think to ask over on the Elite forums.

Could you give us more info on how it&#39;s used&#92;works out in some of the different mission types for OFP Elite? Or perhaps thats a better posted on the Elite forum?

[maxqubit]

Thanks salisan, didn&#39;t think to ask over on the Elite forums.

Could you give us more info on how it&#39;s used&#92;works out in some of the different mission types for OFP Elite? Or perhaps thats a better posted on the Elite forum?
For co-op it works like this in Elite

1. Host decides on the mission (could be standard ofpe or own mission)

2. Host decides if missing real players is filled with AI (say its a coop for 6 and there are only 3 online, you could have the rest (3) AI soldiers)

3. Host can use Friendslist, this is typical Xbox Live feature AND THIS IS GREAT(&#33;) and assign 0 to max slots to &#39;Friends Only&#39; ... so if you don&#39;t like kiddies, well just make the mission available to &#39;friends only&#39; Great stuff:)

4. Every player can choose which character he/she play before the mission start (Host can assign too)

5. Host starts the mission (in case of user mission, parameters are uploaded to the other players)

Now we get to the JIP feature&#33;

If AI slots were allowed and AI soldiers participate (say a mission for 6 was started with 2 live players and 4 AI players) you will have JIP slots (in this case 4) available.

A. If a real live player dies he can &#39;respawn&#39; in a AI player of his choice (if JIP slots are still available).

B. If a real live player disconnects for whatever reason he can JIP the mission as above (provided there are still JIP slots and he can find the lobby)

C. If a new real live player arrives he can JIP the mission as above (provided JIP slots are available)

If no more JIP slots are available you will become a seagull once you die:)

In OFP:Elite this worked great. (Let me advocate again that the tight integration of game and xbl is imho great and relaxing stuff ... although there are games wich have a horrible lobby system, OFP:E has a great lobby system)

[Heatseeker]

JIP might do more harm than good, OPFR MP requires some "dedication" to get going and yet you still find some people doing the most stupid things. Most of those who play (even without JIP) know that the experience is worth it and play because they really like the game. I&#39;ve joined empty servers and had some good coops with people i didnt know in the past, all it took was a good admin and some luck with the people that join http://forums.bistudio.com/oldsmileys/whistle.gif .

With Arma being all new and featuring JIP im expecting the great invasion of the idiots, TK&#39;ers, cheaters and the ordinary online FPS gamer (wich is an asshole by nature).

I dont think i will bother with pubs in Arma... atleast in the first 2.5 years.

[VISTREL]

I disagree. Lack of JIP contributed to small number of OFP players. Most of newbies, and potential good players, might get turned off by OFP style of server, and will move on to other games.

Imho, option to turn on/off JIP is the best compromise. http://forums.bistudio.com/oldsmileys/pistols.gif

[UNN]

Quote[/b] ]If no more JIP slots are available you will become a seagull once you die:)

That sounds good, so if your willing to abide by the mission. Your slot will always be reserved?


Quote[/b] ](provided there are still JIP slots and he can find the lobby)

What happens if the position becomes full in the mean time. Do you still have a lobby, where you can chat to the server admin. Or are prevented from joining the server altogether?

Cheers

[maxqubit]

Quote[/b] ]If no more JIP slots are available you will become a seagull once you die:)

That sounds good, so if your willing to abide by the mission. Your slot will always be reserved?

Yep. (btw you could lock the server and play it with the same ppl as it started, apart from the disconnect that is. You can also leave out the AI, but a mission designed for 6 playing with only 2-3 is of course a bit more hard:)



Quote[/b] ](provided there are still JIP slots and he can find the lobby)

What happens if the position becomes full in the mean time. Do you still have a lobby, where you can chat to the server admin. Or are prevented from joining the server altogether?

Umm, from memory.

Example: You have a lobby of 8 max, but there are currently only 3 ppl. You start a co-op designed for 5 with only 3 ppl + 2 AI. You&#39;d have 2 respawn/JIPs ...

Now:

- if a new person (nr 4) enters he can take the 1st JIP
- if you die you (can) respawn in the 2nd JIP
- if you die again you will become a seagull, as will the others when they die (until mission completed or all died:)
- if a new person (nr5) enters he will be in the lobby and has to wait as are nr 6,7, 8 ... and the server is full.
- if the server is full and you are getting disconneted cause the wife tripped over the network cable, you could find &#39;server full&#39; cause a 9th person was able to enter ... but then again you can send a msg to the host and normally he will ask the 9th person to leave because of mentioned reason (or he could kick him) ... Lots of things going on on xbl, my rule is simple &#39;The host is the boss, you play by the rules of the host or you are out&#39;:)

Btw, you can also lock the server so nobody new can enter the loby, and there is this friends/public slots thing ... you can pretty much do everything ... and kicking, muting, etc:)

(i&#39;d say, this xbl thingy is not so bad after all ... sorry i couldn&#39;t resist:)

[Frederf]

I belong to a cooperative gaming unit that plans to have large large numbers of players at one time. This means maybe 100 JIP slots and being able to leave yours and come back and select Alpha Orange 6 sepecifically. Is it possible to uniquely identify and select which JIP slot you wish you join as? Also is it possible to password certain/all JIPs?

[maxqubit]

I belong to a cooperative gaming unit that plans to have large large numbers of players at one time. This means maybe 100 JIP slots and being able to leave yours and come back and select Alpha Orange 6 sepecifically. Is it possible to uniquely identify and select which JIP slot you wish you join as? Also is it possible to password certain/all JIPs?
Yes, you can uniquely identity the JIP slot/role .. like medic, sniper, rifle man 2, tk commander Bravo or something like that.

http://www.dutchghosts.nl/img/dg111.jpg

The host can assign also.

No password protection.

Ehh, and another thing. In Elite you could NOT &#39;just&#39; leave and come back. In case of disconnect the soldier freezes i think (or does he die?) anyway, the AI doesn&#39;t take over so you can&#39;t return to him (ermmm i think .. i should check this one time:)

A true kind of logoff/logon system (with a password, now i understand why you ask this;) is NOT in Elite.

For grand scale ongoing mission this would be very nice ... Dunno if ArmA will have this (but i think Game2 must have this)

[bravo 6]

sounds interesting http://forums.bistudio.com/oldsmileys/smile_o.gif

Edit: I have some questions about this JIP feature:

1- Where does the JIP player starts? Will he start at base as the mission maker desires (available slots for JIP) or will it go to the AI living bodys in the already action squad?
If we want like 50 units to use JIP, will we need to creat 50 empty slots (playable) for this people who will arrive and use JIP? it may cause lag, no?

2- If we want to have 100 units for JIP will they come one by one entering the game using JIP also one by one (ex: 5 mins after another 5 mins) in the connecting order or will they come and join mission like in squads using fully ocupied vehicles ( makes more sence, as reenforcement )?

ps- by using this feature the enemys must be by thousands, and not hundreds only. This feature might/must turn missions into really really massive battles http://forums.bistudio.com/oldsmileys/wow_o.gif

[maxqubit]

sounds interesting :)

Edit: I have some questions about this JIP feature:

1- Where does the JIP player starts? Will he start at base as the mission maker desires (available slots for JIP) or will it go to the AI living bodys in the already action squad?
If we want like 50 units to use JIP, will we need to creat 50 empty slots (playable) for this people who will arrive and use JIP? it may cause lag, no?

2- If we want to have 100 units for JIP will they come one by one entering the game using JIP also one by one (ex: 5 mins after another 5 mins) in the connecting order or will they come and join mission like in squads using fully ocupied vehicles ( makes more sence, as reenforcement )?

ps- by using this feature the enemys must be by thousands, and not hundreds only. This feature might/must turn missions into really really massive battles :o
Player starts in a living playable AI soldier of his chosing

So, if you want max 50 players you create a mission for 50 players (btw the max in Elite co-op was 12 players&#33;). You could start alone(&#33;) with 49 AI soldiers and 1 by 1 more ppl jump in.

Of course you can go about with these 49 AI soldiers (as far as your role allows you to control them), or just leave them at the base.

Designate a kind of priority and/or grouping of JIPs is NOT in Elite, so in big co-ops it could well turn into chaos:) ... E.g. a JIP squad, and the first JIP player takes the sniper (who cannot take control of this squad) and not the commander of that squad is a bit weird:)

... of course the true OFP player will abide by the orders of his commander so if you design a mission for 4 teams of 12, and you start with 4 ppl, each taking the role of team commander, the ppl who later on JIP should by nature fall under command of the 4 starting players:)

NOTE:Perhaps i didn&#39;t make this clear. You have playable characters (JIP) but you can of course add nonplayable Ai soldiers on both sides (see &#39;battle at le port&#39; in my sig which is 80+6 versus 80, so 6 playable/JIP rest AI)

Most success/fun i had was with relativly small co-ops say max 6 players/JIP, the rest was non-playable AI on both sides, you know the move, cycle, search, destroy, guard, getin/getout waypoint stuff.

I&#39;m positive that ArmA will provide much more flexibility in setting up these kind of thing. Like making only the commanders playable/JIP and the team members non-playable ... Hmmm, i dunno about the command level structure in ArmA. In Elite the squad commander was highest, so if there were 2 or more squads you could only control 1 squad maximum, you&#39;d need a second player to control the 2nd squad, etc.

[lwlooz]

If we were to get an Eventhandler "Joined","Disconnected" for units in the game , then you could do with the units whatever you please script-command wise. For example setpos them to whatever place you feel like.

On that note:
How come OnPlayerConnected,onPlayerDisconnected doesn&#39;t even has the unit that Player joined into as an parameter? Or does that kick off everytime someone connects/disconnects but yet isn&#39;t even in the game world http://forums.bistudio.com/oldsmileys/huh.gif .

Also,if you want to prevent DeltaSniperReconMarine856 to spawn into your squad during an patrol you gotta demand from BIS to change "setPlayable unit" to "unit SetPlayable true/false".
Thus you would be able to shut off any unused AI for JIP at any time http://forums.bistudio.com/oldsmileys/smile_o.gif

I hate to say the obvious,but the more script control we get over JIP and connected/disconnected players(or the units they left behind) the more sophisticated missions you are going to see.

[Frederf]

Is it possible to create new JIP characters on-the-fly? {CreateNewUnit, JIP=true}?

[Big Dawg KS]

On that note:
How come OnPlayerConnected,onPlayerDisconnected doesn&#39;t even has the unit that Player joined into as an parameter? Or does that kick off everytime someone connects/disconnects but yet isn&#39;t even in the game world  http://forums.bistudio.com/oldsmileys/huh.gif .
Maybe that&#39;s because we have the Player command? OnPlayerConnected and OnPlayerDisconnected is most likely local, and if that is the case there will only be one Player. And an eventhandler for "Joined" and "Disconnected" doesn&#39;t make any sense, nor would they even be needed. Again, you can detect whether or not a unit is a player at any time. A lot of people don&#39;t realize that you can put a script on hold if a unit is or is not a controlled by a player just by using the Player command.


Quote[/b] ]Is it possible to create new JIP characters on-the-fly? {CreateNewUnit, JIP=true}?

If the setPlayable command works as it says on the wiki, then you should be able to create a playable role for any unit during the mission, unless it&#39;s for something else.

[lwlooz]

Well,if it is local you are completly correct.How does OnPlayerDisconnected work on a client that just disconnected tho http://forums.bistudio.com/oldsmileys/huh.gif .

Eventhandlers: So,you expect me to go with the OnPlayerConnected command of which there most likely can only be one per client(Just like OnMapSingleClick), and then try to look through a preset array with my player-references what the hell I wanted to do with that unit.And here again we have the great problem of disconnecting players

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
UnitA addEventHandler &#91;{Joined},{player sidechat {You are UnitA}}&#93;
UnitB addEventHandler &#91;{Joined},{player sidechat {You are UnitB}}&#93;
[/QUOTE]

versus

(Given the thing is executed locally only)
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
onPlayerConnected {if&#40;player == unitA&#41; then {blabla};if &#40;player == UnitB&#41; then {blabla}}
[/QUOTE]

Now I think if you have tons of units for which you want to do different things on when some joins into them or disconnects(which most likely would be executed on the server and obviously the player trick doesn&#39;t work there) I would think eventHandlers wouldn&#39;t be that much of a PITA as having to have a very complicated onPlayerConnected thing,leave alone if 2 script system need to use that

[Big Dawg KS]

Well I noticed another new ArmA command: isPlayer. Supposedly it works for any player, not just the client. Anyway, the eventhandler is totally unnecessary, there are already a few ways to do what you&#39;re trying to do. And the eventhandler just doesn&#39;t seem practical, since it has no parameters it&#39;s only doing the same thing as @<hidden> isPlayer UnitA. Also, your example is flawed, since player sidechat {You are UnitA} is only good if it&#39;s executed locally, in which case you wouldn&#39;t even need for that script to be global. Also, I can assume that using the isPlayer command in the unit&#39;s scripting will be more useful than an eventhandler, since that way you constantly know when that unit is and is not a player, rather than the instant a player connects to or disconnects from that unit. And another thing, you&#39;re assuming that as soon as a player connects he immidiately takes a role, but as far as I can tell the players enter a pool first, and I&#39;m assuming the OnPlayerConnected/Disconnected commands work when the player connects to the server, not when they take a role. And if players are going to be switching in and out of different units, it&#39;s better to have an updating script that utilizes isPlayer to keep track of them. I&#39;m not saying there&#39;d be a problem if these eventhandlers were added, I&#39;m just saying they would probably see limited use, and I&#39;d much rather have more useful ones.

[lwlooz]

Okay,Granted it was a very bad example. But IsPlayer doesn&#39;t fix the problem either.
I come up with another example to try to convey the point I am trying to make to you and I guess BIS.
I do not see how it is so hard to acknowledge that a event Joined/Disconnected that is fired of per unit rather than one eventhandler(OnPlayerConnected,OnplayerDisconnected) that is fired of no matter what unit can be considered useless.
I take it you are an addon scripter or SP scripter since in those enviroments you don&#39;t have to bother with different eventhandlers for the "same" thing. If your tank/plane-addon needs to do something in MP,all other tanks/planes need to do the same.Like produce some dust or something. But in my opinion if you are doing a MP mission and you want to have different units perform different scripts on said event "Joined"/"Disconnected",then bloody seperate eventhandlers for them make very much sense.
Basically what you are advocating is the same as saying: "OH no&#33;, we don&#39;t need killed-eventhandlers,we have the OnPlayerKilled.sqs,OnPlayerRespawnAsSeagulls.sqs,etc scripts,they should be able to handle the killed-event of an player just fine"

[Big Dawg KS]

Maybe I wasn&#39;t clear about my point. I&#39;m only trying to say your idea of such an eventhandler wouldn&#39;t be very practical. I can see your point, but I think if there is going to be a "joined"/"disconnected" eventhandler it could be made more useful than what you exemplified. No I don&#39;t have any ideas for how it can be improved but I guess I just feel it won&#39;t be on par with the rest of the eventhandlers. And I have done quite a bit of MP scripting, it&#39;s not easy (frustrating describes it nicely), and I would like to see it made easier in ArmA.

[Razor [RS]]

I will be disabling JIP on my public OFP server after I convert from Resistance to Armed Assault.

I run a coop only public server. I do not want some idiot joining in the middle of a coop map, ruining the map for everyone else, then leaving. That happens now, but at least it is at the beginning of the map and we can start over again without the problem player.

Also, I currently "lock" the server when playing a map to stop the idiots who repeatily connect and disconnect during the map, rather than using OFPWatch, to know when we have finished the current map and are starting a new map.

I do reassign a map for friends and squad members who try to join the server, if we are not too far into the map. Usually, the friends and squad members connect to my teamspeak server before they try to connect to let us know they are available to play on the server. Otherwise, they have to wait for us to finish the map just like anyone else.

[Rambo-16AAB]

Options should be for the server host. The host is the person who is catering for a specific type of player.
The host should have server options for:-
Join in progress / no join in progress
player respawn/ No player respawn ( or limited number of respawns ? )
vehicle respawn / no vehicle respawn
tracers on / off

Things like that.

Comming from a squad who are used to games with JIP , im looking forward to Armed assault. The lack of JIP is why we only mess arround with Flashpoint occasionally, and dont play it all the time. its just way too frustrating if you in the middle of a game and your crash out / loose connection etc and then you have to wait an hour to rejoin your team mates.
Personally I wont and my squad wont be touching servers that dont run JIP in full and we wont be running a server without it ether.