question about delete and order

You didn’t answer my question about whether both the watch keys and key command of trigger action are treated the same way. Earlier I posted that the code suggests they are treated the same way, but I’ve since seen other code that suggests otherwise. Do you know the answer?

I have a bunch of questions about your paragraph above. First, when you say Trigger does all the inner (higher) traits first. By higher, do you mean visibly higher on the list? Because if so, then that seems to contradict Tim’s Hello World example. Has Tim got it wrong or did you misspeak, or do I misunderstand?

But more significantly to me, what you write seems to contradict what I’m experiencing as documented in the first post in this thread, namely I experience that the order between Delete and TriggerAction doesn’t seem to matter–Delete always happens before TriggerAction.

Mike is correct, my example is backwards


From: fil512 ken.stevens@sympatico.ca
To: messages@vassalengine.org
Sent: Thu, July 29, 2010 12:47:40 PM
Subject: [messages] [Developers] Re: [Developers] Re: Edit: [Developers] Re:
quest

“mkiefte” wrote:

Are they the only exception?� Does this apply to both the watch keys
and
the key command for the trigger?� What about Report Action?� Are
they
last too?� Which is laster?

The default is to do your action first and then check for inner traits
(traits that are higher up on the list).� Trigger does all the inner
(higher) traits first and then does it’s action(s) which may fire
other
triggers which will be after that, etc.� Reports are done after the
keystroke that it’s reporting is done.� Between reports and triggers,
whichever is higher in the list will go first – i.e., it will be the
reverse of the normal procedure.

You didn’t answer my question about whether both the watch keys and key
command of trigger action are treated the same way.� Earlier I posted
that the coded suggests they are treated the same way, but I’ve since
seen other code that suggests otherwise.� Do you know the answer?

I have a bunch of questions about your paragraph above.� First, when you
say Trigger does all the inner (higher) traits first.� By higher, do you
mean visibly higher on the list?� Because if so, then that seems to
contradict Tim’s Hello World example.� Has Tim got it wrong or did you
misspeak, or do I misunderstand?

But more significantly to me, what you write seems to contradict what
I’m experiencing as documented in the first post in this thread, namely
I experience that the order between Delete and TriggerAction doesn’t
seem to matter–Delete always happens before TriggerAction.


Read this topic online here:

You didn’t answer my question about whether both the watch keys and key
command of trigger action are treated the same way. Earlier I posted
that the code suggests they are treated the same way, but I’ve since
seen other code that suggests otherwise. Do you know the answer?

They are treated the same way.

I have a bunch of questions about your paragraph above. First, when you
say Trigger does all the inner (higher) traits first. By higher, do you
mean visibly higher on the list?

Yes.

Because if so, then that seems to
contradict Tim’s Hello World example. Has Tim got it wrong or did you
misspeak, or do I misunderstand?

Don’t know. Where’s Tim’s Hello World example?

But more significantly to me, what you write seems to contradict what
I’m experiencing as documented in the first post in this thread, namely
I experience that the order between Delete and TriggerAction doesn’t
seem to matter–Delete always happens before TriggerAction.

Triggers always happen last. No contradiction. I’ve said that already.

  • M.





You didn’t answer my question about whether both the watch keys and key

command of trigger action are treated the same way. �Earlier I posted

that the code suggests they are treated the same way, but I’ve since

seen other code that suggests otherwise. �Do you know the answer?

They are treated the same way.


I have a bunch of questions about your paragraph above. �First, when you
say Trigger does all the inner (higher) traits first. �By higher, do you
mean visibly higher on the list? �

Yes.
Because if so, then that seems to

contradict Tim’s Hello World example. �Has Tim got it wrong or did you

misspeak, or do I misunderstand?


Don’t know.� Where’s Tim’s Hello World example?


But more significantly to me, what you write seems to contradict what
I'm experiencing as documented in the first post in this thread, namely
I experience that the order between Delete and TriggerAction doesn't
seem to matter--Delete always happens before TriggerAction.

