Pilot limit issue?

[Don Bowen]

Yes Sir Joe - all the items are loaded into core in fixed length arrays. Pilots, leaders, planes, squadrons, bases, land units, ships, classes, and Task Forces. Michaelm is way ahead of me on this one and it is he that determined the 30000 pilot issue.

Besides pilots, possible problem areas are airgroups and land units. Both have a limited number of available "slots' for divided or "split" units. I suspect there is a limit for Task Forces too but I've never come upon it. Basically, anything that can be "generated" by the game has a limit.

I agree that internalization was used for execution speed. Also probably because it has always been used and I suspect that Matrix had a lot of re-useable code based on it.

[Speedysteve]

What you say make's sense Don.

Steven

[Dereck]

ORIGINAL: Marten

ORIGINAL: dereck

ORIGINAL: Marten

there is simple solution to the problem: instead of engaging in air to air combat, destroy planes on the ground. [:@]

Marten, THOSE planes destroyed on the ground COUNT against the hard-coded limit also.

naval bombardment not often kills pilots...

It seems to equate destroyed planes and pilots the same. In my game i have over 21,000 destroyed planes and have this problem - doesn't say how many of those planes had a pilot in them or not.

[Dereck]

Everybody ... I received this PM from Joel Billings concerning this bug and he requested a save file. I'm going to reply back to Joel to see if they still want MY save file since I'm at v1.3 but you others who are experiencing this and running the current version PLEASE send your save files to the email address listed in this quoted message from Joel?

Can you send a save to 2by3@2by3games.com. Gary says only pilots of note should be saved, so this would seem to be a bug.

[Damien Thorn]

ORIGINAL: Don Bowen


Besides pilots, possible problem areas are airgroups and land units. Both have a limited number of available "slots' for divided or "split" units. I suspect there is a limit for Task Forces too but I've never come upon it. Basically, anything that can be "generated" by the game has a limit.

I had the problem with air groups. I wasn't able to split any more because I had used up all of the 'slots'. I haven't had this problem yet with land units but I'm sure I will. I've got tons of fragmentary units all over the map. Actually, I do it on purpose to decive allied intellignece reports. When you get a message that the 34th inf div is in 10 different places it is almost usless information.

They should just increase the size of each array. It's been a few years since WitP came out and everybody probably has a computer with thwice the memory, hard drive space, and processing power now. Double the size of all the arrays and we should be good.

Damien Thorn.

[Mynok]

30,000 makes me suspect this is a two-byte *signed* array size, rather than a two-byte *unsigned* array size, which would give around 65000 slots. This may also have something to do with the compiler, as different C compilers had different philosophies as to whether an int was two bytes or four bytes (i.e. 16-bit or 32-bit). Some had 16-bit int's and 32-bit long's, while others made both 32-bit and made the programmer use short's to get 16-bit numbers. All, of course, take an unsigned modifier and default to signed.

[Dereck]

ORIGINAL: Mynok

30,000 makes me suspect this is a two-byte *signed* array size, rather than a two-byte *unsigned* array size, which would give around 65000 slots. This may also have something to do with the compiler, as different C compilers had different philosophies as to whether an int was two bytes or four bytes (i.e. 16-bit or 32-bit). Some had 16-bit int's and 32-bit long's, while others made both 32-bit and made the programmer use short's to get 16-bit numbers. All, of course, take an unsigned modifier and default to signed.

Very true.

It would depend on the default of the compiler especially if they didn't specifically define the variable as *unsigned* and it defaulted to *signed*.

[scout1]

Oddly enough, I don't think this one really needs a save game file for 2 reasons

1) It's not a bug, but rather a game design limitation
2) It ought to be really easy to check for Mike, just pre-populate the pilot slot to 30k and
try to bring in reinformcements

Unless its a memory thing, why not just increase the hardcode limit to 60k (or some other large number) ?

[Dereck]

ORIGINAL: scout1

Oddly enough, I don't think this one really needs a save game file for 2 reasons

1) It's not a bug, but rather a game design limitation
2) It ought to be really easy to check for Mike, just pre-populate the pilot slot to 30k and
try to bring in reinformcements

Unless its a memory thing, why not just increase the hardcode limit to 60k (or some other large number) ?

Well, they asked for a save so if you have had this happen PLEASE send them a save file.

[scout1]

Don't get me wrong, if I had a save, I'd send it. Just in this case, I'm not sure that it's fair for them to ask for one. It's a question as to the game design itself. This should really be a simple check, what happens when you exceed the design intent ?

[Dereck]

ORIGINAL: scout1

Don't get me wrong, if I had a save, I'd send it. Just in this case, I'm not sure that it's fair for them to ask for one. It's a question as to the game design itself. This should really be a simple check, what happens when you exceed the design intent ?

Well, here's the PM I got from Joel Billings so it sounds like they may not be sure what is causing it:

Can you send a save to 2by3@2by3games.com. Gary says only pilots of note should be saved, so this would seem to be a bug.

[bilbow]

I'm wondering about something as I read this thread. Freeboy and Zeta 16 recently completed a campaign game to mid-1945 where combined air loses were over 57,000. Freeboy (allies) alone lost over the 30,000 that has been mentioned as a limit, plus he must have had thousands more on map at the end.

How does this reconcile to the observed issue/bug? I'm missing something.

[Dereck]

ORIGINAL: bilbow

I'm wondering about something as I read this thread. Freeboy and Zeta 16 recently completed a campaign game to mid-1945 where combined air loses were over 57,000. Freeboy (allies) alone lost over the 30,000 that has been mentioned as a limit, plus he must have had thousands more on map at the end.

How does this reconcile to the observed issue/bug? I'm missing something.

This is what Zeta16 told me about one of his games when I asked if he had a save he could send to Matrix:

It has not happened in a few game months. I could add no pilots, but after I shot close to 1000 planes in a few days I could them again. Sorry I have none of these saves left.

[michaelm75au]

Note that pilots are killed and replaced in the 30K array. I have see this, especially in the early stages of the game.
But at some point, between who is in the Top Pilots PLUS in air groups PLUS whose on leave PLUS MIA PLUS KIA PLUS .. exceeds the 30K total.

Michael

[Speedysteve]

Hi Michael,

I was hoping you'd post your thoughts in here.

Just so I get this straight:

KIA pilots are REPLACED in the 30K limit EXCEPT those on the top pilots list + the MIA + WIA?

In short does every pilot on the top pilot list, regardless of status, remain in the 30K?

Regards,

Steven

[michaelm75au]

From what I can see, the pilot details (like name, group, missions, kills, expericence, etc) are stored in the 30K pilot array.
So in order to show up in the Top Pilot list with those details, the pilot needs to stay in the 30K array.

Now, pilots definitely do come and go from this array. I have done comparision between turns and have seen slots start out assigned to one pilot/group and end up the next turn with a different name/group. And yes the previous pilot was one of the casualties from the air combat that turn. So it does work.

However, in one of the saves I have examined where the 30K pilots were all allocated, I have noticed the following.
(1) Pilots who had a delay of 9999 but assigned to some group were included. Thus wastes a usable slot. This sort of problem can be aleviated by the scenario designer removing pilots with a delay of 9999.

(2) Pilots have been assigned to group numbers that either don't exist or never enter play. Again it wastes usables slots. This sort of problem can be aleviated by the scenario designer.

(3) Some groups have way too many pilots assigned to them. One example; 380th BG which has a max planes of 48 but has 166 pilots assigned to it. But not all the the pilots appear in the group's roster. A method of trickling back excess pilots to the pool would help keep the pilots available.

(1) and (2) I have mentioned before. And I think in most of the recent modded scenarios, the pilot database usually has been left blank. The AI is allowed to create and use up all the available slots, so these points are not of major concern. Some of the early modded scenarios, I think, have experienced this problem before we knew the ramifications of changing/inserting/deleting slots in the database files.[:D]

For point (3), there are a couple of code changes I think would be simple to introduce:[;)]
(a) One method would be to move the most inexperienced pilots back to the pool, just by adding to the pool number available. It would mean that the pilot would get the "pool" expericence of the pilot pool at that time. I think this was done for UV in last patch.

(b) Another method could be to "free" up the inexperienced pilots by transferring them to a similar group(s) which was under staffed. This would not draw down on replacement pilots but would spread out existing pilots, if needed, and maintain their current experience level.

Michael

[Speedysteve]

As per norm Michael excellent stuff. Many thanks for that. Have you been in touch with the dev's re: this?

Steven

[Dereck]

ORIGINAL: michaelm
(1) and (2) I have mentioned before. And I think in most of the recent modded scenarios, the pilot database usually has been left blank. The AI is allowed to create and use up all the available slots, so these points are not of major concern. Some of the early modded scenarios, I think, have experienced this problem before we knew the ramifications of changing/inserting/deleting slots in the database files.[:D]

What ramifications? Are you saying that any custom scenario where changes were made trigger this problem?

[Sardaukar]

I think he means that in some earlier mods pilot database was too filled which did cause problems. I might be wrong, though [8D]. What I understand from the post for modding is that it's beneficial to leave pilot database blank ( or is it ?). [:)]

[Dereck]

ORIGINAL: Sardaukar

I think he means that in some earlier mods pilot database was too filled which did cause problems. I might be wrong, though [8D]. What I understand from the post for modding is that it's beneficial to leave pilot database blank ( or is it ?). [:)]

So if you're making a custom scenario are you saying it would behoove you to empty(?) the existing pilots from the database? I checked and I show only 3,990 pilots in it out of 19,999 slots.

This is confusing me and frustrating since my game has come to a grinding halt I have nothing to do but ponder things while I twiddle my thumbs.