RunUO Community

This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Serialization error when moving saves

Rustedfaith

Wanderer
Serialization moving to the orb-sa svn from runuo 2.2 + neruns rev 65.7.

I started a live server as a garage project and i made it live for some friends and myself. The server picked up nicely in a month and we have a avarage of 15 players online now with 40 accounts.

Im trying to move my saves to the new orb-sa svn as everything is working that I need working on that build. The only problem is i get a serialization error and after 2 weeks now still dont know what im doing. Please could someone assist or explain to me how to do it so that a non coder can do it .... I understand the logic of the code but the rest is the problem.

Im running the orb-sa and nuruns click and play version on the following site but for the love of all things good cant get my saves over to orb.

http://code.google.com/p/runuo-nerun-distro/downloads/list

Please please could someone help im rather desperate ...
 

Lokai

Knight
You may NOT move saves from one server to another unless (basically) all files are identical, or the server to which you are moving has MORE files, but not less files, and certainly not files that have vast differences. Imagine a vending machine. Someone loads the vending machine from the back. (Like a Server saves files.) In each row they put some candy, chips, etc. Lets say the first slot they line up Snickers, Snickers, Milky Way, and Butterfinger. Since they are loading from the back, they reach all the way to the front to put the first Snickers in, then they put the second Snickers in, then the Milky Way, and last the Butterfinger closest to themselves. Now, if I am a customer (or a Server reading a file that has been saved) I HAVE to take the Snickers first, then another Snickers, then the Milky Way, and then the Butterfinger last. If I try to take the Milky Way first I get an error, because it is not at the front of the machine, so it can't come out first. Serialization is the same. All the variables from EVERY item on the Server get saved in a particular order, and written to a file. When the Server loads those files (Deserializes) it has to read them back in the exact same order they were read.
 

Rustedfaith

Wanderer
Hello Lokai

Thank you for taking some time in creatively explaining to me that it cannot be done. I mentioned that I am not a coder but stumbled into this post http://www.orbsydia.com/forum/showthread.php/117-OrbSA-Nerun-s-Distro?p=677#post677 where the guys made a script to do exacly that but unfortunately its for a previous revision and doesn't patch properly.

I also searched extensively online for some answers and got to quite a few forum posts where it was fixed although very time consuming. Im more than willing to put some elbow grease into it but are oblivious to where and what I should compare to fix it. The only problem is there is no info on explaining the process in some form.
 

tass23

Page
Rusted, you're misunderstanding what Nerun's Distro does. It's not a way to transfer saves at all. It is a world spawn generator. Nerun has been trying to update his latest release with the latest Orbs svn.

Everything Lokai said is exactly right. You're not going to be able to take the save file from Server A and load them on Server B when Server A and Server B DO NOT HAVE IDENTICAL FILES. Or, in the example Lokai was giving, he also said the server you are migrating to can have more files, but it can only have more than the duplicated files that exist from Server A.
 

fwiffo

Sorceror
Transfering saves is not hard at all, you could do that with TXT files, saving properties in TXT format and then tryparsing it at load, using system.reflection, system.IO, system and system.collection it could be done in a matter of hours.
 

Vorspire

Knight
Transfering saves is not hard at all, you could do that with TXT files, saving properties in TXT format and then tryparsing it at load, using system.reflection, system.IO, system and system.collection it could be done in a matter of hours.

Nah thatwon't work at all because you can't serialize everything to text unless you're willing to write an entirely new serialization method that outputs text and that will also mean adding support to every special custom class you want to support the text serialization, this would take months to achieve, not hours and would bloat the save files to massive proportions, this is why we don't serialize everything to XML :/

Not to mention that using Reflection for something like this would be painfully slow and resource-consuming, even on a shard with a couple thousand mobs and items. - Reflection is a very, very slow API - if you want the same effect as you can achieve with Reflection, you'd best go for IL and even then, IL is something I find very hard to wrap my head around and requires a serious developer with a keen knowledge of ASM and a lot of previous experience. The only person that I know, who is capable of messing with IL confidently, is Jeff - but he keeps getting banned of the forums FOR NO REASON.
 

