On Mon, Nov 22, 2010 at 06:37:14AM +1300, Ralph Versteegen wrote: > On 21 November 2010 20:44, James Paige <[email protected]> wrote: > >> >> 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. > > Ah, OK. But it seems overcomplicated to add an additional category > just for that. It wouldn't be too harmful to force people to use > either "first" or "atdisplay", and chain two boxes together if they > really must because of 'instead' conditions.
Yeah, it is an unnecessary extra complication with no benefit other than a trivial cosmetic effect, so we shouldn't bother. > >> > * 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... > > All explained by the "instead" node below. I understand it now :) --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
