- Joined
- Aug 18, 2009
- Messages
- 4,097
Suggestion: The below listed jass types should be moved to an own object id pool which is not subject to influence network signals and therefore not to trigger Warcraft III's desynchronization check.
ability, boolexpr, button, defeatcondition, dialog, effect, event, fogmodifier, force, gamecache, group, hashtable, leaderboard, location, multiboard, multiboarditem, quest, questitem, rect, region, sound, timer, timerdialog, trackable, trigger, triggercondition, triggeraction
Furthermore, thread calls should not be part of the shared id pool, either.
Reasoning: Mapmakers want to be able to do stuff only for certain player clients like showing different multiboards to each one. While that particular one is often solved by spanning local blocks with GetLocalPlayer() and putting only the show/hide instructions inside, it has a few drawbacks. The whole content management of the multiboard may still be tasked to all clients although they do not require it, posing extra expenses. In a lot of cases it's not as simple because the API is lacking. It is also lacking in regard to be able to avoid local blocks altogether, like there being no show/hide function for the sfx type effect.
I do not know how the desynchronization detection that halts the game in Warcraft III exactly works but it seems the id pool agent objects share must be left untouched. However, a lot of the types extending agent should not cause any network traffic in the first place. For example the visual type effect or the audio type sound. It does not make sense for them potentially affecting the desync mechanism when constructed/destroyed in local blocks.
Then there are the more logic types like location and rect. They are usually applied in a sync manner but they are purely controlled by user jass, do not emit signals on their own. Therefore, if they were not part of the observed id pool, they would not risk a game desync - unless they were explicitely used for gameplay purposes.
The current situation is that mapmakers jeopardize the game because they do not expect the asynchronity of features like discussed in this post. I deem this behavior creates more desyncs in the end. Also the matter is mostly concerning custom maps, the experience is up to the mapmaker anyway.
Following are event listeners like dialog, region or timer. Those can be registered to ingame events and fire trigger objects or code handles. This means they invoke new jass threads (execution sequences). As far as I know, those are currently required to be kept in sync as well and count to the agent id pool, which I do not understand why. Timers are very important for most frameworks and even have local-only use cases like updating arts. The types of this group still should not have network traffic of their own.
Even widget (unit/item/destructable) should not act freely because Warcraft III does not match after the fact, it waits for player inputs, then is autonomous. But I guess it's most visible from those objects when gameplay does not fit together.
Finally no idea why triggeraction is not subtyping agent, though it does add to the shared id pool.
ability, boolexpr, button, defeatcondition, dialog, effect, event, fogmodifier, force, gamecache, group, hashtable, leaderboard, location, multiboard, multiboarditem, quest, questitem, rect, region, sound, timer, timerdialog, trackable, trigger, triggercondition, triggeraction
Furthermore, thread calls should not be part of the shared id pool, either.
Reasoning: Mapmakers want to be able to do stuff only for certain player clients like showing different multiboards to each one. While that particular one is often solved by spanning local blocks with GetLocalPlayer() and putting only the show/hide instructions inside, it has a few drawbacks. The whole content management of the multiboard may still be tasked to all clients although they do not require it, posing extra expenses. In a lot of cases it's not as simple because the API is lacking. It is also lacking in regard to be able to avoid local blocks altogether, like there being no show/hide function for the sfx type effect.
I do not know how the desynchronization detection that halts the game in Warcraft III exactly works but it seems the id pool agent objects share must be left untouched. However, a lot of the types extending agent should not cause any network traffic in the first place. For example the visual type effect or the audio type sound. It does not make sense for them potentially affecting the desync mechanism when constructed/destroyed in local blocks.
Then there are the more logic types like location and rect. They are usually applied in a sync manner but they are purely controlled by user jass, do not emit signals on their own. Therefore, if they were not part of the observed id pool, they would not risk a game desync - unless they were explicitely used for gameplay purposes.
The current situation is that mapmakers jeopardize the game because they do not expect the asynchronity of features like discussed in this post. I deem this behavior creates more desyncs in the end. Also the matter is mostly concerning custom maps, the experience is up to the mapmaker anyway.
Following are event listeners like dialog, region or timer. Those can be registered to ingame events and fire trigger objects or code handles. This means they invoke new jass threads (execution sequences). As far as I know, those are currently required to be kept in sync as well and count to the agent id pool, which I do not understand why. Timers are very important for most frameworks and even have local-only use cases like updating arts. The types of this group still should not have network traffic of their own.
Even widget (unit/item/destructable) should not act freely because Warcraft III does not match after the fact, it waits for player inputs, then is autonomous. But I guess it's most visible from those objects when gameplay does not fit together.
Finally no idea why triggeraction is not subtyping agent, though it does add to the shared id pool.
Last edited:
