Improve execution speed

[cholmcc]

@steenkh

But I stopped using it and put each row in a single variable because it seemed that the strings have a rather low limit

I don’t think properties have an upper limit on the number of characters that can be stored in them. Even if it did, it will be highly unlikely that you would ever reach that limit.

@steenkh

and I also found that it was too difficult to debug if I had typed a wrong value somewhere in a huge two-dimensional array.

That is why I create most of the modules I’ve done with pywargame. Using that Python module, I write the entire module in Python code in which it is far easier to encode arrays and the like. After all, a module is really only one XML file (buildFile.xml) - actually two, but moduleData is trivial - and a bunch of images, put together in a ZIP archive.

@steenkh

I am warming to the idea of putting code and tables in invisible counters.

There’s a relatively important thing to keep in mind with regards to Global Properties and piece properties like Dynamic Property and Marker trait properties. The values stored by Global Properties are only minimally encoded to be stored in the XML buildFile.xml and when in memory. Properties stored in pieces have to be encoded for them to be stored in the rather obscure trait encoding. That means, that certain characters can be a problem in the trait property values.

One way I’ve encoded “tables” like Combat Results/Resolution Tables (CRTs) is that I have markers for each column, and that marker then contains that column of the table only. You can see how that works in most of the modules that I’ve done. Take for example Anzio Beachhead.

• A user selects the belligerents of a combat and then presses Ctrl-X.
  • First, a battle marker is placed on the belligerents, so as to easily identify the combat participants.
  • The module then calculates the total Attacking Combat Factors (ACF) and total Defending Combat Factors (DCF), possibly taking terrain or features into account.

    • Terrain and features are stored in global properties. For example, all woods hexes are stored in a global property like

      • Property: WoodsHexes
        • Value: "|01@23|02@23|05@43|...|10@50|"
          (assuming grid number separator is set to @).

      To see if a piece is in a woods hex, the code will do

      • Calculated Property: InWoods
        Expression: {WoodsHexes.contains("|"+LocationName+"|")}

      This can then be used like

      • Calculated Property: EffectiveDF
        • Expression: {(InWoods ? 2 : 1) * DF}

      where DF is a for example a Marker trait property.

  • It then calculates the odds, again taking possible odd shifts into account.
  • An odds marker is then placed on the first defending unit.
    • This odds marker knows the CRT column of the odds it represents - no more.
• The user can then select the odds marker and press Ctrl-Y
  • The odds marker then rolls the dice
  • It then looks up the result of the combat in the column of the CRT
  • It replaces itself with a results marker.
• Now the user(s) need to implement the result by manually applying step losses, eliminations, retreats, and so on.
• Finally, the user may clear the combat markers by selecting one of them and pressing Ctrl-C, or they can wait and let the module automatically clean them up at the end of the current phase.

Although this requires a fair bunch of traits, it is no where near 100 - more like 10 or so.

@steenkh

There is one area that has caused a lot of little extra code: the tendency of Vassal to think that LocationNames (hex numbers) are numbers where it removes leading zeros. I have several methods to overcome the problem, but the most effective seems to store all locations appended to a “Z”, like “Z0568”, and then remove the “Z” just before using the location. I have searched here for a better solution, but I haven’t found anything. If you have a solution, I would be grateful.

The setting Preserve leading zeros in Integers in the module Global Options in some sense circumvents the need for this. If this option is enabled, then all values are treated as strings, which means a LocationName like 0123 will have the value "0123". You can of course always get back integer values if you like with something like

{Integer.parseInt(LocationName.substring(0,2).replaceAll("^0*",""))}
{Integer.parseInt(LocationName.substring(2,4).replaceAll("^0*",""))}

See also this thread.

Another option is to define the column-row separator in the Grid Numbering. For example, if you set that to @ (do not use : because that can cause problems with the trait encoding), then LocationName will be something like 01@23 which still needs to be parsed out to get the column and row numbers

{Integer.parseInt(LocationName.substring(0,2).replaceAll("^0*",""))}
{Integer.parseInt(LocationName.substring(3,5).replaceAll("^0*",""))}

but other properties that hold numbers will still be treated as numbers.

All in all, it sounds to me as if your strategy for the module implementation is a bit off. I think that you are perhaps choosing some complicated techniques which end up hurting performance and maintainability. If you can post a draft of your module somewhere - perhaps even make an entry in the Game Libary, making sure to note that this is work-in-progress - for example with a release number like 0.0.1-draft, then others may take a look and give suggestions on better techniques to achieve what you want to achieve. If I have the time - no guaranties - then I might. Of course, if you use third-party copyrighted materials, you should make sure you have license to share those materials.

Yours,
Christian