Locality issues

[anaximandross 34]

Hello all! So i've been writing some scripts for multiplayer missions, but I'm having some trouble understanding locality. I have two questions:

 

1.) How do I decide if something if something needs to be done client side or serverside?

 

2.) How do I ensure that my scripts will work for both a player host and a server host? would something like if(!isServer || !isDedicated) exitWith {}; give me the desired effect?

 

I've read through BI's page on locality, but I don't really understand it.

[pliskin124 4]

I am curious about this as well. My current topic might help you I've compiled the information I can find but no one really wants to answer my questions. I believe if you put it on the serverside only the server will be effected, for instance a teleport script for the server will only apply to the server host, but if it's applied to the client side it applies to all players. That's the way I understand it anyway.

 

 

[anaximandross 34]

Yea, turns out this is a pretty complicated subject, and the entire answer to just about every locality question is, "It depends". If you look at the Biki though for every command, it'll tell you whether it has local or global parameters ad effects.

[pliskin124 4]

This might help you, I just found this.

 

Quote

Normally you find in the upper section in the BI Biki some Icons and if you hover over these icons you find out if the command is global or local.

 

https://community.bistudio.com/wiki/createVehicle

 

directly under CreateVehicle you find two icons. The first tells you since when this command is available and the second tells you that the command is global and the effects are global. That means if you use the create vehicle command on any computer whether its the server or any player computer the vehicle you created is available on every computer.

 

https://community.bistudio.com/wiki/addAction

Here you find that the effects of that command is local but the arguments are not necessary local.

Explanation:
1. You create an addAction with a simple hint for player p1. Player 1 use the addAction and get a hint saying something. Player 2 (and all other players even the server) is not seeing the hint.

2. You create an addAction with a createVehicle inside. Player 1 use the addAction and create the vehice which is also visible to Player 2 (and of course all other players including the server)

 

[opusfmspol 273]

6thSense.eu - Locality Helped me much with understanding locality, but it was just a start.  There's so much more, and I can't hit it all, others might chime in to help.  But here's my experience.

 

When scripting for MP you must always, with every script, keep in mind which machines will be running that particular script.  Server?  Client?  Both?  or maybe even a Headless Client?  You have to keep your head wrapped around that.

 

Argument local:

When reviewing script commands and you find the argument is an object, and the command is "Argument Local" (e.g. setFuel), it means is that the object (in this case a vehicle) has to be local to the machine issuing the command, whether server or client.  With AI, they might be local to the server or not.  AI are usually local to the server, right?... one might think.  But with a driver who is AI subordinate to a player leader, the vehicle is local to the player leader machine.  This is where one would use local command:  "if (local vehicle1) then {vehicle1 setFuel fuelAmount};"

 

Effect Local:

The local command is "argument global", and what that means is the object must exist on all machines.  There is a command createVehicleLocal which has only local effect, i.e the vehicle would exist only on the machine that runs the command.  Hint and addAction are also local effect.  It means the hint only occurs on, or the action only exists on, the machine running the command.  If you want it to occur on all player machines, the command has to be run on those machines.  That would mean the script is spawned, called or execVM'd by the target machines, or Public Variable Event Handler is used, or remoteExec (allows suspension) or remoteExecCall (does not allow suspension) are used to target them.

 

Headless and Dedicated:

But AI can also belong to a headless client, which is a player and yet not a player.  It's a machine run to offload AI functions, so the server can run faster doing basic processes while the headless handles its AI functions.  In essence it's like having another proxy server, yet the headless client AI leader is registered as a player and it's AI subordinates are local to the headless client machine.  Headless client has no user interface (UI), neither does a dedicated server.  So to exclude those two and only target real player client machines, one can use "if (hasInterface) then { . . . };"

 

Dedicated server has no player.  Player is objNull on a dedicated server.  This is why when scripting for MP you should avoid using player command in any server or common scripts.  Using it in client or headless scripts is fine.  But if a dedicated server runs a server or common script which issues a player command expecting a return, it could error and maybe even terminate the script.

 

Effect Global and Editor Triggers/Waypoints:

When you see a command that has "effect global" (e.g. createVehicle), it means you will usually only want that command to run on only one machine.  Because the result will propagate over to all machines.  This is important to keep in mind with Editor triggers and waypoints.  They will exist on all machines that load the mission.  Many times people post "Why am I getting (_x number of vehicles) created when a (trigger/waypoint) goes off?"  First response:  "Is it an editor (trigger/waypoint)?"   - - "yes."  (been there, done that).  Usual fix is to localize the condition so only the server runs the global effect command, or a specific client machine if that's what is better for the mission.  Instead of just "this", condition would be "this && isServer", or "this && local TeamLeader1".

 

In MP you'll have problems with synced LOAD and GETIN waypoints when the vehicle and troops are not local to the same machines.  I suspect (not confirmed) it might be that the two waypoints use the unitReady command on each other.  My tests with unitReady command have shown that the command is "local argument".  It only returns a correct true/false on the machine where the unit is local.  On any other machine, where the unit is not local, it always returns "true".  And that causes unexpected results when a mission event, like deployment or extraction, relies on it.

 

Finally, with waypoints, I had an MP problem and ran a test one time, which found that only the machine where the group leader was local did the condition check, but the waypoint expression was run on all machines when the condition returned true.  It had the standard placement condition.  However I can't say whether that was a local mission issue or not, I don't believe it was.  I've kept that in mind ever since.  I would invite others to test whether it's true or not.  So this final observation, take with a grain of salt.

 

--- Edit: Reviewed that particular mission again, and recalled the waypoint had not used standard placement condition as first thought.  Extraneous code was run in a waypoint condition field ahead of the returned waypoint condition "true".  But the extraneous code only occurred on one machine, where it was expected to occur on all.  To find out why not, diag_log's were added.  The WP condition diag_log only logged on the machine where the leader was local.  The WP expression diag_log was logged on all.  That's when I figured that  waypoint conditions are only checked on the machine where the group leader is local.