Create account / Log in

question about delete and order

Discussion area for the development team.

Moderators: Tim M, uckelman

question about delete and order

Postby fil512 » July 28th, 2010, 4:10 am

I've narrowed the TTA wonder bug down to an interaction between Delete and a TriggerAction.

If I remove the Delete, then the TriggerAction fires. But with the Delete in, the TriggerAction does not fire. Interestingly, if I add a ReportAction beside the TriggerAction that triggers on the same key, then the ReportAction DOES fire, which surprised me.

Here are the details.

Colossus Card includes AgeACivil prototype
AgeACivil prototype includes PickCard prototype

PickCard ctrl-A TriggerAction issues Ctrl BACKQUOTE
Colossus CTRL BACKQUOTE is the input key for a Delete on that card
BUT
AgeACivil ctrl-A TriggerAction is supposed to issue a alt-semicolon
But that triggeraction never happens.

If I remove the Delete trait, then the AgeACivil ctrl-a TriggerAction DOES happen.

Which makes me suspect that the Delete is happening before the AgeACivil ctrl-a TriggerAction, and so, since the card no longer
exists, the TriggerAction can't happen.

I've tried changing the order--moving Delete to top or bottom, but it makes no difference.

Any suggestions?

Thanks!
Ken
fil512
 
Posts: 160
Joined: June 27th, 2010, 5:10 pm
Location: Toronto

Re: question about delete and order

Postby tmccarron » July 28th, 2010, 11:36 am

Hmmm..yes. What you suspect is the logical reason. Changing the order in this case will not make a difference. The routine is flawed. It needs a controlling DP interacting with the routine to let it know what it should do - if true goto trigger, if false goto delete. To do this you will have to nest the existing routine with another Trigger/DP check and set routine
I'm doing something Vassal related all the time
User avatar
tmccarron
 
Posts: 19
Joined: July 17th, 2010, 12:36 pm

Re: question about delete and order

Postby fil512 » July 28th, 2010, 1:09 pm

Thanks for the quick reply. By DP I assume you mean Dynamic Property? Do I really need to create a new DP for this? That seems convoluted.

What determines the order between a Delete and a TriggerAction on the same object (possibly in different prototypes)? I am seeing a ReportAction and GlobalKeyCommand both occurring before the Delete, but the Trigger Action after the Delete. What determines the order that traits fire?
fil512
 
Posts: 160
Joined: June 27th, 2010, 5:10 pm
Location: Toronto

Re: [messages] [Developers] Re: question about delete and or

Postby tmccarron » July 28th, 2010, 1:41 pm

yes DP = dynamic property

Certain traits�do not obey stacking trait order so their location within the
piece/prototype is irrelevant - this may be one of those cases and why I bring
up the DP need to bring order to the chaos :)

In general as you look at the piece tree execution runs from bottom up as you
look at it.

i.e

Basic Piece

(Prototype A): Delete

(Prototype A): Marker

Trigger 1

(Prototype B): Rotate

(Prototype B): Layer

Report

GKC

Trigger 2

In this example Trigger 2 affects everything�where as Trigger 1 should only
affect the Delete and Marker trait.


You can try and fix your stack order according to this general rule but I don't
think it's going to matter though


________________________________
From: fil512
To: messages@vassalengine.org
Sent: Wed, July 28, 2010 8:09:56 AM
Subject: [messages] [Developers] Re: question about delete and order

Thanks for the quick reply.� By DP I assume you mean Dynamic Property? Do I
really need to create a new DP for this?� That seems convoluted.

What determines the order between a Delete and a TriggerAction on the
same object (possibly in different prototypes)?� I am seeing a
ReportAction and GlobalKeyCommand both occurring before the Delete, but
the Trigger Action after the Delete.� What determines the order that
traits fire?

_______________________________________________
Read this topic online here:
viewtopic.php?p=18919#p18919
I'm doing something Vassal related all the time
User avatar
tmccarron
 
Posts: 19
Joined: July 17th, 2010, 12:36 pm

Re: question about delete and order

