- Thread starter xantier
- Start date
ServUO's primary focus is on implementing current content, although we are a long way from it. The primary reason to use ServUO is that we are in active development. We respond to defects and provide support for modifications to the distribution. I am not entirely sure who is supporting RunUO, but they do have the odd commit now and then. I know it gets compatibility updates for VNc.
What about the desync problem that most of the RunUO shards suffer from? Is it still there?
deserialize of data? While I was playing on UOSA, we had to resync due to frequent desyncs during PvPs.desync problem? You mean deserialize of data? Thats still the same way (on most feats i think). There are ideas about a solution, just no 100% clean solution yet
True, but evidently it was common enough for them to build a "re-synch" button into Razor.
Then dont use them..
Running certain macro functions, especially movement-based ones, will cause client desync. The same is true on OSI shards.
Can you elaborate please? I would like to know more about the problem.
Record a macro that moves your character ten paces to the North. Then try to run that macro a few times. You will probably desync.
De-syncing can be controlled by the server. If the server thinks you are speed hacking (even false flags), then it will throttle the data received from the client.
This means that the movement request is dropped periodically and the movement rejection notification may not be sent to the client.
NetStates are paused and incoming data is queued during a world save, so the chances of a de-sync happening would be greater since when the NetState is un-paused, it flushes and handles all the backlogged data, which could potentially trigger throttling.
Movement acknowledge/reject packets synchronize the current movement "sequence" between the server and client and if these two numbers are not synchronized, it can cause issues.
This is most notable when using mouse movement to control High Seas boats. Currently, the mouse movement handlers do not reply to the client with regular movement acknowledge/reject requests so therefore the client de-syncs - it is much more obvious when you 'dismount' the boat then try to run around on deck, and even more-so if you're a gargoyle trying to fly.
This means that the movement request is dropped periodically and the movement rejection notification may not be sent to the client.
NetStates are paused and incoming data is queued during a world save, so the chances of a de-sync happening would be greater since when the NetState is un-paused, it flushes and handles all the backlogged data, which could potentially trigger throttling.
Movement acknowledge/reject packets synchronize the current movement "sequence" between the server and client and if these two numbers are not synchronized, it can cause issues.
This is most notable when using mouse movement to control High Seas boats. Currently, the mouse movement handlers do not reply to the client with regular movement acknowledge/reject requests so therefore the client de-syncs - it is much more obvious when you 'dismount' the boat then try to run around on deck, and even more-so if you're a gargoyle trying to fly.
Thanks for the clear explanation. So de-syncing is still a thing (and it's only related to movement)? Are there any possible solutions rather than a resync button?
Also that explains why it doesn't happen in other emulators which don't have any speedhack prevention mechanism.
Last edited:
I can't say whether it is only related to movement, but I do know that a movement request packet handler does have a throttle attached to it - not all packets get throttled.
I also can't say if it is the same context as the kind of desync that is resolved by Razor's "Resync" button, though I'm interested to find out now
Gonna look through the Razor source code, will update when I can confirm details.
Best assumption is that it does something like dump pending packets that aren't deemed critical (things like effects and damage numbers and possibly system messages) in order to catch up to the server sending so many packets.
I also can't say if it is the same context as the kind of desync that is resolved by Razor's "Resync" button, though I'm interested to find out now
Gonna look through the Razor source code, will update when I can confirm details.
Best assumption is that it does something like dump pending packets that aren't deemed critical (things like effects and damage numbers and possibly system messages) in order to catch up to the server sending so many packets.
I think desyncing is somewhat frequent on UOSA/UOR/UOLL which all use the 5.0.8.3 client. I do not think this problem happens frequently with newer clients, but I can't say for sure because I haven't used them a lot.
UOR is on RunUO 2.2, UOLL is on 2.5 and I believe (but am not certain) UOSA is on 2.1.
UOR is on RunUO 2.2, UOLL is on 2.5 and I believe (but am not certain) UOSA is on 2.1.
The RunUO versions could have a lot to do with it.
2.3 (from a specific SVN revision) and later has updated Map.cs and FastMovement.cs implementations (ServUO has these too).
Those changes vastly improved the way movement is handled, so it is very likely that older versions without these changes would cause noticeable movement lag. This doesn't explain why UOLL experiences it though, unless they opted out of the updates?
Another possibility is that I'm barking up the completely wrong tree, lol.
The older clients were still quite stable, 5.0.8 was relatively good but my client of choice quickly became 5.0.9.1 when they buried a ton of bugs to do with terrain and season issues
2.3 (from a specific SVN revision) and later has updated Map.cs and FastMovement.cs implementations (ServUO has these too).
Those changes vastly improved the way movement is handled, so it is very likely that older versions without these changes would cause noticeable movement lag. This doesn't explain why UOLL experiences it though, unless they opted out of the updates?
Another possibility is that I'm barking up the completely wrong tree, lol.
The older clients were still quite stable, 5.0.8 was relatively good but my client of choice quickly became 5.0.9.1 when they buried a ton of bugs to do with terrain and season issues
I developed UOLL from a fresh copy of 2.5, I didn't opt out of any of the updates. Desyncing definitely seems to happen a lot when PvPing on foot. I've never attempted to find out why due to how difficult it is to reproduce, some days there might be no desyncing at all and others it happens 5 times in an hour :/
The only reason I mention the client differences is that from what I'm aware, desyncing isn't a big deal on other shards and those 3 shards just happen to all use the same client.
The only reason I mention the client differences is that from what I'm aware, desyncing isn't a big deal on other shards and those 3 shards just happen to all use the same client.
No definitely not. I'm using ServUO and migrating to Net5Never heard of it. So... your first post - is an ad?