Triggers always happen last.� No contradiction.� I've said that already.

- M.

I think the best strategy is to create new Traits with new names that mimic
the behaviour of old Traits but which are implemented in a more consistent
way. The old traits do not need to appear on the list, but will continue
to exist internally.

  • M.

On 29 July 2010 14:22, Tim M timothy.mccarron@sbcglobal.net wrote:

“uckelman” wrote:

The more discussions I see of the way that traits work, the more I
think
that we need to overhaul it to make it more consistent…


J.

Think we went over that once before, the problem iirc is not that it
can’t be fixed to act in a consistent way, it’s that modules might break
after if they depend on the way things work now.

Heres a simple example:

Today you might have a stack order like this -
BasicPiece
Report Action, CTRL B, output “Hello”
Trigger Action, inkey CTRL A, outkey CTRL B, CTRL C
Report Action, CTRL B, output “World”
Report Action, CTRL C, output “End of Routine”

when we execute the CTRL A we get the output in the chat window as
follows

World
Hello
End of Routine

thasts not quite right, so to fix we reverse the 2 CTRL B reports

BasicPiece
Report Action, CTRL B, output “World”
Trigger Action, inkey CTRL A, outkey CTRL B, CTRL C
Report Action, CTRL B, output “Hello”
Report Action, CTRL C, output “End of Routine”

and when we run again we now get

Hello
World
End of Routine

it works - but now if we leave it like it is and fix all traits to
respect stack order properly we would only get

World

which is breaking the way things work today and to fix properly we would
have to reorg the entire stack like so

BasicPiece
Report Action, CTRL C, output “End of Routine”
Report Action, CTRL B, output “World”
Report Action, CTRL B, output “Hello”
Trigger Action, inkey CTRL A, outkey CTRL B, CTRL C

Now ideally everything should be organized like the last example and
work that way, but unfortunately it’s not and/or doesn’t

I agree with Mike, that change could be dangerous

I think the best strategy is to create new Traits with new names that mimic the behaviour of old Traits but which are implemented in a more consistent way.�� The old traits do not need to appear on the list, but will continue to exist internally.


- M.

On 29 July 2010 14:22, Tim M <timothy.mccarron@sbcglobal.net> wrote:


"uckelman" wrote:
The more discussions I see of the way that traits work, the more I
think
that we need to overhaul it to make it more consistent...

--
J.


Think we went over that once before, the problem iirc is not that it
can't be fixed to act in a consistent way, it's that modules might break
after if they depend on the way things work now.

Heres a simple example:

Today you might have a stack order like this -
BasicPiece
Report Action, CTRL B, output "Hello"
Trigger Action, inkey CTRL A, outkey CTRL B, CTRL C
Report Action, CTRL B, output "World"
Report Action, CTRL C, output "End of Routine"

when we execute the CTRL A we get the output in the chat window as
follows

World
Hello
End of Routine

thasts not quite right, so to fix we reverse the 2 CTRL B reports

BasicPiece
Report Action, CTRL B, output "World"
Trigger Action, inkey CTRL A, outkey CTRL B, CTRL C
Report Action, CTRL B, output "Hello"
Report Action, CTRL C, output "End of Routine"

and when we run again we now get

Hello
World
End of Routine

it works - but now if we leave it like it is and fix all traits to
respect stack order properly we would only get

World

which is breaking the way things work today and to fix properly we would
have to reorg the entire stack like so

BasicPiece
Report Action, CTRL C, output "End of Routine"
Report Action, CTRL B, output "World"
Report Action, CTRL B, output "Hello"
Trigger Action, inkey CTRL A, outkey CTRL B, CTRL C

Now ideally everything should be organized like the last example and
work that way, but unfortunately it's not and/or doesn't

I agree with Mike, that change could be dangerous


For example, above you write, “I would think delete would take
precedence over other traits.” You’re making a guess when you say this.

Delete follows the same precedence rules as almost all other traits. It is
not an exception. It is perfectly possible to delete a piece before it’s
finished processing a key command.

