On Sat, Jun 12, 2010 at 06:01:48PM +1200, Ralph Versteegen wrote: > On 12 June 2010 09:31, Bob the Hamster <[email protected]> wrote: > > > > I have been thinking a lot about this one. I have a plan that I am > > pretty happy with. I have written it up on the wiki, but I am going to > > reproduce it here for discussion: > > > > =Restoring NPC locations on the current map= > > > > * Add data to each NPC instance that indicates whether or not it's > > location should be saved/loaded from the RSAV file. > > * Add an edit counter to each npc instance slot > > You never mentioned what the edit counter is used for! So I'm not > going to comment on the loading scheme itself until I know what it > actually is :)
Oh, sorry I wasn't clear about that. When you change an NPC location in the editor, the edit count gets incremented. (it only really needs to happen for once per NPC instance slot per edit session) When you save NPC state, the NPC edit count gets saved too. When loading saved NPC state, the old state only get used of the edit count matches. Some scheme for ovverriding that when appropriate can be devised, but that is the heart of it. > > * Add the ability to mark an NPC instance to be saved in the NPC > > location editor. > > * Add data to the NPC definition for a default unsaved/saved setting > > * Use the default from the NPC definition when placing an NPC on the map. > > I think there should also be a default for the NPC definition default. > It could come from the map state save option. And if you toggle that > either the NPC def default or the map-global default, you could be > prompted whether you want to want to reset the save flag on all > instances of the NPC, or all NPCs, respectively. I like that. Shouldn't be too hard to do either. > > * Write the NPC location's edit count into the RSAV file. > > * Make NPCs on the current map restorable from the RSAV file > > So I assume you are not suggesting any toggle for this, but NPCs are > always restored for the current map if they are marked as such (ie. > treating the current map and other maps differently)?. Is the > intention is to allow saving the state of the current map in save > files, without having to make it save when you leave the map as well? > OK, that seems pretty logical. Yes, that is what I had in mind. :) > > * Add a plotscripting command that can retrieve an NPC's starting > > state as defined in the map editor (in cause game authors want to use > > NPC location saving normally, but override it sometimes) > > What about NPC definitions? Suppose you repurpose NPC ID 4, which was > a villager and was set to save NPC instance state, but is now a log. > Assumably you want all the old villager NPCs to disappear, and new log > NPCs to appear when you load an old save. I though about that. At first I was thinking that changes to the NPC defintion should increment the edit count for each instance too... but thinking about it more, I think that would usually be the wrong thing to do. Frequently, changes to the NPC definition are just updates, not total changes of identity, so you would not normally want to lose saved positions. In the Villager-is-now-a-Log situation, the log wouldn't stay standing in front of the item shop, would it? Nah, you would move it's instance to the firewood pile behind the blacksmith's shop. The only time that not updating the edit counter when the definition changes would be the rather rare case where an NPC's identity completely changes but their instance needs to remain at the same spot on the map. > > =Restoring NPC locations on other maps= > > > > * Update the current implementation of NPC off-map saving to use a > > RELOAD format similar to the saved NPC locations in RSAV > > Why would there be any need to use a different format at all? There are 4 used and 1 wasted int in each record of the L format. I need 6 ints. (or 5 ints and 1 bitset) > > * Add an option to the choices for NPC state saving that allows > > them to be stored in the RSAV file. > > o This will only apply to individual NPC instances that > > allow saving, just like in the current-map saving. > > * At load-time, re-create the saved NPC location files using > > behavior consistent with the curent-map saving. > > > > =File format to replace L lumps= > > > > A RELOAD document. The filename would probably be something like > > npcloc-#.reld where # is the map id. > > Aside, I just realised that if saved NPCs on a inactive map have > script objects stored in their extra data, then the interpreter would > have to keep track of that extra data. Oh, I forgot about extra data. I am going to want to save that too... WOuld it cause problems if I save the simple ints now, and we worry about more complex script objects later? > > * npcs - stores NPC locations > > o npc int - for each npc instance. value is instance slot id > > number 0-max. Nodes exist for any slot that has ever been used. > > I assume that you meant that this int is the reference number, not the > id number. Yes, when I say "instance slot id" I really should be saying "reference" number :) > > + id int - npc id number 0-max (only saved if NPC exists) > > + x int - x position in pixels (only saved if NPC exists) > > + y int - y position in pixels (only saved if NPC exists) > > + d int - direction 0-3 (only saved if NPC exists) > > + save - node exists if NPC can be saved/loaded in the > > RSAV file (only saved if NPC exists) > > Did you intend this item to be saved in RSAV? If not, then I No, the "save" node would not be saved in the save game, sinc ethta would be redundant to the node existing vs not existing. > understand what you meant by using a different file format. If yes, > and this stored flag is used instead of the saveable flag in the > actual, updated RPG file for deciding whether or not to restore an > NPC, then I don't know if I agree. No worries. The saved flag in the RPG file would take priority. One thing I had not though about until now is saving script-created NPC instances... That is something I would want to allow. What if a script creates a bunch of NPCs, which are saved... then the map is edited and some of those slots get filled, and the save is loaded... I guess the RPG file would still take priority, so this would not be a special case. Also, the fact that the map editor allocates NPCs starting from reference number 1 and the "create NPC" command allocates them starting with reference number 299 minimizes the chances of this kind of collision occuring. --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
