per48r
Assigned
Reported
Comments
that’s good @josh. I’m still having major block breaking issues and movemement issues (not related to block breaking)
Would you mind sharing your relevant settings from server.properties or dockerfile?
The rubber-banding issue still exists for us unfortunately.
I’ve tried a lot of settings and sometimes it settles down for a while, but only in the short term. Players are back to restarting their client
Ultimately, the client (iPad) is regularly getting out of sync with the server and from that point they never reconcile the issue so a restart of the client is required.
eg. block placement, block breaking and player position.
fyi, our server is having issues again… rubber banding. Which is very weird because it was working much better. I’m going to try different settings and will report back..
Oh, I just noticed this setting I used in my ‘worked well’ settings from previous post…
player-movement-action-direction-threshold=0this property is the only one that is “not” strict…
0 = very lenient
1 = very strict
Anyway, “0” is the setting we have now and it seems stable (I have no reason to change it, since it’s working)…
Following my last post, I’ve now played around with the newly added settings in server.properties. I’m able to get pretty stable performance for a LAN linux server with the modified settings shown below.
Overall,
we were able to stay connected and play continuously for around 90 minutes. previously, we had to restart every 5 minutes or so as the client and server would eventually disagree on this blocks were broken
Previously, I had assumed that I wanted the server to be less strict and more forgiving of client discrepencies. HOWEVER, it turns out that making the server very strict and unforgiving of client discrepencies is the best outcome (and introduces no noticeable lag for my setup)
Since changing the settings, players on the server have noticed:
block breaking is 99% accurate and solid. there was an instance of one broken block showing broken on the client but the vines
the client/server synchronisation of position appears to be 100% solid. There are no more instances of bumping into free air as the client and server seem to agree on the state of blocks and the clients location.
latency with the server is not noticeable at all. However, I need to test this with a remote connection when there is a longer ping… will need to get back on this.
fast boat travel is pretty good. As usual (for the last 3+ years) chunks can be slow to load when you are travelling 5000 blocks in a few minutes. However, there was a little bit of rubber banding at one point, but it resolved itself within a few seconds and didn’t require any restart. So, I would consider this a non-issue, from what I’ve seen
We’ll keep playing and will report back if we notice any further glitches
these are the settings changes that worked well:
server-authoritative-movement-strict=true
# Set at true to be more strict toward the Player position and be less permissive in accepting the client info.
# This means clients will receive more position corrections. This will impact Player around moving block if there is high latency
server-authoritative-dismount-strict=true
# Set at true to be more strict toward the Player dismount position.
# This means clients will receive a correction on their dismount position in higher latency situation
server-authoritative-entity-interactions-strict=true
# Set at true to be more strict toward the Entity interactions.
# This means clients will be more strict towards Entity interactions. This will impact Players interacting with each other in higher latency situations.
player-position-acceptance-threshold=0
# This is the tolerance of discrepancies between the Client and Server Player position. This helps prevent sending corrections too frequently
# for non-cheating players in cases where the server and client have different perceptions about when a motion started. For example damage knockback or being pushed by pistons.
# The higher the number, the more tolerant the server will be before asking for a correction. Values beyond 1.0 have increased chances of allowing cheating.
player-movement-action-direction-threshold=0
# The amount that the player's attack direction and look direction can differ.
# Allowed values: Any value in the range of [0, 1] where 1 means that the
# direction of the players view and the direction the player is attacking
# must match exactly and a value of 0 means that the two directions can
# differ by up to and including 90 degrees.
I have this issue too on linux bedrock server 1.21.73.01. My server is a year old or so, fairly big survival world. Hopelessly unplayable for several weeks now, due to rubber banding, block placement getting out of sync between server and client. We have to restart the client every 3-5 minutes basically if we want to play which is getting very tiresome.
So, anyway I did suspect that I need to look closely at server.properties. I downloaded a fresh version of linux bedrock server and check those defaults in server.properties. There are many new settings and many that are removed that relate to client and server auth…
I applied the defaults and still broken unfortunately. 3-5 minutes of vigorous survival building and thebn then the client/server start to disagree on which blocks are broken and which position the client is in… and rubber banding during boat travel.
After updating to 1.19.40, the unloaded chunks issue appears to be resolved for us on all affected iPads (some ipad pros, some standard ipads) - thanks team
Same here: Multiple iPads connected to bedrock server are having the same issue as reported above....
Bedrock server, linux. iPad clients, some Pros, some Airs.
The main problem: Chunks do not load, on first world load. Strangely, re-opening the client app completely (ipad task manager, swipe up on app to exit) will fix the chunks and the game then runs fine. In a small number of cases a third load is required before the world runs properly.
Also related?
players have died entering the world (suffocation, I think). Seems to be related since the chunk is not loaded in all cases
players device have locked up going through netherportal (during "building terrain" step, I think). Maybe related?
This issue only started in 1.19.30. Our world was started in 1.18 so it's been through a few upgrades in 2022.
1.19.2 fix works for me
chunk loading lagginess is solved.
fast boat travel (packed ice road) is fast, smooth frame rate and chunks are loading easily, without disruption to travel
notes:
i updated my bedrock server, on linux docker, to 1.19.2.02
then updated my iOS clients to 1.19.2
I have tried with 2 simultaneous users, will try more tomorrow
hardware:
iPad Pro 12.9 (3rd gen)
In 5 minutes of testing, I have encountered only one issue in 1.19.2
When eating food 3 times, the client then reverted 2 of those actions, so it appeared I had only eaten once).
it was like the client and server were getting out of sync
This issue appears unrelated to MCPE-156737. If it persists, I will raise a new issue...
We're experiencing the same chunk loading lag on iOS with bedrock server (linux).
It seems to me that the issue is client side (iOS) not the server. Here's what we've noticed to support this:
using boat travel over ice (which is a very fast way to travel), you quickly encounter undrawn (invisible) blocks that take up to 30 seconds to load
the client will not allow you to travel into the invisible area. It's not clear that this is a server or client issue though (at this point...)
once the blocks load, you can travel like normal. (it's consistent it's just slow to load)
mob pathfinding still works over invisible blocks. Ie. mobs travel over/around the invisible blocks like the blocks are drawn (mob pathfinding still works over invisible blocks). Whilst the client gets stuck
additional game issues
we sometimes get stuck (eg. in between blocks/soffocating) due to travelling too quickly into invisible blocks. This is a major issue for playability
Just to confirm the impact of this.
I can easily rollback Bedrock Server to a prior version 1.18.30
However, clients on iOS will not be able to connect to the Bedrock Server since it enforces version parity. iOS clients are essentially stuck on 1.18.30
So, in our case it's essentially bricked at the moment, unless we begin a new world from scratch in 1.18.30, which is very undesirable.
It stands to reason that we all hope that workarounds will be considered soon if solutions are not imminent.
If you need, I'm happy to provide world files from our bedrock server (backups immediately prior to 1.18.30 and other backups after things go bad).
Or I can do testing on a beta when you're ready with that. Whatever helps.
The devs are appreciated nonetheless, they have built a great game that we all love
I'm experiencing the same issues since 1.18.30 with bedrock server world (windows 11). I had raised a separate (duplicate) issue but will add here for completeness...
Note: This world was started in 1.18.2.03 (28 Jan 2022) and it has become quite active with 4-7 players daily.
Gameplay experience after 1.18.30
for the first day or so, the world was working fine with multiple players
after a while, minecart travel stopped working. during travel, the player stopped moving, cart dissappeared. it was found at the end of the track
apart from the cart glitch, it seemed pretty normal. The affected user found the cart could not be picked up though even after they did "Save and Quit" which usually solves small consistency issues
Things started going downhill
the server started to lock up and needed restarting
users found that the world did nothing
users tried to disconnect from their client but the server did not report that they had disconnected. It seemed like it wasn't responding so it was restarted.
upon restart, all sorts of weirdness. could not interact with blocks
Memory issues started
several restarts later...
the server is crashing now, due to out of memory
memory peaks at 24GB+ allocated to bedrock_server.exe
the memory issues now occur as soon as anyone enters the world (doesn't matter who). It climbs very quickly to 20GB+ and bounces up and down a little and then crashes
Sometimes the crash is reported in Windows Event Viewer.
Faulting application name: bedrock_server.exe, version: 0.0.0.0, time stamp: 0x624cf184
Faulting module name: ucrtbase.dll, version: 10.0.22000.1, time stamp: 0x00e78ce9
Exception code: 0xc0000409
Fault offset: 0x000000000007c648
Faulting process ID: 0x718
Faulting application start time: 0x01d856178fd240d8
Faulting application path: C:\Users\deang\Minecraft\bedrock-server-1.18.30.04\bedrock_server.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report ID: a018c101-eeaf-402d-bda1-d0ec2eab8c29
Faulting package full name:
Faulting package-relative application ID:Please let me know if there's any more information you need. I can provide the world file if you want to take a look at that.
We didn't have any issues at all with this world until 1.18 but now it is unusuable. I suspect there is a bug that this world is able to reproduce, so it may be worth taking a look
Thanks
I have Created this issue again in BDS (where it belongs).
Correct Issue:
Please close this issue:
MCPE-154397
Thanks heaps Josh, I’ll try that out