Is this only an issue with Motion Smoothing enabled in the config?

Nope, doesn't seem to change anything sadly

I can confirm this is definitely an issue. The issue is I love this mod so much but I can't use it in MP because of this bug. Enemies have severe desync/miscalculated motion in multiplayer.

To the dev "Stellar":
You are doing God's work making this mod... please let me know if there is anything I can do to help get you more info for fixing this.

Although one extra tidbit of info: This does NOT appear to be a visual bug, the enemies really are in weird places and the desync propogates locally as well (i.e. you can be hit by enemies that aren't even where the server thinks they are)

There is a huge issue with desync because it seems like the server can't properly calculate enemies' movement as it should. Enemies randomly accelerate dozens of times faster than they should in erratic movement patterns going back and forth at high speeds.

Ursprünglich geschrieben von osu! aim:

There is a huge issue with desync because it seems like the server can't properly calculate enemies' movement as it should. Enemies randomly accelerate dozens of times faster than they should in erratic movement patterns going back and forth at high speeds.

this.

So yeah if the dev is down I would be so happy to lend any support in investigating this. I hate to pull the "I'm a SWE" card but I would be happy to take a look at the code as well :)

I couldn't reproduce this with Motion Smoothing disabled, but I did see some funky stuff happening when I enabled it and then intentionally desynced myself.

This should hopefully be fixed now.

Ursprünglich geschrieben von Stellar:

I couldn't reproduce this with Motion Smoothing disabled, but I did see some funky stuff happening when I enabled it and then intentionally desynced myself.

This should hopefully be fixed now.

Ooh I am about to test 6.1 so I will let you know. I forgot to mention that having motion smoothing off didn't have any issues... sorry about that.

You fixed it, awesome! If you're ok with it, I'm curious to hear what was causing the bug.

It had to do with Terraria receiving and applying network updates even on frames where the game doesn't update the world. Hard to explain but I kinda already did in a comment so I'll just paste that here lol

// Here we block network updates on partial ticks.
// This is needed because once keyframes are created, they will be reused every partial tick until the next full tick when they are recreated.
// If NetReceive code changes the state of entities in the world before a partial tick, the changes will be overwritten and lost when the interpolation system sets entity states based on existing keyframes.
// The result will effectively be massive packet loss, as most ticks are partial ticks when running at high framerate.
// If we defer network updates so that they only happen when the next tick is a full tick, we can ensure that new keyframes will always be created after the NetReceive code has run, and nothing will be overwritten.

Ursprünglich geschrieben von Stellar:

It had to do with Terraria receiving and applying network updates even on frames where the game doesn't update the world. Hard to explain but I kinda already did in a comment so I'll just paste that here lol

// Here we block network updates on partial ticks.
// This is needed because once keyframes are created, they will be reused every partial tick until the next full tick when they are recreated.
// If NetReceive code changes the state of entities in the world before a partial tick, the changes will be overwritten and lost when the interpolation system sets entity states based on existing keyframes.
// The result will effectively be massive packet loss, as most ticks are partial ticks when running at high framerate.
// If we defer network updates so that they only happen when the next tick is a full tick, we can ensure that new keyframes will always be created after the NetReceive code has run, and nothing will be overwritten.

Awesome, great job with the fix!