Postby fil512 » July 28th, 2010, 5:47 pm

Thanks tm. It sounds like you don't know the answer to my question. Is there anyone else who lurks in these forums that knows the answer? Once again, my question is as follows.

What determines the order between a Delete and a TriggerAction on the same object (possibly in different prototypes)? I am seeing a ReportAction and GlobalKeyCommand both occurring before the Delete, but the Trigger Action after the Delete. What determines the order that traits fire?

Is there a list I can consult that shows the order? Is it determined by depth (i.e. would a chain of 3 triggers fire before a chain of 4 triggers)? Is it determined by type (as seems to be the case illustrated above)? How can I determine the order? I don't want to just code *a* solution that works and leaves a big mess for the next guy. I want to code the "proper" solution.

Thanks!
Ken
fil512
 
Posts: 160
Joined: June 27th, 2010, 5:10 pm
Location: Toronto

Re: [messages] Edit: [Developers] Re: question about delete

Postby tmccarron » July 28th, 2010, 10:07 pm

No - I did answer your question.

What determines the order between Trait A and a Trait B on the same object
is its Stacking Order

Again, trait order work bottom up, as explained here
viewtopic.php?f=6&t=178

There is no other determining factor.
BUT there are exceptions and you've come across one

Namely, Triggers do not obey stack order and Report Actions do not obey
stack order. If the key that implements them is picked up by the keylistener
- they will execute - thats just how they work

There is no list. It's just something you learn building modules

-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of fil512
Sent: Wednesday, July 28, 2010 12:49 PM
To: messages@vassalengine.org
Subject: [messages] Edit: [Developers] Re: question about delete and order

[This message has been edited.]

Thanks tm. It sounds like you don't know the answer to my question. Is
there anyone else who lurks in these forums that knows the answer? Once
again, my question is as follows.

What determines the order between a Delete and a TriggerAction on the
same object (possibly in different prototypes)? I am seeing a
ReportAction and GlobalKeyCommand both occurring before the Delete, but
the Trigger Action after the Delete. What determines the order that
traits fire?

Is there a list I can consult that shows the order? Is it determined by
depth (i.e. would a chain of 3 triggers fire before a chain of 4
triggers)? Is it determined by type (as seems to be the case
illustrated above)? How can I determine the order? I don't want to
just code *a* solution that works and leaves a big mess for the next
guy. I want to code the "proper" solution.

Thanks!
Ken

_______________________________________________
Read this topic online here:
viewtopic.php?p=18926#p18926
I'm doing something Vassal related all the time
User avatar
tmccarron
 
Posts: 19
Joined: July 17th, 2010, 12:36 pm

Re: question about delete and order

Postby fil512 » July 28th, 2010, 10:57 pm

tm,

Thanks for your patience with me. I still have much to learn about VASSAL module programming. That post you sent me was helpful. It should be a part of the "Game Piece" page in the Reference Manual. Is anyone maintaining the Reference Manual?

I guess I didn't formulate my question clearly enough and that's why you feel like it's been answered. Let me try a more precise formulation:

There are 34 different types of traits, starting with Basic Piece and ending with Set Global Property. There are four different "entry points" into a piece:
1) A player can select it by left-clicking it.
2) A player can trigger a pop-up menu of choices by right-clicking on it.
3) A player can type a keystroke that the piece is listening for.
4) The engine can fire a keystroke that the piece is listening for.

In each those four different entry points, which of the 34 traits are involved? For a particular entry point, and the traits that are involved in that entry point, in which order are the traits executed?

Not knowing the answer to these questions makes it hard to program in VASSAL. It sounds like you are recommending determining the answer to my question by trial and error, "learn by building modules". But if I take the trial and error approach, I'll probably end up coding all sorts of stuff unnecessarily, and my resulting module will be complex and difficult for maintainers to support. In order to create a nice clean module, I need to know the rules of the VASSAL programming language.

From what I've seen working with it so far, I get the sense there are two distinct pathways through a piece. If the entry point is mouse clicking (selecting), then it behaves in the way described in that post you sent me. If, however, the entry point is a keystroke, then I get the sense a completely different set of rules apply.

