Bug 4302 - Trigger Action/Global Hotkey command order

Thxs, Brent. I know MH is too messy/convoluted to use it for debugging. I imagine this is a really nasty bug to properly fix, so take your time, of course. I just wanted to make sure you saw/acknowledged the issue with the initial fix vs MH, so that when 3.2.0 is officially released MH would still work :slight_smile:

Ok, I have finally cracked this. My previous attempt to fix this by playing with the Trigger Action code was doomed to failure. The key was to change the way the Global Key Command trait works since it was the offender, firing off hot keys that where sent immediately to the client when all other commands generated by a key stroke are batched up and executed in one go.

Global Hot Key now captures the commands generated by the Hot Key and returns them to be added to the Key Stroke command sequence.

This fix fixes the Stack Overflow problem caused by the previous fix and also fixes the operation of both the Marvel Heroes module and the little test module that displayed the problem.

Brent does this fix the stackoverflow I just submitted off of a trigger? It
does not use a GKC at all, just a straightfwd trigger

-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of Brent Easton
Sent: Saturday, August 11, 2012 6:15 PM
To: messages@vassalengine.org
Subject: Re: [messages] [Technical Support & Bugs] Bug 4302 - Trigger
Action/Global Hotkey command order

Ok, I have finally cracked this. My previous attempt to fix this by playing
with the Trigger Action code was doomed to failure. The key was to change
the way the Global Key Command trait works since it was the offender, firing
off hot keys that where sent immediately to the client when all other
commands generated by a key stroke are batched up and executed in one go.

Global Hot Key now captures the commands generated by the Hot Key and
returns them to be added to the Key Stroke command sequence.

This fix fixes the Stack Overflow problem caused by the previous fix and
also fixes the operation of both the Marvel Heroes module and the little
test module that displayed the problem.


Read this topic online here:
https://forum.vassalengine.org/t/bug-4302-trigger-action-global-hotkey-command-order/5132/22

Yes, it should fix that also.

On 12/08/2012 9:40 AM, Tim McCarron wrote:

Brent does this fix the stackoverflow I just submitted off of a trigger? It
does not use a GKC at all, just a straightfwd trigger

ā€“


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

So, in other words, GKCā€™s were the culprits then? I guess I was suspecting as much when I asked about them in this other post last week ([url]GKC: fully resolved or just initiated?]).

Unless you tested the $currentPlayer$ thing yourself already I will give the fix a full try with MH as soon as Joel publishes the updated Windows build.

In the meanwhile, thxs a lot already!

Only because of the way they where being fired off by Global Hotkey traits in counters that are in turn fired off as part of a Trigger sequence. Other module and map level components such as Global property commands may also cause a similar problem. There was no inherent problem in GKCā€™s as such.

Brent.

Thus spake barbanera:

ā€œBrent Eastonā€ wrote:

Ok, I have finally cracked this. My previous attempt to fix this by
playing with the Trigger Action code was doomed to failure. The key
was to change the way the Global Key Command trait works since it was
the offender, firing off hot keys that where sent immediately to the
client when all other commands generated by a key stroke are batched
up and executed in one go.

Global Hot Key now captures the commands generated by the Hot Key and
returns them to be added to the Key Stroke command sequence.

This fix fixes the Stack Overflow problem caused by the previous fix
and also fixes the operation of both the Marvel Heroes module and the
little test module that displayed the problem.

So, in other words, GKCā€™s were the culprits then? I guess I was
suspecting as much when I asked about them in this other post last week
(GKC: fully resolved or just initiated?).

Unless you tested the $currentPlayer$ thing yourself already I will
give the fix a full try with MH as soon as Joel publishes the updated
Windows build.

In the meanwhile, thxs a lot already!

Build uploaded, try it out.

ā€“
J.

I tried it and it all works nice. However, I must say that I only have access to the one laptop at present (traveling). Therefore, I managed to start network play via the ā€œrunasā€ command under Windows, to open the second instance of Vassal on the same computer but under a different user name. Hopefully that should not be a problemā€¦ if memory spaces are separated and not shared, that is.

Can you also publish a 3.1.20 build with the fix, please?

Thus spake barbanera:

Can you also publish a 3.1.20 build with the fix, please?

Brent, can you comment? Does it make sense to apply 8267 to 3.1?

ā€“
J.

No, the internal support for the change does not exist in 3.1.

I finally managed to try a network game with 2 different computers and I can confirm everything works. I donā€™t get the stack overflow, the currentPlayer variable is set properly on both computers and even log reports show in the proper sequence on both computers.

Thank you very much for the great work, Brent!