Closed epolixa closed 2 years ago
This is very interesting, as I am using vanilla travel code. I will push a release that marks nether portal travel as unsafe and off by default until I solve this.
Can confirm, happened to me too in singleplayer so it might not be so much of a client/server desync issue
I have run out of time to work on this today, but I have a theory:
[11:34:51] [Server thread/INFO] (HorseBuff) TP- Got Vehicle
[11:34:51] [Server thread/INFO] (HorseBuff) TP- Split
[11:34:51] [Server thread/INFO] (HorseBuff) TP- Changed Player Dimension
[11:34:51] [Server thread/INFO] (HorseBuff) TP- Copied Vehicle to new dimension
[11:34:51] [Server thread/INFO] (HorseBuff) TP- Set Vehicle Position to new coordinates
[11:34:51] [Server thread/INFO] (HorseBuff) TP- Remounted Player on vehicle
[11:34:51] [Server thread/INFO] (HorseBuff) TP- Teleport Complete!
Old Coords:(-160057.3342998588, 71.8500000178814, -135527.75621073725)
TP- New Coords:(-20015.5, 71.8500000178814, -16948.75308572533)
[11:35:20] [Server thread/WARN] (Minecraft) Can't keep up! Is the server overloaded? Running 28708ms or 574 ticks behind
Somehow, after my code, the game runs into something that causes massive TPS lag, leading to the server not saving the new player position, along with causing a a few packets to be dropped telling the player about their new mount. Following a relog, the server puts the player back at the coordinates it had pre-teleport, and the player gets their packets about their mount.
If possible, could you try replicating the issue on a server again, while viewing TPS? (you can use carpet mod and /log TPS for this)
This time I tried to reproduce the issue on a clean server instance with only Fabric, Cloth Config, HorseBuff 1.2.0, and Carpet (and a vanilla client instance again). Interestingly, the travel seemed to go smoothly... no desync issue and the positioning was consistently correct. On the first couple of travels, I definitely noticed the spike in TPS - you can see the console warning(s) as well as the Carpet meter running pink for a moment. Despite this lag, the horse and I traveled as expected. Perhaps the issue is exacerbated on a remote server instance with other mods running, chunks loaded, etc as in my first test.
I have found that the further you are from 0,0 the more consistent the bug occurs, try redoing testing further out
I made some changes inside PortalTravelDev, I am no longer able to recreate the issue
Try the latest actions from that branch and let me know if you can still replicate the issue: https://github.com/CodeF53/Horse-Buff/suites/5948766161/artifacts/203996306
No evidence found that the issue still remains after experimental changes. Pushing those to main and creating a new release
I ended up recreating this in my test world on accident once.
Fixed
Server: Fabric 1.18.2
Client: Vanilla 1.18.2
Some interesting experiences with the new nether portal feature. See video. When entering a portal from the nether to the overworld, it appeared that I ended up a few blocks underneath the portal, inside the ground, instead of at the portal. I also still appeared to be riding the horse despite the horse not being there, and I could not dismount. On relogging, I found myself in a new position, roughly at my previous X/Z coordinates divided by 8, and I was riding the horse I started with. The horse took a little bit of damage - I think when I logged in I was actually in the air (at the original Y pos) and fell down while the server resources loaded. From there, I was able to ride the horse and dismount normally.
Another player reported a similar experience when going to the overworld to the nether - however the position they ended up in was multiplied by 8 instead of divided and unfortunately they suffocated.
I'm wondering if this might be caused by some server/client desync with my client not having HorseBuff installed.
Thanks for the cool mod! Let me know if I can provide any more details!