> >> I'd like to get in texttags/improved textslices in. And to make actual > >> use of those new features in textboxes SAY will have to be replaced. > >> Replacing SAY itself isn't much work, since you've already abstracted > >> to Load/SaveTextBox, but of course I immediately wondered what other > >> changes to textboxes could be snuck in at the same time, like more > >> than 2 choices for choice boxes. Well, more choices should be just as > >> easy to add later. However, I was wondering about reorganising the > >> conditionals. What if you could add more conditionals as you pleased, > >> so you could set an arbitrary number of tags, each with a different > >> tag condition? I saw someone request this; previous to that I was > >> worried about messing with what I consider the best menu in Custom. > > > > That stuff does sound cool, but none of it is must-have for zenzizenzic, > > we can always add such things incrementally. I think incrementalism is > > why the nightly builds are usually in such good shape anyway :) > > OK, we can add the ability for freeform conditional adding later, but > structure the file format it support it now. > > Actually I just realised (after writing the rest of this email) that > this would still mean implementing nearly everything except the > conditionals menu UI. Well, either we can do it all for Z after all, > or use an intermediate inflexible file format for coditionals that > closely mirrors SAY's. > > I'll see how I go.
I'll keep the text box conditional menu in mind when I am working on the editor editor. > > One thing to be aware of if we reorganize conditionals, is that we have > > to separate when a conditional is evaluated: > > > > * Before instead-chaining? > > > * Before display? > > * Immediately after display? > > What's the difference between these two? Wouldn't "immediately after" > mean one tick after the textbox appears? Or do you mean "after the > textbox has finished displaying"? Maybe no meaningful difference... just for something modal like calling up a shop it would make a difference whether or not the text box gets painted underneath the shop. > > * At box advancement? > > > Alternatively instead chaining could be done with a category of > conditionals just like the others, but evaluation of the box stopping > if any match. Order of evaluation of conditionals matters and should > be explicit. Maybe I am just too sleepy right now, but I am having a hard time parsing this idea... > Initial idea of file format: > > * textbox > * ... > * conditionals > * before > * zero or more "conditional" nodes checked in order, 'textbox' not > allowed > * instead > * zero or more "conditional" nodes checked in order, evaluation > stopping if any match > * atdisplay > * zero or more "conditional" nodes checked in order, 'textbox' not > allowed > * after > * zero or more "conditional" nodes checked in order, matching > 'textbox' nodes after the first ignored I think I follow that, and I think I like it :) > Types of conditional nodes: > * add_hero ... > * rem_hero .. > * textbox ... > * script ... > * etc. > > Also, each conditional node can have zero or more of the following > node types as children (which must all evaluate to true): > * tagcheck - int: a tag number, positive for on, negative for off > (or however we store them) > * moneycheck - int: check player has at least this much money > * itemcheck - int: check player has one or more items > * amount - int [optional] That is good too. I like that. > >> Some time in December I plan to buckle down and focus on the new > >> script interpreter, and hope to get that done in the next few months. > > > > Cool. That will be great. > > But should we do a stable release right before that? The script > > interpreter is a pretty big change. > > No need to worry about that: I am probably not going to check anything > in for a long time. I am planning to develop the interpreter in its > own git repository (haven't touched in a long time; it's still in svn) > since it's a standalone library which I'll be working on separately. > Once we're using it, I'll copy new versions to svn as needed, I think. > Probably worth copying individual commits outside of large feature > branches too. Groovy. > >> Incidentally, any progress on the editor editor interpreter? I put off > >> the zone menu until I could author it in style. I sense a great > >> scarcity of your free time; I should perhaps just code it the old > >> fashioned way. > > > > Yeah, I have a big project at work due february, which I will probably > > have to work some overtime to finish, and I am moving, and trying to > > find new homes for my pets, and etc. Real live intrudes on fun > > programming :) > > Very busy. More fun for me! Lucky :) --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
