Locality in Multiplayer – Talk

From Bohemia Interactive Community
Jump to navigation Jump to search
No edit summary
(clarified why I think the effects icon isn't really helpfull)
Line 48: Line 48:
:::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. --[[User:Kronzky|Kronzky]] 18:08, 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. --[[User:Kronzky|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. --[[User:CrashDome|CrashDome]] 02:46, 24 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. --[[User:CrashDome|CrashDome]] 02:46, 24 August 2006 (CEST)
:::::''In response to: [[User:CrashDome|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.<br>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.<br>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.<br>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. --[[User:Romolus|rom]] 04:25, 24 August 2006 (CEST)

Revision as of 03:25, 24 August 2006

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 --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)