Programming shouldn’t be about guesswork. The rules about how VASSAL
works should be clear: no guessing; so we can all just get on with the
business of building modules.

If the rules are still not clear, let me know.

Your suggestion to use an invisible piece is intriguing.

This is done in many cases where it is impossible to manipulate a property
that does not belong to a Game Piece. You can have one invisible Game Piece
that contains all such properties.

Someone
earlier suggested I use a Dynamic Property. There are probably other
ways to skin this cat too. But I want to pick the “proper” solution.

Sometimes there are several “proper” solutions. I wouldn’t get too caught
up in that idea.

And in order to do that, I need to know the rules that govern trait
order execution. Surely someone in the VASSAL community knows the
answer to that question without guessing… Anybody?

Yes. Several.

  • M.



For example, above you write, “I would think delete would take

precedence over other traits.” �You’re making a guess when you say this.

Delete follows the same precedence rules as almost all other traits.� It is not an exception.� It is perfectly possible to delete a piece before it’s finished processing a key command.


Programming shouldn’t be about guesswork. �The rules about how VASSAL

works should be clear: no guessing; so we can all just get on with the

business of building modules.

If the rules are still not clear, let me know.


Your suggestion to use an invisible piece is intriguing. �

This is done in many cases where it is impossible to manipulate a property that does not belong to a Game Piece.� You can have one invisible Game Piece that contains all such properties.
Someone
earlier suggested I use a Dynamic Property. �There are probably other
ways to skin this cat too. �But I want to pick the "proper" solution.

Sometimes there are several "proper" solutions.� I wouldn't get too caught up in that idea.

And in order to do that, I need to know the rules that govern trait
order execution. �Surely someone in the VASSAL community knows the
answer to that question without guessing... �Anybody?

Yes. Several.

- M.

What do you mean by a “Trigger does all the inner traits first”? Do you mean that if a keystroke is hit that a Trigger is listening to, then the trigger first sends that keystroke to all inner traits, then processes the keystroke itself, and then the keystroke is sent to traits below the Trigger? If that is what you mean, then that would seem to contradict the fact that triggers “always go last”. So I guess that probably means that I don’t understand what you mean by “does all the inner traits first”…

Thanks to your patience in answering my question, it is getting clearer for me. I guess I still don’t have a complete answer to the question of what happens when multiple traits in the same piece are listening to the same keystroke. Let me take a crack at answering this question based on what I know so far:

Case 1) keystroke came from outside the piece.
In this case, all traits listening for the keystroke execute in order, starting with the bottom of the trait list working backwards up to the top, with the exception being trigger actions which are always executed last (in presumably the same order–i.e. bottom to top).

Case 2) keystroke came from a trait within the piece.
Case 2a) keystroke came from a trigger
In this case, all traits listening for the keystroke execute in order, starting from the one above the trigger working backwards to the top, then the trigger sends its keystrokes and those are resolved, and then all traits below the trigger are executed working backwards from the bottom up to 1 below the trigger.
Case 2b) keystroke came from another trait, not a trigger (e.g. an action button)
In this case, the traits are executed in the same order as Case 1.

Have I got it right yet?

P.S. If you reply by clicking on the little icon on the top-right corner of a post, your replies will be half the size.

Thus spake fil512:

P.S. If you reply by clicking on the little icon on the top-right
corner of a post, your replies will be half the size.

This is not Micheal’s fault. It’s due to the code I wrote for the
mailing list-forum bridge which translates quoted parts to BBCode
not being quite right yet. (I see that I must also have a character
encoding problem in there, too.)

If anyone who knows PHP wants to debug this, feel free to volunteer.


J.

What do you mean by a “Trigger does all the inner traits first”? Do you
mean that if a keystroke is hit that a Trigger is listening to, then the
trigger first sends that keystroke to all inner traits, then processes
the keystroke itself, and then the keystroke is sent to traits below the
Trigger? If that is what you mean, then that would seem to contradict
the fact that triggers “always go last”. So I guess that probably means
that I don’t understand what you mean by “does all the inner traits
first”…

