What is ServUO's status compared to RunUO?

xantier

Initiate
I am using RunUO 2.4, since runuo.com is dead, I am planning to transfer everything to ServUO. I am not interested in the new expansions since the server is run at UOR. What are the advantages of using ServUO? Have you ever stress tested a ServUO shard, any performance comparison?
 
I'm not sure really what expansion Runuo is now at, the developers on ServUO have been hard at work fixing bugs and updating to TOL (Time Of Legends)
 
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.
 
Norman Lancaster said:
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.
Click to expand...

What about the desync problem that most of the RunUO shards suffer from? Is it still there?
 
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:)
 
Crome969 said:
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:)
Click to expand...
deserialize of data? While I was playing on UOSA, we had to resync due to frequent desyncs during PvPs.
 
I've never seen that happen before after a save with ServUO or RunUO. It may be a shard specific issue, or very rare.
 
m309 said:
I've never seen that happen before after a save with ServUO or RunUO. It may be a shard specific issue, or very rare.
Click to expand...

True, but evidently it was common enough for them to build a "re-synch" button into Razor.
 
Very interesting. I've never really used Razor. I'm more of a decrypted client sort of guy!

Carry on! :D
 
Somehow I believe that it might be because of assistant tools like razor, uo steam. Those two tools ruin my UO experience, the game is much smoother when I log on to EA servers with plain client.
 
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.
 
Voxpire said:
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.
Click to expand...

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 :D

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.
 
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 :D
 
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.
 
RunUO has always had desync issues and still does to this day. ModernUO doesn't have this issue. I don't know about ServUO but from the looks of it, it may.
 
You must log in or register to reply here.

Active Shards

Donations

Total amount
$0.00
Goal
$1,000.00
View
Back