On 12 June 2010 09:31, Bob the Hamster <[email protected]> wrote: > On Sun, May 30, 2010 at 2:51 PM, James Paige <[email protected]> wrote: >> So seeing as I will be soon working on NPC and map state saving as a NEW >> feature, (since the limited support that was already present was broken >> for 11 or 12 years and nobody noticed (and why should they? Nobody but >> me knew it was supposed to be a feature)) >> >> I digress. >> >> Suppose you release your first demo. Everybody plays it, and then saves >> their game at the end. >> >> Then a few weeks later you release your second demo, which among other >> things includes heavy revision of the NPCs on the same map where the >> previous demo ends. >> >> Everybody who continues from their old save says "the NPCs are all >> crazy! They are in the wrong place! Some of them are missing" >> >> >> How do we resolve this situation? >> >> For a while I was thinking we should have a version number of some kind >> on each map that the game author could manually incremment, which would >> invalidate old saved state for that map. >> >> So that is one option. >> >> Another option is that each NPC would have a timestamp tracking when it >> was placed/edited in the map editor. That could be compared to a >> timestamp on the save game to determine if the NPC's saved position >> should be restored. > > 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 :) But so far, specifying saving on an NPC-by-NPC basis sounds good. > * 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. > * 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. > * 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. > =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? > * 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. > * 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. > + 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 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. Consider the example with logs and villagers. (But it could all depend on how edited NPC definitions are handled.) > + edit int - counts edits of this NPC instance slot. > Can exist even if the slot is empty (but does not exist if the NPC > slot has never been used) _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