I think I see where you misunderstand.

If a trigger is listening for a keystroke, it will let all the inner (i.e.,
higher) traits respond to the key first. It will then do the keystrokes
it’s asked to do afterwards. That is what I mean by triggers always go
last.

For example, a trigger is asked to respond to SHIFT-A and, in response, it
sends SHIFT-B. When it receives SHIFT-A, all the the inner traits respond
to it before the trigger does SHIFT-B.

Case 1) keystroke came from outside the piece.
In this case, all traits listening for the keystroke execute in order,
starting with the bottom of the trait list working backwards up to the
top, with the exception being trigger actions which are always executed
last (in presumably the same order–i.e. bottom to top).

Correct, except for the trigger part. Triggered keystrokes are done from
top downwards – the opposite of the usual.

Case 2) keystroke came from a trait within the piece.
Case 2a) keystroke came from a trigger
In this case, all traits listening for the keystroke execute in order,
starting from the one above the trigger working backwards to the top,

Trigger properties are activated from the top down – i.e., after all the
non-trigger traits have done their thing, the triggers then respond to the
event one at a time from the top downward. When they fire their keystrokes,
they affect the game piece in exactly the same way as if you had done it
externally.

then the trigger sends its keystrokes and those are resolved, and then
all traits below the trigger are executed working backwards from the
bottom up to 1 below the trigger.
Case 2b) keystroke came from another trait, not a trigger (e.g. an
action button)
In this case, the traits are executed in the same order as Case 1.

That sounds right.

P.S. If you reply by clicking on the little icon on the top-right

corner of a post, your replies will be half the size.

I’m not even using the forum.

  • M.





What do you mean by a “Trigger does all the inner traits first”? �Do you

mean that if a keystroke is hit that a Trigger is listening to, then the

trigger first sends that keystroke to all inner traits, then processes

the keystroke itself, and then the keystroke is sent to traits below the

Trigger? �If that is what you mean, then that would seem to contradict

the fact that triggers “always go last”. �So I guess that probably means

that I don’t understand what you mean by “does all the inner traits

first”…

I think I see where you misunderstand.

If a trigger is listening for a keystroke, it will let all the inner (i.e., higher) traits respond to the key first.� It will then do the keystrokes it’s asked to do afterwards.� That is what I mean by triggers always go last.�


For example, a trigger is asked to respond to SHIFT-A and, in response, it sends SHIFT-B.� When it receives SHIFT-A, all the the inner traits respond to it before the trigger does SHIFT-B.


Case 1) keystroke came from outside the piece.
In this case, all traits listening for the keystroke execute in order,
starting with the bottom of the trait list working backwards up to the
top, with the exception being trigger actions which are always executed
last (in presumably the same order--i.e. bottom to top).

Correct, except for the trigger part.� Triggered keystrokes are done from top downwards -- the opposite of the usual.�

Case 2) keystroke came from a trait within the piece.
Case 2a) keystroke came from a trigger
In this case, all traits listening for the keystroke execute in order,
starting from the one above the trigger working backwards to the top,

Trigger properties are activated from the top down -- i.e., after all the non-trigger traits have done their thing, the triggers then respond to the event one at a time from the top downward.� When they fire their keystrokes, they affect the game piece in exactly the same way as if you had done it externally.

then the trigger sends its keystrokes and those are resolved, and then
all traits below the trigger are executed working backwards from the
bottom up to 1 below the trigger.
Case 2b) keystroke came from another trait, not a trigger (e.g. an
action button)
In this case, the traits are executed in the same order as Case 1.

That sounds right.

P.S. �If you reply by clicking on the little icon on the top-right

corner of a post, your replies will be half the size.


I’m not even using the forum.

- M.

