Object Loading and Saving in Lists and Files.

ID:931971
 
Aug 15 2012, 6:14 am
Keywords: doors, loading, object, saving
(See the best response by Alathon.)
Problem description:
No code that works as of yet, I believe I'm overcomplicating my logic so I won't put anything up for public tearing. But my issue is that I'm attempting to take a group of objects already in the map.

For instance "/obj/Doors/"

Add it to a "Doors" list, hopefully this would include any variables attached, such as ID and other variables attached to it.

Then saving that list to a .sav file.

On the load procedure I wish to load the .sav file, repopulate the list with the variables and doors. Delete all existing doors on the map and then replace them with those that are in the list.

I had a quick look around and was unable to find anything in the search functions or any demo's that I could look at. But the community are the experts so I was wondering if anyone could point me in the right direction or offer a little help.

Thanks for any assistance.
Aug 15 2012, 6:20 am
Saving this would work just like saving players. Just loop through everything that has the /obj/Doors type and add its instance to the list. I'm not so sure about how lists work in savefiles, so you may end up having to have a savefile for each door. Obviously this is not a very pleasant solution so if someone knows more detail on lists and savefiles (I read somewhere that they are a bit funky), please do chip in here.

Saving and loading the savefiles will be just like normal.
Aug 15 2012, 6:53 am
May I ask why you need to save them? What are you doing to them at run time to require saving them?
Aug 15 2012, 7:03 am
The solution I'm trying to program for is to have a mass amount of ID's for each door which would have a specific key that could be stored inside of an inventory of a player with the same ID. This is the only way I can think of doing this bar saving the entire map, and with the size of the map as it is this is processing complications I don't want to work with if possible to work around it.

Obviously if there's another easier way of doing what I plan to, that's also appreciated for suggestions.
Aug 15 2012, 7:16 am
In response to Raishii
Raishii wrote:
The solution I'm trying to program for is to have a mass amount of ID's for each door which would have a specific key that could be stored inside of an inventory of a player with the same ID. This is the only way I can think of doing this bar saving the entire map, and with the size of the map as it is this is processing complications I don't want to work with if possible to work around it.

I'm not sure I really understand this. If you stop thinking about saving for a moment, and consider the play aspect, can you describe that? What are you trying to make possible?
Aug 15 2012, 7:19 am
What I'm attempting to make possible is for a key to be assigned to a door, so a key has the same ID that a door will have, this will allow for individual housing for instance.

Although as I said, I may be overcomplicating the situation but the only way I can see a door keeping its ID after a reboot or crash would be to save the variable of the ID on the door.

To elaborate both the key and door object would have an ID variable, which would be identical, only a key with the same ID as a door can open it.
Aug 15 2012, 8:16 am
In response to Raishii
Best response
Raishii wrote:
What I'm attempting to make possible is for a key to be assigned to a door, so a key has the same ID that a door will have, this will allow for individual housing for instance.

Aha. Well, that makes sense. You pretty much nailed what you need to do, though.

Give the /obj/Door's a keyID variable, and give keys an ID variable. Upon trying a key on a door, check if the keys ID matches up with the doors keyID variable.

If you're not sure how to propery define variables, check out Chapter 5 in the DM Guide :)

As to the saving, that really depends how you save things in your game. Is anything else in the game currently being saved already?
Aug 15 2012, 8:28 am (Edited on Aug 15 2012, 9:07 am)
You'll have to forgive me for this absolutely terrible looking code, very much my usual way of stabbing at the keyboard until something compilable toddles along.

This is what I currently have. I'll put comments next to the stuff I'm more or less sure doesn't work.

Code:
var/list/Doors = list()
obj/var/idcode = 0

proc/SaveDoors()
    world << "Showing it's working"
    for(var/obj/Doors/M in world)
        Doors:Add(M)
        world << M.idcode
    if(length(Doors))
        var/savefile/F = new("Doors.sav")
        F["Doors"] << Doors
    world << "Finished here"

