Trigger Fails, Leading to Desyncs

A clip from my fangame project demonstrating the issue.

So it seems I'm having OnSyncedTriggerStay and OnSyncedTriggerEnter on my bullets fail occasionally, different for each player.
This happens twice in the clip. The first one is inconsequential at 2:12, missing a frame or two on the STornado (pink swirly thing) on the TriggerStay. The second one though is hugely consequential as you see at 3:13 when the splinter of SIce (small blue projectile) TriggerEnter triggers for one player but not the other (But clearly hits on both on the freeze frame).

Since these were both at either the apex or start of a jump, I'm thinking that like the 3d physics collisions, the 2d one also might not like me changing the player's layer on jump/falls (for colliding with platforms) and missing a frame or two as a result. I'll try to run a few tests both without the platforming fall-through mechanic as well as with it set to change to a trigger instead of changing layers. PS: I'm using a sync window of 10 with no rollbacks and speculative contact checked on.


  • Wheathn
    edited April 2017
    UPDATE: Changed the player's hitbox to a trigger to a child GO with a static layer.

    I'm not sure if that fixed the above issue, but I just had something new pop up:

    When the game stops from the short lag spike in that clip, it becomes desynced at 0:09, here. I'm sure the input/physics are written correctly in SyncedInput/SyncedUpdate. The only things I have written in Update() are animations and UI, so I have no clue what could cause this. Could it also be a result of changing layers? It looks to me like player 2 (red)'s inputs skipped ahead after the lag spike. His dash should have been delayed another 2-3 frames or so on P1(blue)'s screen on the bottom view.
  • As a temp fix, I've implemented my own Re-Sync function which, when it determines the game is out of sync (via sending HP updates over SyncedInput and checking to see if it matches 0.3s after the last damage taken), freezes both players for 1 second, then sends the owner's hp/position over SyncedInput, then unfreezes them 0.5sec after. Seems to work so far.
  • Hello @Wheathn, interesting approach, but as you want before the desync should not occur. It is kind hard to tell just by looking you recorded situation what is the cause, could be the changing layers if this change is not deterministic (if you change it in Update for example). To detect the cause you should isolate a few things, for example:

    - Problems in initialization: run the game wthout press no inputs for a few time (10s) and look the checksum, if you get a NOK here you know you have some issue at the beginning.
    - Layers changing: disable this and try to play a little to check if you get a desync or not.

    It can be something in your code or a TrueSync bug.
  • Wheathn
    edited April 2017
    I'm not sure what Checksum means, but I only get NOK for a second or two shortly after either player takes damage, as far as I can tell from a few minutes testing alone on 2 clients.

    Before adding my Re-Sync function I tried without the platform (changing layers) mechanic, but the match result still ended up being off. I did notice though changing the layers throws off the collision speculation hardcore (you dip into the platforms on landing sometimes)--even with speculative contact on.

    I wouldn't ask anyone to go through it all but this controls nearly all of my player's actions to show I don't have anything in Update() other than animations/UI and everything dealing with the physics is an FP and runs on TrueSyncManager.Deltatime if needed. And the only things that use non-TS components is UI (the player's name text). I do have some non-physics things like HP and damage not being FPs, but that doesn't seem to affect the determinism (maybe I'm wrong?).

    Wish I could do more to help track it down, but if it's in the TrueSync code, unless it's something really straightforward like the 3d physics' axes freeze or changing layer/isTrigger only to have it keep colliding until moving (or rotating) a certain distance, then I think it's out of my league.
  • Hi @Wheathn, thanks for the sharing the code, I have take a look, it was not a deep look but it seems to follow TrueSync guidelines. It quite tough to detect the cause when the code is big as yours, but you notice something interesting, that it leads to a desync after some damage. You can make sure that this is the cause, you could disable damage effects on the code to check if the desync never appears. If it was the really cause of the desync than you can dig a little bit more only the part of code affected by take some damage.