You mention TriggerAction and ReportAction as being exceptions, but I count at least 9 different traits that listen for keystrokes. Some of those determine whether a keystroke makes it to another trait, and in those cases order could matter (or it could be that those "Restrict" type traits apply to all other traits in the piece irrespective of order). From trial and error, so far I've determined that ReportAction and GlobalKeyAction both fire before Delete actions, but TriggerActions fire after delete actions. This suggests that there is a list. A list that determines the order in which key listening traits fire when there are multiple traits on the same piece listening for the same keystroke. I confirmed that Delete happens before TriggerAction by moving the Delete above TriggerAction and then below TriggerAction and in both cases the Delete prevented the TriggerAction. But when I removed the Delete alltogether, then the TriggerAction happened. Why did Delete take precedence over TriggerAction in this case? Why is Delete higher than TriggerAction on the list? ("The list" being the order in which key-based traits are executed when multiple traits on a single piece listen for the same key.)

I hope that this clarifies my question. I am probably making a number of mistakes in the way I formulate my question because I am still learning how VASSAL works. I look forward to further enlightenment.
fil512
 
Posts: 160
Joined: June 27th, 2010, 5:10 pm
Location: Toronto

Re: question about delete and order

Postby Tim M » July 28th, 2010, 11:43 pm

Ok I see what your getting at better.
Your 4 entry points - Im not sure what #1 is/does, a piece doesnt do anything just by left clicking it unless it is invoking an Action Button which invokes a Key command to initiate something (or do you mean dragging)

#2 is no different than #3 that is just how you interface - it is their key command that initiates the action
#4 cannot happen without some sort of initiation previously from 1-3 above - something told it to do it :) If #4 is the cause, you need to widen the scope to find out where it came from to understand the reason why

Which of the traits are involved? I've d/l and will look, this requires plain old fashion detective work to figure out what is trying to be done (Need to find the original sequence description first so I know where to start)

Programming is different from Modding - which one is it your wanting to do ?

Delete vs Trigger problem. Something to consider here. A Delete trait employs an active key command, but a Trigger trait can be employed in two different ways, active (using only the key command field) or passive (using only the listen for keystroke field).
Perhaps this may be why you are seeing the Delete occur before the Trigger if the trigger is using a passive key instead of an active key.
Tim,
Vassal Uber Geek/Guru

Problems? post your OS, Physical Mem, version of Vassal and Java plus the Module in question.
No developer can help with out that info, thx!
User avatar
Tim M
 
Posts: 1777
Joined: December 8th, 2007, 12:22 pm
Location: Earth

Re: question about delete and order

Postby fil512 » July 29th, 2010, 1:37 am

Tim,

Thanks for offering to help. I posted details to the problem on the following forum.

viewtopic.php?f=8&t=3203

Now onto your response. The reason I mentioned clicking is that it seems to me there is a concept of a "selected" piece. E.g. when you hit a keystroke, I believe that the keystroke is sent to the selected piece. I thought the way you selected a piece was by clicking on it. E.g. if you left-click on a card and then press ctrl-a, it will add THAT card to your hand. If you left-click on a different card, then the ctrl-a will apply to that card instead. There will often be logic in a prototype that fires conditionally based on attributes of a piece; the values of those attributes, I assume, is based on the left-click selection of that piece.

That is why I assumed that #2 and #3 are different. After writing that, it occurred to me that there's a #5 which is dragging the piece.

The reason I broke out #3 and #4 is it seems to me there are plenty of places in the code where there is a keystroke trigger for a key that it is assumed will be pressed by the engine and not a player (a dumb way to call a function IMO but that's a separate topic.)

On the programming vs. modding topic, I understand that supporting the VASSAL engine is different work from supporting a module. But I would call both programming, it's just that in the former you're programming in the functional programming language of Java whereas in the latter you're programming in the declarative language VASSAL. Java has a very clear instruction manual. If you want to know what order things happen in Java, it's very clearly documented. Things also happen in a specific order in the VASSAL programming language, but I've been having trouble finding the documentation that will tell me what order key listeners will execute in. But whether it's programming or modding I guess is a semantic debate.

