Hello Brent, Hello Rodney,

What is the current status?

Regards
Alain

-----Message d'origine-----
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
la part de Rodney Kinney
Envoyé : mardi 6 décembre 2005 00:28
À : [EMAIL PROTECTED]
Cc : [EMAIL PROTECTED]
Objet : Re: GKC and trigger

I am pretty sure this is happening because Translate buffers up 
counters to be moved and then starts a new Thread to do the actual 
move. When the Global Key Command runs, the counter hasn't actually 
moved yet.

I am not sure what can be done about this?

That sounds right, and I don't think there is an easy fix.  The only 
idea I have is that you could make a trait that would "batch-up" 
other keyboard commands the same way that the Translate trait does.  
Then the trait order would determine which one went first.  It would 
work, but it would be pretty obscure to try to explain in the docs.

rk

-----Message d'origine-----
De : Gorodoff [mailto:[EMAIL PROTECTED]
Envoyé : lundi 5 décembre 2005 17:35
À : Brent Easton; Rodney
Objet : RE: GKC and trigger

Hello Brent, Hello Rodney,

In order to simply things, I reduced the ninja piece definition even 
more, took out the GKC and used a place marker instead
(module attached)
The ninja first move and then the marker is placed at its previous 
location: behind the new location of the ninja
Conclusion the trigger key is the one that does memorize the 
properties of the ninja at the time it is fired as Brent sayed

The funny thing is : if you take out the doesnotstack trait from the 
marker, you will see the marker "jumping" back on the ninja piece 
from its 'behind' position.
Conclusion there is a discrepancy, but there is also a way for the 
doesnotstack to retrieve the ninja and its new position/properties

Kind regards, 
Alain

-----Message d'origine-----
De : Brent Easton [mailto:[EMAIL PROTECTED]
Envoyé : lundi 5 décembre 2005 04:37
À : [EMAIL PROTECTED]
Cc : Rodney
Objet : Re: GKC and trigger

Hi Rodney,

Alain has a problem with his module (cut-down version attached). I 
think I have tracked down the problem, but not sure what can be done 
about it.

Alain is basically using a Trigger Action to 'Translate' a unit 
(ninja) forward 1 hex, then perform a Global Key Command with a range 
check that makes any Samurai counters within 1 hex visible. The 
trouble is that the Global Key command is being performed before the 
unit is moved.

I am pretty sure this is happening because Translate buffers up 
counters to be moved and then starts a new Thread to do the actual 
move. When the Global Key Command runs, the counter hasn't actually 
moved yet.

I am not sure what can be done about this?

Regards,
Brent.



*********** REPLY SEPARATOR ***********

On 4/12/2005 at 6:07 PM Gorodoff wrote:
Hello Brent,

Thanks for helping me
I join the little module, the ninja is the man that should revert 
invisibility on the two other pieces:
trap at range 0 (=trap hit) 
samourai at range 1 (=combat to start)
Regards,
Alain
____________________________________________________________
Brent Easton                       
Analyst/Programmer                               
University of Western Sydney                                   
Email: [EMAIL PROTECTED]






------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page
http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/IMSolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/vassalengine/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to