It seems to me that whether another trait is “inner” or “outer” to the Trigger is irrelevant to the case I’m concerned with here. If a Delete trait is below a Trigger, and both the Delete and the Trigger are listening for the SHIFT-A, then the Delete will still respond to the SHIFT-A before the Trigger. In fact, the Delete will kill the piece before the trigger can even respond to the SHIFT-A. So it doesn’t matter if the trait is inner or outer to the Trigger. It seems to me that ALL non-trigger traits, irrespective of inner or outer respond to the SHIFT-A before the Trigger does. That is, if I understand you correctly.

What do you mean by a triggered keystroke? Do you mean a keystroke sent by the engine? Does that apply to Action buttons and Global keystrokes as well? Or do you mean only keystrokes sent by Trigger Actions? If the latter, does it matter whether the Trigger Action is in the same piece or a different piece? Or does my question even make sense?

Actually that’s something I’ve been really curious about–the scope of key commands. When a trait issues a key command (e.g. trigger, action, or global key command) does that key go to ALL pieces that are listening for that key (or in the case of global key commands, does it go to ALL MATCHING pieces) -OR- does it only go to some pieces? E.g. in the case of TriggerAction does the key command only go to inner pieces? Not understanding this detail is likely the root of much of my confusion.

Thank you. This is very clear. I hope the Reference Manual guy’s listening, because this is one of those facts that needs to be in the manual. You know, if the manual were a WIKI, I would have already added this paragraph to it myself by now…

Struggling to understand.
The journey is taking longer than I expected.
Ken

It seems to me that whether another trait is “inner” or “outer” to the
Trigger is irrelevant to the case I’m concerned with here. If a Delete
trait is below a Trigger, and both the Delete and the Trigger are
listening for the SHIFT-A, then the Delete will still respond to the
SHIFT-A before the Trigger. In fact, the Delete will kill the piece
before the trigger can even respond to the SHIFT-A. So it doesn’t
matter if the trait is inner or outer to the Trigger. It seems to me
that ALL non-trigger traits, irrespective of inner or outer respond to
the SHIFT-A before the Trigger does. That is, if I understand you
correctly.

That is correct. If you want the delete to happen last, you should give it
different keystroke and put that keystroke at the end of the chain of
commands that the trigger does in response to SHIFT-A.

What do you mean by a triggered keystroke?

A keystroke that is generated by a trigger.

Do you mean a keystroke sent
by the engine? Does that apply to Action buttons and Global keystrokes
as well?

Action buttons are normal.

Or do you mean only keystrokes sent by Trigger Actions? If
the latter, does it matter whether the Trigger Action is in the same
piece or a different piece? Or does my question even make sense?

How can a trigger be in a different piece? Global Key Commands have normal
precedence, though.

Actually that’s something I’ve been really curious about–the scope of
key commands. When a trait issues a key command (e.g. trigger, action,
or global key command) does that key go to ALL pieces that are listening
for that key (or in the case of global key commands, does it go to ALL
MATCHING pieces) -OR- does it only go to some pieces?

It only goes to the piece it’s attached to.

You can highlight a whole lot of pieces and trigger them all simultaneously
by issuing the same key stroke, but the order in which the game pieces
receive the command is not defined. However, for each piece, a separate
command is generated.

Global Key Commands are different in that they are like generating a key
stroke for every piece that applies. But the order of the pieces in not
defined.

E.g. in the case
of TriggerAction does the key command only go to inner pieces?

No, triggered keystrokes are issued to the bottommost traits and they go up
the chain as normal.

Not
understanding this detail is likely the root of much of my confusion.

It’s probably not the most straightforward thing in the world. I think I
would have preferred triggers following the normal precedence. Likewise
with Report Actions. There have been times when I wish they had.

  • M.





It seems to me that whether another trait is “inner” or “outer” to the

Trigger is irrelevant to the case I’m concerned with here. �If a Delete

trait is below a Trigger, and both the Delete and the Trigger are

listening for the SHIFT-A, then the Delete will still respond to the

SHIFT-A before the Trigger. �In fact, the Delete will kill the piece

before the trigger can even respond to the SHIFT-A. �So it doesn’t

matter if the trait is inner or outer to the Trigger. �It seems to me

