I am trying to build a button on a piece. I have no particular reason to want the button to be unclickable once pressed.
So far I I have set up an action button and I can show that gets triggered through the report action trait.
Then I set up a dynamic dynamic property and a trigger action. So that I can string various bits together. Now I can show that the dynamic property is changed and its value printed out via the same report action. Then I put in a layer trait and hooked that up to the trigger action and now when the button is clicked the user can see a visual change.
However if I click on it again, the visual change (hence the layer) disappears. I cannot see why this should be the case.
I tried fixing it with a Restrict Command trait but that did not work. Either way I don’t see why it should be necessary.
The button I am working on is “Extra Buildings”. I am still working on the graphics. In particular when you press that button you just get placeholder graphics. If you press on the edge of the placeholder graphic nothing happens. The placeholder disappears when you press where the button would be.
One other idea is tying the layer to a numeric variable. I already have the dynamic property. It is just “Yes” or “No” right now. I did try that much earlier but now I am thinking I should have persevered with it. So I am guessing I could make it that if the property is 0, the layer is not used. If it is 1, then the first (and only) level is used. That would make the semantics of the property odd, I would have to change “Remove_Extra_Buildings” to “Keep_Extra_Buildings”.
Okay I have found something that sort of works. If I allow the numeric dynamic property to wrap between 0 and 1, then the button can be unclicked. That is not what I intended but it can be plausibly seen as a feature.
I took a peek – one suggestion is that rather than have your entire configuration page be a single piece, you might be better off making it into a Map, and then put pieces on it for the individual buttons. Having an individual button be a piece should make it simpler to maintain the buttons. And instead of having the layer only be for putting ONE of the states of the button, try putting both the unclicked and clicked state into the same Layer property (as two different layers), and then you can have the layers change back and forth.
If you want to see an example of a configuration screen that’s built as a “Map”, pull down For The People, and look for the “Preferences” Map Window (and it is built with the “Prefs Marker” and “Prefs Space” prototypes). It has a slightly different visual scheme than what you’re going for, but it illustrates some of the things you’d want to do. And it lets you click on the pieces (OR the empty places) to change the state.
I had a quick look at For the People. There is one immediate concern I had during my work. Before the game starts I need to return some tiles to the deck, because different maps start with different numbers of tiles. VASSAL does not seem to have an “at start” trigger or anything like that. So I needed to stick something under the user’s nose and say you cannot play the game until you have at the very least pressed one button. I am hanging my critical code off that button.
I can see that the approach taken in For the People is a natural one, but would not have worked in this case.
You have set up a layer trait that is not “always active” with an “activate” command. The activate command shows a different image. The reason for the behavior is:
“Activate” is a toggle. Press it once, and it activates, which causes your secondary image to appear. Press it again, and it de-activates, which removes your secondary image.
Wouldn’t it be easier to dump the button and make it a checkbox? (You could use your existing code with different images.) Then you can do the dirty work when the user dismisses the window. It would also allow them to change their mind.
Also, if you right click at the module level, there is a “startup global key command” that you might find useful.
You CAN do an at-start keystroke, as shilinski points out – a STARTUP Global Key Command.
Be aware that this command will trigger whenever you start up the module (I think even when you load a saved game?) so you might want to have a Global Property or something that tracks whether the game is already started so that you don’t do startup stuff a second time. (Just set it to a different value after you run your game start stuff, and then ignore the Startup Global Key Command whenever you find it already set to the new value)