tbaMUD Continued development of the CircleMUD core

How difficult would it be to allow certain mobs to save the variables that are given to them via dg_scripts? Players save variables currently and if a mob is given a new flag MOB_VAR_SAVE it too should be able to save them. I would find this very helpful for player run shops, certain quests and tons of other little things. Has anyone done this?

Mobs can already save variables to themselves with global. If you want them to save to the mob over reboot there's currently no way to do that, but I can't think of anything that would be possible that way that isn't currently possible.

yes, im speaking of saving them over reboots.

what are you trying to do exactly? chances are anything you want saved to the mob would probably have a reasonable workaround via saving to the player

have you ever seen a trigger that saves a variable to the mob that is executing it? For example... I have a mob that checks you when you walk by to see if you have the high score for a trigger based "ski-ball" game on the mud. If you have the high score it lets you know and then saves your ski-ball high score and your name to variables on the mob.

so much like players.... mobs can save information to themselves as variables. But they arent saved in a file like players variables are.

I think if this were possible it would be a huge upgrade for dg scripts... honestly would open tons of doors.

There are some design issues to consider, though:
We don't really want to store all variables for all instances of all mobs - most of them are not relevant to store. Also, it could be somewhat difficult to set them back up again after a reboot, since IDs for non-players are subject to changes over reboots.

We are really talking about a new scope for variables: "prototype-scope" (as opposed to "local" in a trigger and "global" on a mob/room/object).

To make this, two things need to be written: A setter and a getter.

How about a command like "save_var <varname>" and a corresponding "%self.saved_vars(<varname>)%" getter?

I imagine the setter to simply add to/alter a (sorted tree? hashmap?-)structure in memory, which if changed will be written to disk once per game loop (or each 10 game loops? performance might be an issue here), and the getter just looking up by vnum and varname in the in-memory structure.

Come to think of it, "persist" and "persisted()" sound better.

I whipped something up. Check the front page : http://www.tbamud.com/content/saving-variables-mobsroomsobjs

here is a little script that reads 3 persisted variables. name, level and class. In line one he is supposed to spit out the name and the level. 2nd line is the class and 3rd is the level.


Puff says, 'saved name var is: Bosstone and lvl var is .' (here, not outputting 2 persisted vars in one sentence)
Puff says, 'vartree saved as Mercenary.'
Puff says, 'vardeuce is: 23'


in the first sentence puff is not outputting the variable vardeuce. he will output it on line 3 but for some reason he wont spit our 2 persisted vars in one sentence.... any ideas?




say saved name var is: %self.persisted(last-player-to-trigger-me)% and lvl var is %self.persisted(vardeuce)%.
say vartree saved as %self.persisted(vartree)%.
say vardeuce is: %self.persisted(vardeuce)%

Apparently the tree (which I regret to say I didn't write myself, so I can't debug it) doesn't like calling TREE_FIND twice in rapid succession. This is one of the things it's reasonably easy to work around though:

right on. thanks for this, it is very handy!

also seems that rooms saved vars cant be recalled... insta crash

hmm.. that'll probably need a gdb backtrace to debug