Don Bowen
Posts: 8183
Joined: 7/13/2000 From: Georgetown, Texas, USA Status: offline
|
quote:
ORIGINAL: Woos While evaluating error reports concerning witpDecoder I stumbled upon two strange things in a few scenarios: In scenario 190 (Big B mod) the 7th USA Div (Unit 2760) has 50000 supply on hand at start. Is that actually intended or a typo (e.g. assigned supply to the unit instead of the base). Since I have never before seen a unit with that much supply on hand, witpdecoder uses a smallint to store unit supply in the database. Now, this could be changed but it is quite some effort. I would thus avoid to do it just to support a typo, When a land unit is loaded onto a TF, all of it's supply is stripped off and assigned to the base. So coding large supply values to land units is a sneaky way of having supply arrive during the game. It could obviously be reduced in value to fit i_16. quote:
In scenario 155 (CHS?) there seems to be several cycles in the ship upgrade graph, e.g. ship class 58 (Izumo) updates to class 636 which in turn updates back to ID 58 (at least I got a .csv dump claiming to be from that scenario which has that in it). This makes IMHO no sense (will the ships continuously be updated between those classes?). Additionally, the new routine for reading in the ship upgrades graph into witpdecoder (specifically added to V.03b to support some other upgrade idosyncracies of CHS ;-) does not support such upgrade cycles. Can we agree that such cycles are scenario errors or is there some rational behind them? The ship classes in question which are in such cycles are 58,230,447,636,641,641,725,1697, and 1740. Obviously wrong (and probably my fault) - Copy, Paste, don't fully update, d'oh. Probably a good idea to make sure Andrew knows of this.
|