synchronizeObjectsAdd – Talk
Jump to navigation
Jump to search
(Created page with "These synchronizeObjects add/remove commands works as links in editor SP or MP. But modules sometimes don't work as intended. For example, you can't cope with conditional code...") |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
These synchronizeObjects add/remove commands | These synchronizeObjects add/remove commands work like links added/removed in editor SP or MP. But modules sometimes don't work as intended. For example, you can't cope with conditional codes, toggling these commands for enabling or not supports. | ||
If you link support modules and player(s), in initServerLocal.sqf for example, only player on hosted server will receive these supports as intended. For remote players, modules can lead to disabled (grayed) support or, on contrary, repeated supports. | If you link support modules and player(s), in initServerLocal.sqf for example, only player on hosted server will receive or loose these supports as intended. For remote players, modules can lead to disabled (grayed) support or, on contrary, repeated supports. | ||
So, pay attention for MP behavior | So, pay attention for MP behavior even if commands are stated as AG EG. The afterwards treatment can be weird (modules). | ||
Latest revision as of 23:39, 29 February 2016
These synchronizeObjects add/remove commands work like links added/removed in editor SP or MP. But modules sometimes don't work as intended. For example, you can't cope with conditional codes, toggling these commands for enabling or not supports. If you link support modules and player(s), in initServerLocal.sqf for example, only player on hosted server will receive or loose these supports as intended. For remote players, modules can lead to disabled (grayed) support or, on contrary, repeated supports. So, pay attention for MP behavior even if commands are stated as AG EG. The afterwards treatment can be weird (modules).