Locality in Multiplayer – Talk

Should we add here a list of commands and there locality or should we do that in the list of all scripting commands? --T_D 19:33, 21 July 2006 (CEST)

I would say both. It's good to have a placeholder with all the commands with specific locality behaviour, isn't it? Whisper 23:46, 21 July 2006 (CEST)

---

I have removed following rule

- AI units in a vehicle under player's command are local to player's PC.

The rule is simply not true. AI units are always local where their leader is local. (This is necessary for them to communicate properly)

--Suma 19:56, 21 July 2006 (CEST)

---

Could someone create a table for global and local commands? I dont know how to do it. --T_D 00:39, 22 July 2006 (CEST)

I wouldn't list it in a table, but rather create a template and write the locality into the entry of each command itself. --hardrock 13:38, 24 July 2006 (CEST)

see Whisper's comment above ;) --T_D 14:06, 24 July 2006 (CEST)

A table or simply a list of exceptions? Adding comment in a table is not easy, and often, cases are rather dodgy. moveInXXX need their unit argument to be local, setFog has its effects local, specific eventHandlers (hit, killed) are only triggered where unit is local, etc... this needs explanations. Is it feasible in table?

After thinking about it, perhaps only a list links to the commands that have specific locality behavior in their description.Whisper 14:26, 24 July 2006 (CEST)

I have a complete list with the different locality behaviours of all commands. These exceptions apply for almost any command, so I really think it should be better to have a section "Multiplayer Behaviour" for each specific command. --hardrock 14:34, 24 July 2006 (CEST)

I agree with that -> table deleted --T_D 14:39, 24 July 2006 (CEST)

Good decision. Me or hardrock can hand out this list to anyone who wants to add the locality notes to the scripting command pages, or you can check hardrock's beta Script Ref link courtesy of
OFP-Faguss.com --raedor 00:18, 25 July 2006 (CEST)

---

With the current icons I find it a bit confusing to see what the command really does. Take the flyInHeight command for example. The icons suggest that this command needs to be applied to a local object and its effects aren't broadcated across the net in MP. Technicall that's probably correct since the flyInHeight command itself isn't broadcasted, but the effect of the unit flying at a different height is reflected on every machine on the net in MP. What someone wants to know when he's looking for locality of a command is:

• Do I need to apply it where the unit is local to have it do anything at all, or not?
• Are the results of the command reflected on all machines in MP, or not?

Everything else is just technical detail and doesn't really help when looking up a command for MP scripting. So instead of focusing on the technical details of whether a command is broadcasted or not, I would focus on the effects it has in MP. I think that this would be more consistent to what a user might look for when looking for the locality of a command and avoid confusion about how to actually read and interpret the icons. The technical detail of whether a command is actually broadcasted in MP or not is only interesting for judging whether a script is affecting net traffic or not but not really important for the questions around locality. --rom 18:03, 10 August 2006 (CEST)

If you feel it is correct, just change it. It's not very hard to do, just look at the page source. I based the locality information of each command on a list by spinor, who of course did technical research on each command and its behaviour. But if you feel something different needs to be applied for the one or other command, then change it. That's why it's a wiki. --hardrock 10:38, 11 August 2006 (CEST)

It's not that it's technically incorrect (otherwise I would have changed it as you suggested), but that I was wondering whether the locality info we have right now with the icons is what a user is looking for. Right now the two similar icons for argument and broadcasting describes technical details that are correct as far as I've seen. But when you're doing MP scripting, basically 3 things are important to know:

1. Do I have to execute the command where the unit/argument is local to make the command work?
2. Is the effect of the command visible all over the net or do I have to run the command on all machines?
3. Is the command broadcasted itself (and therefor might have a hit on the traffic if executed often) or are the effects of the command seen across the net because a regular broadcast (like usual position updates) does the job (and therefor using the command has no/minor effect on net traffic).

Right now the icons deliver answers to 1. and 3. but not 2. Hence my suggestion to change the effect icon to give an answer to 2. and maybe add an additional icon that shows the broadcasting (3.) which is what the effect icon is currently doing.

Since the suggestion I made isn't about correcting something that's wrong, but rather a suggestion of how to change the way the info is displayed, I thought I rather point it out for discussion instead of just changing it myself based on only my own personal liking. --rom 16:18, 11 August 2006 (CEST)

I would agree with rom that items 1 & 2 are the most imporant things for an issue like this (execution & visibility location). That's what the icon should signify. I wouldn't add another icon though for network traffic, as that's a fairly technical subject that most people wouldn't be too concerned about, and that wouldn't really deserve a prominent icon at the top like that. --Kronzky 18:08, 11 August 2006 (CEST)

I was reading this and about to agree with rom also until I simplified the question. What rom is asking is "If flyInHeight because it's effects are "seen" on all machines as global so therefore should be listed as global?" That statement is incorrect. flyInHeight is a command that is parsed and executed on a local machine as it only needs to be executed on a local machine. The effects of the helo flying at the preset level has no relation to the flyInHeight command directly. Rather, the height of the helo is the broadcast positional updates from whomever the helo is local to. So, yes it is technical but that is the point of these icons IMO. It is for the technical facts of how a command operates. Granted most scripters (especially the beginners) are not interested in technicalities, but if the situation arises where it is very important to find out the technical details, I would assume they would come here for that. A better example would be the addWeaponCargo command. In this case if addWeaponCargo is executed locally to an ammo crate, the weapon is seen by units local to that machine only but not other clients (try it once). Yet, if a local unit picks up a weapon, all other clients see the unit carrying the weapon. Of course it is this way.. otherwise MP would never work in the first place. Should we change the icon to global because after pick-up the weapon is finally "seen"?? IMO to change icons to global simply because there is visibility (and has nothing to do with the command directly) is a BIG mistake. --CrashDome 02:46, 24 August 2006 (CEST)

