What works well is stopping the debugger before decode(), then running custom strings through decode() and looking at the output. Or stopping right after encode and compare the command that was encoded to the string that came out of it.
emb2 is “Embellishment” which is the internal name for the Layer trait. It’s the one you will see and the one you want.
emb1 is “Embellishment0”, a legacy earlier-version-of-Layer, which exists for support of Modules From Ancient Times (e.g. pre 3.2.x, I think). You will only see it in very old modules which have never been re-saved under 3.2 versions.
There is a lot in VASSAL that exists to keep old modules running, as that has always been a priority for us.
Brian
@Flint1b - cheers - super helpful advice…
the debugger might be unnecessary if I can get my head around the bits below for prototypes and pieces (output from my buildFile report script)
Prototype: name = Division Cmdr
text = 1+/null/footprint;84,130;Movement Trail;true;true;5;0,204,153;0,204,102;100;50;20;30;1.0
rotate;12;102,130;100,130;Rotate CW;Rotate CCW;;;Rotate Vertex\
emb2;Out-Cmd;2;;Out-Cmd;2;;;2;;;;1;false;0;0;,m_out.gif;,Out_Cmd;true;Out of Command;;;false;;1;1;true;79,130;79,130;\\
emb2;Activate;2;;Div Ineff;2;;;2;;;;;false;-40;0;,inefd.gif;,;true;Division Ineffective;;;false;;1;1;true;65,130;88,130;\\\
emb2;Orders;2;;Orders;2;;;2;;;;;false;0;-40;,m_attack.png,m_march.gif;,Attack,March;true;Orders;;;false;;1;1;true;82,130;82,130;\\\\
emb2;Flip;2;;;2;;;2;;;;;false;0;0;,;,;true;Flip;;;false;;1;1;false;70,130;;\\\\\
markmoved;moved.gif;32;-32;Mark Moved;77,130\\\\\\
delete;Delete;68,130\\\\\\\
piece;;;;/true;;0
0\
1\\
1\\\
1\\\\
-1\\\\\
false\\\\\\
\\\\\\\
null;0;0;and
Piece: id = 1129
name = D.H. Hill Corps
text = +/null/delete;Delete;68,130
footprint;84,130;Movement Trail;true;true;5;0,153,0;0,153,0;100;50;20;30;1.0\
rotate;12;102,130;100,130;Rotate CW;Rotate CCW;;;Rotate vertex\\
emb2;Flip;2;;Flip;2;;;2;;;;;false;0;0;,D_H_Hill_back.png;,+ -repl;true;Flip;;;false;;1;1;true;70,130;70,130;\\\
piece;;;D_H_Hill_front.png;D.H. Hill Corps/
true;;0\
0\\
1\\\
null;0;0;1129
Each trait is separated by a tab character (in the report I show each on its own line for ease). Some traits end with a recursion marker, ‘’ and the recursion depth is the number of markers (the zero-th trait has zero ‘’ markers).
For the prototype we have the
'piece;;;;/
which shows the end of the piece and for the piece it has the piece image and piece name.
And then a line for each of the traits with either true;;0, 0,1,-1,false, or (empty string),
markmoved - false
delete, submenu, - empty string
movement trails - true;;0
the rest - 0,1,-1
and then the final
null;0;0;
with the piece ending in the Piece ID (1129).
Are my above dissections correct so far??
I want to be able to modify a buildFile to:
- remove traits,
- add traits
- modify command names
- modify keyboard shortcuts
Only removing traits and adding traits is dangerous because it changes the number of ‘’ markers needed for the traits that come after, and things have to be added/removed to the end of the string and not just the middle.
Any clue as to what the piece at the end of the string is? When I get it wrong the module gives me a bad Map ID error.
Thanks again, jas…
The serialization code is ancient, and if you continue working on this you are likely to be come the one guy who knows the Vassal’s serialization language 
Sounds so good that it might even make sense to add this to Vassal itself. Either to the module editor, or as an alternative second module editing tool, “Editor++”.
Also, there are plans to create a whole new module serialization system which would read/write modules in JSON.
A very dangerous part of my brain wonders if it isn’t easier for me to write the JSON (de)encoder and then the create the Perl/Python library based on that than it is to reverse engineer the existing (de)encoding system…
OK. Field Report 14 September 2020.
After having loaded VASSAL into IntelliJ and debugged the module loading behavior of game pieces and prototype definitions, I now feel confident on how to describe the structure of the strings in the buildFile.
The components of a piece are delimited by the ‘/’ character and consist of 4 pieces:
[1] The AddPiece token: ‘+’
[2] The piece ID - always ‘null’ in the buildFile
[3] The trait stack for that piece - with each sub-trait separated by ‘\t’ (and the ‘’ chars multiply protected by further back ‘’ chars)
[4] The state info for each element of the trait stack - with the same caveat above for ‘\t’ and protection of the ‘’
So… The long and short of this is there needs to be two stacks - one for the nested traits and the other for the state information for those traits. If any trait is removed, then it’s corresponding state information must also be removed before being reconverted into a string value.
et voila.
This is sufficient for the swiss army knife script I’m writing to convert a bunch of modules. Unfortunately, it is NOT sufficient to use for updating the information for pre-defined setups stored in the module… The savedGame files stored inside the .vsav files are obfuscated text files which are just one long game command string to modify the starting setup…
Dude… Just popping in here to drop an enthusiastic THANK YOU from a guy who’s foolishly mucking around parsing a buildFile to generate custom .vlogs. <3
I haven’t even bothered to fully understand the format used to store game pieces. I expected it to be XML, but it turned out to be some sort of hack to get nested string values quoted into an XML string. Even a simple thing like adding a second Prototype turned out to completely alter the way the string must look like. I postponed reading DataSequence.java for now. I guess most things I need to know are in there, but I also noticed some other values that seems to randomly vary even when I create a duplicate of a counter.