I finally got around to having a closer look at the Startup GKC code and am planning to re-work it for Vassal 3.6 as follows:
Startup GKC’s are currently run independently at indeterminate times during the game startup procedure. This causes them to run in an indeterminate order.
- That Startup GKC’s be guaranteed to run last, after all other Vassal components have been fully initialized during the game startup process.
- That Startup GKC’s be guaranteed to run in the order in which they are defined in the buildfile. i.e. earlier defined maps will have their Startup GKC’s run first, in the order they are defined within the Map.
- That if a user attempts to Undo a Startup GKC, they will get a suitable warning Dialog that this is not advisable.
- That the new behavior will be the default, but there will be a Compatibility Preference to ‘Enable Legacy Startup GKC Behavior’.
Sounds good with #4 option well.
I used a startup for initialization in one module based on player button selections but never saw any odd behaviors with it so assumed it always worked properly
If you only had one startup, everything was probably fine. Modules with multiple startup GKC’s would be more likely to have problems (from the SGKCs running in different orders).
It’s one of those things that will work in certain limited situations, but doesn’t work in more general cases.
If you have only one startup GKC, you are probably OK, and I doubt this will affect you.
Although #3 still probably applies and could render a newly created game unusable.
Here’s a possible #5 that I remember being requested:
- Have an option to only apply a startup GKC in particular start situations. Any combination of:
a) New Fresh Game
b) Loading pre-defined setup
c) Loading a new external vsav or vlog.
d) Loading a continuation vsav or vlog.
Startup GKC’s are of course defined at the Module level, so that makes it simpler.
I’m interested in this too, including point 5 (ability to distinguish between the four states a-d would be useful and make Startup GKC easier to understand, I think).
Sounds good - problematic non-deterministic behavior always is…
- Rather than simply warn a user about undoing GKC, why not simply not allow it…
- WRT the compatibility preference, were you thinking this would be a player configurable option (if so I would put red warning text that it isn’t advisable unless needed due to bad module behavior) or a option in the editor?
^^ FWIW, I agree that just not allowing UNDO over an SGKC sounds like a very sane approach. Unless technically unfeasible of course.
On a somewhat related subject, has any thought been given to eventually implementing some sort of “Startup Command” which is “bound” to a specific Map Window instead of bound at the Module level? This new Startup Command would execute when the map window is first initialized (which might not be during Module initialization if the window does not default as open).
I realize that this request is outside the scope of a Startup GKC, but I thought I’d bring it up in case it might impact your 3.6 implementation.