Saving hotkeys

ID:1778716
 
Feb 5 2015, 5:06 am
(See the best response by Turboskill.)
Sorry if I'm not showing something needed to solve this

Code:
    MouseDrop(over_object,src_location,over_location,src_control,over_control,params)
        ..()

        var/player/p = usr
        if(istype(over_object, /obj/HotbarExtend))
            var/obj/HotbarExtend/O = over_object
            if(!O.jutsu)

                O.jutsu = src
                src.screen_loc = O.screen_loc
                usr.client.screen += src

                spawn()
                    for(var/i = 1; i <= length(p.hud.hotslot); i++)
                        var/obj/HotbarExtend/check = p.hud.hotslot[i]

                        if(check == O) continue
                        if(check.jutsu == src)
                            check.jutsu = null


This is where the list is set.

            F["hotslots"] << p.hud.hotslot
            Write(F)

// ... save ^ load v

                F["hotslots"] >> p.hotslots
    
                p.hud = new(p)

                spawn()
                    for(var/obj/HotbarExtend/hotbar in client.screen)
                        
                        for(var/skill/s in p.hotslots)


Problem description:

I'm trying to use lists to store my hotkeys, when dropping the hotkey into its slot its stored in an object list attatched to the actual slots. I'm trying to use the object list to save into the mob's list when saving/loading. Just can't figure out how to get it done in the loading process.

As you can see I have nothing for the load process, that's just what I assumed would be used. I'm sure this is very simple and I'm just overthinking it, thank you for the future help!
Feb 5 2015, 11:31 am
 
mob
    Write(var/savefile/S)
        ..(S)
    Read(var/savefile/S)
        ..(S)

mob
    proc
        Load()
            if(slot)
                var/savefile/S=new("Saves/[ckey].sav")

                usr.Read(S)
                S["Hotslots"]>>p.hotslots


        Save()
            if(slot)
                var/savefile/S=new("Saves/[ckey].sav")
                
                usr.Write(S)
                S["Hotslots"]<<p.hotslots

As example not for use intented!

                    if(fexists("Saves/[ckey].sav"))
                        Load()
                        world<<"([src.key])[src.name] has logged in!"

then you do something like this to look for the save and load its content, Id say when the Players Login!
Feb 5 2015, 12:49 pm (Edited on Feb 5 2015, 1:32 pm)
The problem isnt saving and loading the list, its more loading the list and then using its contents to display the hotbar at their corresponding slots. Sorry for not being more specific!
Feb 5 2015, 6:51 pm
Bump, really can't figure this out!
Feb 6 2015, 7:50 am
I think they are actually loading, but that doesnt matter if you dont update them when you login, so you need to have a update hotslots somewhere in there that has to be in on with the login so when it checks for the saves it also updates its positions on the map.
Feb 6 2015, 3:11 pm (Edited on Feb 7 2015, 10:59 am)
Best response
well what i'd wanna know is what are you saving to your p.hotslots list? You should be saving the references to the objects themselves if you'd like them to appear as they were before logout with all functionality. For example:

mob/var/list/listOfHKeys = list() //initialise

//then in the appropriate place in your code, everytime a hotkey is created\
and added to the screen also store it inside the above list e.g:

obj/hotkeySlots
    New()
       //could have some add to screen e.t.c. stuff here
        listOfHKeys += src // store reference of obj for saving later


Now, if you have the above done, when loading from the savefile back into the list (p.hotslots in your case) you simply load each object back onto screen with their corresponding screen locations as they were before logout (or w/e it maybe be). However, since screen_loc doesn't get saved you'll need to work that out, as such, what would be good would be that the way you fix the hotslot positions onscreen initially is in a smart way, utilising some clear logic. For instance, after just having a go earlier myself, what i did was:

***Note: Now that i think about it, i might as well mention that my attempt was at an inventory system more so than a 1 row hudskills setup like it seems you're working on, however, this should still come in handy. Also not having to worry about calculations for several rows should make the logic for specifying each of your slot screen loc's somewhat easier to define by comparison.***

