Page 5 of 7
RE: Fixing some problems with 0.5a
Posted: Mon Jan 07, 2008 9:42 pm
by Roger Neilson II
ORIGINAL: Woos
A new version (0.5a) is available from
http://extweb.retsiemuab.de/witp/witpdecoder0.5a.zip . It is the whole zip file (and not only the jar) since I also included a new version of hsqldb.jar (although that didn't help with the Load Batch problem)).
Fixed:
- CHS 157/158 problem: Now witpDecoder simply uses 127 as durability and warns you about it.
- Scenario 2 & 5: Missing HQs for Airgroups are now allowed, so the scenarios should load. Be aware that if all planes of one type have missing HQs, they will only show in the "AC classes" tab if "All nationalities" are selected.
- Load Batch might now work. I could reproduce Martti's problems with the Allies and "fixed" it by increasing the checkpoint frequency. Of course that is not really a fix but it seems to work now.
- On special request from VSWG the numbers of Ships Available/Building/Sunk are now listed per class in the "Ship classes" tab. Note that for witpdecoder each update is an own class, so to see all ship, select the "All" choice for "Availability". Otherwise you will not see ships building for future updates and (once you have updated) won't see ships of out-of-date classes anymore.
Ok worked fine for a week or so of game time then I get this new message....
Roger
RE: witpDecoder 0.5 released
Posted: Mon Jan 07, 2008 10:09 pm
by Nomad
ORIGINAL: Historiker
ORIGINAL: Mistmatz
ORIGINAL: Historiker
I wanted to use it for 075 RHS EOS
I used the database editor to change the 271 and removed the " " in it.
Now this message is coming:
...
I learned that WitPload does not handle the RHS scenario files correctly (at least RHSCVO scen. 70). WitPExcel on the other hand seems to work but is not compatible with the decoder.
When I have some spare time I'll try to input the WitPExel data into the decoder, I believe this should work, see also my above postings.
Btw. initially I had the same message you have historiker and it was _NOT_ due to circular upgrade paths, or at least not with class 800.
What would have to be done to make the Decoder usable for RHS?
Could you send me the senario files you are using? nomad(dot)pbem(at)gmail(dot)com
RE: witpDecoder 0.5 released
Posted: Tue Jan 08, 2008 1:23 am
by Nomad
If people will read things, this would be a lot easier. ship class 800 in senario 75 upgrades to ship class 1700. Ship Class 1700 is undefined. change ship class 800 to upgrade to itself and the DB will initialize with three warnings about three different ship classes having more than 127 torpedeos. I do not know if Cid wanted that or not - I don't know if it is an error or design.
the bottom line is if you will read the error message and fix things RHS is usable with WitPDecoder.
RE: Fixing some problems with 0.5a
Posted: Tue Jan 08, 2008 4:39 pm
by Mistmatz
Woos, could you please elaborate in which order the files from witpload (or in my case the local ones) are read in?
I'm getting the message:
Could not create or initialize the databasejava.sql.SQLException: bad TEXT table source file - line number: 81 Attempt to insert null into a non-nullable column: column: NAME table: WITPSHIP in statement [
SET TABLE WITPSHIP SOURCE "WITPcls.csv;ignore_first=true"]
java.sql.SQLException: bad TEXT table source file - line number: 81 Attempt to insert null into a non-nullable column: column: NAME table: WITPSHIP in statement [
I checked the ship file (esp. around line 81) and couldn't find any problems. But maybe the problem is in one of the files it is depending on, eg the classes file?
RE: Fixing some problems with 0.5a
Posted: Tue Jan 08, 2008 7:01 pm
by Woos
ORIGINAL: Roger Neilson II
Ok worked fine for a week or so of game time then I get this new message....
I should make you beta tester.
The factory update routines were rewritten for 0.5a and what you have seems to be a problem with them (you shouldn't get that problem with 0.5). Please send me the usual stuff (save game, .csv files, password if necessary) PLUS the previous save game (this is an update problem so I need the previous state of your database). If you don't have that anymore please tell me. I will then have to try to find the problem by hand.
*edited* Wrong numbering of versions. 0.5a has the new routines, 0.5 should be the version without the problem
Mistmatz
SET TABLE WITPSHIP SOURCE "WITPcls.csv;ignore_first=true
You have a problem in WITPcls.csv (which is the ship classes file, not the ship file). Most probably you edited it with a spreadsheet program (yes, I know I suggest everyone to use one to avoid syntax errors) which removed some cells only containing a blank so those fields are now empty (i.e. you will see two commas directly after each other). As that would constitute a NULL value and the DB does not like those values, you get the error. If you look closely at the error message you will see that the column in question is the NAME column.
RE: Fixing some problems with 0.5a
Posted: Tue Jan 08, 2008 10:41 pm
by Mistmatz
You're right Woos, should have read the whole message...
Nevertheless I went ahead and came back to the famous ship class 800 issue. No cycle here and when I change it to upgrade to itself the next time I get a complaint about 799 and 800.
Fixing 799 leads to complaint about 798, 799 and 800 and so on.
So I checked and class 800 is not used in the ships file at all. Could that be a problem or should the decoder handle that?
RE: Fixing some problems with 0.5a
Posted: Wed Jan 09, 2008 8:27 pm
by Woos
You get the error with class 800 because it does not get added to the Database. You get the "wrong" message (about the cycle) because witpDecoder assumes a correct set of ship classes (i.e. classes updated to also exist) and assumes all problems stem from cycles.
The DB initialization routine for ship classes first inserts all ship classes into the DB which update to itself (or nothing) as those are the end of the upgrade paths. In further passes all classes are inserted which upgrade to classes already in the DB until such an insert does no longer expand the Db (i.e. a fixpoint is reached). Then it is checked whether all classes in the .csv file are also in the DB. If not their class numbers are shown.
This ensures that the DB is cycle free and that the join I precompute is really precomputed. (In the very first versions of witpDecoder things were read in linearly much faster but then modders started to upgrade ships to lower numbers so linear reading didn't work anymore ......)
I don't know why you get problems with 799 after you fixed 800, but either you created a cycle or some other problem. If class 800 is really not used by the scenario you can remove it without problems (witpDecoder knows nothing about class usage during DB initialization as that is only apparent once ships are added and those are only read from the save file).
Best is to not use witpDecoder with RHS.
RE: Fixing some problems with 0.5a
Posted: Wed Jan 09, 2008 10:32 pm
by Mistmatz
ORIGINAL: Woos
You get the error with class 800 because it does not get added to the Database. You get the "wrong" message (about the cycle) because witpDecoder assumes a correct set of ship classes (i.e. classes updated to also exist) and assumes all problems stem from cycles.
The DB initialization routine for ship classes first inserts all ship classes into the DB which update to itself (or nothing) as those are the end of the upgrade paths. In further passes all classes are inserted which upgrade to classes already in the DB until such an insert does no longer expand the Db (i.e. a fixpoint is reached). Then it is checked whether all classes in the .csv file are also in the DB. If not their class numbers are shown.
This ensures that the DB is cycle free and that the join I precompute is really precomputed. (In the very first versions of witpDecoder things were read in linearly much faster but then modders started to upgrade ships to lower numbers so linear reading didn't work anymore ......)
I don't know why you get problems with 799 after you fixed 800, but either you created a cycle or some other problem. If class 800 is really not used by the scenario you can remove it without problems (witpDecoder knows nothing about class usage during DB initialization as that is only apparent once ships are added and those are only read from the save file).
Best is to not use witpDecoder with RHS.
Thanks for your explainations and support Woos.
Not using the decoder with RHS is simply no option, this tool is just too valuable to not use it. [;)]
When time permits I'll continue working on this issue, I'm still optimistic.
RE: Fixing some problems with 0.5a
Posted: Thu Jan 10, 2008 11:54 am
by Historiker
What to do?
RE: Fixing some problems with 0.5a
Posted: Sat Jan 12, 2008 9:29 am
by Roger Neilson II
Sorry, been away.... will pull the stuff together over the weekend and get it to you.
Roger
RE: Fixing some problems with 0.5a
Posted: Sun Jan 13, 2008 12:33 pm
by KTNJR
Does this work with Big B games?
RE: Fixing some problems with 0.5a
Posted: Sun Jan 13, 2008 12:46 pm
by BigBadWolf
It does.
RE: Fixing some problems with 0.5a
Posted: Sun Jan 13, 2008 1:25 pm
by cantona2
Just like to say that i love the enhanced features in the map section of this version. Many thanks to the powers that be
RE: Fixing some problems with 0.5a
Posted: Sun Feb 10, 2008 9:37 pm
by bobogoboom
silly question but will the decoder work with wpo?
RE: Fixing some problems with 0.5a
Posted: Sun Feb 10, 2008 9:54 pm
by Helpless
ORIGINAL: bobogoboom
silly question but will the decoder work with wpo?
no
RE: Fixing some problems with 0.5a
Posted: Sat Mar 08, 2008 7:52 pm
by Martti
I get the following error:
Couldn't write things to the DB due to java.sql.SQLException: Integrity constraint violation - no parent AGsMissionMustBeKnown table: AirGroups
The error appeared after I converted some airgroups into kamikazis.
witpDecoder bugs
Posted: Thu Mar 13, 2008 9:45 am
by herwin
1. Reports missing captains for a number of units and ships in the build queue.
2. Treats an upgrade number of 0 (which means no upgrade) as an error.
3. Generating an SQLException--"Ships4History already exists". The table exists, but is apparently unpopulated. This is a show-stopper as it aborts the update.
RE: witpDecoder 0.5 released
Posted: Thu Mar 13, 2008 9:49 am
by herwin
ORIGINAL: Historiker
I wanted to use it for 075 RHS EOS
I used the database editor to change the 271 and removed the " " in it.
Now this message is coming:
That's because 800 doesn't upgrade, and witpDecoder doesn't respect the code for doing that. Use the database editor and set it to upgrade to itself.
RE: witpDecoder 0.5 released
Posted: Thu Mar 13, 2008 9:50 am
by herwin
ORIGINAL: Mistmatz
ORIGINAL: Historiker
I wanted to use it for 075 RHS EOS
I used the database editor to change the 271 and removed the " " in it.
Now this message is coming:
...
I learned that WitPload does not handle the RHS scenario files correctly (at least RHSCVO scen. 70). WitPExcel on the other hand seems to work but is not compatible with the decoder.
When I have some spare time I'll try to input the WitPExel data into the decoder, I believe this should work, see also my above postings.
Btw. initially I had the same message you have historiker and it was _NOT_ due to circular upgrade paths, or at least not with class 800.
Add scen 71 to the list.
New WITPDecoder plugin
Posted: Sun Apr 06, 2008 2:05 pm
by Martti
I have created a new (and I believe first) plugin for the excellent WITPDecoder. The plugin gives you at-a-glance view of where your LCUs are preparing for. While the WITP already gives you this information, this plugin shows you the same information in a (hopefully) quicker way.
Instructions: download the plugin files from
http://koti.mbnet.fi/~zombie/WITP/WitpD ... Plugin.zip and unzip the contents into <witpdecoder>\de\retsiemuab\witpDecoder\gui\mapviewPlugins (yes, you need to overwrite the existing TestPlugin.class file).
Next run the WitpDecoder and select Map OverView. In the primary data dropdown list you should see an entry "LCU prepare data". Select it and you should see circles in your screen showing where your LCU are preparing. Only units preparing for other bases (ie not the base where they are) are shown. The opaqueness of the cirle represents the average preparedness of the units, opaque=100%. The units are treated equally when calculating the average, an NLF counts the same as a division. The size of the circle shows the number of units preparing for that base. Clicking on the base shows you the details.
Hopefully this will be of some use.
The source code is also available:
http://koti.mbnet.fi/~zombie/WITP/PrepData.java and
http://koti.mbnet.fi/~zombie/WITP/TestPlugin.java.
Also if someone has ideas for further plugins but lacks the skills to implement them, I might be willing to help.