buildFile PieceSlot format

I am dabbling with buildFile.

Background: there are >100 cards in the module. The plan is to create a master data file collating all the data related to the cards: id, prototypes, markers and generate directly–based on the master file–corresponding sections of buildFile.

In theory that is quite straightforward.

What puzzles me is the intricate structure of PieceSlot item–who on Earth came up with that?

Read this:

<VASSAL.build.widget.PieceSlot entryName="Reformed Theology" gpid="40" height="0" width="0">+/null/mark;area	mark;id\	piece;;;card033.png;Reformed Theology/The West	33\	null;0;0;</VASSAL.build.widget.PieceSlot>

See, there are markers (name of the marker follows the tag mark followed by a semicolon) but the values of the markers are located at the end of string (so that it is area=The West and id=33). How?

If I was to add few prototypes to that, the structure gets even more convoluted. Anyone could please enlighten me on how this string is generated?

I managed to come up with a simple (?) AWK script that reads a master file of a format:

Inquisition Pope;card029.png;prototype:westdeck,whiteinquisitor;marker:id=29,area=Papal States Papal Elephant;card030.png;prototype:westdeck,whiteinquisitor;marker:id=30,area=The West Grand Inquisitor;card031.png;marker:id=31,area=Portugal

and adds pieces to the deck of my choice directly into buildFile.

Thus spake grouchysmurf:

[This message has been edited.]

I am dabbling with buildFile.

Background: there are >100 cards in the module. The plan is to create a
master data file collating all the data related to the cards: id,
prototypes, markers and generate directly–based on the master
file–corresponding sections of buildFile.

In theory that is quite straightforward.

What puzzles me is the intricate structure of PieceSlot item–who on
Earth came up with that?

It’s generated by VASSAL.tools.SequenceEncoder. The explanation for
it is that long ago—when the program was VASL, before VASL became
a module—XML parsing was too slow. SequenceEncoder was devised to
produce a quasi-binary format that was faster to parse. It’s been
ages since this has been necessary, due to improvements in Java’s
XML parser and increasingly powerful CPUs, but getting rid of it
would mean breaking compatiblity with literally every module, save
file, and log every written. Hence, we’re stuck with it until VASSAL 4.


J.