Manually building the buildfile

Due to the high number of counters in my game, I build manually the buildFile. This works all fine, but I would like to understand better the encoding of pieces (counters) in the buildFile. I understood (mostly) all
of the ; encoded sequences, but there is also a sequence encoded with tab characters and \ included that I do not fully grasp. Right now, I must design every piece and copy the code (with modifications). If I could understand this final layer (or initial layer) of encoding, I could progress much more quickly. Any help somewhere? (yeah I downloaded the code, but it’s a bit too large to grasp like this).

Thus spake “jcdubacq”:

I can’t help you with this, becuase at present I don’t understand it myself.
One of my long-term projects is for everything in the buildFile to become
human-readable. This doesn’t help you right now, but might help you sometime
in 2009.


Messages mailing list …

Post generated using Mail2Forum (

The format is +/type/state where ‘type’ is the type of the GamePiece and ‘state’ is its state.

To build the type:
Start with the type of the BasicPiece
For each trait:
type = <trait’s type> + ‘TAB’ + <type with every ‘TAB’’ replaced with ‘TAB’>

where TAB is the tab character: ‘t’

You end up with something like "trait3-type TAB trait2-type TAB trait1-type TAB basic-piece-type

Same thing for the state.


Post generated using Mail2Forum (


I, and others, have had success manually building the buildfile, but not building up each piece from scratch, that is too hard.

If I have 50 (or 500) pieces that are almost the same, I build the first two pieces using standard Vassal and save the module. Then I examine the buildfile and work out what is changing between the two counters.

Then I create multiple copies of that counter and change each line as appropriate. For small numbers of counters ( <100) I just do this manually. For large numbers of counters, I have had success using Excel to build up lines. Others have had success with Perl.

Hope this helps,

Messages mailing list …

Post generated using Mail2Forum (

Rodney has described it well. The ADC2 importer does a lot of direct manipulation of type and state strings. One thing you have to watch out for is semicolons and backslashes. They are escaped with a backslash. The reason you occasionally see a huge number of backslashes is that info is often nested. For example, if you have a replace trait, the unit that is to do the replacing is embedded in the string, but its own semicolons and slashes are escaped.

If you are interested in looking at the source code, take a look at Each property and trait uses this to encode it’s type and state.

That’s probably more information than you need, but I had to work all this out myself relatively recently.

  • M

2008/8/20 Rodney Kinney < (>

Post generated using Mail2Forum (

My own findings concur with that (except that the backslashes were removed at some point in your post: TAB is replaced by Backslash-Tab).
The basic type is always null. And for what I use, apparently, State is always empty (therefore resulting in a succession of tabs and backslashes). Thank you for the insights (I had not understood the type/state separation).