ORIGINAL: el cid again
The player reports seem not to be right in many cases. For example, you cannot believe the aircraft used from pool data. It 'resets' all the time - and it ignores data before the reset. A "minus" means "we destroyed that many planes because the pool was too large and you didn't use any yesterday" while a "plus" means "we issue that many as replacements since the last reset" approximately. It is certain that any change from plus to minus ignores the previous total instead of incorporating it. But it also appears that the plus data resets for other reasons - so you will show 19 used when you have really used 110 - and only the gods of programming understand why?
You can drive the "used from pool" number for an aircraft type into the negative range quite easily if the "used from pool" is fairly low by converting one or two flying units using that plane to something else and dumping those planes back into the pool.The game deducts those planes from the "used from pool" number.
This also happens when a device is replaced by a different device in an LCU, you can best see that with tanks. As the armoured units convert to newer models, say from Type 89As to Type 97s, you will see the "used from pool" number for the Type 97 climb while the "used from pool" number for the Type 89A declines and the "in pool now" number for the Type 89A increases - usually the "used from pool" numbers for the replacing device correspond quite well to the "in pool now" number for the replaced device.
And that is just what I see when those high slot devices reach their availability date, quite apart from seeing them replacing older equipment inside the LCUs.
I don't disbelieve what you say about slot usage, and what you've been told about how the high slots work, but I can't quite reconcile that with my empirical results. Now I know from my own experience that interpreting other peoples' undocumented code is always fraught with danger, even if it's just COBOL, and I think C written by somebody intent on achieving minimal size and maximum performance may be even harder to interpret than straight Assembler. C leaves you as programmer a lot of rope and will cheerfully let you hang yourself with it. C will also allow you to write fantastically concise and obscure code that even the author may not be able to understand after some time has passed. I think that, by now, even Mr. GG wouldn't completely understand what's happening inside the WitP exe. It wouldn't surprise me if there were an obscure branch somewhere in the program that causes this kind of counter-expectant (is that really a word?) behaviour. Remember how a developer once said, "I thought I understood that routine, and then I found a branch that changed everything"? If the code contains enough indirection by pointer, it will defy analysis by code-reading anyway.