Background Saving (For those that dislike Worldsave pauses)

[Arahil]

still, you are not doing the decay and restock in the main-thread. when your thread calls SaveCycle++; the value is set within the thread....
you should do for example a timed call to a method, which does the cleanup. then it is executed in the main-thread.

i also thought over the decaying stuff again, and you should also put the lines which find the items to decay in the main-thread, since there can be again some side effects when a mobile picks up an item which is marked to decay between finding the items to decay and the decaying itself...
same for the vendors.


and another little thing:
you do not need to build a new hashtable to map the mobiles serials to the values of world.mobiles, since you never use the keys in your code. just getting a deep copy of world.mobiles.values would be enough.
same goes for all the other saving methods, you never need the serials, since you iterate through the whole collection anyway.

it would also be interesting to know how much ram is used on that server normally, since i am pretty surprised memory still increases just a few mbs for a deep copy of a world as big as yours...

 

[Bmzx007]

Ok, I get what your at now with the timed cleanup, since I moved it out of the actual save methods, it shouldnt be overly difficult.

The Serials not being used, Duely noted, I was more interested in actually getting a full copy of that array as opposed to only what was needed.

it would also be interesting to know how much ram is used on that server normally, since i am pretty surprised memory still increases just a few mbs for a deep copy of a world as big as yours...

The standard RAM size is around 160-170MB for normal usage with 1 person, It jumped to around 10MB more when I had 30 clients online. When saving it jumps to around 180-200MB then plummets back down due to the garbage collection (intentional).

I talked to Asayre8 about this, and he seems to beleive its alright, or at least to be expected. If you take the factors, it sets out about right.

 

[Kamron]

I just fear that for a shard that uses 3GB out of 4GB, this won't work. :\ What a shame.

 

[Bmzx007]

The original post actually stated it wasnt a deep copy as originally thought, So this is still a very unusable system. I can imagine when I get a Deep Copy going properly, it will double the RAM usage like expected.

Which of course, for larger shards is unusable.

 

[Alis]

At last hey allready i finished this project never thought someone else will do it thats good.

But dont listen to anyone even the devs The project whern you will finnish it will work fine only 1 problem will occure but the occurance of the problem is very very small i propose you to read my post i allready finished the non-pausable save system.And another type of save system which actually works great.

In further techniques if you improve in the modifiyng you will observe you will have to modify again you said 0.3 0.5 thats big numbers i should give you numbersthe same amount of intigers of mobiles items and clients which will have = .158795 - .298361 ms

Well your still in the begginig but good job.

Dont listen to anyone they are correct but they are deeply wrong..

The correct spot yeah its unstable

The wrong spot is no its not unstable allways except its not good for newbies only good programmers should be advised to use this modification.

5 Months ago on this thread http://www.runuo.com/forum/showthread.php?t=58934

you will see that we anlayzed all the prospects of this project..

Well my project was not only this there were two types of save conditions.

1-

No Pause archiver ;

2-

Update new movements modificitaion archiver;

I propose you to read the systems and improve your project .

PS: Im very happy that people are starting to be more usefull.

Need any help on this project just p.m.


Note ;

I would really advise that you change the methods.. it could be done better and more stable.

http://www.runuo.com/forum/showthread.php?t=58934

Only read this.

Good Luck Matey

 

[seanandre]

Umm, where exactly are you supposed to put this World.cs file? Because when I do a search in my RunUO folders for the original World.cs file, all it is able to find is CreateWorld.cs.

 

[Bmzx007]

Third line of the first post

Please note...THIS IS STILL EXPERIMENTAL AND IT IS A CORE MODIFICATION.

I do not advise using this on a live or even test shard, unless you are going to develop it further. A deep clone is required for it to work correctly.

And if you do not know the difference between a Core Modification, and a Script Release, then perhaps you shouldnt be looking in this side of the forum.

 

[DaLaw66]

Whoops, a crash!