fwiffo

Sorceror
you would be amused if I say you that in our case we got it done. It's not that hard to do. And also you did misunderstood why one could do that, I didn't talk about save, I didn't talk about trasferring data too, but that was the discussion (even if implicitly).
And I'm not speaking of saving, performances, etc, I'm speaking of transfering data from one server to another, for example in the case of emulator switching, in case of version switch, etc.

It would be a pain to rewrite all the serialization and deserialize of anything, this is more true in case of server change, EG: UOX->Runuo, sphere->runuo, with a more simple method you can transfer, by cross checking properties of types, what you can trasfer and what you cannot, and anyway, you only have to read what is of your interest, but reflection already do that, unless you change property names once in a week, that could be done and effortlessly.
 

Vorspire

Knight
You do realise that serialization is a concept and process, not just something that happens in RunUO's context?
 

fwiffo

Sorceror
you seem to not understand me, and I'm realizing that the causes could be two:
a) we speak different languages even if I write in english
b) you try to do your best to not understand me

I am not speaking of serialization, I am speaking of a way, slow (in the term of performance yes, but who cares? you do trasfer from one server to another ONE TIME, not a dozen of times!), but more easy to some extent, to move something from one emu to another (or even from one server to another) without having to redo all the checks, you transfer settings on items, objects like gold, skills, guilds, weapons, etc, are really easy to transfer with the way I'm talking about, mantaining what could be mantained and loosing something (but not all of) of the content (but that is true only if you don't put inside what is needed in the new item).

If you want to continue your serialization discussion, continue, I think I'm done.

PS: maybe you got it wrong, all the things I speaking about are done in a blank server, no items, no mobiles, nothing, you load your save in old server, save in the file with the method I described (and you export everying with settings included, it could take an hour, who cares, in this example I've taken the save and I'm working offline in local), the with the import method you do exactly the same on the target server. Everything is saved, except new skills, new item properties, that would not be modified and would be leaved with "null", empty, zeroed or default value.
 

Vorspire

Knight
You try your best to not understand me.

If you have to save ANY property of ANY item in ANY way, to text, xml, binary or any other format, you are SERIALIZING the property.
There is no two-ways about it.

Yes, it's easy to use reflection, but reflection, when serializing the properties to text format is insane.

Can't be more clear.

en.wikipedia.org/wiki/Serialization said:
In computer science, in the context of data storage and transmission, serialization is the process of converting a data structure orobject state into a format that can be stored (for example, in a file or memory buffer, or transmitted across a network connection link) and "resurrected" later in the same or another computer environment.[1] When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. For many complex objects, such as those that make extensive use of references, this process is not straightforward. Serialization of object-oriented objects does not include any of their associated methods with which they were previously inextricably linked.
This process of serializing an object is also called deflating or marshalling an object.[2] The opposite operation, extracting a data structure from a series of bytes, is deserialization (which is also called inflating or unmarshalling).

So tell me, what are you doing again when you're transferring your data via text format?
 

fwiffo

Sorceror
ok, got it. phef

Yes, it's insane, but we had to do it that way to import from another emu, since it was the only way to do it.
 

Rustedfaith

Wanderer
Hi Guy's

Thanks fwiffo for the assistance. I went the route of transferring everything manually in the end it was a solid 6 days of work to respawn all the player items etc ...

:)
 

Eric T. Benoit

Wanderer
ok, got it. phef

Yes, it's insane, but we had to do it that way to import from another emu, since it was the only way to do it.


I know this is old now but wouldn't it be easier to simply write a small executable that would deserialize the save files using the methods from ServerA and then does a new save using the serialize methods from ServerB, thus converting your save files? I seem to remember doing this with a MUD a long time ago when we changed the way saves were done, we simply loaded the old save and wrote the new one with an external program we wrote to do just that. Then we started up the MUD again with the new save format and that was it. Had a total downtime of about 10 minutes I think.
 
Top