that ALL non-trigger traits, irrespective of inner or outer respond to

the SHIFT-A before the Trigger does. �That is, if I understand you

correctly.

That is correct.� If you want the delete to happen last, you should give it different keystroke and put that keystroke at the end of the chain of commands that the trigger does in response to SHIFT-A.






What do you mean by a triggered keystroke? �


A keystroke that is generated by a trigger.

Do you mean a keystroke sent

by the engine? �Does that apply to Action buttons and Global keystrokes

as well? �

Action buttons are normal.
Or do you mean only keystrokes sent by Trigger Actions? �If

the latter, does it matter whether the Trigger Action is in the same

piece or a different piece? �Or does my question even make sense?


How can a trigger be in a different piece?� Global Key Commands have normal precedence, though.


Actually that's something I've been really curious about--the scope of
key commands. �When a trait issues a key command (e.g. trigger, action,
or global key command) does that key go to ALL pieces that are listening
for that key (or in the case of global key commands, does it go to ALL
MATCHING pieces) -OR- does it only go to some pieces? �

It only goes to the piece it's attached to.�

You can highlight a whole lot of pieces and trigger them all simultaneously by issuing the same key stroke, but the order in which the game pieces receive the command is not defined.� However, for each piece, a separate command is generated.

Global Key Commands are different in that they are like generating a key stroke for every piece that applies. But the order of the pieces in not defined.

E.g. in the case
of TriggerAction does the key command only go to inner pieces? �

No, triggered keystrokes are issued to the bottommost traits and they go up the chain as normal.
Not
understanding this detail is likely the root of much of my confusion.

It's probably not the most straightforward thing in the world.� I think I would have preferred triggers following the normal precedence.� Likewise with Report Actions.� There have been times when I wish they had.

- M.

OK, I think I’m getting really close to getting this now. Let me see if I’ve got it right.

  1. When a keystroke enters a piece, the traits are visited in a particular order to see if they’re interested in that keystroke, and if they are interested, they execute.
  2. When a keystroke enters a piece, the behaviour is identical irrespective of the origin of that keystroke. The keystroke could have come from the player, from a global key command, from an action button, or from a trigger within the piece.
  3. The order traits are visited is as follows.
    3a. First all non-triggers are visited. This happens starting at the bottom of the list going up.
    3b. After all the non-triggers are visited, then all triggers are visited, starting at the top of the list of triggers going downwards.

If that’s all there is to it, then it’s actually pretty simple. “Inner” and “Outer” don’t even enter into the picture!

Have I got it right?

Ken

Thus spake fil512:

Thank you. This is very clear. I hope the Reference Manual guy’s
listening, because this is one of those facts that needs to be in the
manual. You know, if the manual were a WIKI, I would have already added
this paragraph to it myself by now…

We have a wiki. I begged and pleaded to get someone to help organize it,
to no avail. All of the manuals are supposed to be in the wiki. You
could help with this, if you wanted.


J.

All this is correct.

The terms inner and outer are used because that’s what it’s called in the
Java code. Inner refers to something that’s higher in the list and outer
refers to something that’s lower in the list. Outermost is the thing at the
very bottom which is first to receive the keystroke and respond to it. So
bottom to top is the same is outermost to innermost.

  1. is functionally correct below, but it’s a simplification. But yes, it’s
    correct. Just for for clarification here’s what happens in most traits:

a: receive keystroke
b: do my action if keystroke matches
c: send keystroke to piece above me

But for triggers (and ReportActions) it’s like this:

a: receive keystroke
b: send keystroke to piece above me
c: if keystroke matches, send all the keystrokes I’m asked to perform to the
outermost trait in order

If you think about it, you can see why triggers are done from top down and
everything else is done from bottom up. If you have triggers that are
activated by other triggers, it, of course, gets a little complicated.

  • M.

On 29 July 2010 23:03, fil512 ken.stevens@sympatico.ca wrote:

OK, I think I’m getting really close to getting this now. Let me see if
I’ve got it right.

  1. When a keystroke enters a piece, the traits are visited in a
    particular order to see if they’re interested in that keystroke, and if
    they are interested, they execute.
  2. When a keystroke enters a piece, the behaviour is identical
    irrespective of the origin of that keystroke. The keystroke could have
    come from the player, from a global key command, from an action button,
    or from a trigger within the piece.
  3. The order traits are visited is as follows.
    3a. First all non-triggers are visited. This happens starting at the
    bottom of the list going up.
    3b. After all the non-triggers are visited, then all triggers are
    visited, starting at the top of the list of triggers going downwards.

If that’s all there is to it, then it’s actually pretty simple. “Inner”
and “Outer” don’t even enter into the picture!

Have I got it right?

Ken

All this is correct.

The terms inner and outer are used because that’s what it’s called in the Java code.� Inner refers to something that’s higher in the list and outer refers to something that’s lower in the list.� Outermost is the thing at the very bottom which is first to receive the keystroke and respond to it.� So bottom to top is the same is outermost to innermost.


3. is functionally correct below, but it’s a simplification.� But yes, it’s correct.� Just for for clarification here’s what happens in most traits:

a: receive keystroke
b: do my action if keystroke matches

c: send keystroke to piece above me

But for triggers (and ReportActions) it’s like this:

a: receive keystroke
b: send keystroke to piece above me
c: if keystroke matches, send all the keystrokes I’m asked to perform to the outermost trait in order


If you think about it, you can see why triggers are done from top down and everything else is done from bottom up.� If you have triggers that are activated by other triggers, it, of course, gets a little complicated.


- M.

On 29 July 2010 23:03, fil512 <ken.stevens@sympatico.ca> wrote:

OK, I think I’m getting really close to getting this now. �Let me see if

I’ve got it right.


  1. When a keystroke enters a piece, the traits are visited in a

    particular order to see if they’re interested in that keystroke, and if

    they are interested, they execute.
  2. When a keystroke enters a piece, the behaviour is identical

    irrespective of the origin of that keystroke. �The keystroke could have

    come from the player, from a global key command, from an action button,

    or from a trigger within the piece.
  3. The order traits are visited is as follows.

    3a. First all non-triggers are visited. �This happens starting at the

    bottom of the list going up.

    3b. After all the non-triggers are visited, then all triggers are

    visited, starting at the top of the list of triggers going downwards.



    If that’s all there is to it, then it’s actually pretty simple. �"Inner"

    and “Outer” don’t even enter into the picture!



    Have I got it right?




    Ken

Joel, I’m not getting all the posts. I never got this response from Ken.

  • M.

P.S.: Is there a Reference Manual guy?

On 30 July 2010 06:21, Joel Uckelman uckelman@nomic.net wrote:

Thus spake fil512:

Thank you. This is very clear. I hope the Reference Manual guy’s
listening, because this is one of those facts that needs to be in the
manual. You know, if the manual were a WIKI, I would have already added
this paragraph to it myself by now…

We have a wiki. I begged and pleaded to get someone to help organize it,
to no avail. All of the manuals are supposed to be in the wiki. You
could help with this, if you wanted.


J.

Joel, I’m not getting all the posts. I never got this response from Ken.

- M.

P.S.: Is there a Reference Manual guy?

On 30 July 2010 06:21, Joel Uckelman <uckelman@nomic.net> wrote:

Thus spake fil512:
>
> Thank you. �This is very clear. �I hope the Reference Manual guy's
> listening, because this is one of those facts that needs to be in the
> manual. �You know, if the manual were a WIKI, I would have already added
> this paragraph to it myself by now...
>

We have a wiki. I begged and pleaded to get someone to help organize it,
to no avail. All of the manuals are supposed to be in the wiki. You
could help with this, if you wanted.

--
J.

Thus spake Michael Kiefte:

Joel, I’m not getting all the posts. I never got this response from Ken.

That’s disturbing. I got it, so I know it’s not a general list problem.
I’m looking into it now.

