Movement trail bug v3.4.10

[gwarren25]

The movement trail in v3.4.10 does not track through each hex moved, if you move a hex out of a straight line, the trail moves in a straight line between the starting point and ending point.
Version 3.2.17

Vassal v3.2.17 movement trail.png (85.13 KiB) Viewed 2723 times

Version 3.4.10

Vassal v3.4.10 movement trail.png (82.13 KiB) Viewed 2723 times

[uckelman]

In what module are you seeing this?

[gwarren25]

Sorry, I guess that would help!

starfire_2.1_retro.vmod

[uckelman]

I've tried to reproduce the problem, but can't. Can you give more detailed steps for triggering it?

[gwarren25]

Start a new game online
Select setup -> New scenario
Join game as which side? -> <observer>
Select Board -> Open Space
Finish
Click on Hourglass Icon
Hit "+" until "Turn 1, Movement Phase" appears
Click on Spaceship Icon
Drag Red "SD" counter onto map in hex 0807
Click on "SD" counter to select
Hit <CTRL> F four times (moves forward four hexes)
Hit <CTRL> R to turn right
Hit <CTRL> F twice to move forward two hexes
(movement trail forms straight line between starting hex and current hex, instead of following the path moved)

[gwarren25]

steps to replicate issue are above

[Rindis]

Okay, took a little fiddling around (the 'forward' command is hidden in that module if you're not in a movement phase) but I can reproduce it.
http://www.vassalengine.org/mediawiki/i ... retro.vmod

Note, if you just drag the counter from hex to hex, the movement trail is fine, it has the 'nodes' in each hex, and all that. But if you rely on a doing a command through a 'move fixed distance' trait, then it seems to always consider everything to be part of one move. No 'waypoint' nodes appear, and the line always goes from where the piece started to its current location. I also note that selecting a different piece and moving it in between (by either method) does not help.

[Brent Easton]

Thanks all, I found the problem.

A fix will be included in 3.4.12. The creation of Movement Trail points by Move Fixed Distance was inadvertently dropped when the code was re-written to fix the numerous MFD bugs in the 3.2 version. This fix will restore the dropped code and MFD will go back to creating Movement Trails as it did before.

Note that there is a similar issue with Send To Location not creating Movement Trail points. This has never worked. I have added a fix to version 3.5 to have STL create Movement Trail points. Since this may affect a small number of modules that may depend on STL not creating movement trail points, I have also added a Compatibility preference to turn this new behaviour off.

Regards.

[barbanera]

Thanks all, I found the problem.

A fix will be included in 3.4.12. The creation of Movement Trail points by Move Fixed Distance was inadvertently dropped when the code was re-written to fix the numerous MFD bugs in the 3.2 version. This fix will restore the dropped code and MFD will go back to creating Movement Trails as it did before.

Note that there is a similar issue with Send To Location not creating Movement Trail points. This has never worked. I have added a fix to version 3.5 to have STL create Movement Trail points. Since this may affect a small number of modules that may depend on STL not creating movement trail points, I have also added a Compatibility preference to turn this new behaviour off.

Regards.

Compatibility preference is the way to go, nice!

However, what do you mean "turn this behaviour off"? I would hope any new behaviour that changes how things were before should be explicitly turned "on", instead. I am sorry if I am looking like the one spoiling for a fight here, but I think this is a delicate policy issues that should be given a thorough consideration.

Exploiting the fact that STLs were not showing movement trails was perhaps perceived and exploited as a useful feature, rather than a bug, in some modules (and how do you now they are just a "smaller number of modules?"). I am NOT claiming I am one of those involved, just to be clear. I MIGHT be, though: I just don't remember at the top of my head and would need to check all my modules (or more likely to wait for some "bug" report from players).

However, as a similar example, for sure I am exploiting the fact that STLs don't trigger reports to log from things like "execute command for pieces ending movement on this map". I shiver at the idea that all of a sudden a new release of the engine declares this behaviour as and old bug to be fixed by default and forcing me to a) take note, b) update all my modules to check some boxes "off", c) spread the word about the new update.

[Brent Easton]

As in all things, there is a trade-off between leaving the stupid, non-sensical and obviously broken behaviour as the 'standard' behaviour that all new Vassal developers will see as standard and have to work around unless they happen to notice that preference, as against breaking any existing modules that are dependent on that behaviour, but providing an option in the obvious place (Compatibilities tab) to turn broken behaviour back on.

Ultimately, it comes down to whether you classify that behaviour as a bug or not, and the expected number of modules changing it is likely to impact.

In this case, I would argue that the current behaviour is definitely a bug, and on closer investigation, the potential 'use case' I identified for making use of that bug doesn't actually stack up. If you have a Movement Trail active and start using Send To Locations, then the STL 'steals' the last valid Footprint and makes it magically follow the unit around as you use STL. It's just wrong.

So, I have indeed given this some 'thorough consideration' and am also happy for anyone to jump in and change my mind. 3.5 is some time off and beta2 will be out shortly if anyone cares to check their modules. Nothing in 3.5 is a done deal and we are open to discussion about all changes. The problem is that very, very, very few people actually take the time to test the beta releases for us.

The hypothetical case you posit as being a 'similar example' is not one I would classify a bug. There is no obviously 'buggy' behaviour (more mildly inconsistent) and no-one has ever complained about that behaviour (as opposed to the multiple times people have complained about STL's not updating movement trails).

[barbanera]

Ok, fair enough.

I do make use of STLs in a lot of automatic setup procedures and I definitively prefer that players do not see confusing trails and log reports (just the end result).

For trails, I guess even if they are "on" by default in future releases, I guess just clearing them all out at the end of the procedure works all right anyway. Except, wait, there was no "clear off" command key in 3.2.17 (or earlier), just a toggle command, so that could not be already implemented in those "old" modules. I am just thinking out loud here, bear with me.. Oh well, add to my personal TO DO list just to make my modules 3.4+ compliant.

For log reports from STLs in the example given, that would be impossible to do post-fact, I presume. Therefore, I am confident really "throrough consideration" will be given should there ever be a urge to change that because of future complaints or requests or somebody decides it's not a "mild inconsistency" but a major one, after all.

[gwarren25]

Thanks to all for looking at this, and finding a fix. I appreciate all of your help!

[Brent Easton]

For log reports from STLs in the example given, that would be impossible to do post-fact, I presume. Therefore, I am confident really "throrough consideration" will be given should there ever be a urge to change that because of future complaints or requests or somebody decides it's not a "mild inconsistency" but a major one, after all.

Well, you are the only one who has ever suggested changing that