For several years now I have used a javascript program to generate the counters, using Adobe Illustrator. The JS program calls the graphics API on AI and draws the counters. The advantage for me was that I could easily change the design, or the counter information.
I need to create a Vassal module of the game for external playtesting, we have been using hand-assembled cardboard & paper playtest kits for internal playtesting, but I have been advised to also create a Vassal module.
So, I have ported my counter generator to create SVG graphics instead (see attachment, a subset of the Entente forces). My goal is to extend the program to also auto-generate the XML definition of the counters within the Module file. I unzipped and untarred a module and looked at the build file, and could reverse engineer the xml format. I can generate the hierarchy of counters, my code is already organized as a class hierarchy that matches the Order of Battle. I would just create the module file with perhaps one counter, then open it up in a text editor and drop all the counters in. The XML would refer to images in the subfolder, and they will also be auto-created.
My question is whether there already is a bulk loading interface, and am also looking for general comments on the approach.
(In case it is not obvious I am a software engineer by trade).
cheers
Geoff
[attachment=0]Screen Shot 2015-02-23 at 9.32.10 PM.png[/attachment]
Under the game piece palette there is a command to add multiple pieces - this is the mass piece loader, you may want to check its documentation to see if this fits your needs in any way
Having written several Perl scripts to bulk edit the buildFile (eg : swap sides of all counters, add a zone for each hex on a map, …) I heartily support this approach. Computers are meant to quickly and flawlessly perform repeated tasks that would bore us to death if we had to do it manually… And I cannot say that I like the Vassal interface for editing modules (several features that I consider crucial for editing are missing or poorly implemented). [I don’t want this to sound like a harsh criticism of the developers, I know it is a hard job to do and I am unable to develop something similar]
Thus, whenever I need to do something many times in Vassal, editing the buildFile is often my favourite way (even if it’s just a bunch of copy/paste that don’t really need scripting).
However, you may run into trouble with prototypes (aka abstract class inherited by the counters, in a programmer’s language) or heavy use of properties like markers (‘constant’) and dynamic properties (‘variables’). Last time I checked, the counters were stored in a mix of XML and csv, the csv inside the XML obviously being used to store prototypes, markers and such. The XML is easy to understand. I did not bother to fully reverse engineer the csv. And given your background, there is probably no need to emphasize the extreme usefulness of prototypes for a clean and maintainable design…
I remember someone saying that soon the buildFile will be pure XML…