In response to: CrashDome 02:46, 24 August 2006 (CEST)

My point was not that the current icons are technically incorrect. My point was that the technical detail about the command being broadcasted provides very little usefull info for someone who's doing MP scripting.
The only real info you currently get from that icon is that you might be able to judge how the network traffic is affected by the command. But what's really of interest for someone doing MP scripting is how a command behaves in MP in terms of how the effects are seen on non-local machines.
Your example is actually a quite good one: The icon doesn't say anything about the behaviour you're describing, but this behaviour is exactly what a scripter is looking for. Yet this info can't be found anywhere. Instead there's just this icon about broadcasting that is technically correct, but can very easily be mistaken for the general MP behaviour of a command by someone who is just getting into MP scripting. And those are probably the ones who are using this Wiki more often than us who allready know all the details about MP scripting.
I agree that the MP behaviour of some commands can be a bit more complicated, so an additional icon would probably not be suitable. But my main point is that the second most important behaviour of a command (beside the locality of the arguments) is nowhere to be found and that the second icon can easily be mistaken to provide that info. --rom 04:25, 24 August 2006 (CEST)

To be fair, 1-3 are not unrelated points. 1. (Must Be Local to object?), 2. (Effect is Global?) and 3. (Net Load Effect) seem to me to work in this way: if 1) is true, then 2) is true or irrelevant and 3) is purely generated by the results of the command within the game engine (I would say minimal, but if you have a weapon with a 9000 RPM rate of fire, and you doFire 1000 times, that's a lot of TCP going out). When 1) and 2) are false, 3) is necessarily zero/minimal (no network effect = no bandwidth). 3) is thus only important when 1) is false and 2) is true, and to be technical about it, again comes down to the difference between instances where the game engine handles the effects of the command (as in SetPos) and those where the command itself transmits directly (="creation" rather than "causation", as with publicVariable, createVehicle, createUnit, u.s.w.).

So reworking the logic, we have
1' Local Effect Only (not 1 or 2)
2' Object Must Be Local For Command To Work (1 = true)
3' Command Works in Multiplayer
4' "Transmitter" command to be used with care in Multiplayer

Basically, 1' and 2' are what "Local Effect" should be now, applied to different groups of commands (doFire addresses the AI and thus is an example of 2', setObjectTexture, the graphics engine, hence 1'). 3' is "Global Effect", and 4' need big fat warning labels (like maybe a voodoo doll, or a giant letter D sinking below the waves) suggesting abusing such a powerful command will pork a multiplayer game superquick.

In the end, you guys are probably overthinking the matter: icons like this will help MP Scripters very little. Once they get the idea of how things work (very few commands "transmit", but some effects "transmit"), they won't be looking at the labels anyway.Dinger 09:54, 24 August 2006 (CEST)

---Yes, IMO those first 3 points did not address the idea properly and Dinger's is much closer. I would rework the icons altogether maybe or even replace them with something a bit more descriptive. As you said (Dinger) these icons help very little. There is more at stake than just Global/Local. IMO this very page should provide the newcomer scriptors the information to understand how scripting in MP works on the client/server level rather than just global/local effects to each client. Originally, these icons were based on Spinor's notes which I believe were about whether or not the command induced traffic or was broadcast (and then expanded to include effects), which is why I said changing them to mean something else as suggested by rom might be a bad idea. What rom wants is certainly meaningful and useful information but simplifying it by two icons might be over-simplifying. After seeing everyone's POV, my suggestion would be to first properly instruct newcomers as to the way MP scripting works on a fundamental level (as exampled by Dinger's logic). After that, the icons do become relatively meaningless. I've never needed them to understand that when I want A, B, and C clients to see the correct time I need to skipTime on all machines. I think the problem newcomers have are that they don't understand why they need to do it on all machines. --CrashDome 03:09, 25 August 2006 (CEST)

As a "newcomer" in MP scripting in Arma, I think that what lacks in the commands description are examples of usage in MP games. It will help to know what are the effects of the command depending on how it's used (used very often, only by server, on a single machine, on all machines, etc), a sample script.

In this moment I'm editing a ctf map and I want to make some objects (a motorcycle and a small shed) to be indestructible. So I'm interested in the setDamage command behaviour.

For example I would have liked to see in the command's description something looking like this :

Script sample of how to make undestructible objects : Motorcycle is an object -> only one computer handles the object (non static object) -> command only needs to be executed on this machine -> damage attribute will be transmitted over the network to all the other machines

intuitive solution : ... ... Only local machine needs to execute command but local machine may change etc ... ... Event Handler ? ... ...

Then some scripts may be discussed, improved, and personally I think it would be easier to understand Some people could start a topic (hiding dead bodies script - link to hideBody command, link to deleteVehicle command). Each command will be linked to some script samples. I know there are forums and websites to find tutorials, discuss scripts, isn't it better to gather all that info around one or more commands ?