Slitherine

quote:

ORIGINAL: Woos

quote:

ORIGINAL: RAM
yah, got the problem too, I'm trying to load a savegame of the scenario 157, got exactly the same error.

Can't be since other people reported the problem during initialization, not during save game loading.

This is most probably a mismatch between the value range witpDecoder's database expect for some AC attribute and what CHS choose to set it to. Unless someone with this error sends me the generated WITP???.csv files from his witpdecoder directory I can't do anything about it. I got CHS 158c (due to some other issues) and with that the problems doesn't seem to occur.

Oh, and no fix before Christmas anyway, have a nice holiday.

quote:

ORIGINAL: skrewball

Ok I am confused when it comes to the clusterbases and clusters csvs. I am using CHS Scen 155. So can I used one of the included CSVs? 192 has the extended map, should I used that one? How will I know if something is incompatible? Thanks.

quote:

ORIGINAL: 1EyedJacks

Hi Woos,

Does this new version by any chance work with RHS EOS?

quote:

ORIGINAL: Woos
...
* RHS support
Not planned as I fear that too much hacking along the boundaries of the engine went into that mod. Why do you need Ship update cycles anyway (I had to agree some time ago that it is necessary for switching Petes between Fighter and Float Plane so for ACs upgrade cycles are now supported (made reading them in much slower than before)).

quote:

ORIGINAL: Woos

* The "Numeric value out of range" problem (Thanks to Lokal Yokel for the csv files) aka CHS 157/158 problem

This is caused by the "P-61A Black Widow" (Aircraft number 177) having a durability of 129 where I only provided a byte for durability (in stock nothing comes near 128). Short term solution: Edit the WITPair.csv file in a spreadsheet program (Excel or OOcalc) and set the durability of that plane to 127. Afterwards _remove_ witpload.exe from the scenario directory (or rename it). Start WitpDecoder, Initialize Database, Ignore the warning on missing witpload.exe and voila (except of course that the plane will show with a durability of 127 within witpDecoder). Don't forget to bring witpload.exe back into the scenario directory for future DB initializations of other scenarios.

quote:

ORIGINAL: Roger Neilson II

Nope, have edited the spreadsheet as suggested, it does now come up with warning about being unable to find witpload... proceeds but then will not work as before.

Something very odd here.

That's on a completely fresh install of the utility, with the password put in - I'm quite used to all this now!

Roger

quote:

ORIGINAL: Woos
* The "Numeric value out of range" problem (Thanks to Lokal Yokel for the csv files) aka CHS 157/158 problem

This is caused by the "P-61A Black Widow" (Aircraft number 177) having a durability of 129 where I only provided a byte for durability (in stock nothing comes near 128). Short term solution: Edit the WITPair.csv file in a spreadsheet program (Excel or OOcalc) and set the durability of that plane to 127. Afterwards _remove_ witpload.exe from the scenario directory (or rename it). Start WitpDecoder, Initialize Database, Ignore the warning on missing witpload.exe and voila (except of course that the plane will show with a durability of 127 within witpDecoder). Don't forget to bring witpload.exe back into the scenario directory for future DB initializations of other scenarios.

Long term solution: Change the DB schema. Before I do this, I would be interested in feedback from someone in CHS who defined the numbers whether that value is really as intended. The durability data in the .csv file I got really looks skewed: The Black Widow is closely followed by 3 Beaufighters and a Ventura. The B29 is on place 23 with about 15% less durability than the Black Widow.

• 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.
  

quote:

ORIGINAL: Andrew Brown

quote:

ORIGINAL: Woos
* The "Numeric value out of range" problem (Thanks to Lokal Yokel for the csv files) aka CHS 157/158 problem

This is caused by the "P-61A Black Widow" (Aircraft number 177) having a durability of 129 where I only provided a byte for durability (in stock nothing comes near 128). Short term solution: Edit the WITPair.csv file in a spreadsheet program (Excel or OOcalc) and set the durability of that plane to 127. Afterwards _remove_ witpload.exe from the scenario directory (or rename it). Start WitpDecoder, Initialize Database, Ignore the warning on missing witpload.exe and voila (except of course that the plane will show with a durability of 127 within witpDecoder). Don't forget to bring witpload.exe back into the scenario directory for future DB initializations of other scenarios.

Long term solution: Change the DB schema. Before I do this, I would be interested in feedback from someone in CHS who defined the numbers whether that value is really as intended. The durability data in the .csv file I got really looks skewed: The Black Widow is closely followed by 3 Beaufighters and a Ventura. The B29 is on place 23 with about 15% less durability than the Black Widow.

What version of CHS was this from? I just checked the latest version of scen 157 from my website (2.08c) and it has a value of 48 for the P-61A durability.

Andrew

quote:

ORIGINAL: Woos

@Andrew
No idea, I'm always only interested in the .csv files. Local Yokel should know.
But since the high values therefore seem to be unintentional I will not change the schema to allow more than 127 durability. Instead the initialization routine will catch this.

quote:

ORIGINAL: Local Yokel
Andrew, I can tell you that the CHS scenario 157 version from which I derived the files sent to Woos was 2.08, but I can't tell you whether it was 2.08c or some other sub-version. "CHS 2.08 + Nik mod" is all that appears in the scenario selection screen within the game. Is there a way in which I can distinguish one sub-version from another?

quote:

ORIGINAL: Woos

[snip]

* Eskil's problem with scenario 5 & baskreuger's problem with scenario 2
It's a new variant of the "We make the scenario by removing some LCUs without caring whether they are HQs or something". The next minor update will be able to handle this for air groups, too. But Scenarios 2 and 5 does have production turned off anyway, why do you need witpdecoder?

[snip]

quote:

ORIGINAL: Woos

The error message means that there is very probably a cycle in the upgrade path of ship classes and ship class number 800 is involved in it (It is a bit strange that only 1 number is mentioned as normally at least 2 are needed for a cycle). If you look in the editor (or the WITPcls.csv file) for the "UpgradeToUnitID" field, you might be able to spot the cycle and break it in the .csv file (and then proceed similarly as described in post 41 for the "value out of range" problem). Note that changing the upgrade relationships will have serious effects on the correctness of the information shown in the "Ship Updates" and the "Ship classes" tabs.

And I fear that even if you solve that problem by .csv file editing, more will come up after it in other tables.

quote:

ORIGINAL: Nomad

quote:

ORIGINAL: Woos

The error message means that there is very probably a cycle in the upgrade path of ship classes and ship class number 800 is involved in it (It is a bit strange that only 1 number is mentioned as normally at least 2 are needed for a cycle). If you look in the editor (or the WITPcls.csv file) for the "UpgradeToUnitID" field, you might be able to spot the cycle and break it in the .csv file (and then proceed similarly as described in post 41 for the "value out of range" problem). Note that changing the upgrade relationships will have serious effects on the correctness of the information shown in the "Ship Updates" and the "Ship classes" tabs.

And I fear that even if you solve that problem by .csv file editing, more will come up after it in other tables.

Ship Class errors can be reported as one number. I set up Gary Childress's Mod and it had three ship classes that had upgrades to blank entries. the blank ones did not get reported in the error report. BTW, Garys mod will work by setting those three to upgrade to themselves.