ArmA (MP) Scripting

[Sickboy]

I created a MP Scripting/Editor Guide a couple of days ago, you can find it at the BIKI:
http://community.bistudio.com/wiki/6thSense.eu:EG

I would like to use this thread for discussing the content of the guide, or for questions/answers surrounding the wonders of MP Scripting etc.

In the end I hope to use the information to include in the wiki.

[Sickboy]

First Subject I would like to throw up:

TeamSwitch within Multiplayer
My experience with ArmA v1.01/1.02 (I think it was) tells me that teamSwitch does work in MP. With full option to switch between the different units you have setup as teamSwitchable.

Reading Doolittle posts and some others, it is claimed that teamSwitch does not work in MP. (Thread Link)

What are other people's findings?
I will be able to look into it myself in the next days, possibly weeks.
But I would like to supplement the Wiki page with informations on how to work out teamSwitch within MP etc ASAP.

[raedor]

Can't say anything about that ts issue.

But still a good idea to open up a discussion here.

[benreeper]

I found that when you switch to a unit (I believe that is NOT in your group) you will have no control over that unit. It is like you are "Being John Malkovich". Also your soul, face, stats and whatever are still part of the original unit.
--Ben

[The_Captain]

I've had MP teamswitch (using a custom interface and selectplayer, not the BIS interface) within my own mission for a little while now, limiting use only to units local to the switcher's computer and within his own squad (and no players are ever in another player's squad, to prevent horrible bugs). From hearsay, I've heard that switching to a unit not local to your computer causes a crash. However, testers of my mission have occasionally experienced the "john malkovich" bug where they are accidentally inhabiting an AI which is local to the server (I suspect) and have no control over it.

if you 'addswitchableunit' more than one unit, the BIS dialog becomes enabled (also I think there's a command to enable or disable the dialog itself.) All of my tests have been done with a custom interface, so I can't comment on how BIS' works in MP.

It thus seems that if you wanted to enable teamswitch in MP missions, you should override the default BIS interface and write your own that changes a unit's locality before the switch, as long as the unit is not controlled by another player.

And as stated, the original player's identity stays with his server joined unit. In another thread it was pointed out to me that identity can be changed in MP, but I have been unsuccessful trying it myself. If you *never* use setidentity on a player's new unit, he retains his name in chat but not on his new unit's in game tag.

Another infuriating bug with teamswitch in SP or MP, is that when you change to another unit within the same vehicle (say, driver or gunner), the original player unit retains control of the vehicle. So if you 'move to cargo' from the driver position, and then teamswitch to the driver position, the cargo unit will retain control over the vehicle. Or, a player who gets in as cargo and then teamswitches to driver will also encounter this problem. Teamswitching within the same vehicle can thus cause problems when a player cannot retain control over his own vehicle, or can't switch to other positions (because he is no longer the effectivecommander). A clever combination of getin-getout actions to reset the commander of the vehicle to the original player works, but it's still an annoying workaround.

[Doolittle]

I've never tested teamSwitch since people reported problems.. I made a fake teamSwitch in my CTI where you switch positions and weapons.

The variable time is synced when you connect.. is param1/param2 synced?

What I'm curious about: when is onPlayerConnected run? When the new person is in the game and has a player variable?

Also, what I noticed for JIP clients... all objects since the start of the map seem to be created and then put into their present state! E.g. if something dies and is deleted, it will be created then deleted again. So with that in mind.. what if you setVehicleInit adding of ammo to ammo box.. and that ammo box is destroyed.. then JIP player joins (redundant to say that? heh) ... they create then destroy ammo box..do they also put ammo in it? Is it possible for setVehicleInit code to check "this" and see if it's dead yet before running a command on the object? (Seems you have to delay it)

It's interesting what Lester said about lock! I've been trying to figure out what's going on with that.

[Sickboy]

Thank you all for responding.

@Raedor; Pitty, but thanks!

@The Captain; Interesting. Will work those details out in the Guide, and maybe there's a chance we could figure out how to get around these weird issues. Custom dialog might be the way to go, as you did.

...

Quote[/b] ]I've never tested teamSwitch since people reported problems.. *** I made a fake teamSwitch in my CTI where you switch positions and weapons.

Ok
The captain seems to have some interesting info. I guess my little tests back then involved AI local to the player machine

Quote[/b] ]The variable time is synced when you connect.. is param1/param2 synced?

