UO Second Age

Derrick,
here is another way to reduce server load.

The problem as you state it is the junk in the packbacks of characters that just dont login anymore? simply stated of course. Then I think the concept of item certificate should help.

Basically you have code that detects a character who hasnt been logged in for 6 mos. You detail the contents of the back pack and replace it with a item certificate(a deed) that enumerates it. In this way a back pack of 127 items becomes 1. Do this for 50K or so characters it reduces the load.

When they log back in they go to the banker and he will convert the deed to actual items.

Also As an addendum this data that a certificate holds can stored in an external source like a db. A certificate is in game holds only one piece of data a unique record id. When the say the banker recreates the items then all the relevant data is read back into the game. Now you have the original items.

This is obviously so completely NEA I feel almost compelled to yell GO AWAY...but on reflection does that matter on this issue? If it's possible it sounds pretty neat.

I believe it would be possible to do this in a way where the player is completely unaware of it--i.e. create this item after they have been inactive for a certain period of time, and as soon as that player logs in, automatically "redeem" everything that is in the certificate (which basically amounts to deserializing all of the items under that certificate's serial number stored in an external file, just as the server deserializes stored data when the server is brought up).

I think this is actually a pretty neat idea. It would really only work for bank boxes and inventory items, though, as there would obviously be some serious issues if it extended to items stored in houses. That might be only a small fraction of the items in the world, however

Right, but items stored in houses would condemn/decay if the time period of inactivity was 6 months, right?


Win win.

I like it. I don't think the world save times are inordinate and this sounds like it might take some serious dev time and testing. In other words, I wouldn't make it a top priority. But as a rough idea, it's good.

While we're on the subject, how did OSI do it? They never had to pause the game to save it. They only saved a few times a day, but the saves seem to have caught one instant in time. Maybe that's not the case and they slowly compiled everything over the course of a few hours so that it would have minimal effect on the game? Probably not I guess, since a revert would always revert everything by the same amount of time. Do we not know how OSI did it, or is it just something we can't replicate despite knowing what it is?

Great idea, and irrelevant if it's era accurate or not as it is a server side only mechanic, nothing to do with gameplay whatsoever.

LKP wrote:While we're on the subject, how did OSI do it? They never had to pause the game to save it. They only saved a few times a day, but the saves seem to have caught one instant in time.

OSI saved world states once a day, just before "server wars".

This is probably not the right topic, but whatever. What we could do (what Derrick could do, that is) - implement completely new saving system, that would queue saving items and save them in the background to the real database (RunUO uses flat files by default if I recall correctly) that stores data in memory (for speed), e.g. Redis or MemcacheDB. While the bottleneck is not in the speed of writing, rather than in speed of serialization of items (we should throw more CPU power), this would be even more faster, but requires significantly more RAM (ECC preferably -> more $).

They definitely saved more then once every 24 hours.......

I thought server wars wars was when they brought down the server for daily maint.

rouss wrote:

LKP wrote:While we're on the subject, how did OSI do it? They never had to pause the game to save it. They only saved a few times a day, but the saves seem to have caught one instant in time.

OSI saved world states once a day, just before "server wars".

This is probably not the right topic, but whatever. What we could do (what Derrick could do, that is) - implement completely new saving system, that would queue saving items and save them in the background to the real database (RunUO uses flat files by default if I recall correctly) that stores data in memory (for speed), e.g. Redis or MemcacheDB. While the bottleneck is not in the speed of writing, rather than in speed of serialization of items (we should throw more CPU power), this would be even more faster, but requires significantly more RAM (ECC preferably -> more $).

Actually, the idea were considering is using a journaling system much in the way that modern filesystems and InnoDB operate by allowing you to queue write transactions while keeping active memory current. In theory, you would never need to /experience/ another save. The need for maintenence (server wars) would also be negated.

Braden wrote: Actually, the idea were considering is using a journaling system much in the way that modern filesystems and InnoDB operate by allowing you to queue write transactions while keeping active memory current. In theory, you would never need to /experience/ another save. The need for maintenence (server wars) would also be negated.

That's what these DBs provide by default, generally speaking. I don't imagine the volume of work (I've never touched RunUO), but saving items specifically won't be rocket science really - I assume what you'll have to do is just rewrite the code so that it queries not only RunUO's inner memory storage mechanisms, but also database (and database, in its turn, queues write transactions)

Gwartham wrote:They definitely saved more then once every 24 hours.......

This. The servers were relatively unstable back then and would crash periodically. They were also brought down for emergency maintenance and rolled back once in a while when a particularly bad bug was exploited. This happened at various times of day. The revert was usually a few hours, but never a whole day.

I hope that, whatever happens, we still have a 'last save' and some time to mess around without consequences each day. It's a good time to test out your house placements

Sorry, off topic.

Would the above certificate idea be possible/helpful?

Clever solution! Good to hear people thinking up cool ways to solve this.

I like this idea and agree that it is irrelevant if it isn't era accurate. Derrrick has to maintain the server and doesn't have the resources OSI had, so anything he can do to help should be considered. They aren't losing their items by having this implemented anyway, so I really don't see what the big deal would be.