Technobabble: I deserialize objects from the .vsav and look at their class to decide if it's something I'm interested in. Most of the time, pieces seem to be stored as objects of type DynamicProperty, but sometimes Hideable (this seems to happen with some 1/2" pieces), sometimes Clone, I found one piece that was stored as an object of type FreeRotator (?!) I'm probably going to make the list of recognized classes configurable, but I was sick of tracking this stuff down and just wanted to push the release out :-/
I honest haven't looked at what you're doing here, and maybe you already understand how VAS(SA)L saves and loads the pieces, but I can shed some light on what you're seeing here and why.
VAS(SA)L pieces are composed of a series of traits. If you open up the VASL editor and click on a piece you can see the set of traits that piece is using
[EXC: many traits are inherited via prototypes, but that can be ignored for this discussion].
Pieces are not stored as objects, but as a text string that represents the set of traits it is using. If you open up the buildFile you'll see the default text string for each of the pieces. Here's the prep fire counter as an example:
<VASSAL.build.widget.PieceSlot entryName="Prep Fire" gpid="0" height="48" width="48">+/null/prototype;DBGlobal AreaOfEffect;;30;0;true;;;Night;true;;\ label;76,130;Label;10;255,255,255;0,0,0;t;0;c;0;b;c;$pieceName$ ($label$);Dialog;0;0;TextLabel;\\ emb2;;0;;Flip;2;F;;0;;;;0;false;0;0;MS\/FirePrep,MS\/FireBnd,MS\/FireOpp,MS\/FireAdv;Prep Fire,Bnd. Fire,Opp. Fire,Adv. Fire;true;;;;false;;1;1;true;;70,130;\\\ piece;K;D; ;Prep Fire/ \ \\ 1\\\ null;0;0;0</VASSAL.build.widget.PieceSlot>
When you save a VAS(SA)L game, each piece is saved in that format, minus the XML wrapper, but including is current status (e.g. if it is flipped). Here's the important part: when you load that game VAS(SA)L fires off a command for all pieces in the save file, and for every trait possessed by each piece. Each of these are recreated in VAS(SA)L by creating a Command object for that trait. VAS(SA)L listens for these commands and uses them to recreate each piece.
If you want a fail-safe way to know what's in a save file you want to listen for these commands when the file is loaded and then inspect the command text to get the details you need to add your setup data. Again, I don't know what you're doing under the covers, but it seems you need to find the command that identifies each piece and then key off of that.
An example of how to listen for commands is located here:
https://github.com/vasl-developers/vasl/blob/develop/src/VASL/build/module/map/PieceLinker.java
In this example the PieceLinker listens for the "link piece" command so it can recreate the links when the game is loaded.
If you try to inspect the piece by checking it's "object type" you're in some muddy waters. It's going to be hard to explain, but VAS(SA)L uses what's called a "decorator design pattern" where each trait "wraps" the previous trait (and therefore the previous class) as a decorator, creating an onion effect of classes within classes all the way down to the first trait. If you look at the class of a piece it's going to show you the class of the outer-most trait. That's why some pieces are "dynamic properties" and others are "free rotators:" these are all just the outer-most decorator. And if a piece changes, like someone adds a trait, your logic is going to break.
-Sully