Bug 4302 - Trigger Action/Global Hotkey command order

Brent_Easton · July 25, 2012, 12:33am

Brent, can I ask that you look at bug 4302 next, when you have a chance? Unless somebody else is taken care of this, that is.

It is a bug related to global hotkeys not respecting order of execution (jumping the line) in network play for the remote clients. It is very painful to work around, if possible at all.

As an example (but this is a relatively painless one) suppose a trigger on your units fire an hotkey to move forward the turn counter after a moving/action is done on the piece. Then the report trait associated with the turn counter will show up first on the remote computer, which is rather confusing/ugly:

Local client: Tank fires on infantry - Turn finished
Remote client: Turn finished - Tank fires on infantry

This same example becomes much more painful if you have any extra “intelligence” in the module to change state when the turn moves on, as it will change it too soon on the remote client.

Ok, the good news is I believe I have been able to get this fixed fairly easily. This bug is related to
Bug 1948 -Single UNDO for any User action and I have used the same functionality I added for Action buttons to apply it to the Trigger Action.

My worry is, as usual, compatibility. If I fix this, how many modules will break because their owners have worked either around this bug, or are inadvertently using it to their advantage? I’m not really sure though, since the bug causes different behavior in the two clients, it has probably been worked around by completely leaving it out.

I have coded the fix so that I can add a ‘3.1 compatibility’ preference later to force a module to go back to the old behaviour.

Brent.

barbanera · July 25, 2012, 8:45am

Thxs Brent, great news.

In my case I did work around the bug (3.1.18). but I am not sure exactly how I did it anymore. For sure I remember it involved much trial and error and lots of grief. Maybe, since in my case the bug mostly showed up when moving forward the turn counter, which itself triggered a lot of state chances and setting up as appropriate, I think I exploited some “fake” extra turns/phase in between two actual turns, to give things time to get back in synch…

In the end the only visible effect of the bug remained having the inverted log reports issue I mentioned. It will be nice to see that gone away when the bug fix is officially released, and people start downloading the new engine version on a regular basis. Thanks again.

uckelman · July 25, 2012, 9:42pm

Thus spake Brent Easton:

Ok, the good news is I believe I have been able to get this fixed fairly
easily. This bug is related to
Bug 1948 -Single UNDO for any User action and I have used the same
functionality I added for Action buttons to apply it to the Trigger
Action.

My worry is, as usual, compatibility. If I fix this, how many modules
will break because their owners have worked either around this bug, or
are inadvertently using it to their advantage? I’m not really sure
though, since the bug causes different behavior in the two clients, it
has probably been worked around by completely leaving it out.

I have coded the fix so that I can add a ‘3.1 compatibility’ preference
later to force a module to go back to the old behaviour.

Merged to trunk@8224.

Please test 3.2.0-svn8224:

vassalengine.org/~uckelman/builds/

–
J.

Brent_Easton · July 31, 2012, 1:31am

Hi barbenera,

I am looking at bug 4302 but it is proving a bit difficult to track down the problem due to the complexity of the Space Empires module.

I’ve found that the problem is occurring when the After Move key Ctrl-Shft-L is being applied to the piece after it is moved. Can you give me a run-down on what the Ctrl-Shft-L does to the counter?

Thanks,
Brent.

Brent_Easton · July 31, 2012, 1:45am

It apepars to be just just reporting the unit movement, is that right? I think I can create a simpler test case if so.

BTW is there a reason you are not using the Maps inbuilt movement reporting?

B,

barbanera · July 31, 2012, 11:55am

Sorry Brent, but I don’t follow…

Are we talking bug 4302 here, the one about global hotkeys in network play jumping the queue? Why are we talking about Space Empires? Unless Seth mentioned it relative to this bug, maybe? Sorry, but I don’t know anything about that game/module. Also, not sure which practical situation Seth was referring to when he originally reported the bug.

My own problems with this bug appear in various circumstances in my own module Marvel Heroes and they do not concern simple unit movement reporting. Unfortunately, my module is rather complex and it’s no simple matter to follow the full logic behind it. However, we did some tests with Seth back then and he agreed I could indeed be hitting bug 4302.

I wrote some details down below, but if you prefer you can avoid reading them and just hook up with me on the Vassal server for 10 minutes when you have a chance and I will show them in action.

(details)

Basically in Marvel Heroes they are related to the turn counter (which itself is probably innocent, though): when a network player initiates game setup or signals that his turn ended etc etc then the module will do various operations - setting global properties, moving pieces, dealing cards, reporting in the log etc etc - and it will then issue a global hotkey to advance the Turn Counter. In turn, advancing the turn counter will do various things, like moving a turn tracking piece on the main map and updating various global properties, such as currentPlayer, with the name of the side whose turn it now is.

However, in the latter case bug 4302 intervenes: initiating the game setup by one player will update currentPlayer correctly for him but not for the remote player(s). This is because the global hotkey to advance the turn counter happens on the remote clients too fast, I think, and they will not yet know which side was selected to go first in the game (there is a random playing order selection procedure done at setup time).