param1 and param2 do not have to be synced as variables. param1 and param2 are set by admin or per mission default, if they were set by admin, I believe when the JIP player connects, when he looks at the param1/param2 setting in the server, it matches what was set by the admin / default. These settings are then used for param1 and param2 by the client. Just as an ordinary client would, when he was connected while setting the param(s) and starting the match

It's indeed the time variable that is synced, but afaik a jip player's dayTime gets set like: current daytime (mission time set in editor) + (synced) time = real current daytime on all clients+server. (Unless the time was artificially manipulated with setDate, skipTime, in this case, the jip player will have his time still said to what I wrote above, but is out of sync with the rest because their time was manipulated)

Quote[/b] ]What I'm curious about: when is onPlayerConnected run? When the new person is in the game and has a player variable?

My Findings:[*] onPlayerConnected fires after the Briefing for all players that are ingame[*] onPlayerConnected fires when a jip player's world is initialized, but it does not have to mean that the player object itself is already initialized.
I must say that these have not been confirmed by the proper testing chain... Maybe someone should do it, so we can confirm

Quote[/b] ]Also, what I noticed for JIP clients... all objects since the start of the map seem to be created and then put into their present state! E.g. if something dies and is deleted, it will be created then deleted again. So with that in mind.. what if you setVehicleInit adding of ammo to ammo box.. and that ammo box is destroyed.. then JIP player joins (redundant to say that? heh) ... they create then destroy ammo box..do they also put ammo in it? Is it possible for setVehicleInit code to check "this" and see if it's dead yet before running a command on the object? (Seems you have to delay it)

Samething I noticed here, and also one of the reasons why I stopped using setVehicleInit and now work with a Network Service that uses a publicVariable per channel (clients or server), and addPublicVariableEventHandler. I send an array with: Destination, code to execute, and extra parameters like object references etc, which can be accessed from within the code to execute.
The problem is only that for your example, ammo boxes, you would need setVehicleInit because you want the boxes to be filled with the right ammo for the JIP players
But this actually creates a desynchronized environment I believe, because you fill it to 100% when the vehicleInit is ran at JIP, while the box contents could already have been changed.

Testing object for alive could require a short sleep so the object is initialized, and if destroyed, this should &#39;ve propagated by then aswell. I can remember however a test where I set a vehicleInit with a player sidechat str(this), deleted the object, and let a jip player join. He said he received "<Null Object>" in the chat.
Which would indicate that the init is ran after initialization+synchronization of the objects, not directly after initialization.

I don&#39;t remember if alive check on an objNull gives true or false, I believe false, so using an alive check in the code would be ok.

Quote[/b] ]It&#39;s interesting what Lester said about lock&#33; I&#39;ve been trying to figure out what&#39;s going on with that.

I guess I missed that going to look into it
Update Ok, took a look.
Some functions must be executed where the object is local, and do not have effect from every machine.
Maybe those functions should all be listed and marked, in their BIKI pages aswell as the EG I believe.
The solution is to use a network service or a simple publicVariable with addPublicVariable like in my example above. The code to execute should only check if the object is local to the machine, and then execute the command.
In my opinion, such network service should be common practice for MP missions, as many more advanced features require this kind of communication possibilities

[Dr_Eyeball]

I&#39;ve added 3 notes recently as tips directly relevant to JIP:
- player - waiting until player is not null
- playerSide - equals west during JIP
- publicVariable - prevent overwriting during initialisation

Not sure whether they may be of use to your discussion.
I&#39;ve only learnt these things recently. Pretty simple but I wish I knew them 6 months ago.



Edit:
Also, the script to &#39;get a list of all (alive)player-objects&#39; doesn&#39;t take into consideration that the player may be a crew member inside a vehicle (with multiple crew members) and hence will be excluded. You need to add something like:
<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> if &#40;&#91;_vehicle&#93; call fn_IsVehicle&#41; then
{
{
if &#40;isPlayer _x&#41; then
{
_playerList = _playerList+&#91;_x&#93;;
};
} forEach &#40;crew _vehicle&#41;;
}
...
[/QUOTE]

[The_Captain]

Re: time:

Time seems to be synchronized well enough for players who start at mission start and players who JIP. However, time is NOT synced for players who are stuck in lobby or briefing when the game starts ("If you start mission you may leave players behind. Would you like to continue?" or such). Naturally these players also do not get additional updates since mission start, and I wish there was a simple way to 1) figure out which players are in this state, and 2) give them an accurate time value from the server to replace their timelagged value.

Re: network engine:

I just want to chime in that I wrote a network engine similar to sickboy&#39;s which has publicVariableEventHandlers on the server to recieve info from each client, and clients that wait for broadcasts from the server. This method is far easier to implement & cleaner than setvehicleinit as sickboy has pointed out, especially now that we can send arrays (been waiting for this since OFP..).

Also, in terms of publicVariables being synced for JIP players: The client seems to receive the variables either before or while his init.sqf is running (ie, before sleeps). So, if in your scripts you initialize a publicVariable (say, so you can wait for variables to be sent to that client later), your client will end up with his variable initialized without the value that was sent as he connected. This means you either need to check for an existing value when you initialize client variables on JIP, or resend publicvariables from the server after a player is connected to ensure they get the value. As well, I think the publicvariable that is synced when a player connects will not trigger the publicVariableEventHandler (unless the handler is added in the init, before any waits), but I have not tested this specific case. (ack, looks like DrEyeball pointed this very fact out on the wiki)


And to chime in about &#39;lock&#39;: I&#39;m happy that command is local&#33; In my own mission I lock east&#39;s crew restricted vehicles to west, and vice versa. (Tanks, helis, etc). This would not be possible if the command were global...

[Sickboy]

....

Quote[/b] ]I&#39;ve added 3 notes recently as tips directly relevant to JIP

Nice one&#33;

Quote[/b] ]I&#39;ve only learnt these things recently. Pretty simple but I wish I knew them 6 months ago.

I know where you&#39;re coming from

Quote[/b] ]Also, the script to &#39;get a list of all (alive)player-objects&#39; doesn&#39;t take into consideration that the player may be a crew member inside a vehicle (with multiple crew members) and hence will be excluded

Good point&#33; Resolved.

...

Quote[/b] ]However, time is NOT synced for players who are stuck in lobby or briefing when the game starts

Good point. Maybe we should bring this to BI&#39;s attention as I believe it&#39;s a bug or at least no good exception handling
We could always create a heartbeat and make the server send out it&#39;s time every 60 (or so) seconds and let clients sync with it. Or as Victor Farbau wrote a script; use a global equally named object and use setPos on the server to keep track of hours, minutes, seconds

Quote[/b] ]The client seems to receive the variables either before or while his init.sqf is running (ie, before sleeps)

Yep, it&#39;s important to check if the variable is nil or not before initializing them, incase of publicVariable.

Quote[/b] ]especially now that we can send arrays (been waiting for this since OFP..).

Oh yes&#33; Boy public Arrays rock (Sending arrays as strings was such a shitty solution, as when you wanted to send objects, they had to be named the same on all machines, through a variable, vehicleVarName (or in the editor).

Quote[/b] ]And to chime in about &#39;lock&#39;: I&#39;m happy that command is local&#33; In my own mission I lock east&#39;s crew restricted vehicles to west, and vice versa. (Tanks, helis, etc). This would not be possible if the command were global...

Agreed, it&#39;s a good thing