zerodowned

Moderator
Personally, I've set it to hourly saves and increased the number of save folders so that I end up with a day/24 hours of save records.

But going live soon, hourly doesn't sound like a good idea, I feel more comfortable with half hour or shorter. Then I worry about 1) the file size and hogging up my HD, but I've got like 300 GB free :)

2) If a problem does occur, I want to have minimal loss in terms of how long ago the last save was

3) I want to have plenty of backup saves in case what ever is causing the issue happened/started a few hours before.
 
After three saves, your backups will start to be replaced, so you don't have to worry about file size.

Also, consider the time it takes to save increases depending on how much data has changed. I think, if you save often enough, you could theoretically have such a short save time you could probably ditch the announcement of a save and have the players experience a "lag step" - some people may experience nothing if they're not moving.

I think I'm going to try and save every 90 seconds, see how it goes.
 
I've always felt safe with half hour saves.
I like half hour too

I think I'm going to try and save every 90 seconds, see how it goes.
90 seconds! :-O

I know about the three saves part. I was referring to this party in AutoSave

Code:
 private static readonly string[] m_Backups = new string[]
        {
            "Third Backup",
            "Second Backup",
            "Most Recent"
        };

If you add more saves there, it will create more backups before replacing the old ones. Might be a good idea if you're doing 90 second saves.

Good point though, the longer between saves, the longer it will take to save.
Let me know how the 90 seconds goes.
 
What Enroq said is exactly how I have been running things. I have removed the broadcast during saves and I have 20 minute save durations.

I realized a long time ago that no matter how fast your save times are, it seemed to always be a hot topic with players. No matter if they are 0.3 seconds, or 3.0 seconds, players will argue about it or complain.
Since removing, there is no discussion any more, and no one is the wiser (almost). 20 minute intervals are great, and that split second (or even up to 3 seconds on a 1.4 million item count shard) pauses not hardly noticed. And if anyone complains, you must remind them that there is nothing to be worried about. Its not just players that freeze/lag for that moment, Everything does, even the Mobs they are fighting, etc.

In the AutoSave.cs;

World.Save( false, permitBackgroundWrite ); <where false is the bool broadcast message>
 
Let me know how the 90 seconds goes.


I have run a server for world building, and even though there is only a couple/few people ever on there at a time, the entire world is melted (less dungeon area). The item count is near 1.5 million items. At 10 minute intervals, the save times are between 2.0 and 3.5 seconds.. and that is on just a decent PC with oh, dual core 2.8 GHz w/ 4 gig ram. It would be half that or better on the system I would run a game server on, no doubt.

But, the more frequent you have it save and get that hesitation, the more likely it will be that players notice it. If you really want to throw players off the scent, make the save times random times.. It wouldnt take much to add some code to have the saves fire between 20 and 35 minutes, so there is no set time frame for players to figure out. *shrugs*

I know thats not what you were referring to, I am more or less just thinking out loud while on the subject.
 
I hadn't considered removing it either but it's a good idea. #1 on my list of changes.

Random saves would be ccol too.
and good point on the save time.

i noticed there's something for "background saves". any idea what that is? sounds like it's constantly saving or something.
 
We ran a save every 20 minutes or so. When it comes to making sure people's progress get saved, we didn't want to take any chances. The highest save time we ever got up to was about 4.6 seconds so it wasn't terribly unbearable.
 
I hadn't considered removing it either but it's a good idea. #1 on my list of changes.

Random saves would be ccol too.
and good point on the save time.

i noticed there's something for "background saves". any idea what that is? sounds like it's constantly saving or something.

zero, I think the background save was an attempt to have the save stream in real time without freezing the game world that just did not actually work correctly. But its just long enough now I do not remember the details. It was something to do with that, anyways.
 
I vote moving it do a DB and then no worries on the save, but worries on setting up a DB which is also easy thanks to XAMPP.
 
I hadn't considered removing it either but it's a good idea. #1 on my list of changes.

Random saves would be ccol too.
and good point on the save time.

i noticed there's something for "background saves". any idea what that is? sounds like it's constantly saving or something.
It does require double amount of memory and some others hardware/configs requirements
It basically work this way: (for sure exists other approaches, but the general idea is this one)
1- Stop the game
2- Deep clone the ENTIRE game data in the memory
3- Resume the game
4- Write the clone data into the memory

Small servers may be able to do this without any noticeable performance decrease, but bigger servers may have difficult to do this
A good alternative would be to use a SQL based data storeage, like WoW emulator does; but can you imagine the amount of work required to translate RunUO saves into SQL and still maintain 'customizability', scripting freedom and reliability (custom variables, items, structures, etc...) ?
 
The shard Age of Valor I believe, did rewrite saves to use SQL. They released the entire shard package awhile back.
 
If I remember correctly that was done, but it was done by saving to sql with the onsave event only, not real difference except to where it was putting the saved info.
 

Active Shards

Donations

Total amount
$0.00
Goal
$1,000.00
Back