Create account / Log in

Calculated properties

Talk about module design ideas and techniques.

Moderators: Tim M, uckelman

Calculated properties

Postby panther 2010 » April 1st, 2014, 5:50 pm

Hi

please, can someone out there explain how a calculated property really works ?

A few examples of the various very interesting features will be greatly appreciated!

Thanks in advance.

Panther 2010 :)
panther 2010
 
Posts: 95
Joined: July 18th, 2010, 3:04 pm

Re: Calculated properties

Postby Sebaestschjin » April 11th, 2014, 4:33 pm

Okay, I try to explain what those CalculatedProperties are good for, based on my own experience with Vassal so far.

Roughly spoken a "CalculatedProperty" (CP from now on) as similar to a "DynamicProperty" (DP form now on) which is set to "Set value directly", but with one important distinctions: It doesn't need a trigger to change. It will change immediately whenever a property of the associated expression changes. The expression of a DP will be calculated only once, for every trigger it receives. A CP will always be recalculated. I think a CP best works togehter with the "GetProperty()" function you can put into expressions. I can try to demonstrate this with an example I am using for my module.

I have a deck of cards. Each card has two different properties (triangle and circle) where each property can have a value between 0 and 5. I now want a label between the deck which counts the number of cards in the deck where the triangle property equals 1. This can be done with the deck option "Perform counting of property expressions". And I then can use a TextLabel with the name of the property as its value. However now I want a button which changes the content of the label. When I press the button, the label shouldn't print the number of cards where the triangle property is 1, but where the circle property is 1. That's where the CP with the "GetProperty()" function comes into play. My CP is specifyed as:

Value = GetProperty($DeckName$ + "_" $Property$)

And the Textlabel I mentioned before now has the content: $Value$. My button now changes the property $Property$ to "Circle" which immediately leads to a reevalutation of $Value$ and the new value can be seen in the label. Of course you could also use a DP instead and set the property $Value$ within the DP, but the power of the CP is its flexibility. I combine different CP within a prototype, which each calculate different stuff, depending on the properties given. I need this type of calculation in different places of the module but based on different concrete property values. So I use this CP in a prototype and add marker traits to the pieces where I need the calculation results. This way I can easily use expressions within a gamepieces without worrying abouts where they come from.

I hope I somehow could make clear, what I mean and what the benefits of CP are. I think they are bessed used in prototypes that perform typical calculations you will need in different places of your module. If you want I could make a sample module including the example I talked about. It's actually a little more complex than I explained, but I wanted to keep it as short as possible.
Sebaestschjin
 
Posts: 23
Joined: April 10th, 2014, 10:49 am

Re: Calculated properties

Postby Brent Easton » April 11th, 2014, 10:57 pm

please, can someone out there explain how a calculated property really works ?


By Calculated Property, I am assuming you mean the Dynamic Property trait? A Dynamic Property is like a cell in a spreadsheet with a formula in it. Whenever you use the value of the Dynamic Property, it recalculates its value based on the formula and the values of the other properties it references.

I think the previous comments about 'Dynamic Properties' where actually about Global Properties which are holders for values that you can set specifically by trigger.
User avatar
Brent Easton
 
Posts: 2757
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: Calculated properties

Postby Sebaestschjin » April 12th, 2014, 8:17 am

No, I think you mixed up the both terms. Both traits are available for game pieces, "Dynamic Properties", which change on triggers and "Calculated Properties", which are, as you described, similar to spread sheet cells. "Global Properties" behave similar to "Dynamic Properties" as they can only change on triggers.
Sebaestschjin
 
Posts: 23
Joined: April 10th, 2014, 10:49 am

Re: Calculated properties

Postby Brent Easton » April 12th, 2014, 11:47 pm

Well, there you go, I am out of touch. Considering I wrote those traits, it's a bit embarrassing.You are of course correct.
User avatar
Brent Easton
 
Posts: 2757
Joined: December 21st, 2007, 3:06 am
Location: Berry, NSW, Australia

Re: Calculated properties

Postby panther 2010 » April 13th, 2014, 4:09 pm

Hi Sebaestschjin

Thank you very much for your reply.

Well, I will try to explain a bit better what I' m trying to do.

A) In a DP or a GP you can increment the value by a fixed amount (+1, -2 , etc.). I need to use a CP because I want to increment the value of a given property by the value of another property.

I tried :

Property name : Prop1
Expression : Prop1 + Prop2

but this didn't work.

Then I tried :

Property name : Swap
Expression : Prop1+Prop2

followed by : Prop1 = Swap

and this seems to work, at least for now, and only in a test prototype.

B) I noticed the IF feature of CP and tried to use it, without any success. I tried in several ways, but it looks like I always made a sort of syntax error (the "red cross" never disappears"...).

What I want do is this :

If Prop1 = true then Prop2 = X else Prop2 = Y.

It looks very simple, but I'm not able to do this working in no way, at least till now.

Any suggestion and/or working examples would be very appreciated.

Thank you again!

Panther 2010 :shock:
panther 2010
 
Posts: 95
Joined: July 18th, 2010, 3:04 pm

Re: Calculated properties

Postby Sebaestschjin » April 14th, 2014, 7:01 am

Hi Panter2010

To A)
DP can also increment by another given property, not only by a fixed value. The only problem is that you have to take care how you expression looks like. If you simply type
Code: Select all
$Prop$

Vassall will handle this as a string, so it will not use the actual property value. You have tu sorround it with curly braces:
Code: Select all
{$Prop$}

This will be done automatically if you use the expression generator by clicking on the calculator icon. But sometimes I quickly wanted to enter an expression and I often forgot the curly braces which won't work. So maybe this is also the case for you?

Your example of a CP with
Name: Prop1
Expression: Prop1 + Prop2
won't work, because it will create an infinite loop while evaluating the expression of Prop1. Prop1 will be recalculated whenever the properties of its expression changes. Since Prop1 itself is part of its own expression this is always the case.

So you don't need a CP for this case. In principal a DP and a CP are very similar. The only difference is that a DP can only change on a Trigger, so either a click by the user on a menu, or some other key command from somewhere else. A CP is always recalculated. As Brent Easton already said, its behaviour is very similar to a spread sheet cell with a formular.

To B)
The If-Then-Else syntax is as follows:
Code: Select all
If(<expression>,<then-case>,<else-case>)

Where the names in <> are actual expressions. So in your case this would look like this:
Code: Select all
Name:Prop2
Expression: { If($Prop1$ == true, X, Y) }

You have to use == instead of = for an equality check and again the curly braces are needed. What I am not sure about is how Vassal actually handles boolean values. It works in this example but to on the safe side I always use string comparison.

I attached a dummy module which uses all the mechanics I described above, if you want to have a look at it.
Attachments
testModule.vmod
(2.54 KiB) Downloaded 90 times
Sebaestschjin
 
Posts: 23
Joined: April 10th, 2014, 10:49 am


Return to Module Design

Who is online

Users browsing this forum: No registered users and 3 guests