Matrix Games Forums

Thank-you Sir, that works a treat. [&o]

Michael, this is just an informational query. The section of the manual below describes the progression of the dud rate for torpedoes in the game. Upon reading it closely I wonder of the part that I made bold should actually read as follows: "In September 1943, all torpedoes with an adjusted dud rate equal to or greater than 20 have their dud rates lowered to 10." I put the edited part in italics.

6.4.2.1 NOTE ON TORPEDO DUDS
In January 1943, all torpedoes with a dud rate of greater than 49 have their dud rates reduced
by 20. In September 1943, all torpedoes with an adjusted dud rate greater than 20 have their
dud rates lowered to 10. Allied torpedoes were notoriously inefficient in the early stages of the
Pacific War, and this rule reflects their slow but steady improvement over the years.

Note: if the Realism option “Reliable USN Torpedoes” (see
section 2.4.7) is selected, this rule does not apply – no
torpedoes will have dud rates higher than 10%.

I am not asking for a manual update, just using that to illustrate a query about how the code works.

The code is wrtitten as per the manual and that its the same as the original WITP.

Michael, I installed the beta patch yesterday and am very, very happy with all of the improvements. It works perfectly for me, and has really improved the experience of playing the game.

Thanks very much for your work on making the game even better!

Eastern USA base has stored over 281k in supply as of 16th Dec 42. I started this game using k9 and just got my opponent to go up to m3. Anyone else having problems with supply moving out of USA base with new game (scenario 2)?? We had played into June 42 while Beta's were coming out to ensure some stability before restarting. Prior, supply would move every second or third day out of USA base. I will send MichaelM a PM after next turn if it continues to stockpile supply (yes, I recycled the stockpile switches to make sure they were not stuck).

ORIGINAL: ny59giants

Eastern USA base has stored over 281k in supply as of 16th Dec 42. I started this game using k9 and just got my opponent to go up to m3. Anyone else having problems with supply moving out of USA base with new game (scenario 2)?? We had played into June 42 while Beta's were coming out to ensure some stability before restarting. Prior, supply would move every second or third day out of USA base. I will send MichaelM a PM after next turn if it continues to stockpile supply (yes, I recycled the stockpile switches to make sure they were not stuck).

Are your US mainlamd bases running short of supplies? Or ports not keeping up with TF loading supplies?

Both.

Turn sent via PM that used k9. Will send next turn with m3 later.

ORIGINAL: ny59giants

Both.

Turn sent via PM that used k9. Will send next turn with m3 later.

I am not having that problem. Now I'm past k9, but I don't recall having it then either.

This is an update just of the EXE/DLL with these couple of fixes.
I suggest trying this but not for games in progress as it might have undesired consequences if I have made any errors.
Note that once you save a game under this version, it most likely wont be able to be read under the older ones.

[1108m4]
Tweaked Wrong altitude was being used in some cases. Could impact raid, co-ordination and low level intercepts [MEM]
Fixed Overflowing list caused lockup during air/land combat [MEM]
Fixed Carry over replacement delay on LCU recombining [MEM]
Changed Color of supply dot to yellow [MEM]
Added Option to retire low experienced named pilots - in group and reserve lists [MEM}
Fixed Error in movement of fuel and determination of excess resources [MEM]
Tweaked Pilot overflow to clear more pilots. Corrected some discrepancies in pilot numbers [MEM]
Fixed Auto-upgrade of squad devices when LCU taking replacements that cause an upgrade [MEM]
Changed Auto-upgrade devices treated as 'new' for the device tally report [MEM]

Michael,

Is the altitude tweak the solution to the kamikaze bug? Should kamikazes now go in at the altitude the player selects instead of defaulting to 9,000 feet?

If it is I'll go with this change for my current game. Lack of kamis is a killer in the late-war scenarios.

I had an Australian artillery unit(1st Medium Regiment) with a British TOE, it made a TOE upgrade again to a British TOE but now it is also listed as British unit not Australian anymore, I guess it should work that way or?

ORIGINAL: Nemo121

Michael,

Is the altitude tweak the solution to the kamikaze bug? Should kamikazes now go in at the altitude the player selects instead of defaulting to 9,000 feet?

If it is I'll go with this change for my current game. Lack of kamis is a killer in the late-war scenarios.

The setting of 9K actually wasn't the cause of the issue. The Kami were still coming in at 6K regardless of what was being stated on the reports.
The CAP was being set to intercept at a incorrect alt, which resulted in being able to intercept easier. This has always been there, but is obvious on the low level intercepts where the random alt setting could moved the CAP from its patrol alt to almost on top of the raid.

Just be aware that this fix of the bug may make low level intercept much harder, unless the CAP is placed lower than maximum altitude. It also could have impact on other air attacks. This is why I have not updated it as a normal beta until some players could try it out.
Once you change to m4, you can't go back from what I can see due to a new entry in the save file. I have yet to try tracker to see if it ignores the new entry as it should.

So, are the planes still forced to come in at 6,000 feet? ( albeit with the CAP positioned a little less perfectly to intercept ). Previously they would come in at 100 feet or 30,000 feet if that's what you chose.

I'll test this in an ongoing game and feed back. I'm trying to split CAP with low only, high only and hi-low mixes of strikes so we'll see how it goes.

Quick testing shows low-level strikes now come in very low, are spotted late and usually leak a little. In testing I found a clear correlation between speed of the low level kami ( 100 feet ) and likelihood of getting through the CAP. The faster it was, the less time to intercept and the more leaked through.

Ohkas worked well also, their high speed and low altitude made them very difficult to intercept. They have a terrible hit rate once they break through but at least most of them do break through.

