On Fri, Jun 18, 2010 at 06:37:33AM +1200, Ralph Versteegen wrote: > On 14 June 2010 10:48, James Paige <[email protected]> wrote: > > On Sat, Jun 12, 2010 at 06:01:48PM +1200, Ralph Versteegen wrote: > >> 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) > > Currently of course, you can't edit an NPC after placing .it; you can > only remove and replace it. But soon enough you'll be able to edit an > NPC instance, such as to change the extra data and toggle saving. I'm > thinking that editing extra data shouldn't increment the edit count by > default?
Yes. I'll be adding an NPC instance detail editor that will let you change the "save" setting. I can make extra data editable there too. I can also make an option for manually marking the NPC as edited. > >> 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. > > OK, I agree changes to NPC definitions aren't going to be much of a problem. > > Semi-relatedly, I've been thinking about saving the state of running > scripts - I'd like to be able to save the state of NPC movement > scripts. A script could be resumed if it has not changed at all (and > hopefully that means restoring is alright even if the scripts it calls > have changed). If either the NPC movement script ID/trigger, the > movement script argument, or the actual scripts themselves have > changed, then the NPC would not be restored from save file. Maybe > extra data too, for safety. That makes sense. > As for restoring any other kind of script, I think that could only > possibly work if there are similar fallbacks (ie, a load-old-game > script (which is what we already have - if script state could be > restored, you wouldn't need a load game script)) Ah! Interesting! For any situation where a script's state can be saved, we also have to have a trigger appropriate for restarting that script if its saved state becomes invalidated by an edit. We are efectively designing a system that has to tolerate editing of scripts while scripts are running. > >> 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) > > I didn't mean the current L format, I asked: why use different RELOAD > formats in RSAV and for saving the state of other maps? Oh, I follow. They are basically the same. the RSAV format lacks the "save" node because we will always be respecting the "save" node from the L data the "fr" "xgo" and "ygo" nodes are not present in the L data because the editor can't set them. And now that I look at the "hidden" node in the RSAV, I am wondering if I should remove it entirely, since it is redundant and can be (and is) regenerated after loading anyway. Other than thoe differences, the formats are the same. > >> 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? > > No problem. Go ahead. Awesome. I'll do it. > > 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. > > Especially once the NPC limit is raised. I assume we are just going to > pick some new hard limit (like 2000?). A flexible limit would also be > possible I think a flexible limit will be pretty easy. That is what I will go for. > (in fact, we could even renumber NPC references when loading > a game safely, once NPC references are typed) Would renumbering them be better than leaving them alone? --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
