It looks like the top card of a deck is reported being in position 2 (DeckPosition=2) and not 1, as it should be (DeckPosition returns the position of a piece within a Deck (top = 1) if the piece is currently stacked in one, or 0 otherwise.)
This looks like a bug. Using 3.3.2, but I think this issue was already there in earlier versions.
Okay I have put a fix in for 3.6. You can try it out in the 14365 branch test build.
Thanks for the test module! I do try to reward those with fixes … even 9 months late!
Brian
Nice thanks, but will this break modules that were just subtracting 1 from the (buggy) DeckPosition to make it work, now?
Yes it probably would.
Ok, I understand there was no other realistic option if the bug had to be squashed (and thanks again for not forgetting about it!).
However, let me strongly plead for a comprehensive and detailed list of bug fixes (and new features) that might alter the way existing modules work. A big Warning section, spelling out what could be “broken” due to the - necessary - bug fixes. Let me stress that I am trying to be constructive here, not at all criticizing bug fixes or new features (on the contrary!).
Imho, this should be a list compiled by you - engine developers - yourselves, whenever any contribution you have might alter/break the way existing modules work. It should NOT be something module developers should track down themselves, perchance reading about it in one of the dozen threads in the forum or after a certain critical mass of unspecified module malfunction reports have accumulated, perhaps months (and engine releases/bug fixes) later.
It seems obvious to me that it’s far more efficient and reasonable if the engine developers spend a few minutes more thinking what the new fix/feature they worked on could break/alter AND clearly spell it out in full in a dedicated section of the Release Notes, than handing the ball to the module developers to keep up to date with the (rather cryptic!!) list of bug fixes and figure everything out on their own (perhaps by tons of trial and errors, browsing dozens of forum thread reports, starting new threads etc).
For example (bunching up a few of bug fixes that affect some of my modules since 3.2.17, for illustration purposes):
Version 3.6.XX
WARNING:
the DeckPosition fix will break old modules that managed to make an use of DeckPosition by fixing it by custom methods of their own
the STL fix will “break” old modules that gave for granted that no movement trails would be generated
the Calculated Property update will break old modules that relied on a Calculated Property to be calculated only on a specific call
etc etc.
I suppose we could add a “compatibility tab option” for having DeckPosition report +1. Would you want that and use it?
(since you’re the first person to report this problem – at least as far as I know – you may be the only one who ever tried to use DeckPosition in a computational context)
If we tried to make documentation substantially more detailed than the release notes we currently provide, the likelihood is that it would be read by fewer module designers.
No, never mind about the compatibility option. I would have to update that one module anyway, just to make sure to check the compatibility mode, and then might just as well spend the time to remove all +1 hacks, instead.
Of course, it would be another much happier story - for me at least - if the new engine release with your fix would check for modules built with older versions of the engine and automatically add +1 to DeckPosition, to simulate the old (buggy) behaviour. But I am sure that will never happen and I don’t want to beat a dead horse bringing that argument up again.
Users will keep updating the Vassal engine, whenever they see there is a new version out (I would do it myself), but won’t realize there might be new versions of their installed modules, which they also need to update to, till they get hit by some apparent bug etc. But there is nothing realistic one can do about that, I guess.
However, my argument was about something very realistic and, I think, pretty straightforward to do: at least make sure module developers are fully informed of potential impacts of bug fixes/new features on modules built to work when we had to live with those bugs. You engine developers are the only fully qualified to work out all possible angles of what you fixed/changed.
I mean, I started this thread, I submitted the bug myself (or didn’t I? I forgot), now I am alive on the forum these days, I noticed your response and took notes and I know I have to find some time soon to fix that module (and advertise about the new release on all relevant forums etc). But what about other developers that might have found similar workarounds about this bug (or other bugs) and not notice it got fixed till many months/years later because life is keeping them busy otherwise?
Obscure oneliners in the Release Notes (e.g. “14348: Invisible Trait UI conflated opacity with transparency references”) are not always exactly eye catching or clear enough to the actual impact of certain updates (do I have to worry if I was using transparent traits? opaque layers or zones?). Especially when you have to parse through dozens of those lines in multiple releases, only a handful of which, if any, are potentially “breaking” something backwards, in the sense of invalidating workarounds people could have put in place back then.
The warnings I am talking about would probably be no more that 2-3 extra sentences per release notes document, I believe. A single section/document to look at, potentially updated as needed, instead of happening by chance on the relevant info in some obscure thread like this one 