Can module detect which VLOG (or VSAV) was loaded?

Module Design
1

Hi,

Is there a way for a module to detect which VLOG was loaded by the user? Is there some global property that contains the name (or the like) of the VLOG? I’ve looked around (docs and code), but I couldn’t seem to find any place where such a property is set, or similar.

The use case: The user fires up a module and selects to run the tutorial. The module should then pop-up the Notes window which will contain the tutorial messages for the user to read.

Concretely, I would expect something like

  • A Startup Global Key that fires if a global property - say GameLoaded (or something otherwise appropriate) - contains a specific string - say tutorial.vlog
  • The Startup Global Key may have to trampoline through a regular Global Key for the condition (`GameLoaded==“tutorial.vlog”).

A similar approach could be used if the module wish to give additional information if a specific predefined setup or similar is loaded.

It seems to me that

  • VASSAL.build.module.GameState.decodeSavedGame(InputStream) should accept another argument of class String, which if is not empty would set the global property GameLoaded (or similar).

  • The overload decodeSavedGame(File) can use File.getPath (or similar) to propagate the filename to the InputStream overload.

  • Now, clearly the class VASSAL.build.module.WizardSupport.SavedGameLoader would need to have the filename information too, as would derived VASSAL.build.module.WizardSupport.TutorialLoader (perhaps these should be passed the PredefinedSetup and Tutorial objects directly so that the loaders can extract both content and file name directly).

    • Perhaps the base class SavedGameLoader should accept a prefix to prepend to the file name.
      • For PredefinedSetup this could then be predefined: - e.g., the GameLoaded could have the value predfined:EasternFront.vsav
      • For a tutorial it could be tutorial: (defined by TutorialLoader) - e.g., the value of GameLoaded could be tutorial:Tutorial.vlog
      • For disk files (or perhaps remote files) it could be empty to match VASSAL.module.build.GameState.decodeSavedGame(File).

  • VASSAL.module.build.GameState.loadGameInBackground(String,InputStream,boolean) (and loadGameInForeground) should also pass it’'s String argument to decodeSavedGame.

The only other alternative I can currently see is to

  • Define the module, including some special interface that sets the global property IsTutorial,
    and the Startup Global Key to fire up the Notes window.
  • Open the module and start logging.
    • Activate the special interface to set IsTutorial
    • Build the tutorial using the Notes window.
    • End logging
  • Rebuild the module, but disabling the special interface, and attaching the tutorial.

This, however, scales rather poorly to other cases.

My apologies if I missed something.

Thanks.

Chrisitan

1 Like
2

Hi,

Any thoughts on this topic? Thanks.

Yours,
Christian

3

You could get the name of the save file from GameState.lastSaveFile and the name of the log from BasicLogger.outputFile if you were willing to write some custom code for your module.

4

Hi,

You could get the name of the save file from GameState.lastSaveFile and the name of the log from BasicLogger.outputFile if you were willing to write some custom code for your module.

Thanks, but it doesn’t really address the question. First off, I think it is desirable to get such information from the properties system of VASSAL rather than writing custom Java code. Custom Java code is sensitive to changes in VASSAL (as seen recently). Secondly, the question was if there was a some sort of property by which one can accomplish something like outlined in the use case.

Long of the short, I guess, is that there currently is no way for a module to know which VLOG or VSAV was loaded, except via some hackery.

Perhaps the proposed code changes to could make it into 3.7? They would not, as far as I can tell, break anything external to the changed code but would provide additional functionality to VASSAL.

Thanks.

Yours,
Christian

5

Yes, though we try to maintain compatibility and give advance notice long before we remove anything that might be used in custom code. Given how much of a time sink removing code deprecated for longer than a year was last time, it’s unlikely that we’ll be doing it again.

There isn’t, which is why I suggested custom code.

I’m not convinced that triggering on filenames is a good idea. Filenames can change. What happens if you have an external saved game with the same filename as one of the predefined setups?

Anyway, I’m trying hard to minimize the time I spend on V3 from here on, so that I can focus on V4. (I may still fix V3 bugs occasionally, but working on new features is not in the cards.) If you want to pursue this, you need to get the attention of somebody other than me.

6

Exactly why I suggested to prefix the files so that the module code can deduce where the file came from (predefined for embedded VSAV, tutorial:for embedded tutorial, and nothing for other files).

Do you think that you would accept a PR? - Not that I can promise to make one, but are you willing to accept PRs?

Yours,
Christian