High level kamis didn't appear to stay at the altitude I set... It appears to have dropped down to a lower altitude as planes with ceilings well below the ceiling of the Ki-43IIIs shot some of them down. Overall though 50% of the raid got through which seems fairly reasonable to me and a big improvement on the last beta AND, crucially, the previous official executable.

So, pending further play/testing my initial assessment this seems to fix the bug and also improves on the behaviour of the previous official executable ( wherein Ki-43 IIIs flying at max altitude were pretty much uninterceptable by planes with lower ceilings ). Obviously I'll have to test more but so far so good.

ORIGINAL: michaelm

ORIGINAL: Nemo121

Michael,

Is the altitude tweak the solution to the kamikaze bug? Should kamikazes now go in at the altitude the player selects instead of defaulting to 9,000 feet?

If it is I'll go with this change for my current game. Lack of kamis is a killer in the late-war scenarios.

The setting of 9K actually wasn't the cause of the issue. The Kami were still coming in at 6K regardless of what was being stated on the reports.
The CAP was being set to intercept at a incorrect alt, which resulted in being able to intercept easier. This has always been there, but is obvious on the low level intercepts where the random alt setting could moved the CAP from its patrol alt to almost on top of the raid.

Just be aware that this fix of the bug may make low level intercept much harder, unless the CAP is placed lower than maximum altitude. It also could have impact on other air attacks. This is why I have not updated it as a normal beta until some players could try it out.
Once you change to m4, you can't go back from what I can see due to a new entry in the save file. I have yet to try tracker to see if it ignores the new entry as it should.

So far no problems with Tracker & 1108m4. If there is something specific I should look for just let me know.

Update: I spoke too soon, Tracker gives the error: "Can't Read Save File"

Isn't there a .dll that the AE team gave to the Tracker Guys to read the save file?

ORIGINAL: BigDuke66

I had an Australian artillery unit(1st Medium Regiment) with a British TOE, it made a TOE upgrade again to a British TOE but now it is also listed as British unit not Australian anymore, I guess it should work that way or?

If the TOE has a British nation set, then it will be passed onto the unit as part of the TOE upgrade. IIRC, the type of unit/suffix can also be changed by this if so set.

ORIGINAL: witpqs

ORIGINAL: michaelm

ORIGINAL: Nemo121

Michael,

Is the altitude tweak the solution to the kamikaze bug? Should kamikazes now go in at the altitude the player selects instead of defaulting to 9,000 feet?

If it is I'll go with this change for my current game. Lack of kamis is a killer in the late-war scenarios.

The setting of 9K actually wasn't the cause of the issue. The Kami were still coming in at 6K regardless of what was being stated on the reports.
The CAP was being set to intercept at a incorrect alt, which resulted in being able to intercept easier. This has always been there, but is obvious on the low level intercepts where the random alt setting could moved the CAP from its patrol alt to almost on top of the raid.

Just be aware that this fix of the bug may make low level intercept much harder, unless the CAP is placed lower than maximum altitude. It also could have impact on other air attacks. This is why I have not updated it as a normal beta until some players could try it out.
Once you change to m4, you can't go back from what I can see due to a new entry in the save file. I have yet to try tracker to see if it ignores the new entry as it should.

So far no problems with Tracker & 1108m4. If there is something specific I should look for just let me know.

Update: I spoke too soon, Tracker gives the error: "Can't Read Save File"

Isn't there a .dll that the AE team gave to the Tracker Guys to read the save file?

Did you copy the new DLL from m4 zip to the tracker install directory? It might still be using the older one.

Hi Michael,

Would it be possible to adjust it so that you can halt production of ships even if they aren't yet draining shipyard points (i.e., before they slide down on the cue)? The way it currently is, I have to look through my ship production every turn to see if any can be halted. Of course, any ships that are halted should still slide down until they start consuming production points at which points they should stop sliding.

ORIGINAL: michaelm

ORIGINAL: witpqs

ORIGINAL: michaelm


The setting of 9K actually wasn't the cause of the issue. The Kami were still coming in at 6K regardless of what was being stated on the reports.
The CAP was being set to intercept at a incorrect alt, which resulted in being able to intercept easier. This has always been there, but is obvious on the low level intercepts where the random alt setting could moved the CAP from its patrol alt to almost on top of the raid.

Just be aware that this fix of the bug may make low level intercept much harder, unless the CAP is placed lower than maximum altitude. It also could have impact on other air attacks. This is why I have not updated it as a normal beta until some players could try it out.
Once you change to m4, you can't go back from what I can see due to a new entry in the save file. I have yet to try tracker to see if it ignores the new entry as it should.

So far no problems with Tracker & 1108m4. If there is something specific I should look for just let me know.

Update: I spoke too soon, Tracker gives the error: "Can't Read Save File"

Isn't there a .dll that the AE team gave to the Tracker Guys to read the save file?

Did you copy the new DLL from m4 zip to the tracker install directory? It might still be using the older one.

I did once Damian advised me to, and it works! Thanks.

When a LCU takes replacements, it can upgrade them in order to match the TOE if the new device exists in the pool.
The old devices are returned to the pool, but the squad type ones aren't being automatically upgraded to the new device as per the normal device upgrade process.

I will be duplicating that normal device upgrade process into the LCU replacement code.

Also, as a result of this, I find it difficult to get the device numbers (used, in pool) to add up properly. The used total doesn't change (+ , - the same number) and it in't obvious that there has been some sort of device movement.

As a result, I will be making a subtle change.
If the device is being added back to the pool from the device auto-upgrade, it will be added to the 'produced this turn' rather than subtracted from 'used'. It just seems to make more sense when looking at the numbers.

[edit]
This is still under review. The numbers bit, not the upgrade.