I had a look at the code and it looks to me like the "active" and "passive" keys in a TriggerAction are treated identically.

From TriggerAction.java:
Code: Select all
  public Command myKeyEvent(KeyStroke stroke) {
    /*
     * 1. Are we interested in this key command? Is it our command key? Does it
     * match one of our watching keystrokes?
     */
    boolean seen = false;
    if (key.equals(stroke)) {
      seen = true;
    }

    for (int i = 0; i < watchKeys.length && !seen; i++) {
      if (watchKeys[i].equals(stroke)) {
        seen = true;
      }
    }
fil512
 
Posts: 160
Joined: June 27th, 2010, 5:10 pm
Location: Toronto

Re: question about delete and order

Postby fil512 » July 29th, 2010, 2:29 am

If it helps in your troubleshooting, I've uploaded the output of vassal-module-analyzer for TTA. It prints out all the traits in a human-readable, searchable format as well as lists all key senders and key listeners by key. (I wrote vassal-module-analyzer last week in order to wrap my head around this wonder problem--for more details on it, see my other posts in the forum.)
Attachments
vassal-module-analyzer.zip
(98.43 KiB) Downloaded 160 times
fil512
 
Posts: 160
Joined: June 27th, 2010, 5:10 pm
Location: Toronto

Re: [messages] [Developers] Re: question about delete and or

Postby uckelman » July 29th, 2010, 8:18 am

Thus spake fil512:
>
> Thanks for your patience with me. I still have much to learn about
> VASSAL module programming. That post you sent me was helpful. It
> should be a part of the "Game Piece" page in the Reference Manual. Is
> anyone maintaining the Reference Manual?

Last I checked, Ed Massena said the next version was nearly ready.

> Not knowing the answer to these questions makes it hard to program in
> VASSAL. It sounds like you are recommending determining the answer to
> my question by trial and error, "learn by building modules". But if I
> take the trial and error approach, I'll probably end up coding all sorts
> of stuff unnecessarily, and my resulting module will be complex and
> difficult for maintainers to support. In order to create a nice clean
> module, I need to know the rules of the VASSAL programming language.
>

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.
User avatar
uckelman
Site Admin
 
Posts: 8140
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: [messages] Edit: [Developers] Re: question about delete

Postby mkiefte » July 29th, 2010, 1:34 pm

> In each those four different entry points, which of the 34 traits are
> involved?


It doesn't matter which entry point. And almost all of them are involved
depending on the keystroke.


> For a particular entry point, and the traits that are
> involved in that entry point, in which order are the traits executed?
>

If you're looking at the list of traits in the editor, it goes from bottom
up. There are some exceptions, however. Triggers are always done last and
I believe that Reports are done last.


>
> Not knowing the answer to these questions makes it hard to program in
> VASSAL. It sounds like you are recommending determining the answer to
> my question by trial and error, "learn by building modules".


Experience is invaluable. Also looking at other people's examples.


>
> From what I've seen working with it so far, I get the sense there are
> two distinct pathways through a piece. If the entry point is mouse
> clicking (selecting), then it behaves in the way described in that post
> you sent me. If, however, the entry point is a keystroke, then I get
> the sense a completely different set of rules apply.
>

There is no difference.


>
> You mention TriggerAction and ReportAction as being exceptions, but I
> count at least 9 different traits that listen for keystrokes.


Actually, almost all of them do. Off the top of my head, I can't think of
one that doesn't.


> Some of
> those determine whether a keystroke makes it to another trait, and in
> those cases order could matter (or it could be that those "Restrict"
> type traits apply to all other traits in the piece irrespective of
> order). From trial and error, so far I've determined that ReportAction
> and GlobalKeyAction both fire before Delete actions, but TriggerActions
> fire after delete actions.


Triggers are usually fired last. All the others are triggered from the
bottommost in the list to the topmost in that order.


> This suggests that there is a list. A list
> that determines the order in which key listening traits fire when there
> are multiple traits on the same piece listening for the same keystroke. I
> confirmed that Delete happens before TriggerAction by moving the
> Delete above TriggerAction and then below TriggerAction and in both
> cases the Delete prevented the TriggerAction.


Triggers are an exception to the rule.


> But when I removed the
> Delete alltogether, then the TriggerAction happened. Why did Delete
> take precedence over TriggerAction in this case? Why is Delete higher
> than TriggerAction on the list? ("The list" being the order in which
> key-based traits are executed when multiple traits on a single piece
> listen for the same key.)
>

Trigger is last. This is because it waits for the state of the change to be
finalized before checking whether the trigger can be fired.

Hope this helps.

- M.


>
> I hope that this clarifies my question. I am probably making a number
> of mistakes in the way I formulate my question because I am still
> learning how VASSAL works. I look forward to further enlightenment.
>
> _______________________________________________
> Read this topic online here:
> viewtopic.php?p=18944#p18944
> _______________________________________________
> messages mailing list
> messages@vassalengine.org
> http://www.vassalengine.org/mailman/listinfo/messages
>
>







In each those four different entry points, which of the 34 traits are

involved? �

It doesn't matter which entry point. And almost all of them are involved depending on the keystroke.

For a particular entry point, and the traits that are

involved in that entry point, in which order are the traits executed?

If you're looking at the list of traits in the editor, it goes from bottom up.� There are some exceptions, however.� Triggers are always done last and I believe that Reports are done last.




Not knowing the answer to these questions makes it hard to program in

VASSAL. �It sounds like you are recommending determining the answer to

my question by trial and error, "learn by building modules". �

Experience is invaluable.� Also looking at other people's examples.



From what I've seen working with it so far, I get the sense there are

two distinct pathways through a piece. �If the entry point is mouse

clicking (selecting), then it behaves in the way described in that post

you sent me. �If, however, the entry point is a keystroke, then I get

the sense a completely different set of rules apply.

There is no difference.�




You mention TriggerAction and ReportAction as being exceptions, but I

count at least 9 different traits that listen for keystrokes. �

Actually, almost all of them do.� Off the top of my head, I can't think of one that doesn't.

Some of

those determine whether a keystroke makes it to another trait, and in

those cases order could matter (or it could be that those "Restrict"

type traits apply to all other traits in the piece irrespective of

order). �From trial and error, so far I've determined that ReportAction

and GlobalKeyAction both fire before Delete actions, but TriggerActions

fire after delete actions. �

Triggers are usually fired last.� All the others are triggered from the bottommost in the list to the topmost in that order.

This suggests that there is a list. �A list

that determines the order in which key listening traits fire when there

are multiple traits on the same piece listening for the same keystroke. I confirmed that Delete happens before TriggerAction by moving the

Delete above TriggerAction and then below TriggerAction and in both

cases the Delete prevented the TriggerAction. �

Triggers are an exception to the rule.

But when I removed the

Delete alltogether, then the TriggerAction happened. �Why did Delete

take precedence over TriggerAction in this case? �Why is Delete higher

than TriggerAction on the list? �("The list" being the order in which

key-based traits are executed when multiple traits on a single piece

listen for the same key.)

Trigger is last.� This is because it waits for the state of the change to be finalized before checking whether the trigger can be fired.

Hope this helps.

- M.




I hope that this clarifies my question. �I am probably making a number

of mistakes in the way I formulate my question because I am still

learning how VASSAL works. �I look forward to further enlightenment.



_______________________________________________

Read this topic online here:

viewtopic.php?p=18944#p18944

_______________________________________________

messages mailing list

messages@vassalengine.org

http://www.vassalengine.org/mailman/listinfo/messages






User avatar
mkiefte
 
Posts: 1144
Joined: January 5th, 2008, 1:29 am
Location: Halifax, Nova Scotia, Canada

Re: [messages] [Developers] Re: question about delete and or

Postby cparrott » July 29th, 2010, 3:14 pm

Maybe I'm missing what it is you are trying to accomplish with having a
delete trait and a trigger trait fire on the same keystroke, but this
behavior I would expect out the delete trait. If you delete a piece you are
telling to the module to remove it completely and make it unable to be
referenced for the rest of that session and save files. I would think delete
would take precedence over other traits just to be sure it couldn't cause
any undo issues like infinite loops on key strokes or circular references
generating errors.

Perhaps what you are looking for is an invisible piece that can act as a
proxy for the trigger actions and send the delete keystroke to the real
piece when needed.

-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of Tim M
Sent: Wednesday, July 28, 2010 7:44 PM
To: messages@vassalengine.org
Subject: [messages] [Developers] Re: question about delete and order

Ok I see what your getting at better.
Your 4 entry points - Im not sure what #1 is/does, a piece doesnt do
anything just by left clicking it unless it is invoking an Action Button
which invokes a Key command to initiate something (or do you mean
dragging)

#2 is no different than #3 that is just how you interface - it is their
key command that initiates the action
#4 cannot happen without some sort of initiation previously from 1-3
above - something told it to do it :) If #4 is the cause, you need to
widen the scope to find out where it came from to understand the reason
why

