[General] Deselection and blocking/delaying orders bugs in multiplayer again

[Barade]

Hi,
my map has again some weird deselection and blocking order bugs but only in multiplayer.
In the past, the deselection bug was caused by using "Units currently selected by" in a trigger condition which you should never do: [General] - Selection Bug?
It is mentioned in the GUI trigger and from what I have read is due to SyncSelections causes some waiting which is not supported in trigger conditions/TriggerEvaluate.
However, the trigger has long been removed and I am really struggling to find the latest reason.


My map is: World of Warcraft Reforged 4.0
You can see the latest map script here: https://raw.githubusercontent.com/tdauth/wowr/refs/heads/master/wowr.w3x/war3map.j
I do the multiplayer tests myself by hosting a LAN game with a logged out user and joining with a logged in user.
When I click on a tavern/neutral building, it sometimes immediately deselects.
Besides, issued orders sometimes take for a long time until they are actually issue as if there was something blocking them.
I have searched for all my SyncSelections/GroupEnumUnitsSelected/GetUnitsSelectedAll in the script and cannot find one in any trigger condition.
Besides, there is only two EVENT_PLAYER_UNIT_SELECTED and one EVENT_PLAYER_UNIT_DESELECTED events with normal trigger actions.


Is there something else which causes this weird bug of deselection stuff and blocking orders in multiplayer?
It is really annoying since this makes the map unusable for multiplayer.
Understanding the reason for it will help me to prevent it in the future but I don't even know the reason now.
I will test a multiplayer game without any map scripts to make sure it actually is a script issue.

 

[PurgeandFire]

You might also want to take a look at any code that hides units, as AFAIK that also causes the player's selection to drop. Not sure otherwise, unless you have SelectUnit calls.

For the delay on orders, do you have a lot of units with active orders? If you have too many active orders on the map, the engine will eventually hit a rate limit and you'll start to notice all sorts of delays on orders (you might also notice units "stopping" in the middle of the order once they reach a way point, and then continuing after a short period). I believe this is just a limitation of the engine (even if your computer can handle it), and it is reproduceable even in single-player (although multiplayer maps tend to have it more since more players typically imply more units with orders).

To monitor this, I would recommend setting up a trigger that detects all order events and then adds the units to a list (or unit group). Whenever a unit is added to the list, increase the counter. Then have a timer that runs to detect when they become idle, i.e. (this is just a sample from my old map, you would probably want to tweak it/remove the alive check):

    --- Returns true if the unit is considered idle (stop or hold position).
    ---@param unit unit
    ---@return boolean
    function isUnitIdle(unit)
        local currentOrder = GetUnitCurrentOrder(unit)
        local isIdleOrder = currentOrder == 0 or currentOrder == 851993
        return UnitAlive(unit) and isIdleOrder and not IsUnitLoaded(unit)
    end

And when they become idle, decrease the counter and remove them from the list. Then display the total number of active orders in a leaderboard or as something retrievable with a chat command (e.g. -debugordercount) so you can see what the number of active orders are at any time.

If you can find a reliable way to reproduce it (and it seems to be based on order count), then the only way to really solve it is to go through your map and cull any unnecessary orders. For example, if you have a lot of patrolling/orders for immersion (e.g. some creeps or NPCs walking around), you can try removing them or only triggering them when players enter that region.