We have a ‘Must Fix’ problem with changing Global Preferences in v3.1.
The Module Manager starts up and loads a copy of the Global Preferences. You can then run modules and change Global preferences and they get saved. When you shutdown the Module Manager, it writes out it’s private copy of the Global preferences and overwrites any changes you have made while playing/editing modules.
For example, you can’t change the language setting. Every time you restart the Module Manager, it has reverted to what it was the last time the Module Manager started.
I’m not quite sure of the best way to attack this. We need to communicate changes in the Global prefs between instances.
The best idea I’ve come up with is to have Prefs check the DTM stamp on the Prefs archive whenever reading a Global Pref value or opening the edit dialog and reload the Pref values if it has been updated.
The Preferences Editor should keep track of the diff’s rather than holding onto an entire copy of the preferences. Then apply the diffs before exiting. The Editor just needs to register a PropertyChangeListener with each of the configuration options to keep track of when one is actually changed.
What happens when you change the same preference in two different Players?
I was going to suggest that Players and Editors not have editable copies
of the preferences at all, but rather that they use the MM as a preferences
server—if a Player wants to change a preference, send a request to the MM
to change it, and send back a reply indicating that it changed.
This avoids problems with the concurrent modification of preferences.
I dont think this will help. The problem is that we now have 2+ different processes running, all with access to update Preferences.
I’m wondering if this is a bit of an overkill? As I see it, it is only really a problem with the Global Preferences.
If you think this is necessary, you’ll have to look into it as you are familiar with the launch communication stuff. If you have no time, I would be happy to look into my Preference file DTM solution, which should do the trick, though in a somewhat more lo-tech fashion.
Turning the MM into a Global Preferences server is way overkill for this problem. If a user has two Player instances open and modifies the same preferences setting, he will expect the second change to overwrite the first. You don’t need a service to solve that problem.
The problem right now is that saving preferences overwrites even the unchanged values with whatever’s stored in the saving process’ preferences. Applying just the diffs solves the problem.
Ok, Gotcha. So when writing a Prefs, we would need to read in a copy of the current Prefs to pick up any changes from other instances, apply any changed Prefs, then write out the updated copy.
Rodney, are you putting up your hand to do this? Let me know if you are too busy and I will have a go.
This won’t work unless every time you need to use a pref, you read it from
disk, since some other process might have changed the pref since the last
time you read it.
I think Rodney’s point is that this level of detail is not required. Changes to a preference will only affect the instance you make the change in, not any other instance. As long as the last preference set is used in any future instances that start up. It’s only really an issue with Global Preferences, most of which are only read at startup anyway. Spending a lot of effort updating prefs to all active instances would achieve nect to nothing.
I don’t see that doing it the way I suggested would be a lot of effort. I
think it will be less effort this way in the long run, as othwerwise we’re
going to end up with mysterious consistency problems that we’ll then spend
time debugging, only to find that the cause of the problem is the solution
Rodney is proposing now, at which point I will again propose the solution
I’ve already proposed.
I don’t like the idea of writing code to implement something which we knew
was defective before we started.
I doubt it, interaction of preferences between different instances is negligible.
I’m not particularly fussed. It’s a matter of time, and the knowledge required to implement a given solution. At the rate we are moving, Vassal 3.1 might be ready by next June One of us needs to put our hand up and take this bug.
Actually, your solution is similiar to my proposal of checking the DTM on the Preferences file, no need to read from disk if they haven’t changed.
Great. If you can fix the preferences issue, I will take care of
Bug [2358673] Piece transparency in LOS looks weird at non 100% zoom
These are both Must Fix for 3.1.
I’m also looking after
Bug [2418907] NPE When SendToLocation sends to Region that does not exist
Bug [2415632] NPE in DeckGlobalKeyCommand.encode()
which I hope to fix over the weekend.
Bug 2418907 actually points to a general problem with poor Bad Data reporting in Decorators. There is next to no information with which to be able to identify which GamePiece is actually causing the problem. Also, the error messages are not translatable. I’ll look into this as part of fixing this bug. I’ll also ensure all numeric FormattedString fields default to “0” if blank.