Which of the traits are involved? I've d/l and will look, this requires
plain old fashion detective work to figure out what is trying to be done
(Need to find the original sequence description first so I know where to
start)

Programming is different from Modding - which one is it your wanting to
do ?

Delete vs Trigger problem. Something to consider here. A Delete trait
employs an active key command, but a Trigger trait can be employed in
two different ways, active (using only the key command field) or passive
(using only the listen for keystroke field).
Perhaps this may be why you are seeing the Delete occur before the
Trigger if the trigger is using a passive key instead of an active key.

_______________________________________________
Read this topic online here:
viewtopic.php?p=18947#p18947
cparrott
 
Posts: 64
Joined: July 19th, 2008, 9:09 pm

Re: [messages] [Developers] Re: question about delete and or

Postby fil512 » July 29th, 2010, 4:32 pm

uckelman wrote:Thus spake fil512:
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...


I agree with you that consistency is the best route whenever possible.

However, there are probably good, practical reasons why VASSAL has made exceptions to consistent trait order execution. But if you are going to make exceptions, then you really need to write down the rules for people so we know how it works. Otherwise module designers will code via trial and error, and guesswork which will result in them feeling frustrated and it will also result in convoluted modules. I'm really happy to hear that someone is working on updating the Reference Manual. That's hard work, but the benefits to the community will be enormous.
fil512
 