Moreover, bug 4302 is clearly visible by looking at the report action trait fired by players ending their turn: on the remote client(s) they will incorrectly appear after the report action trait(s) triggered by the turn counter itself (as in the “Tank fired - New Turn” vs “New Turn - Tank fired” mock scenario I imagined).

Brent_Easton · July 31, 2012, 12:01pm

Sorry,

I am getting confused as to who owned which module. The fix for 4302 has a bug in it and this bug showed up in the Space Empires module. I have managed to reproduce the bug (in the 4302 bug fix) in a simplified module, so hopefully I can sort it out and produce a fixed fix for 4302 shortly.

B.

barbanera · July 31, 2012, 12:21pm

Still not sure how Space Empires enters the equation… Unless it was mentioned in the Bug 1948 report, which you said it was related to Bug 4302?

Anyway, looking forward to your fix and I will sure put it to test with MH and let you know

Brent_Easton · July 31, 2012, 12:27pm

Ok,

Found the problem. Corrected fix submitted.

Your module was not affected by the bug in the fix, someone else found it using the Space Empires module. It was discussed on another thread somewhere.

B.

barbanera · July 31, 2012, 12:33pm

I am getting confused again… the fix for the bug (4302) or the bug in the fix (1948?) ?

Are you saying global hotkeys don’t jump the queue anymore now, whatever the module? That would be great

Brent_Easton · July 31, 2012, 12:40pm

This thread is about bug 4302. I have fixed bug 4302.

uckelman · July 31, 2012, 1:40pm

Thus spake Brent Easton:

Ok,
Found the problem. Corrected fix submitted.
B.

Merged to trunk@8255. Uploaded 3.2.0-svn8255, try that.

–
J.

barbanera · July 31, 2012, 4:33pm

Well, I sure hope you did, but something else must be broken then.

I am getting the same exact error as with the previous botched fix/build (8224).
See http://www.vassalengine.org/forum/viewtopic.php?f=5&t=5376&start=15#p35414.

Basically the Marvel Heroes module does not work at all any more with this patch. At least not in network mode. Just to clarify: I tried a previous build (8249) and with that it works fine (but of course with those issues mentioned in the previous post relating to bug 4302, afaik).

Please let me know if I can help (by demonstrating you the crash, by showing you the original bug in action etc).

Brent_Easton · July 31, 2012, 9:37pm

Both the test module supplied by Seth plus my own test module are now working with svn 8255.

Could you please describe the exact sequence of events using the MH with svn 8255 module to generate the Stack Overflow error.

Thanks,
B.

barbanera · July 31, 2012, 10:29pm

Start new game with computer A. Pick a side, say Avengers (not “solo play”). It will take a bit for the initial splash screen to pop up (see first snapshot, MH module page).
Join room with computer B and wait for side selection. Join as another side, say X-Men, and wait for splash screen.
Now on computer A click on the “click if ready” button next to Avengers: should change to “(A’s username) is ready”
Then on computer B click on the “click if ready” button next to X-Men: should change to “(B’s username) is ready” (and some other button/cards also become visible). At this stage you get the Stack Overflow error for computer B (whereas A will still be there peacefully waiting for A to check in).

You could also revert 3 and 4 (checking in first B and then A) and the same bug will appear (on computer A this time).

No such stack overflow with earlier builds, like 8249 or beta1.

Those check-in buttons are in the Game Board (main map), when editing the module, towards the bottom.

Also, if you do the above procedure with 8249, say, you can then continue by selecting a scenario and clicking “start game”. After a while the splash screen will disappear on both computers and the actual game board will show up (see 2nd snap shot, MH module page). If computer A (=Avengers) was the one starting the game and the random selection gave Avengers the starting position (check game log) you will be able to do things (for example on the Avengers map right click on the heroes to see commands like “set ready”, “set supporting”). However, if the starting side was selected to be the X-Men, then computer B (=X-Men) won’t be able to do anything (discounting dragging cards from the decks, which is not supposed to be done) because the currentPlayer variable is not updated correctly for him and I think it’s the hotkey triggering the turn counter jumping the queue.

To check the value of currentPlayer on both computers issue ALT-SHIFT-D and a “debugging” window will pop up. The last line shows currentPlayer, among other things.

Thanks for investigating this.

barbanera · August 8, 2012, 11:15am

Brent, any news about this?

Brent_Easton · August 10, 2012, 11:52pm

I just can’t sort this out unless we can get a simpler example that demonstrates the error.

barbanera · August 11, 2012, 10:54am

Ok, but can you at least tell me if you tried the 4 steps I indicated with the MH module to see the error message? Or is it just me doing something wrong? Thanks.

Brent_Easton · August 11, 2012, 11:50am

Yes, I tried it, it failed. It is way too complex to try and debug using the MH module.

I am currently working on resolving the related issue in the Space Empires module which is being caused by the same attempted bug fix. I have managed to isolate it and and am hoping if I fix it, it will fix your problem as well. I am up to my elbows in Vassal entrails as I type this.

Brent_Easton · August 11, 2012, 12:52pm

Aagh, my brain hurts. Getting a circular command reference when processing nested Triggers. Will try again tomorrow.