On 18 June 2010 09:01, James Paige <[email protected]> wrote: > 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.
Looking forward to it! >> >> 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. Better split this into a new conversation, once I've put more thought into it. >> >> 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. Actually, why shouldn't we like people set NPC frame in Custom? And there's no harm in supporting xgo/ygo, but not let people set it in Custom, if it lets us merge two pieces of loading code. I'd rather use the same format in all places: for example, it'll be useful to be able load saved NPC instances in Custom to examine 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. Right, I see no point. > 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. I'm wondering whether you've done anything? I wanted to do some work on NPCs in a branch (to be merged in once .SAV is dropped); maybe I will also replace .L. >> > 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? Sounds better than just deleting NPCs which collide. > --- > James > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
