search

SpongePowered / SpongeForge

A Forge mod that implements SpongeAPI
http://www.spongepowered.org/
MIT License
1.14k stars 306 forks source link

Ticking entity crash when being thrown between 2 SpongeForge servers in Waterfall #1978

Closed Pythonic-Rainbow closed 6 years ago

Pythonic-Rainbow commented 6 years ago

I am currently running

Issue Description When a player being thrown between 2 SpongeForge servers ( both build 2859), the player will have a high chance of being crashed by 'Ticking entities'. However the weirdest thing is the bugged entity is the player itself, and the entity is being null.

There are many exmaples. https://gist.github.com/phit/5dc541052475794c91a3654323395565

phit commented 6 years ago

I moved your logs to a gist, so people don't have to download a zip. Also remapped the first example. But yeah, you gonna have to figure out what mod is needed to reproduce this, I run multiple 1.12 servers behind Hexacord myself and haven't had such issues.

The log seems to suggest the player may have a parrot on them?

dualspiral commented 6 years ago

Try this without SF and IP forwarding and see what happens in a testing scenario, I suspect you may find a similar result.

I'm not convinced that this is a SF problem at all. What happens is that the forge handshake to check compatibility with the recieving server occurs before the server switch occurs, so the client gets reverted to frozen and then has the new mod mappings sent. My gut feeling is that the server ticks on the entity while mod mappings are being sent due to the handshake occurring on a network thread rather than the main thread. If the network is somewhat slow, the entity ID can't find a mapping, returns null, and this happens.

In this case, the real solution is to work with the various proxy systems and Forge to reduce the points where such desyncs can cause problems, but it's a non-trival amount of effort and isn't within the remit of Sponge.

Zidane commented 6 years ago

Not an issue with Sponge code.

ryantheleach commented 6 years ago

@Pythonic-Rainbow Did/Does this happen before 2951 or so?

@Faithcaio Remember that shoulder entity stuff we touched? maybe that caused a waterfall bug to surface?

Pythonic-Rainbow commented 6 years ago

@ryantheleach yes this did happenn b4 2851 @dualspiral Yes ,from Waterfall's log,the client connected to game server first,after it loads the map and then disconnect from lobby.However I believe my network is not slow at all.

So do I have to create an issue in Forge and Waterfall?

Pythonic-Rainbow commented 6 years ago

Here is an example for the Waterfall. SpongePI was just added, so when i created the issue SpongePI wasnt there.

[17:39:14 INFO]: Listening on /0.0.0.0:25565 [17:41:53 INFO]: [/192.168.1.1:50954] <-> InitialHandler has connected [17:41:54 INFO] [SpongePls]: Using the Forge Server Connector for Pythonic_Rainbow [17:41:54 INFO] [SpongePls]: for the target "lobby". [17:41:54 INFO]: [Pythonic_Rainbow|/192.168.1.1:50954] <-> ServerConnector [lobby] has connected [17:42:36 INFO] [SpongePls]: Using the Forge Server Connector for Pythonic_Rainbow [17:42:36 INFO] [SpongePls]: for the target "agp". [17:42:36 INFO]: [Pythonic_Rainbow|/192.168.1.1:50954] <-> ServerConnector [agp] has connected [17:43:03 INFO]: [/192.168.1.1:50954|Pythonic_Rainbow] <-> DownstreamBridge <-> [lobby] has disconnected

phit commented 6 years ago

remove SpongePls, its not needed for Waterfall

dualspiral commented 6 years ago

If you have a load of mods, the mappings might take a non trivial amount of time to transfer.

It's something that needs to change in the Forge client because the reset packet and transfer of new mod mappings take effect before the handshake is complete. To be honest, I don't see Lex going for it, but you never know.

Either way, not a Sponge issue.