Leader Bug

[ZOOMIE1980]

ORIGINAL: pompack

ORIGINAL: ZOOMIE1980

What in the world would the OS be significant for a bug like this? The code is compiled as a 32 bit WIN32 app no matter what OS is used, isn't it??? I remember the sizeof(int) being a problem back in the Win 3.1 (16bit)-Win95 (32bit) days because variables declared as type int in 'C' were 16 bit values in Win3.1 but 32bit values in Win95 and later? But all supported OS's are now all 32 bit and all use 32bit defaults for common datatypes???? If someone has a technical reason as to why the OS has any bearing, whatsoever, on a bug of this type I'd love to hear it!!

ZOOM: are you saying that is is not possible for the OS to be a factor in this bug?

Not unless they are accessing Ring 0 level calls. In that case, a lot of the Win9x series (that includes ME) still have a lot of 16bit DOS remenants in the kernel. In those cases, if you are making kernel level calls for something or even calling DX or other routines that in turn make calls into the kernel at Ring 0 (like driver calls) then you can, theoretically get some data corruption if you don't know what you are doing or you aren't being very careful.

This kind of a bug though doesn't seem to have anything at all to do that sort of thing. Bugs that involve OS specifics are usually system level bugs, like sound errors and video traps. This is a programming logic bug (Ring 3), which means it is very doubtful it has anything at all to do with the OS as all pointers and standard ints (int/long) are 32bit values.

[ZOOMIE1980]

ORIGINAL: pompack

ORIGINAL: pasternakski



If not, just fix the goddamned thing and be done with it . But stop pretending that somehow it's my fault because I can't produce a "repeatable save."

But pasternakski, there simply is NOT any way to fix it without a repeatable save. Mike has got to have something to work with. I have not seen any thread where a dev or mod has said or implied that this is a customer's fault; even Mr Frag just comes across as frustrated because he can't give Mike anything to work with.

It appears users and testers are at least beginning to narrow it down to the this auto-leader facility. Mog doesn't ever see it because he never uses the feature. It is also one of those things that is extrememly hard to catch precisely when it happens. past's point is that he doesn't feel it should be up to users to meticulously examing every TF/ship to try and catch the exact occurance of a bug, that is the dev's job. We can help narrow something down like this, but we shouldn;t have to expend valuable play time to try and pin it down exactly. Our job is to play, not test/debug. But I suppose if you have major heartburn over the problem you might be more motivated in helping them pin it down.....

[pompack]

ORIGINAL: ZOOMIE1980

ORIGINAL: pompack

ORIGINAL: ZOOMIE1980

What in the world would the OS be significant for a bug like this? The code is compiled as a 32 bit WIN32 app no matter what OS is used, isn't it??? I remember the sizeof(int) being a problem back in the Win 3.1 (16bit)-Win95 (32bit) days because variables declared as type int in 'C' were 16 bit values in Win3.1 but 32bit values in Win95 and later? But all supported OS's are now all 32 bit and all use 32bit defaults for common datatypes???? If someone has a technical reason as to why the OS has any bearing, whatsoever, on a bug of this type I'd love to hear it!!

ZOOM: are you saying that is is not possible for the OS to be a factor in this bug?

Not unless they are accessing Ring 0 level calls. In that case, a lot of the Win9x series (that includes ME) still have a lot of 16bit DOS remenants in the kernel. In those cases, if you are making kernel level calls for something or even calling DX or other routines that in turn make calls into the kernel at Ring 0 (like driver calls) then you can, theoretically get some data corruption if you don't know what you are doing or you aren't being very careful.

This kind of a bug though doesn't seem to have anything at all to do that sort of thing. Bugs that involve OS specifics are usually system level bugs, like sound errors and video traps. This is a programming logic bug (Ring 3), which means it is very doubtful it has anything at all to do with the OS as all pointers and standard ints (int/long) are 32bit values.

