per48r

Thanks heaps Josh, I’ll try that out

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=0

this 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.

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:

BDS-16847

Please close this issue:
MCPE-154397