Now that I learned about the next complication in the save file format for bases it seems about time to explain why using a DB with integrity constraints is a good thing and dumping data into a file in various ways as WitP does is bad. Maybe some people at Matrixgames will learn.
WitP save files contain information about bases. Even information about bases not used. Normally a base is not used if its type is set to 0. That is except for dot bases, which use a secondary type indicator, which, if set to "base" even if the primary one is 0, indicates a dot base. That is unless it is a special kind of dot base which even has the secondary indicator set to 0, too. I don't know what is special about them, so the only way to distinguish them from non-existant bases is to check whether they have a position defined. So, to get you all back on track, it is a base
a) if its type is set or
b) if the type is 0 but the secondary type is set or
c) if both types are 0 but the position is set.
Can you still follow? Well, now the interesting question, when is an entry in the save file not a base? You think you know it? Well, forget it. In addition to everything you might think because of the above statements a base is also
not a base if
a) its type is set but
b) its position set to -1,-1.
Completely logical, isn't it? I mean just setting the type to 0 wouldn't have been an alternative.[:@]
Not imagineing such a complication is the reason for the error "Some Dude" reported above and will currently prevent the use of witpDecoder on any restricted scenario (e.g. the Coral sea scenario). * Edit *
Coral Sea scenario will never be supported by witpDecoder. After solving the above problems it turned out that also the Truk
base is used as Headquarter for the "Truk Base Force". Now that is an interesting hack given the WitP save file format but can not be supported in witpDecoder which - for good reasons - dinstinguishes between bases and LCUs.
Now, how did I find it (and why are integrity constraints so great)? Well integrity constraints let you formulate your understanding of the data you intend to store. witpDecoder for example tells the DB that it assumes that all bases will have different positions (quite obvious if you look at the map). Storing the second base with a -1,-1 position into it the DB complains with the exception seen in Some Dude's posting. Result: Report is investigated and error found and fixed instead of lots of headaches later on why other functions don't work as expected.
Using an DB and formulating into it that the leader part of the ship-leader relationship needs to be unique would have found the leader bug long ago. Now it is still in and I can't put that constraint into the witpDecoder DB unless I want to prevent lots of people from using the tool.
OK enough ranting. Answers to the questions:
ORIGINAL:Arkady
So we can assume that security of PBEM is breached.
Please read the section on "PBEM security" in the documentation (available seperately via a link in the first post).
ORIGINAL:Sneer
i can't download new .jar file
object not found error
witpDecoder2.jar was an intermediate version between 0.1 and 0.2. Now that 0.2 is out I removed it since you don't need it anymore (and it would break things).
