[Trigger] Desync problem with simpel Trigger

[Paddy]

Hello,
I have a small problem with one trigger.
This trigger makes people desync, but I can't figute out why

• Events
  • Unit - A unit Begins casting an ability
• Conditions
  • (Ability being cast) Equal to Select spawns (Neutral Hostile 1)
• Actions
  • Selection - Select (Units within 2000.00 of (Position of (Triggering unit)) matching (((Unit-type of (Matching unit)) Equal to Spawn) and ((Owner of (Matching unit)) Equal to (Owner of (Triggering unit))))) for (Owner of (Triggering unit))

As you can see, it selects specific units of one type for the triggering player. But it also makes the player desync, has anyone ideas why?

 

[Paddy]

So the function we use is this:

function SelectGroupForPlayerBJ takes group g, player whichPlayer returns nothing
if (GetLocalPlayer() == whichPlayer) then
// Use only local code (no net traffic) within this block to avoid desyncs.
call ClearSelection()
call ForGroup( g, function SelectGroupBJEnum )
endif
endfunction

That means we can't use it in multiplayer, because it will always desync, like the function Pan Camera as necessary. Or am I wrong?

 

[Carnerox]

library Snippet
   public function SelectGroupForPlayer takes group unitGroup,player whichPlayer returns nothing
       local group g=CreateGroup()
       local unit u=null
       call GroupAddGroup(unitGroup,g)
       set u=FirstOfGroup(g)
       if (GetLocalPlayer()==whichPlayer) then
           //Clear the current selection of the player.
           call ClearSelection()
       endif
       loop
           exitwhen (u==null)
           if (GetLocalPlayer()==whichPlayer) then
               call SelectUnit(u,true)
           endif
           call GroupRemoveUnit(g,u)
           set u=FirstOfGroup(g)
       endloop
       call DestroyGroup(g)
       set u=null
       set g=null
   endfunction
endlibrary

Try using that. It's tested and works as intended.

Example usage would be.

• Example
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
    • (Ability being cast) Equal to Spawns
  • Actions
    • Set myUnit = (Triggering unit)
    • Set Player = (Owner of myUnit)
    • Set myPosition = (Position of myUnit)
    • Set myGroup = (Units within 2000.00 of myPosition matching (((Unit-type of (Matching unit)) Equal to Spawn) and ((Owner of (Matching unit)) Equal to Player)))
    • Custom script: call Snippet_SelectGroupForPlayer(udg_myGroup,udg_Player)
    • Custom script: call RemoveLocation(udg_myPosition)
    • Custom script: call DestroyGroup(udg_myGroup)

Also for the pan camera question, this is how you would use it.

• Example
  • Events
    • Time - Elapsed game time is 5.00 seconds
  • Conditions
  • Actions
    • Set Player = (Player(1))
    • -------- These would be the x/y position that you need the camera to pan too. Possibly GetUnitX/Y or actual coordinates. --------
    • Set realX = 0.00
    • Set realY = 0.00
    • Custom script: if (GetLocalPlayer()==udg_Player) then
    • Custom script: call PanCameraTo(udg_realX,udg_realY)
    • Custom script: endif

These should not cause any sort of desync within your game by using them this way. Hopefully this helps.

If it continues to desync players, then there will be most likely another problem within other parts of your triggers.

Side note: You should set variables for locations, groups, units, etc and null them after you're done with them to prevent problems later on. Take a look at this for help - Memory Leaks.

 

[Paddy]

Thanks for the reply. I now use the "Add Unit to Selection of Player" Trigger and loop it threw my whole Unit Group, that gives me the same results with no desyncs.

Edit: One question about these temporary Variables, if I reuse them in other Triggers, it it then still necessary to null them? Since I will overwrite them anyways.

 

[Carnerox]

If it's a temporary unit group or location, then absolutely yes you should. They will create memory leaks over time. Look over that link I added into my first post and it will give you a greater understanding.

Variables that are going to be frequently used, you shouldn't have too.