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. >> > * 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. >> 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 > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
