Non-pausing saves?

[rwuser]

Any chance we can get non-pausing saves or something similar?

I find the constant pausing very diminishing to the experience of the game.

[Batlin]

The saves are long due to the many items on this shard. It will only get worse I'm afraid.

[TheEttinKing]

what bring back the CUB? ok

[Blaise]

If we're going to be stuck in the past, we should have annual CUB.
Heaven forbid more rares/rewards are fed into the shard bringing the value down on some items that the super-rich have plenty of anyway.

[Pirul]

Scheduled CUB's reward hoarding. Hoarding causes longer server saves. Do not reward longer server saves.

[Halbu]

People need to stop hoarding items and houses full of items, period.

And Pirul is right, which is why I hope they never have another CUB.....

[Hack Attack]

Easy/logical solution. Accept the ACTUAL model for housing secure containers/lock down items. Granted it will increase the number of sercure chests and locked down items, but it will GREATLY decrease the 5,000,000 stacks of random shit just sitting on the floor in the hundreds and hundreds of houses that exist (which coincidentally is why OSI orginally adopted this system).

[Pirul]

shit in containers = shit on the floor as far as saves go.

What would be awesome to pull off would be for the server to recognize undisturbed containers, and not save the contents of those, just leave them as they were. Unfortunately, that might open the window for exploits and nobody wants that.

[Hack Attack]

I understand that the items on the floor and item in chests require the same amount of data backup. What you are missing is that if you observe the actual game mechanics, a small house would be limited to 425 items. Anything just left laying in the house would decay within a few hours, just like if you lay it on the ground outside. This would GREATLY reduce the amount of items to save. Currently I can stack crap floor to ceiling on every floor tile, as well as have a secure chest with 125 items and 25 non-secure containers that you can place even MORE crap in. These housing rules would force people to make choices as to what kind of loot they hold onto. Do they really need 79 suits of bone armor? How many dye tubs do you actually need? Have you ever watched the show "Hoarders"? They could do a UO:Second Age edition. Since 'ERA ACCURACY' is out the window, why not place something in the game where you could recycle unwanted items (and NOT a ticket system with rare rewards). I'm thinking you could turn items back into some base resource (iron ingots, boards, leather scraps, etc), this would be some incentive not to hang onto the durable pitchfork of ruin.

[Kaivan]

It would be awesome if we could have non-pausing server saves in the same way they did on OSI servers. However, I'm not sure that the know-how exists for us to adapt RunUO to operate in that manner, and even if it did exist, this would present a major undertaking in order to successfully implement while making a smooth transition.

Beyond that, the idea of the CuB has been discussed in the past, and we have clearly stated that we will not have another CuB. This is for several reasons, at least one of which has been made clear in this thread.

Finally, regarding the lock down system for houses (this can be considered an adequate response to the other thread as well), we have chosen to utilize the pre-November 23, 1999 housing system, despite the fact that the housing system falls within our time frame. This is because Phase 2 housing (CuB was Phase 1 for anyone who is interested), and the resulting housing mechanics, were intended (for the most part) as a temporary mechanical state until January 24, 2000. Given this, we have decided not to have anything related to the housing patch.

[rwuser]

Sounds to me like the server just needs to learn to append to saves, saving fully once before the server close and then creating a different save before the server allows clients back in and just appending state changes to it by hooking onto the event system.

Appending, or manipulating; either would work I suppose. Unless of course its actually serializing directly from program object data and not intermediate structs or representations. In that case, that would require a translation system of course, creating more overhead and possibly destroying the intended script-based design of the runUO system but I can't see any other alternatives really other then going back to the era accurate one save per day (this is a recollection: is it accurate? When I played it, duplicate names wern't allowed either).

[Wonko the Sane]

Hey, if not a reward based CUB, maybe one or so days a year we can lift the 5 item autosell limit? Or have a trash barrel (again, once a year or so) that would give you the same amount of gold that you would if you had autosold things?

[xenoglyph]

Does UOSA use DynamicSaveStrategy.cs?

I think a multi-threaded approach to seamless saving wouldn't be a ton of work. Create a hashtable of item serials and last time the item was saved. Background thread gathers up items that are due to be saved, serializes to memorystream, updates hashtable with save time, and another thread is responsible for dumping that stream to disk. Add in one extra thread to check for new items that don't exist in the hashtable and keeps the hashtable updated. I could be dead wrong here, but I don't think thread safety (regarding world items) would be a huge concern...meaning I don't think that serialization at the same exact moment an item property is being modified would have strange consequences.

New hashtable would be generated at server up so it wouldn't need to be saved. Server shutdown would just kill the threads and do a standard save.

Figuring out when to end a save file would have to be considered, but that shouldn't be difficult. If there was enough memory to hold an entire save type (i.e. items) at a time, it would eliminate that problem.

[Stranger]

Or they could just save once a day at server down. Of course there is more risk, but when OSI had a crash you lost nearly a day. Personally, I do not think the saves are that intrusive. Though they do take a small amount away from a true t2a OSI feeling.

[xenoglyph]

Scratch that idea. I took a closer look at the DynamicSaveStrategy in RunUO 2.2 source, and it looks like it already supports non-pausing saves as long as you pass true for the permitBackgroundWrite parameter.

What's needed to test it out: Go to SaveStrategy.cs and change the "if (processorCount > 16)" line to something sane so that DynamicSaveStrategy will be picked. Recompile targeting .Net Framework 4.

This is very easy to add to RunUO 2.1.