Interesting, just learned something here [X(]

[PeteG662]

OK.....here is a synopsis of what I have seen in many hours hunting this puppy down. I play new 1.4 scenario 15 allied vs Jap AI. I have windows XP. Auto leaders is OFF. Non historical, non surprise. The bug starts on turn 1! You can save the turn before execution and all is well. After running the turn, there will be leaders that have changed. Check the AKs, APs, and PTs in the area of India. Check all ships around in and around PH and Hawaii. Check the ships in Australia. I would be willing to bet you find some leaders have changed, normally I have between 3 and 10 leaders that have changed during the turn execution. Turn 1 is not repeatable due to the random number generator so all the leader changes here have not beenable to be reproduced but if you run turn 1 over and over again you will see many different leaders change each time. I do not assign admirals to my TFs early on due to the leader loss issue. The senior ship captain is in charge of the TF. If the TF is attacked and a ship is split off, the likelihood of a leader changing to a Japanese officer increases however this is not a deciding factor in the leaders being changed. They change randomly it appears as ships at sea will change from an allied leader to a japanese leader with no combat or no orders issued. It happens even with warships. When it comes to LCUs, the same thing happens starting on turn 1 but less frequently. Open scenario 10 and look at the Chinese LCUs. As many as one third will have "staff officers" in command. The staff officer designation was one that was changed from 1.3 to 1.4. These would have been the WOs or replaced entirely with a Japanese officer in previous patches. Air units I have not found too many leader changes yet since I try to nail the ones I do find early on and have not progressed very far in the game with the restarts and testing.

I would ask that each of you take some time and run a stock scenario 15 versus the AI and check every leader every turn for the first 10 turns with saves before execution and after execution of each of these game turns. Yes, this takes some time but I am sure you will see the prevalence of the issue and maybe we could get the saves in for fixing!

[Ol_Dog]

I am using Windows XP, started new game in 1.40. I do not use auto disband.

2 Lt Hyakutake is in command of TF 1006, CV Enterprise and escorts. He is rated leadership 65 and inspiration 60. The Enterprise was in action at Wake Island in early December 1941, then returned to PH.

I found him as TF commander when the TF was in Pearl. I have not tried to replace him. It is 13 Jan 1942 now. I have saves 12/8/41, 12/31/41 and 10 Jan - 13 Jan 1941.

Ol' Dog

[pasternakski]

ORIGINAL: pompack

ORIGINAL: pasternakski



If not, just fix the goddamned thing and be done with it . But stop pretending that somehow it's my fault because I can't produce a "repeatable save."

But pasternakski, there simply is NOT any way to fix it without a repeatable save. Mike has got to have something to work with. I have not seen any thread where a dev or mod has said or implied that this is a customer's fault; even Mr Frag just comes across as frustrated because he can't give Mike anything to work with.

Well, all I can say is take a look at Tallyman662's post, which is just about exactly what I am seeing, as well (although at some later point, it begins happening to LCUs too). BTW, I do not use the autoleader assignment feature. Ever.

I don't see why it is so impossible for someone on "the other side" to experiment and come up with the same phenomena we players are seeing.

I also don't know why nobody will explain what the effect is on game play. If WO 0/0 can run a submarine just as well as the original commander he replaced, I'm prepared to shut up, go away, and forget about even looking at who's leading what. If, on the other hand, there is a practical effect ...

[mogami]

Hi, The manual says that rank has no effect.

[Ol_Dog]

On 12/8/41 Halsey was commander of Enterprise TF. On 12/31/41, it was 2Lt Hyakutake. Hyakutake was still in command on 1/13/42. While sailing from Pago Pago to Normeu(sp)on 1/14/42, the Task Force commander lost his name - was blank - but was a 2Lt. On 1/15/42, WCDR Wright became Task Force commander of Enterprise Task Force.

Wright's stats are better than Hykutake's - 65, 82 as compared to 65, 60



[:D]

[PeteG662]

You lost it some time after 12/8 when Halsey changed to the Jap Cdr. You probably don't have Halsey any more either!

[pasternakski]

ORIGINAL: Mogami

Hi, The manual says that rank has no effect.

Russ, fer chrissake, I'm not talking about rank. I swear, you are so different after your computer respawning, I think you must have stuck your finger in a light socket and burnt out some of your humor cells ... or something.

[mogami]

I also don't know why nobody will explain what the effect is on game play. If WO 0/0 can run a submarine just as well as the original commander he replaced, I'm prepared to shut up, go away, and forget about even looking at who's leading what. If, on the other hand, there is a practical effect ...

Hi, I was just answering a question.

[dtravel]

ORIGINAL: Mogami

I also don't know why nobody will explain what the effect is on game play. If WO 0/0 can run a submarine just as well as the original commander he replaced, I'm prepared to shut up, go away, and forget about even looking at who's leading what. If, on the other hand, there is a practical effect ...

Hi, I was just answering a question.

Then you didn't understand the question.

[mogami]

Hi, Well that would be a first........[X(]

[dtravel]

ORIGINAL: Mogami

Hi, Well that would be a first........[X(]

(Just on general principles.)

[WhoCares]

I can confirm the bug in 1.4 once a TF breaks up after battle, as Tankerace already described it.

w2k, Japan vs. AI, patched to 1.4, started as 1.1 (iirc, started on 7th Aug.), plain scen. 15, flagship (still) afloat (but now split off), saves (pre- and post-bug) are available.

[latosusi]

You can get "leader bug" even if you don't use "auto-leader" feature. My sub S-38 had Chapple
as a CO on 12/17/41 then Hickman on 12/18/41 and finally WO Hamano (Jap?) on 12/19/41!
It look like that this bug is not repeatable because it is totally random. Savegames sent to
witp@sympatico.ca

[PeteG662]

WhoCares,

Please send your save game files in regarding that leader loss. The more we can send them the more they can see and hopefully fix!

Thanks

[Ron Saueracker]

Why not just start from scratch? Scrap the current leader code (many have said this is a very obsolete approach) and add a more current one, is this impossible? Seems to me this bug is eating up more resources than rewriting would. Of course I'm no programmer.[;)]

[Ol_Dog]

I had Enterprise TF at sea under command of 2Lt I Hyakutake 65,60 on 1/13/41, then on 1/14/41 the commander was 2Lt (blank) 65,60, then on 1/15/41 WCDR I Wright 65,82.

I reran the 1/13/41 above again - 1/14/41 the commander was 2Lt (blank) 65,60 again; running the original 1/14/41 again the 1/15/41 commander was WCDR K Dobbins 69,84.

I have all 5 saves.

Does anyone need any of these?

[PeteG662]

send them in.....Frag or Pry or Kid