P.S.: Is there a Reference Manual guy?

Yes, Ed Massena, who worked on the User’s Guide, is also working on the
Reference Manual, but he’s doing it by himself. I’d like to get all of
the bits and pieces out into the open so that more people than just Ed
can work on them.


J.

On 30 July 2010 09:20, Joel Uckelman uckelman@nomic.net wrote:

Thus spake Michael Kiefte:

Joel, I’m not getting all the posts. I never got this response from Ken.

That’s disturbing. I got it, so I know it’s not a general list problem.
I’m looking into it now.

We experienced an e-mail outage recently. Might be related.

  • M.



On 30 July 2010 09:20, Joel Uckelman <uckelman@nomic.net> wrote:

Thus spake Michael Kiefte:

>
> Joel, I'm not getting all the posts. I never got this response from Ken.
>

That's disturbing. I got it, so I know it's not a general list problem.
I'm looking into it now.


We experienced an e-mail outage recently.� Might be related.�

- M.

Thus spake Michael Kiefte:

That’s disturbing. I got it, so I know it’s not a general list problem.
I’m looking into it now.

We experienced an e-mail outage recently. Might be related.

We delivered your message. It looks like somebody named KIL-MX-1.UCIS.dal.ca
signed for it:

Jul 29 15:29:58 one postfix/smtp[22888]: BC1513C4: to=mkiefte@dal.ca, relay=KI
L-MX-1.UCIS.dal.ca[129.173.1.129]:25, delay=1.3, delays=0.1/0.02/0.64/0.58, dsn=
2.0.0, status=sent (250 2.0.0 o6TMTvMF023529 Message accepted for delivery)

You’ll have to take it up with him. :slight_smile:


J.

Now I’m disturbed.

  • M.

On 30 July 2010 11:23, Joel Uckelman uckelman@nomic.net wrote:

Thus spake Michael Kiefte:

That’s disturbing. I got it, so I know it’s not a general list problem.
I’m looking into it now.

We experienced an e-mail outage recently. Might be related.

We delivered your message. It looks like somebody named
KIL-MX-1.UCIS.dal.ca
signed for it:

Jul 29 15:29:58 one postfix/smtp[22888]: BC1513C4: to=mkiefte@dal.ca,
relay=KI
L-MX-1.UCIS.dal.ca[129.173.1.129]:25, delay=1.3,
delays=0.1/0.02/0.64/0.58, dsn=
2.0.0, status=sent (250 2.0.0 o6TMTvMF023529 Message accepted for delivery)

You’ll have to take it up with him. :slight_smile:

Now I’m disturbed.

- M.

On 30 July 2010 11:23, Joel Uckelman <uckelman@nomic.net> wrote:

Thus spake Michael Kiefte:

> >
> > That's disturbing. I got it, so I know it's not a general list problem.
> > I'm looking into it now.
> >
> >
> We experienced an e-mail outage recently. �Might be related.
>

We delivered your message. It looks like somebody named KIL-MX-1.UCIS.dal.ca
signed for it:

Jul 29 15:29:58 one postfix/smtp[22888]: BC1513C4: to=<[mkiefte@dal.ca](mailto:mkiefte@dal.ca)>, relay=KI
L-MX-1.UCIS.dal.ca[129.173.1.129]:25, delay=1.3, delays=0.1/0.02/0.64/0.58, dsn=
2.0.0, status=sent (250 2.0.0 o6TMTvMF023529 Message accepted for delivery)

You'll have to take it up with him. :slight_smile:

I will help with getting the Reference Manual up on a Wiki. But I’m leaving for Iceland today. I’ll be back mid-August. I’ll follow up then.

Ken

Thus spake fil512:

I will help with getting the Reference Manual up on a Wiki. But I’m
leaving for Iceland today. I’ll be back mid-August. I’ll follow up
then.

Thank you! (We’d also appreciate having more dev help, especially if
you’re interested in writing tests.)

Enjoy Iceland. If you’ve never been there before, it’s worth going to the
Blue Lagoon.


J.