Reading objects from savefiles

ID:2171350
 
Nov 10 2016, 10:07 pm
(See the best response by Kaiochao.)
Code:
        load()
            if(!name || !path) return src
            var/savefile/s = new(path)
            s >> src
            return src


Problem description:
What exactly happens if I output an object written to a savefile to another object? I believe it calls object.Read() right?

Also, what if the saved object has a different type than the object it's being Read to? Will it just copy over variables that they both have?

Nov 10 2016, 10:35 pm
DM isn't a strictly typed language, the only thing type-casting really does is let the compiler safely access variables.

At runtime everything's basically the same when it comes down to it,

var/obj/my_obj/my_obj = locate() in loc


That simply sets my_obj to a reference to an /obj/my_obj on your loc, if one is there, when you load from a savefile all you're doing is changing the variable to reference a different object, the object the variable was pointing to still exists, it's just not being referenced by that variable anymore.

In the case of turfs and areas, they'll be replaced (as is the case of creating new turfs/areas at the same location as another) if something with the same location is loaded from a savefile.

More than one object can exist on a tile though, so if you save location data and load it, you'll just be loading that object back to where it was, existing objects on that tile won't be effected unless you tell them to be.
Nov 10 2016, 10:48 pm
Best response
When you do s >> src, you're loading an object (or some value) into the src variable. Since types don't matter, and src can be reassigned, there's no problem.

The object that used to be referenced by src is not affected (although it may be garbage-collected if src was the only reference to it, as usual).

As usual, the object that is loaded gets its variables initialized to initial values, then its New() is called, and then its Read() is called.
Nov 10 2016, 10:56 pm
In response to Kaiochao
Okay, so I don't have to worry about making sure the right object type was loaded, it will be recreated exactly as it was saved, and be referenced by src.

What happens if the object being 'replaced' is the thing calling the loading proc?

Like..

DataObject
    proc
        load()
            savefile >> src


As a rough example.
Nov 10 2016, 11:00 pm
In response to Kitsueki
If you don't return src, then you won't have a reference to the loaded object. The object it was called on is not affected.
var DataObject
    a = new
    b = a
a.load()
ASSERT(a == b)

If you do return src, then the reference to the loaded object is... returned, obviously.
var DataObject
    a = new
    b = a
    c = a.load()
ASSERT(a == b)
ASSERT(a != c)
Nov 10 2016, 11:08 pm
Okay cool, that makes sense.

    loaddataobjs()
        for(var/path in data2load)
            var/DataObject/d = new path
            var/DataObject/n = d.load()
            dataobjs += n


That's what I have been doing. I'm just having some savefile issues where data isn't being saved right or possibly isn't being loaded. Now that I know this it will be a lot easier to track down. Thanks Kaiochao!
Nov 11 2016, 9:45 am
Loading into src is, however, bad form. Better to load to . which will also automatically give you a return value.
Nov 14 2016, 12:17 am
In response to Lummox JR
Indeed. After messing around a bit I realized that, since it wont somehow update the current object to be the loaded one, there's no sense in pointing src to something else.
Nov 14 2016, 12:18 am
On a different note, does the >> operator start a new call stack at all? I'm curious if Read() and New() for the new object will return before my proc continues.
Nov 14 2016, 4:48 am
Read() and Write() are blocking calls.

New() is also a blocking call.

The only non-blocking calls that I am aware of in the language are as follows:

Enter()/Exit()/Exited()/Entered()/Crossed()/Uncrossed()/ Move()/Bump()
Nov 14 2016, 6:45 am
In response to Ter13
Ter13 wrote:
Read() and Write() are blocking calls.

New() is also a blocking call.

The only non-blocking calls that I am aware of in the language are as follows:

Enter()/Exit()/Exited()/Entered()/Crossed()/Uncrossed()/ Move()/Bump()

Those are all still blocking. They only return early if there is a sleep/spawn in them. That's the behavior of set waitfor=0.
Nov 14 2016, 10:43 am
Those are all still blocking. They only return early if there is a sleep/spawn in them. That's the behavior of set waitfor=0.

Ah, better way of phrasing it.