On 20 November 2010 07:17, James Paige <[email protected]> wrote:
> On Sat, Nov 20, 2010 at 06:49:22AM +1300, Ralph Versteegen wrote:
>> On 20 November 2010 05:50, James Paige <[email protected]> wrote:
>> > Fenrir-Lunaris mentioned in the Heart of the OHR thread that he thought
>> > he could have a zenzizenzic-worthy update to Vikings of Midgard ready by
>> > christmas, and he wondered if zenzizenzic would bre ready by then.
>> >
>> > So we were discussing this earlier when we talked about ypsiliform+3 but
>> > I would like to reopen the discussion on what we want to include in
>> > zenzizenzic.
>> >
>> > ---
>> > James
>>
>> 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.
> 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"?
> * 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.
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
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]
>> Other than that, lots of zones features, a stab at implementing a
>> script console, and a random selection of stuff from the "medium term"
>> column of my todo list. Mystery!
>
> Oh, yes, I keep forgetting about limiting NPC movement by zone and
> adding the walking types for tracing the edge of the passable area.
I forgot about the NPC instance editor too.
>> 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.
>> 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!
> ---
> James
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