Exception:
System.NullReferenceException: Object reference not set to an instance of an object.
   at Server.SectorEnumerator.Instantiate(Map map, Rectangle2D bounds, SectorEnumeratorType type)
   at Server.TypedEnumerator.Reset()
   at Server.TypedEnumerator.Instantiate(Map map, Rectangle2D bounds, SectorEnumeratorType type)
   at Server.Map.GetClientsInRange(Point3D p)
   at Server.Mobile.SetLocation(Point3D newLocation, Boolean isTeleport)
   at Server.Mobiles.BaseCreature.SetLocation(Point3D newLocation, Boolean isTeleport)
   at Server.Mobile.Move(Direction d)
   at Server.Mobiles.BaseCreature.Move(Direction d)
   at Server.Mobiles.IdleTimer.OnTick()
   at Server.Timer.Slice()
   at Server.Core.Main(String[] args)

^^ That happend right after the save was complete, my character in UO simply froze while saving :/

 

[Bmzx007]

Interesting result, however I do beleive that your issue is another script colliding with the saves.

In saying that, this save is still not stable, and is not a deep-copy, therefore quite useless, as there will be times where the data saved is out of sync.

I'll be re-working on this project in around 4-5 weeks time after I finish my degree off completely, stay tuned.

 

[Ohms_Law]

Interesting.
It's sure nice to see some folks testing and developing these kinds of systems. Even if nothing actually comes from it, everyone can still learn something from it.

Anyway, the reason for posting.
I haven't had an opportunity to test anything like this yet, but I've thought about it some.
from what I see you saying, you've taken an approach of modifying the just the save System itself, which is good because it's low impact on everything else. However, Have you thought about implementing an interface to add to savable objects in order to help you accomplish the task? Granted, it'll be a huge ammount of work, as pretty much every base class would need to be modified. however, I think that in the end it will be the only good solution to the problems that you've been discussing.
Now, keep in mind that I'm simply spitballing here... this is off the top of my head. I'd think that you would need something in each classes destructor method (in order to remove it from the save "database"), and an interface that each class would implement in order to serialize itself. basically the same thing as already exists... but different. humm.

anyway, keep at it. And keep us updated on how it's going! good reading.

 

[Bmzx007]

I have had more thoughts on how to get this working, and it would involve quite a large modification.

However I still have 3 weeks left of my Degree before I think of starting those things

But I do intend on working on this again after those three weeks. I am adament I want background saving of some sort

 

[Solinari555]

Regardless of whatever bugs may be occuring, it is still a good piece of base code. Many thanks.

 

[Bmzx007]

Its not bad, and possibly might work if some more effort were put into it. Personally now I'd do it a different way.

If your looking at working on it, the only issue there was, is that the 4 arrays it saves arent synchronised, if you can sync them when you save (However you'd go about that), the problem is solved.

 

[noob2]

is this a deep save or shadow save?

 

[Endicott]

Hmm, thanks ill test it out.

 

[noob2]

is this still being worked on?

 

[Bmzx007]

Not right now. It is on my list of things to do, but I have many other Core/Script related projects ahead of it for my personal server.

And to answer your question, it is still a shallow clone. It requires modification to become a deep save before it is "safe". As the shallow clone allows members to be modified during the clone (Meaning arrays will become out of sync, and members will become out of sync with eachother).

I have recently been reading about Array Synchronisation and Thread Safety, so I may revisit this, sooner if I dig up information or have the sudden urge to work on it immediately again.

(Sorry for the lack of response, this thread got burried and I stopped watching it)

P.S. Just thinking ahead as well, I'd rather wait for RunUO 2.0 before I continue work on it at all. To make sure my work is current.

 

[noob2]

yeh thats probly a good idea i'm sure its possible i know others have done it but they just didn't relaese it to the public

 

[Chrono13]

Not right now. It is on my list of things to do, but I have many other Core/Script related projects ahead of it for my personal server.

And to answer your question, it is still a shallow clone. It requires modification to become a deep save before it is "safe". As the shallow clone allows members to be modified during the clone (Meaning arrays will become out of sync, and members will become out of sync with eachother).

I have recently been reading about Array Synchronisation and Thread Safety, so I may revisit this, sooner if I dig up information or have the sudden urge to work on it immediately again.

(Sorry for the lack of response, this thread got burried and I stopped watching it)

P.S. Just thinking ahead as well, I'd rather wait for RunUO 2.0 before I continue work on it at all. To make sure my work is current.

what if during the beginning of the save, it stops the clone and saves, then it closes the process running just through the main thread until the next save? (if it already does that forgive me)

 

[noob2]

yeh that might work if i was better at C# i'd probly mess with it but i'm not quite that far along yet