3.6.19 works as expected
3.7.0 sometimes works, sometimes not
Module Europe Engulfed Release 3.2.0
Steps to reproduce:
Start new scenario
(OLD works as expected)
Click Options - change U-boat build limit
*Pick a new value
*Chat log displays both correct old value and new value
(OLD does NOT work)
Click Options - change Bomber/Fighter cost
*Pick a new value
*Chat log displays only the new value
Can you please more information about the name of the property involved, and paste configurations of the traits involved?
3.7.0 chat log
3.6.19 chat log
Both properties are being set in the “BUILDS Map Window”
UBOATS (at start stack)
UBOATS (single piece)
German Bombers (at start stack)
German Bombers (single piece)
I can see the Global Property BomberCost defined in the module, where is oldBomberCost defined?
Brent - I’m really confused by your question.
When you preface “old” to a property in Vassal, it returns the previous value.
I’ve used that construct consistently in my module and it has always worked prior to 3.7.0.
That only works for properties that belong to pieces, not Global Properties.
How are you changing the bomber cost? I can only see how to ‘Set German Bombers’. Which seems to work.
It worked prior to 3.7 for Global Properties… :<
The “Set Bomber Cost” trait is only defined in the German Bomber piece, but because it is changing a Global Property, it affects both the Allied and German Costs.
I don’t see how this can possibly have worked before, it certainly wasn’t designed to, nor was I aware that this was happening. Global Properties should never appear as an oldXXXX value.
I will look into this but it looks like a inadvertent bug/feature.
I build a lot of functionality around what appeared to be a deliberate consistent feature of Vassal.
Whether a property is a local one or a global one, it is useful to be able to change it and still have access to the previous value.
I’m not trying to be difficult, but I don’t see any rationale to why this isn’t just as valuable for a global property as a local property…
I honestly thought this was a deliberate feature of Vassal and have made significant use of it… I would expect other modules do also…
Ok, So, it was definitely a bug and should never have happened. It’s leakage from the Set Global Property trait. Part of the problem is that it is not consistent, If a piece does not have a SGP for a Global Property, then it will not have an oldName value for that Global Property, even if it causes the value of that GP to change, say by issuing a GKC from trigger to cause some other piece to change the GP.
However, I agree, I think it is now ‘assumed functionality’, or whatever that term is and will have to be reverted.
I suggest that for 4.0, every property local/global/system should allow the use of consistent syntax for calling the previous value (i.e., oldXXXX).
BTW - FWIW, this reminds me of an earlier similar problem (which you were kind enough to fix for me), whereby “oldMap” was not defined if a unit had never been moved, so if you deleted it, you couldn’t report it’s original location.
So again, for 4.0 - suggest that upon initialization of a property (local/global/system), both the $Property$ and $oldProperty$ always be set.
Proving once again, the cliched (but eternal) truth in software development…
It’s not a BUG, it’s a FEATURE!
Fix is lined up for 3.7.2
The fix is merged; every development build from here on will have it, and it will appear in 3.7.2 when that’s released.
Just to confirm, for Global Properties, the $oldProperty$ will only be set if using “Set Global Property” and not if using any of the other mechanisms (e.g., the new Scenario Options, for for instance). Answer won’t affect my module, but will be for future development awareness…
Yes, that is correct. The creation of the oldProperty value is an unintended side-effect of Set Global Property, there is no way to generalise it for all Global Properties.
Thanks Brent, that was my expectation.
However, for 4.0 I definitely would like to see both Global and Local properties have the ability to call the previous value via the “oldXXX” construct, regardless of how the global/local property is changed…