Stoopid mistake. Please try VASSAL-3.6.11-SNAPSHOT-311bf86-11932-Scenario-Preferences . Have fixed the window opening issue as well.
Brent -
File - Scenario Options is now showing up.
TABS appear to be working (created 3).
Both Checkbox and Numeric throw an error on change, but since you said it’s not fully implemented I understand.
Currently, you can select more than one type of option for a single Global Property (e.g., Checkbox and String), which is probably not a good thing (?).
Both Checkbox and Numeric throw an error on change, but since you said it’s not fully implemented I understand.
Oops. I only tested the List one which I thought would be the most used.
Currently, you can select more than one type of option for a single Global Property (e.g., Checkbox and String), which is probably not a good thing (?).
Vassal generally does not stop you creating multiple of anything, however, I have added a Validity Checker that warns you if you try and save the module with multiple defined.
I’m wondering if it would be better to organise this feature in line with (my understanding of) its hierarchy, i.e.
- Scenario Properties (a container equivalent to the module level Global Properties container)
– Scenario Properties Tab
---- Scenario Property (various types)
----- Change-Property
Mark
I had sort of ruled that out as it makes the implementation far more complex, but I have just thought of a way that might make it simpler. Thanks for the feedback.
Do Scenario Properties need BOTH a configurer-type update option in the scenario Properties tab AND standard global property property-change button functionality?
Here’s an alternative hierachy which simplifies the development somewhat:
Global Properties (The same Global Properties container we have now)
– Standard Global Properties and Folders
– Scenario Properties Tab
---- Scenario Property (various types)
----- Change-Property toolbar button
– Another Scenario Properties Tab
---- Scenario Property (various types)
If we allow Scenario Properties to also have a Change Property Toolbar button (previous question), is it a problem that the Scenario Property says ‘I must be one of a list of values’, but a Change property button can be configured to set any value at all?
Don’t really understand the question…
The new Scenario Option ‘things’ we are creating are fully-fledged Global properties.
We are creating this new tabbed screen to collect them into one place and allow them to be changed in a very controlled way.
Do we also want designers to be able to add a Change-Property Toolbar button to one of the scenario options to have a second way to change them (with very little control).
My feeling is no, that’s asking for trouble. But…
I wasn’t sure. It can be useful to set Global Option properties from within the module (using Set Global Property trait) - e.g. to allow a temporary change, precisely because that doesn’t change the persistent preference setting. However, Scenario Option properties are different and the case for Change-Property seems weak or adverse, as you suggest.
Side note: At the moment, I do scenario settings using the toolbar Menu, Global Properties and Change-Property or GKC buttons.
What might be useful, is if the ability to change a Scenario Setting were controllable via a true/false property (like buttons) or calculation. Some settings can be fixed once a scenario is setup or when a game has started. I have examples of these situations. If the setting has been locked down, it would be greyed out.
Thanks - now that I understand the question…
Looking at the Checkbox/String/Numeric/List Option vs. Set via Toolbar:
- both support reporting
- both support hot key
- The Tool Bar allows use of expressions
- The Tool Bar puts a button on the toolbar
I don’t see a need for the additional functionality the tool bar button provides.
Brainstorming a few additional “nice-to-have” features:
- Allow “locking” of scenario options (one-time, irrevocable). Applies to both access via UI and various change Global Property functionality in Vassal.
- Add ability to write ALL Scenario Options (both GP name and value) to a file (record keeping).
1 Like
My Use Case for this functionality:
- Set it at start of scenario (only)
- Once set, the options should be immutable
- The players should always be able to view the list of options/values
1 Like
Not sure about how the locking would work. The moment someone hits that ‘Lock’ button, they are going to go oops, forgot about option x, got to set up the scenario again. Or 5 turns in, you both agree that you really hate rule 9(b) and there is some automation tied to that option that can’t be turned off.
If you then add unlock functionality, what’s the point of having ‘Lock’ functionality?
True…
Maybe just something that requires confirmation, before changing to prevent accidents…
Just thinking out loud here…
Speaking generally, I think scenario options fall into three categories:-
-
Fixed scenario settings (changes to a generic template vsav) - once the scenario is released, you don’t want these accidentally changed, though a backdoor unlock is needed to allow maintenance or new development. e.g. “Scenario Configuration” toolbar menu in C&C Napoleonics v4 has a feature in this category, it allows army pieces to be assigned to a different side, to support non-default scenarios. I could see this being a set of Scenario Options - one per army with the two options each. These settings might even be allocated to a tab that can be hidden on command, as they are not supposed to be player-changeable.
-
Game setup elements that don’t make sense to to allow to be changed mid game. Things that are part of game setup, though can be options for a given scenario. e.g. the deck of cards to be used. Once the game starts, these might remain locked just to show players that they no longer have any effect.
-
Rules or features that can readily be turned on or off. Yes, it doesn’t really help to lock these.
If locking is developed, I think it needs to be flexible. At least at “tab” level, if not individual property.
If the scope of Scenario Options is simply type (3), then locking is not needed. Otherwise, without it, the module will likely need some other protection (esp for type 1), and do more to make it obvious which scenario options are valid / in use.
Locking at a tab level would be simplest to implement and easiest to use.
The simplest locking mechanism would be to tie to the user password, so whoever locked it can unlock it at will. The ‘lock’ will be stored in the save game.
Type 1 settings, the module designer will lock these as part of their scenario development. Players will never get the option to change these.
Type 2 and 3 settings, probably the person who started the game will lock these, (or not bother), with the option to unlock and change them later.
Turns out there are security issues involved in changing options and locking and unlocking tabs. I think I have boiled it down to the following rules:
-
Players are only allowed to make any changes (change option or lock tab) if either
a) There are no player sides defined
or
b) They own one of the defined sides.
i.e. Observers cannot make changes in a game with sides defined. -
A tab can only be unlocked by the player who locked it (based on password).
1 Like
I see that Brent is working on your request, but I wanted to mention that I’ve implemented something that may address your issue. Or maybe not.
I’m updating Pax Renaissance 1st edition, and when a game starts, I must build a game deck that is based on number of players and if an expansion and/or promos are included. When you start a brand new game, a window displays over the main map. In it are checkboxes to add promos, add the expansion, and to add a 2nd edition rule as well as buttons to choose how many players are in the game. At the bottom is a “go” button. When you press it, it sets up the deck and game, and then vanishes.
Is this what you’re looking for, or am I completely off base?
Possibly!
Is there a version I could look at (Googledrive, dropbox, etc)?
I think what I’ll do is create a module called demo_setupwindow.vmod, which illustrates the idea, and I’ll add it to the module library. I don’t presume to be an expert here, but others may find it useful, and others can edit it if they have a better idea.
1 Like