//Save
mob/proc
Save()
var/savefile/S = new("[savepath]/[src.key].sav")
S["Macros"] << macro
//The Macro Var is defined like this.
mob/var/macro[10]
//Macro is set like this.
MouseDrop(obj/Keys/K)
var/I = K.Slot
usr.macro[I] = null
usr.macro[I] = src
var/L[0]
L += image(icon = src.icon, icon_state = "[src.icon_state]")
K.overlays = L
//Macro is used like this.
macro1()
for(var/obj/Skills/S in usr.Skills)
if(usr.macro[1] == S)
usr.SkillActivate(S)
ID:2143793
Sep 5 2016, 8:54 am
|
|
Code:
|
In response to Dragonpearl123
|
|
Dragonpearl123 wrote:
It looks like MouseDrop and your macros aren't nested in the wright place. > client |
Oh its a verb in that case, make a new list and add your verbs to that list and save it using Write and Read methods.
Verbs don't automatically safe and its unsafe to save verbs directly. |
Hes saving objects/mobs. I've had a similar issue with saving objects in an associative list/array in a savefile path. I wasn't able to conquer the problem. I think theres some limitation to storing information in a savefile path that you're coming across. I would either create a separate savefile or save the object types and recreate them when its loaded. I would recode how that system works tho, you saving mobs which is something you want to avoid if you can.
|
Unknown Detective Inc. wrote:
//Save Don't use key; use ckey. The key may (although these days is unlikely to) include characters that you don't want in the name. The ckey on the other hand removes almost everything that isn't alphanumeric. //The Macro Var is defined like this. Nope. That creates a list for every single mob in the world, using a hidden init proc. Chances are not every mob needs that. Instead, define it as mob/var/list/macro, and then create the list only when you need it. //Macro is set like this. Setting usr.macro[I] to null before setting it to src doesn't make any sense. Lose the null line. This is also the place where you would want to create the macro list if it doesn't already exist. E.g., if(!usr.macro) usr.macro = new/list(10) //Macro is used like this. Is macro1() a proc or a verb? If it's a proc, then you should not be using usr in it. Same with the other macro verbs or procs. Looping through the player's skills is silly. In fact doing this with multiple verbs is a bad idea. Let's look at this in proc form, with a single proc that handles all macros: // corrected code; this is called as a proc, so no usr! As to the saving thing, I'm not seeing any particular issues with saving, other than the filename being based on key instead of ckey which is not so good. What's the actual problem you're having with the saving? |
Try