WIN64
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?
Thanks.
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.
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.
Cool.
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.
Thanks muchâŚ
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âŚ