proc/LoadDoors()
    world << "starting"
    for(var/obj/Doors/M in world)
        world << M.idcode
        del M
    if(fexists("Doors.sav"))
        var/savefile/F = new("Doors.sav")
        F["Doors"] >> Doors
    for(var/obj/M in Doors)
        world << M.idcode //Just here to test if it worked, it didn't.
        M = new M(locate(M.x, M.y, M.z)) //This stuff, I have no idea how to re-init the object into the map






obj/Doors/
    Door1
        icon = 'HMBP.dmi'
        idcode = 101
        Click()
            usr << idcode
        verb
            changeID(msg as text)
                set src in oview(10)
                idcode = msg



I'm most likely going around the situation completely wrongly. And once again apologies for the very terribly structured code.

Also thanks so far for all your time and patience with the situation.
Aug 15 2012, 8:43 am
You do realize you are loading "Bans.sav", correct?
Aug 15 2012, 8:48 am (Edited on Aug 15 2012, 9:23 am)
I hate coding. Although that still didn't really change much in the situation, it doesn't seem to save the variable. That I can tell, that and I'm also quite unsure on how to create new objects in the positions they were originally at.

---Edit---

I managed to fix it, the code its self seemed to work. I was just missing some huge logical flaws, such as the X,Y,Z not being stored. Or more being stored but its new location then being inside of a list. So I added a few variables to allow it to store and this is the skeleton code for any who may have the same issue who need to search.


var/list/Doors = list()
obj/var/idcode = 0

obj/var/cX= 0
obj/var/cY= 0
obj/var/cZ= 0

proc/SaveDoors()
    world << "Showing it's working"
    for(var/obj/Doors/M in world)
        Doors:Add(M)
        world << M.idcode
    if(length(Doors))
        var/savefile/F = new("Doors.sav")
        F["Doors"] << Doors
    world << "Finished here"

proc/LoadDoors()
    world << "starting"
    for(var/obj/Doors/M in world)
        del M
    if(fexists("Doors.sav"))
        var/savefile/F = new("Doors.sav")
        F["Doors"] >> Doors
    for(var/obj/M in Doors)
        world << M.idcode
        M.loc = locate(M.cX,M.cY,M.cZ)






obj/Doors/
    Door1
        icon = 'HMBP.dmi'
        idcode = 101
        New()
            ..()
            spawn()
                cX = src.x
                cY = src.y
                cZ = src.z
        Click()
            usr << idcode
        verb
            changeID(msg as text)
                set src in oview(10)
                idcode = msg

mob/verb/SaveDoor()
    SaveDoors()

mob/verb/LoadDoor()
    LoadDoors()


Once again, thanks all for the time and patience of me just being so stupid. Hope you all have a nice day. ^.^
Aug 15 2012, 9:54 am
Don't ever use the colon(:) operator unless you have to. A simple Doors.Add() will work just fine, no need to do Door:Add().
Aug 15 2012, 10:04 am
'Twas a compile error when I did .add due to it being a lower case a, when I looked up the syntax it was displayed as that so I didn't attempt to change it back. What are the differences in operator functions?
Aug 15 2012, 1:19 pm
In response to Raishii
Raishii wrote:
'Twas a compile error when I did .add due to it being a lower case a, when I looked up the syntax it was displayed as that so I didn't attempt to change it back. What are the differences in operator functions?

: will not do a compile-time check on whether the procedure actually exists for that datum. That means that an error that you could've caught at compile-time, automatically, may instead show up at a different time during gameplay (At runtime).

Considering that debugging things that don't work is what you'll be spending most of your time doing while programming, anything that decreases that time (By f.ex giving you an error straight-away for something unsafe), is good. Such as using the . operator instead, which will check for you at compile-time.

For example:

Compiles, but will break if a non-mob enters the turf
mob/proc/GoNuts() {}

turf/Entered(atom/A) {
    A:GoNuts();
}


Doesn't compile
mob/proc/GoNuts() {}

turf/Entered(atom/A) {
    A.GoNuts();
}


The correct way

mob/proc/GoNuts() {}

turf/Entered(atom/A) {
    if(istype(A, /mob)) {
        var/mob/M = A;
        M.GoNuts();
    }
}