obj
    invBoxes
        var/global
            sPlaceX= ixSP+ 14; //ixSP => inventory Casing/outer grid's added pixel x displacement on screen\
                                         and so sPlaceX stores the offset in pixel x from that with which\
                                        to display the first slot
            sPlaceY= iySP+ 11; //ixySP => inventory Casing's added pixel y displacement on screen... "" ""(same as sPlaceX)
            num = 0; lvl = 0;
        icon = 'invBoxes.dmi'
        icon_state = "slot"
        New()
            if(++num > 1)
                if(num/6 <= 1 )
                    sPlaceX+= 37 + 7; //width of a slot(37) + padding/space to next slot(7) in pixel x
                else if(lvl!=3) //no more than 4 rows (0 -> 3)
                    num= 1; lvl++;
                    sPlaceY+= 35 + 4; //height of a slot + padding/space between slots in pixel y
                    sPlaceX=ixSP+ 14; //on new level reset pixel x displacement

                else
                    // had some debug here, since this method was more for quickness. This ,btw,\
             means that using another method not directly tied to the New() proc for the generation\
              of the slots is likely more sensible like a genInventory() proc or something.
                    return

            usr.lOfSlots+= src // just how i wrote it at the time, same thing as listOfHKeys
            screen_loc = "[ixST]:[sPlaceX],[iyST]:[sPlaceY]" //ixST => inv X Start Tile, iyST => inv Y Start Tile
            usr.client.screen += src


Long story short, by being able to logically generate the positions of the slots in this sort of fashion, upon
loading you can simply restore the slots back to their appropriate positions by applying the same logic again
e.g. using your code it might look something like:

for(var/obj/HotbarExtend/hotbar in client.screen)
    for(var/i = 0; i++ < p.hotslots.len)// want to iterate through the list while using the index for\
                                 calculations within the logic (similar to num above)
        //[tweak and insert code used in the New() proc of the slots here]... then i realise\
          that the approach changes in a small but significant way so here goes:
        var
            pX= ixSP+ 14; pY= iySP+ 11; // 14 and 11 are offsets and can be changed for your situation
        if(i == 0)
            p.hotslots[i].screen_loc = "[ixST]:[pX],[iyST]:[pY]"
            usr.client.screen += p.hotslots[i];
            break;
        else if(i % 6 != 0) // the number(6) is for how many slots in a row
            pX+= 37 + 7; // like in New()
        else
            pY+= 35 + 4; pX = ixSP + 14; // ^ ^ ^
        p.hotslots[i].screen_loc = "[ixST]:[pX],[iyST]:[pY]"
        usr.client.screen += p.hotslots[i];


Now.. i haven't tested this out myself yet (i might do after i wake up though), i just walked through it in my head and gave this as a guide, so i'm not 100% confident that this will work exactly as i intend, but hopefully with just this you can get the jist -besides with how inconsistent the indentation of the code became as i edited in here, tabs and spaces existing together, this'd likely be tedious to try and attempt to slot into your code somewhere to try and test it.

Edits: Splitting up the one big dm enclosed post into smaller, more appropriate sections/ refining the comments into proper sentences and so on.
Feb 7 2015, 9:53 am
In response to Turboskill
Couldn't I just set the coordinates of the skillcard to equal the same as the hotslot when its created, the same way I do in the MouseDrop proc? That last part of the example is what I was trying to figure out how to achieve, so thank you. I figured it had to be done by looping through the list and then setting the skillcard based on its position in the hotslot list, I just didn't know how to.
Feb 7 2015, 11:11 am
In response to GohanX1
Well, if that helped you out and you got what you were looking for from my post then thats all good.

GohanX1 wrote:
Couldn't I just set the coordinates of the skillcard to equal the same as the hotslot when its created, the same way I do in the MouseDrop proc?

If you could though, i'd like you to elaborate on what you mean here, set the coordinates like you did in mousedrop how?
Actually i'm also unsure about another aspect concerning what you're trying to accomplish, so could you maybe post a gif of what you've now succeeded in doing in game, particular including the mousedrop stuff then after loading so i can get what the intention is?

Feb 7 2015, 11:24 am
In response to Turboskill
Maybe I'm just horrible at explaining but it seems simple. The MouseDrop works fine, the jutsus set the hotslot you'd like by dropping it. When you relog, it doesn't save so the jutsus arent in your hotslot anymore. I just want it so when you set a hotslot and relog they save where they were.

Basically what I'm saying is when the character loads, their hud is set (including the hotslots). So when you load the skillcards, you could set the skillcard position to the same position as the hotslot since its location is already set.