Posts: 160
Joined: June 27th, 2010, 5:10 pm
Location: Toronto

Re: [messages] Edit: [Developers] Re: question about delete

Postby fil512 » July 29th, 2010, 4:47 pm

Thanks for all the help with this. Sorry that I sound like a broken record about the question of trait order execution. I feel that it's important that it be clear to module designers how it works.

mkiefte wrote:If you're looking at the list of traits in the editor, it goes from bottom
up. There are some exceptions, however. Triggers are always done last and
I believe that Reports are done last.


It sounds like you're guessing. How can I get a definitive answer to my question?

mkiefte wrote:>
> You mention TriggerAction and ReportAction as being exceptions, but I
> count at least 9 different traits that listen for keystrokes.

Actually, almost all of them do. Off the top of my head, I can't think of
one that doesn't.


Here are some traits that don't listen for keystrokes:
Action Button
Does not stack
Non-Rectangular
Area of Effect
Sub-Menu
Restrict Commands
Restricted Access
Marker

mkiefte wrote:Triggers are usually fired last. All the others are triggered from the bottommost in the list to the topmost in that order.


This sounds like another guess. Is there a forum post maybe somewhere that definitively answers the question about trait execution order?

mkiefte wrote:Triggers are an exception to the rule.

Trigger is last. This is because it waits for the state of the change to be finalized before checking whether the trigger can be fired.


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?

Not trying to be a pain in the ass, just seeking to understand,
Ken
fil512
 
Posts: 160
Joined: June 27th, 2010, 5:10 pm
Location: Toronto

Next

Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest