[Solved] Instant Disconnect when using this trigger

[latieswakshrum]

I have a cooldown window based revive - buy back trigger and it works fine in singleplayer. However, I hooked up a friend and we played together. The moment I died and typed -bb , I get instantly disconnected. I'm not sure if it is a server-splitting leak or whatsoever. Here are the triggers:

This just sets some boolean variables to true at the start of the map. True = Alive, False = Dead

• Init Values for Player unit Status
  • Events
    • Map initialization
  • Conditions
  • Actions
    • Set IsAliveBoolean_P1 = True
    • Set IsAliveBoolean_P2 = True
    • Set IsAliveBoolean_P3 = True
    • Set IsAliveBoolean_P4 = True

When Blue's hero becomes revivable, this trigger fires off.

• R Blue Becomes Revivable
  • Events
    • Unit - A unit Becomes revivable
  • Conditions
    • (Owner of (Revivable Hero)) Equal to Player 2 (Blue)
  • Actions
    • Set IsAliveBoolean_P2 = False
    • Set RevivableUnit[1] = (Revivable Hero)
    • Countdown Timer - Create a timer window for Timer[3] with title ((Name of (Owner of RevivableUnit[1])) + (Revive in.. + (String(((Level of RevivableUnit[1]) x 3)))))
    • Set cd_timer_window[3] = (Last created timer window)
    • Countdown Timer - Show cd_timer_window[3] for Player 2 (Blue)
    • Set Real_Number[1] = (3.00 x (Real((Level of RevivableUnit[1]))))
    • Countdown Timer - Start Timer[3] as a One-shot timer that will expire in Real_Number[1] seconds
    • Trigger - Turn on Revive Blue <gen>
    • Trigger - Turn on R Blue Buy Back <gen>

It also turns on these two triggers.
This trigger revives the hero at a region after the cooldown timer expires. It fires off with no issue.

• Revive Blue
  • Events
    • Time - Timer[3] expires
  • Conditions
    • IsAliveBoolean_P2 Equal to False
  • Actions
    • Set IsAliveBoolean_P2 = True
    • Countdown Timer - Hide cd_timer_window[3]
    • Countdown Timer - Destroy cd_timer_window[3]
    • Hero - Instantly revive RevivableUnit[1] at (Center of REVIVE <gen>), Show revival graphics
    • Selection - Select RevivableUnit[1] for (Owner of RevivableUnit[1])
    • Camera - Pan camera as necessary for (Owner of RevivableUnit[1]) to (Center of REVIVE <gen>) over 0.50 seconds
    • Set RevivableUnit[1] = No unit
    • Trigger - Turn off R Blue Buy Back <gen>
    • Trigger - Turn off (This trigger)

and this trigger here is what disconnected me instantly. What this trigger does (or attempting to do) is when blue types -bb, I will destroy the cooldown windows instantly and revive the hero at the region. It works fine in Single Player, but online, disconnects me instantly.

• R Blue Buy Back
  • Events
    • Player - Player 2 (Blue) types a chat message containing -bb as An exact match
  • Conditions
  • Actions
    • -------- ------------- --------
    • Set IsAliveBoolean_P2 = True
    • Game - Display to Player Group - Player 2 (Blue) the text: (|c00FF7F00That Buy back costed you: |r + ((String((200 x (Level of RevivableUnit[1])))) + |c00FF7F00 Gold. Ouch!: |r))
    • Countdown Timer - Hide cd_timer_window[3]
    • Countdown Timer - Destroy cd_timer_window[3]
    • Hero - Instantly revive RevivableUnit[1] at (Center of REVIVE <gen>), Show revival graphics
    • Selection - Select RevivableUnit[1] for (Owner of RevivableUnit[1])
    • Camera - Pan camera as necessary for (Owner of RevivableUnit[1]) to (Center of REVIVE <gen>) over 0.50 seconds
    • Player - Add (-200 x (Level of RevivableUnit[1])) to (Owner of RevivableUnit[1]) Current gold
    • Set RevivableUnit[1] = No unit
    • Trigger - Turn off Revive Blue <gen>
    • Trigger - Turn off (This trigger)

Can anyone tell me what's going on?

 

[Zwiebelchen]

Camera - Pan camera as necessary is known to cause desyncs in Multiplayer.

Use the normal camera panning instead.

 

[latieswakshrum]

Thanks! That resolved my issue.

 

[Zwiebelchen]

Thanks! That resolved my issue.

Blame blizzard for the poor implementation of that GUI action.

You can easily manually code it to not desync, though.

 

[Wietlol]

I actually dont know why it desyncs though.
Cant see anything in the JASS code.

 

[PurgeandFire]

I actually dont know why it desyncs though.
Cant see anything in the JASS code.

function SmartCameraPanBJ takes player whichPlayer, location loc, real duration returns nothing
    local real dist
    if (GetLocalPlayer() == whichPlayer) then
        // Use only local code (no net traffic) within this block to avoid desyncs.

        set dist = DistanceBetweenPoints(loc, GetCameraTargetPositionLoc())
        if (dist >= bj_SMARTPAN_TRESHOLD_SNAP) then
            // If the user is too far away, snap the camera.
            call PanCameraToTimed(GetLocationX(loc), GetLocationY(loc), 0)
        elseif (dist >= bj_SMARTPAN_TRESHOLD_PAN) then
            // If the user is moderately close, pan the camera.
            call PanCameraToTimed(GetLocationX(loc), GetLocationY(loc), duration)
        else
            // User is close enough, so don't touch the camera.
        endif
    endif
endfunction

GetCameraTargetPositionLoc() creates a new location agent within the local player block. Once the engine detects that the agent stack is out of sync (usually instantly), it will disconnect players.

 

[Wietlol]

Lol... I thought that such a thing should only be used in local blocks... but anyway I never use locations any more so idc a lot

 

[Dr Super Good]

GetCameraTargetPositionLoc() needs a net sync because the camera target is not auto synced like in SC2.

 

[Wietlol]

But that still means that you cant load the location of the camera for other players right?
Would be usefull at some point though.

 

[Dr Super Good]

Oh wait NVM, it does not take a player so it must be local code. The problem then is as you said, it returns a new handle which leaks and messes up all handle IDs.

 

[Zwiebelchen]

Basicly, if you code it like this, it will work:

function SmartCameraPanBJ takes player whichPlayer, location loc, real duration returns nothing
     local real dist
     local location loccam = GetCameraTargetPositionLoc()
     if (GetLocalPlayer() == whichPlayer) then
         // Use only local code (no net traffic) within this block to avoid desyncs.

         set dist = DistanceBetweenPoints(loc, loccam)
         if (dist >= bj_SMARTPAN_TRESHOLD_SNAP) then
             // If the user is too far away, snap the camera.
             call PanCameraToTimed(GetLocationX(loc), GetLocationY(loc), 0)
         elseif (dist >= bj_SMARTPAN_TRESHOLD_PAN) then
             // If the user is moderately close, pan the camera.
             call PanCameraToTimed(GetLocationX(loc), GetLocationY(loc), duration)
         else
             // User is close enough, so don't touch the camera.
         endif
     endif
     call RemoveLocation(loccam)
     set loccam = null
endfunction

@Wietlol:
The location created will have different coordinates for every player. Just like GetCameraTargetPositionX()

Also, I love how blizzard never cared about removing locations in their BJs.
Even if they didn't know about the reference leak, it still doesn't explain why they never cleaned actual handle leaks.


It's like the BJs were made by a trainee.

 

[Dr Super Good]

Also, I love how blizzard never cared about removing locations in their BJs.
Even if they didn't know about the reference leak, it still doesn't explain why they never cleaned actual handle leaks.


It's like the BJs were made by a trainee.

The entire JASS system is kind of a mess. Player(16) crashes the game for example.

I am guessing automatic garbage collection was a planned feature, and possibly even partially implemented but it either was axed due to development resource constraints or never worked. As such a lot of the script was designed with it in mind. Additionally local declared local handle variables were not meant to leak reference counts and so a lot of the script was designed as if they did not.

 

[Zwiebelchen]

The entire JASS system is kind of a mess. Player(16) crashes the game for example.

That is not surprising, considering that Player(16) is not even a valid player number.

I am guessing automatic garbage collection was a planned feature, and possibly even partially implemented but it either was axed due to development resource constraints or never worked. As such a lot of the script was designed with it in mind. Additionally local declared local handle variables were not meant to leak reference counts and so a lot of the script was designed as if they did not.

Hmm... that makes a lot of sense if you think about it. Or the guys that implemented the Jass-interface simply assumed that the C++ garbage collection would work for Jass aswell.

 

[Dr Super Good]

That is not surprising, considering that Player(16) is not even a valid player number.

Just try it in SC2. You get an error that it is out of bounds and the game does not crash. WC3 could have caused a thread crash or simply assumed Player(0) but instead it crashes. Crashes are never intended in such a case, especially one as the result of a segmentation fault.

simply assumed that the C++ garbage collection would work for Jass aswell.

C++ has no garbage collector. Sure one can make garbage collected code with some class extensions but that is not required and much C++ code has no garbage collection at all.

 

[Zwiebelchen]

C++ has no garbage collector. Sure one can make garbage collected code with some class extensions but that is not required and much C++ code has no garbage collection at all.

Nono, you didn't understand what I mean.
I meant the garbage collection that was implemented internally in the WC3 engine. At least I assume there is one there, simply because the memory shows odd behaviour (even in no-script ladder games) when monitored, like piling up slowly, then suddenly dropping below a certain treshold again.

There is some garbage collection going on behind the scenes. It just doesn't apply to the JASS layer.

 

[Dr Super Good]

Nono, you didn't understand what I mean.
I meant the garbage collection that was implemented internally in the WC3 engine. At least I assume there is one there, simply because the memory shows odd behaviour (even in no-script ladder games) when monitored, like piling up slowly, then suddenly dropping below a certain treshold again.

There is some garbage collection going on behind the scenes. It just doesn't apply to the JASS layer.

There are a lot of possible causes to this. From dynamic memory mapping of files to unloading of assets to deferring virtual memory page frees. Generally garbage collection is avoided in games to avoid the object access overhead due to indirect pointers. Most games use heap based allocation algorithms where pages are allocated to specific objects or object sizes so do not need garbage collection since malloc will always know where to allocate an object (or make a new page for that object if needed).