Both have a CEL dynamic property with initial value 11 max value 11 and min value 7 with key commands to increase value by +1/-1.
Both have a set piece property to access the CEL property from the other piece with the same key commands.
Both have a layer to show the value with follow expression.
It works perfectly as long as I do not try to go above or below the min/max values.
Let’s say that from the 11 starting point I decrease the value by 1: both pices now show 10.
But if from the same 11 starting point I increase the value by 1 then decrease it by 1 and then by 1 again, the original piece does show 11-10-9 which is expected. The attached piece does show 11-11-10… As if the set piece property was able to increase the value of the attached piece to 12, above the intended max value.
I have a module + scenario that I can share to demonstrate this behaviour if needed.
I found the problem: the dynamic property had “is numeric” checked but not the set piece. If I also chek “is numeric” for the set piece property, then everything is all right. No more going out of bounds.
Not sure what is the intent of this check box in the set piece property. Set piece property should just use the same type as the dynamic property. Otherwise strange things might happen.
This is something I thought about, but never got back to fixing.
Agreed, there needs to be a way to reference an existing numeric constraint on the target property(s).
There are 3 modes of operation that make sense:
Use any numeric constraints on the target properties.
Supply a new set of numeric constraints that over-ride those on the target properties.
Ignore all constraints, just set the property to what I say.
Currently, in the SPP if you check the ‘Is Numeric’ box, you get option (2). If you leave it unchecked, you get option (3).
I think we need an additional checkbox that appears when you check ‘Is Numeric’ that asks
‘Use target property constraints?’ defaulting to Yes. If No, then the additional constraints options appear.
I like this. I expected the default option to keep the constraints from the dynamic property. This would be more intuitive. And you still have the choice should you need to over-ride the constraints, with an option which says what it does. Thanks!
It works as intended without me having to adapt anything. Not sure if it is because my 3.7.0 “is numeric” SPP is converted to a 3.7.1 “over-ride unchecked” SPP or because it is always “over-ride unchecked” by default when you open a 3.7.0 module with 3.7.1.
Over-ride unchecked does exactly that. All good.
Over-ride checked + is numeric unchecked (my dynamic property is numeric) does not work. When I reopen the SPP, this setting has not been saved. It went back to what it was before (over-ride unchecked).
Over-ride checked + is numeric checked: same problem. Settings not saved, went back to over-ride unchecked.
Maybe this happens because my SPP wre created with 3.7.0, I don’t know.
There’s a new build VASSAL-3.7.1-SNAPSHOT-e68460a-12679-SPP-Respect-Constraints ready to test which I believe solves the problem.
Note that the correct values are being stored in the piece in the module, so the module should be working correctly, it is just the Piece Editor that is getting confused.
Both over-ride and not over-ride work now. SPP properties are correctly applied.
The only thing I see is that if I have a numeric DP and an over-ride non numeric SPP with increment numeric value type, it works as if I had a not over-ride SPP. But that is probably a theoretical case rather than a practical one.
So, you are saying that the first example still wraps the DP at 11 back to 5, even though you have specified over-ride with no constraints? That should not happen, that should just keep incrementing the target DP past 11.
Edit: I just tried this and could not reproduce this, the over-ridden but unconstrained increment just kept incrementing, Turning off the over-ride and the target DP constraints took over.
