# Calculated Property slows down VASSAL excessively

When editing the module, the following Calculated Property slows down VASSAL excessively:

If(\$TPPBC\$ + \$d12_result\$<10,0,If(\$TPPBC\$ + \$d12_result\$<13,1,If(\$TPPBC\$ + \$d12_result\$<15,2,If(\$TPPBC\$ + \$d12_result\$<17,3,If(\$TPPBC\$ + \$d12_result\$<19,4,If(\$TPPBC\$ + \$d12_result\$<21,5,If(\$TPPBC\$ + \$d12_result\$<24,6,If(\$TPPBC\$ + \$d12_result\$<27,7,If(\$TPPBC\$ + \$d12_result\$<30,8,If(\$TPPBC\$ + \$d12_result\$<34,9,If(\$TPPBC\$ + \$d12_result\$<38,10,If(\$TPPBC\$ + \$d12_result\$<42,11,If(\$TPPBC\$ + \$d12_result\$<47,12,If(\$TPPBC\$ + \$d12_result\$<52,13,If(\$TPPBC\$ + \$d12_result\$<58,14,If(\$TPPBC\$ + \$d12_result\$<64,15,16))))))))))))))))

Is there a way to simplify the above expression or is it possible to circumvent the expression evaluation process of the trait?

Congratulations,

You have found Vassal’s dirty little secret

Too many traits in a single components tree (fully expanded when including prototypes) or overly complex trait routines grinds vassal down to a crawl making it unusable.

This is due to the engine architecture in how it works.

There was a great thread worth reading we had on why things did what they did back when I first discovered the boundaries (my big contribution - doing things no one expected them to do with traits), and eventually was a partial reason for the need/decision to make Vassal4 differently so this would be one thing that does not happen.

Unfortunately it is not on these forums. I seem to recall it either took place privately between us or it was on the old Yahoo Vassal user group which seems to have disappeared to the ether. It is probably in our email archives somewhere, but I dont have access to them at this moment.

In a nutshell, the quick fix was that if you were going to do something super complex that grinds vassal down, you are probably better off writing a custom class to do the work for you until V4 is made that fixes the issue in the meantime.

Okay, me next question will have to do with custom classes. Having next no idea of Java, this migth take a while.

The slow reaction, btw., was not to be whitnessed when using the module.

Ah well Im actually referring to the actual running of vassal, not editing. There is no reason why it should hang there

It does for minutes, while editing.

I can attest to this hidden flaw.

When adding new functionality to the Star Wars Armada module, I experienced this slowdown effect, and for the longest time I couldn’t figure out why.

Vassal is an interpreted system running an interpreted version of Java to evaluated Calculated Properties. There is a limit to what you can do. If you have a very complex property and that property is used to, say, set the layer number of a Layer trait, and you have have lots of counters with that same setup and you are manipulating the screen as you normally do and so each piece on the screen is being redrawn multiple times per second, then you can quickly have that one particular complex Calculated Property being re-evaluated hundreds of times a second and you have a problem.

Try not to use Calculated Properties for things that calculate the same value again and again. Every time a CP is referenced, it has to calculate its result again from scratch. It can’t ‘know’ whether or not the variables you reference have changed. Your example looks like it is doing something with a Die Roll. Calculate the value just once when the die is rolled and store the result in a Dynamic Property, which are reference extemeley quickly.

Rgds.

PS. V4 is not going to provide a fix for this problem. It will contain an interpreted scripting language that will suffer from the same problems if used incorrectly.

Besides writing a custom java class which I’m at present not capable of doing, what would be the correct way, Brent, if using my calculation is an abuse.

I managed to find a workaround, one that used a much simpler setup of Restrict Commands and Report Action using oldLayer X_Name.

If anything it helped me learn something new

It depends on what you are using the Calculated Property (CP) for and what the variable TPPBC is, how often it changes and where it is stored. The CP must be continually being referenced, so we need to change that so it is only calculated once and the result saved in a Dynamic Property (DP) which will take the CP’s place in your logic.

You have a die called d12, the result of which is the main driver in the CP. How is it rolled? Can you change it to use a Multi-Action button to roll the die, then do the big calculation and save it in a DP. The Multi-action button would probably have to roll the die, then send a Global key Command to all counters to tell them to set the DP to the value of the CP.

If TPPBC is also changing, then you will need to do a similar thing whenever it changes value.

Rgds.

TPPBC is the firepower of units in a zone;

d12 is a d10 rolling for the combat result in that zone.

The CP is used to factor in the combat results table: a if d10 + firepower = x, y hits are scored (an array would do the same thing but i have no idea if I can use one in VASSAL).

Each CP is used for exactly one counter, the one showing the result in its label.

Ok, that’s the worst possible case. Every time every counter is redrawn, the CP is re-evaluated, even though the die might only be rolled once a minute.

As I mentioned above, you need to change the flow around so that the CP in each counter is re-evaluated just once each time the die is rolled.

Use a DP to display the value and reference it in the label. Add a Key Command to the DP that sets the value of the DP to the value of the CP. When the die is rolled, send a Global key Command to all counters to fire off the DP Key command.

Now, every time the counter is redrawn, it just displays the value of the DP in the label. The CP is only invoked when the die is rolled to update the DP value.

Rgds.

I see where the problem is. I’ll try that. Many thanks.