Fix Vehicle entering unloaded chunk to prevent game kicking player off vehicle on MC1165 - MC1201

[Naxgeneral]

About
This is a fix that prevent vehicle from entering unloaded chunk.

How it work

1. Get a block sample by using vehicle's point 3D X,Z position with fixed Y pos being 1. added by vehicle motionApplied * 42 to get position infront of vehicle based on motion.

2. Then cache it in quarantine zone to check if it loaded or not by using minecraft's internal function method.

3. While this being checked it set vehicle's speed factor to 0.009 so vehicle is slow enough to wait for chunk to load. while also set timer to check if player turn away from this unloaded chunk or not to prevent vehicle always travel at 0.009 SF while turn away from unloaded area.

4. If the chunk in the quarantine zone is loaded vehicle will be let go and using its own respective speed factor and get new block sample.

Advantage :
This method will not force limit vehicle actual movement speed which will not cause some plane that require high speed to stall.
Disadvantage :
This probably caused by minecraft basic function stop working when entity left build height cause it seem like the system just not work at all beyond build height This should be fixed in latest commit

My own Test result :
Client :
I tested this my self on my mod pack setup that somehow make world generate 1 chunk per 2 business day and it work as intended
Server :
as well as in server environment i usually have bad connection between a server (800ms ping) which usually make server not realize my actual position and not load chunk in the path and make game kick me out from plane but with this fix i able to fly even with bad internet connection or during high server load.

foot note :
I have to test this all my self as i posted beta and 9999 people who crying over this issue just vanished like they vaporized and not even come to test the fix.

[Naxgeneral]

Additional comment :
I might also make it configurable through mtsconfig.json as in older version such as 1.12.2 there no need to do this. as well as temporary speed factor it change to.

This base code does fix the issue but the method that get block sample to throw into minecraft's chunk checking function just ditch it self beyond build height so if there suggestion or better method for this i also can try it .

-# This code was wrote all by my self with some research of basic Minecraft function through documentation that so hard to find so i know everything i wrote.

[SnailPerson]

@DonBruce64 So we have an issue here, both me and nax have a running attempt at fixing this issue.
My system uses a point 3d to determine whether a chunk upfront (vector of the vehicle) is loaded or not, which scales dynamically with speed. Should the point detect an unloaded chunk it will slow down the plane temporarily until the chunk up ahead is loaded. Critical difference is that it works above build height.

Max system works as described above just that the "dealbreaker" is the system no longer working above build height, which is unfortunately also the height most players will fly above of rather than below. Do you have any insight how we can get the best of both worlds?

[Naxgeneral]

You forgot the part that your just make plane fall like stone when it hit unloaded chunk and not work with heavy mod setup.

[Naxgeneral]

wait i think i see what the issue i will re commit it

[Naxgeneral]

Update
I managed to find the cause of this fix not work above build height and it caused by i calling the function i made in wrong place and that place seem to get blocked when entity left build height. so i move it away and it fixed now.

Test results
Client : Same as above + now works above build height
Server : The fix also work just fine on server without desync and other side effect. I also tested this in many scenario listed here

1. Flying into un generated area : usually vehicle will still continue forwards while game kick player out from vehicle. and this fix completely took care of this issue and this was slingshot proof.
2. High latency connection scenario : usually if i got hit with 500ms+ ping the server will let plane go and not update the chunk loading position cause server didnt recieve player position packet in time and this cause player to get kick off vehicle as it already went into unloaded chunk. And this fix took care of the issue.
3. Connection lost and rejoin : usually if player rejoin world vehicle will already went out of loaded area when player still registering into world but this also got took care off by the fix with 10% chance to not working
4. Sudden server restart : this is almost same as 3rd one but this time its server kicking player out from session. from my test so far the fix couldnt fix this completely and it got 50% yield rate to be stay on vehicle or get kicked off.

Note : the latest commit i made completely work just fine above build height as while testing i fly at Y : 702 at 45+ Blks/s

[SnailPerson]

@DonBruce64 I tested so far, it doesn't seem to quite function for me but it could be my computer being majorly confused. It definitely worked for Nax though...
Either way, his solution seems to be more waterproof than mine? Illl let you decide what works best, but im liking this one ;D

[Naxgeneral]

I committed other change which just comment out section that make the function only work on server side.
So it should work on client side now.
it is weird that last one work in my SP world.

[Naxgeneral]

Update on test result
i recruited people from my own server to test it as literally nobody show up to test it in the bug thread that they whined so much about the issue.
test result from 2 people i get that exclude me was work just fine , the plane pause when about to hit unloaded area and let go after area loaded

[DonBruce64]

@Naxgeneral @SnailPerson so looking at both your codes, I can see what the idea is. Slow down the vehicle when it gets near unloaded chunks. However, you're modifying the speed factor only in some parts of the code. And also you're doing this modification on the client and server, which has the problem of causing de-syncs if the client takes longer to load a chunk than the server, and thus gets knecapped sooner.

What I would potentially try is the following:
Rather than slow down the vehicle, instead, have it not update. So in EntityManager check if a entity will move into an unloaded chunk with its current speed, plus a small safety factor of perhaps 1.25. If it will move into an unloaded chunk with this speed, skip updates.

With this, the vehicle should simply halt processing on the server once it gets to an unloaded chunk. The client could run this code too, and since both don't adjust speed factor, the internal code will act as if it just didn't get a tick update and won't know anything is outside the ordinary. This also ensures that syncing operations don't get mal-adjusted, as they are designed to dynamically rubber-band assuming the server and client have the same math applied. And this is the key: if you change the speed factor on the server for 2 ticks, but the client for 8, then they are going to get out of sync due to them having different physics calculations. But if you block the server for 2 ticks and the client for 8, that just means the client is "lagging" from the server with different calculations and will "catch-up". In the flip side, it might get "pushed back" by the syncing code. But the root thing here is that you don't dyanmically change the physics maths which are fairly important and need to run at a consistent settings in order to prevent issues.

To effect this, you'll probably want to leverage similar logic to the towing vehicles. Having a bit that notes updates are skipped, as you'll need to not only block the vehicle's updates, but ensure that any parts that are on the vehicle also don't process updates. These parts can just check if the vehicle update was blocked, via a function call.

So something like this in EntityManager
if entity not instanceof vehicle or entity.isnotgoingintounloadedchunk() then
update entity
entity.blockedupdate = false;
else
entity.blockedUpdate = true;
endif

Then in the vehicle
public boolean entityisnotgoingintounloadedchunk()
Logic to check this based on physics

Then in the part
Override
public boolean entityisnotgoingintounloadedchunk()
vehicleon == null || vehicleOn !blockedUpdate

[Naxgeneral]

ah i see Thank you for pointing it out but thing was if vehicle fully stop update sometime player want to turn around back into loaded chunk is there way to do that with this method if it make vehicle completely stop updating

[DonBruce64]

Well, the thing is the vehicle will only stop updating until the chunk decides to load. So it won't hurt things. Plus, it'll ensure that vehicles that go really fast won't cause undue tick-calculations with physics updates they don't need to perform since they're on the edge of the world.

Once the chunks ahead load, the player can turn the vehicle around. Though really they shouldn't be flying as fast as they are on the server in general if they're outpacing chunk loading.