Fair enough, I’ll keep that in mind.
So, nice work @Benkyo on the game aesthetic, it feels fairly unified. Your next revision could benefit from some of the new folders we can now use 
This was a big project. I can’t imagine how many hours you put into it. Again, good job. You definitely went nuts with the GPs. It is nice to see that one can build a pretty complex turn-counter-tracker from scratch. In my case, I’d like to avoid it. I think my first course of action would be to build my own custom class to overwrite the “-” button function on the turn tracker and redirect it to the “rewind/undo” button. I hope one day you will do some kind of write-up on how you like to build that stuff. But, after looking at your module “Antiquity” my guess is you are probably still recovering from PTSD
1 Like
Thanks, I think. I wouldn’t know where to start with custom classes, and I do enjoy pushing the editor to see what I can achieve.
All my modules end up like that!
2 Likes
You keep suggesting that the “-” button should Undo instead, but I’m not so sure that’s a good idea–I can imagine players expecting that to rewind the game to the beginning of the turn, when Undo just undoes the most recent command (which can often not even be visible on the current player’s screen). Better to just disable the button, IMHO.
1 Like
That thought has crossed my mind. Thank you for thinking it through with me. You may be right about this. There is definitely the potential for some player confusion. Also, disabling it will be easier, I imagine.
I don’t know why I followed this thread because I have never used the turn tracker and I am not fond of extensive automation, but when I read your plan to write custom Java code, I face palmed. Hell would freeze over before I would write and maintain custom Vassal code. An doing it in Vassal using Vassal tools is not that hard.
First though, I decided I would check out the turn tracker myself with a sample module. I see you press a toolbar button, which opens a turn tracker window. My problem here is I can control anything to do with that window. I can zoom in or out, for example. I fooled with it to see if I could disable buttons. If I shrank the button width to 1 pixel, then I could disable both but not one. I also discovered no matter what the button width, I could never get the hot keys to work. Anyone else notice this? The TT’s hot keys don’t work?
Now if the turn tracker were a PIECE, well now, it would be something I might use. Then I could embed it into my main window where I could lock it in place or not, and I could surround it with related stuff.
To create a turn tracker piece, I would need artwork to look like the current TT window. I would create a piece using an at-start stack in the main window. I would advance the turn by either using an action button or via a toolbar button, which would forward the command to the (what I call) the proxy piece. A proxy piece is a piece that encapsulates code to do a job, and it does not even need to be visible. Here it would show at the very least the current turn and phase information.
Inside the piece, I would create two dynamic properties: turn and phase. Both would have key strings to increment by 1 (advanceTurn and advancePhase). Phase would range from 0 to 3 and wrap (assuming I had 4 phases per turn, for example). Then I would hang conditional triggers on each phase advance.
For example, suppose phase =1 were the “Reinforcements Phase.” When a player pressed the advance button (^A), it would become “advancePhase.” The dynamic property “phase” would go from 0 to 1. A trigger would exist for the key string “advancePhase,” and the test condition would be {phase == 1}. Down in the trigger commands, I would have a list of commands to execute, perhaps code to send units to map locations. To display the phase text, I would probably use what I call a “pseudo-array,” but here it would be just as simple to load “Reinforcements Phase” into a text trait contained in the turn tracker piece. I would then have triggers for each of the different phases. If it was also turn dependent, I would increment “turn” at the appropriate time and write sub-triggers that looked at phase and turn.
And that’s it. Easy-Peasy lemon squeezy.
@shilinski, thank you for giving me a detailed explanation of your preferred approach. I appreciate it and may use it. This is definitely a way to solve the problem.
Personally, I would simply define a property for each turn with a default value of zero. When the turn tracker advances, set the value of that turn’s property to “1”. Then have the automation check that the value is “0” before it runs. This means that if the turn tracker is decremented & then incremented (the mis-use case you describe), the automation doesn’t run again.
I did something similar in the EE module for annual reinforcements.
This approach wouldn’t work well if you have lot’s of micro-turns, vs. a few big turns (e.g., years).
2 Likes
Thanks @Korval, this is a step in the right direction and I am definitely more aware of some of these techniques, thanks to your and other’s suggestions. However, there is at least one snag I can think of. If the player is going back to fix something from their move that was an error, the thing they fix will often be unit state that affects the automation. In other words, if I go back and change my truck movement and re-advance the turn, this time automation doesn’t run, making my truck’s fuel state wrong. Whereas, if I “undo” the turn back, it unwraps the previous automation…I fix my truck’s move…go forward again…automation re-executes and correctly applies to my truck’s fuel state.
Edit: I should add that some have pointed out that I could make my own TTracker with pieces and properties from scratch and this would solve the problem…which is true…I’m just trying avoid “reinventing the wheel”.
IMHO, one of the things you are articulating is a point several of us have made…
Automation easily breaks and can introduce unwanted/unexpected problems…
You may wish to reconsider how much you are automating or make it “semi-automated” by using GKC buttons (that players have to push) for things that are particularly problematic.
The other issue w/ automation, is that it can prevent players from exploring variants where they may wish to make minor alterations in rules to for play-balance or other reasons.
An example from the EE module I updated… I implemented a “Russian Winter” effect, that triggers when players push a button. I could have tied it to the turn counter to auto-trigger on Jan-Feb-1942, but chose to leave it more flexible.
In your particular case, if a player had the option to manually edit a pieces fuel level/state, they could fix problems that way…
When I implemented an automated cost counter for builds, I deliberately kept a “manual” add/subtract feature to allow players to fix errors (and explore variants) for similar reasons to what you describe…
These are both valid points and good advice. I don’t disagree with any of it. As you may imagine, these points have been driven home by my experience in this case. Additionally, you will be pleased to know, I have implemented manual error correction to an extraordinary degree. So, consider your views fully validated.
My request for this functionality stems from my belief that:
- the checkbox would be trivial to implement
- this is a broadly beneficial tweak that would enhance the utility and resilience of the TT
- the existence of the TT and turn-triggered automation itself implies the need for this solution
I am glad so many have offered solutions and opinions based on their experiences here. My overall view is that the discussions have reinforced point #2.
Finally, I think I will probably be able to make this happen with a custom class. If I do, I’ll offer it to the community for use.
Okay, I made this work by modifying the engine code directly. But, I’m now pretty certain that this cannot be done with a custom class. This is because the underlying functionality must be @Override-n and there is a nested class as well as many “protected” members. Custom classes can’t access the protected members from outside the package.
Feel free to go deeper and add appropriate Getters and Setters to the protected members that you cannot access and provide it as a PR. Either add the whole functionality you need, or just make the appropriate info available to custom code.
Unfortunately, this does not help you right now.
It is possible to include custom versions of Vassal code in your custom class code. Include the VASSAL.build.module.turn sub-tree in your custom code included in your module and make the appropriate changes. If you make the same changes here as you submit to us as a PR, you will eventually be able to remove the custom code from the module. The downside is future changes to the Vassal Turn Tracker will not be reflected in your module, but the tracker is pretty stand-alone, that isn’t necessarily an issue.
1 Like
Thank you very much. I was thinking I may try to get a PR to you. The only thing I still need to figure out is the editor controls. Also, I will take another look based on your suggestion about the .turn sub-tree. It would be cool if it worked out the way you described.
PR submitted for TurnTracker / TurnCounter forward-only setting.