AgentRevolution – User talk
Jump to navigation
Jump to search
Are you sure about locality of disableCollisionWith? Because it doesnt make sense for the effect to be local --KK
EDIT: corrected it.
- My conclusion came from these observations: if an MH9 collides into a cargo parachute and both are local, the MH9 gets damaged and crashes. If I call "para disableCollisionWith mh9", the MH9 can freely pass through it. Now, if the MH9 is client-side and the parachute is server-side, and I call "para disableCollisionWith mh9" on the server, it has no effect on the client and the MH9 gets damaged. If the same command is called on the client only, then the parachute has no effect on the MH9, and it will bounce away like a balloon if the heli collides with it. If called on both the client and server, then the MH9 can freely pass through it without the parachute moving at all. Also, if both the parachute and MH9 are local to the server, the command is called on the server, a player gets in the MH9, and rams it into the parachute, the MH9 explodes.
- In essence, the effect on the engine is always local, but what's being perceived globally down the line is how the collision actually takes place. --AgentRev 23:34, 11 October 2014 (CEST)
- That is what I observed as well. This points to local argument requirement. In case of both arguments being local command works just fine, in case them being one local one remote, this is where it gets confusing. In case with the helli, once you got inside, you changed its locality, so you needed to run command locally too. --KK
- In light of what I said, I think it would be most appropriate to remove the argument locality, since it can be a mix and match of local & global, and that the effect locality be changed back to local, as it only affects the computer where the command is called. --AgentRev 10:08, 12 October 2014 (CEST)
- Argument locality indicates execution locality of the command, and with collision command this is exactly where the command should be executed, locally to one of the arguments. However, local to which argument is the question. In case with player and object, player is the main argument, AI and object, it is AI. A Note explaining weird behaviour will be sufficient IMO. As a rule of thumb it would not hurt to execute where each argument is local. --KK
- When I see "arguments local" for a command, I interpret it as "every single object passed to the command must strictly be local otherwise it will irrevocably fail to achieve the desired effect", which doesn't quite match this command. When I see "effects global", I interpret it as "the effects of this command will be applied to all computers on the network and persist if the locality of the object changes", which is true for pretty much every command marked with "effects global" except disableCollisionWith. --AgentRev 13:16, 12 October 2014 (CEST)
- I dont see any problem with what you are saying. In most cases there is only 1 argument so it is easy to understand. In collision command there are 2 arguments. Both should be local to the executing pc. If one is not local then command has to be also executed where it is local. I dont understand what is the problem with this? I can tell you for sure the effect of this command is not local, if you interpret the failure of this command to work on some non local object it is because it never executed for it not because it was executed but not broadcast. --KK
- Just to add effect is also JIP compatible, this means it is global. I think we can close this subject now. --KK
- "If one is not local then command has to be also executed where it is local." - Wrong. If the MH9 is local and the parachute is remote, you can call disableCollisionWith successfully; the computer in control of the MH9 will not generate a local collision on contact with the parachute. But, since the effect of the command is local only, then the server stills detects a collision when the MH9 comes in contact with the parachute, thus making it bounce like a balloon. You're not required to also call it on the server, unless you also don't want the parachute to bounce.
- JIP has nothing to do with this, because the collisions are only calculated on the computers in control of the simulation of the objects that are colliding, what the other computers see are merely a visual broadcast of what is happening on those computers. If the effect was global, then the computer calling the command would broadcast to all other computers "hey guys, please ignore all collisions between the MH9 and the parachute until further notice", which would be persistent on all computers regardless of the locality of either object, which is not the case, since the effect is loss if the MH9 changes locality. --AgentRev 16:01, 12 October 2014 (CEST)
- It is similar to allowDamage. Effect is global as long as vehicle doesn't change locality. Looks like it is applicable do collision too. If I allowDamage false of the object on my PC it is indestructible on every PC. I call this Global effect. It looks like disableCollisionWith works on the same principal, it is handled where unit is local.--KK
- When I see "arguments local" for a command, I interpret it as "every single object passed to the command must strictly be local otherwise it will irrevocably fail to achieve the desired effect", which doesn't quite match this command. When I see "effects global", I interpret it as "the effects of this command will be applied to all computers on the network and persist if the locality of the object changes", which is true for pretty much every command marked with "effects global" except disableCollisionWith. --AgentRev 13:16, 12 October 2014 (CEST)
- Argument locality indicates execution locality of the command, and with collision command this is exactly where the command should be executed, locally to one of the arguments. However, local to which argument is the question. In case with player and object, player is the main argument, AI and object, it is AI. A Note explaining weird behaviour will be sufficient IMO. As a rule of thumb it would not hurt to execute where each argument is local. --KK
- In light of what I said, I think it would be most appropriate to remove the argument locality, since it can be a mix and match of local & global, and that the effect locality be changed back to local, as it only affects the computer where the command is called. --AgentRev 10:08, 12 October 2014 (CEST)
- That is what I observed as well. This points to local argument requirement. In case of both arguments being local command works just fine, in case them being one local one remote, this is where it gets confusing. In case with the helli, once you got inside, you changed its locality, so you needed to run command locally too. --KK