Bug #1
HTML tags are not being properly recognized in the Turn Counter, specifically in the Turn Counter Window. They are properly applied in what is sent to the chat log.
This applies to HTML tags applied at the parent level turn counter “Name Level Format” field
Also applies at the child “Turn Level Format” field
Bug #2
Unrelated to above bug, if you define a “Really Long” name for the turn counter, it may not fit in the turn counter window and be cut off, even when the window width is set to “maximum.”
Bug/Issue #3
The “Name” field is used in both the Module Editor Display and the Window presented to the players when running the module. I can see reasons why these should be different. This may be related to Bug #4.
Bug #4.
The “Tooltip Text” field is mysteriously sometimes populating from the child list’s first field.
A simple module that illustrates Bugs #1 & #2 is enclosed
Issue #1:
The Turn Counter was never designed with HTML in mind and has never supported it. It would make it extremely difficult to manage the floating and docked mini-window sizes. This is not something that will happen soon.
Issue #2: I think you are talking about the ‘Button Text’ not the ‘Name’ which is displayed in the Turn Counter Window? The maximum feature is designed to allow for the maximum expected value in Turn counter itself. Up to you to control the title and width, we don’t have much control over the Window title bars across platforms.
Issue #3: probably easiest to add a Description field for the designer to use.
Actually, for issue #3, I don’t think a description field is even needed. The Name is seen by the Designer and the Button text is seen by the users, so I think you already have what you need?
Regarding Issue #3, I just went back and checked it…
VASSAL 3.5.4-SNAPSHOT-bug14152-d22186aba
In the Counter Properties…
NAME: Alpha
BUTTON TEXT: Beta
TOOLTIP: Gamma
In the module editor, “Alpha” is shown as the label for the counter.
In the executing module, the button text is shown as “Beta”
When you click the button, the window that opens has a label of “Alpha”
So NAME is being used both in the module editor display and also as the window label presented to the player. This seems to deviate from the standard design paradigm for other UI elements, where we can label something in the editor with one name, but have the option to show the players something different.
Additionally - when I hover over the button, I don’t see the tooltip text “Gamma” instead I see the value of the counter…
That should have a list of downloadables? If it doesn’t, click the “Actions” tab (on the Github page), and open the latest one in the list that says it’s from “master”
Brian - negative, neither issue is fixed. BTW, for future reference, the reason I had issues with the pull request was that I wasn’t logged into GitHub. Thus all of the build artifacts displayed as simple text and not as downloadable artifacts. Once I created an account and logged in, I could (and did) download the WIN64 exe.
Using my current module under development: Name Game Turn
This displays correctly in the module editor and also as the window title for the counter when opened… Like other editor features, it would be helpful to be able to have separate fields for what is shown in the editor (e.g., “Description”) vs. what is shown in the executing module. However, this is more of a feature request than a bug. Button Text TURN
This appears to work correctly
Tooltip Text (null, i.e., blank)
In the executing module, when you hover over the button this doesn’t show (null), it shows the value of the counter. I haven’t seen the tooltip field mysteriously populate in the editor, but given that the the ToolTip behavior is still wonky (displaying the value of the counter, rather than the null value), I believe this is still broken.
Oh I have, however found code that seems to set the tooltip of the “launch button” (the one that hides/unhides the turn tracker if it is undocked) to be equal to the turn counter.
This code appears to go back to at least 2007 as an explicit choice, and so I’m hesitant to change it (because there will almost certainly be modules out there that count on this “default” behavior)
The editor UI provides a specific entry field for the tooltip text, the fact that the engine is over-riding the explicit choice of the module designer is IMHO a bug.
Additionally, the fact that not only is it being overridden in terms of executing behavior, but the engine is actually populating this field (although I haven’t seen it yet in the newest build) is doubly problematic.
I’ve seen a lot of buggy behavior in counters, ranging from refusal to increment, to not saving value, undock not working properly for 2nd counters, etc.
So, from what I’ve seen, the counter code needs some improvement…
I suspect at least part of the problem is that there is an underlying assumption that there will only be a single counter implemented in any given module (for turn tracking), rather than multiple counters…
The Turn Counter code could just about apply for its learner’s permit this year (I was thinking it might be old enough to vote or even drink, but apparently not). It does look like it was implemented to have multiple counters though.
It is much more likely that the provision of a configurer field for “Tooltip Text” (when the tooltip text is in fact provided by automation) is the actual bug. THAT we could probably fix.
The test build for 14364 has my fix where I just remove the “Button Tooltip Text” field since it is ignored by VASSAL anyway (and autopopulated with the current turn).