New Pacific War Bug Fixes / Enhancements

[Fishbreath]

This is excellent news. I was planning on running a real-time AAR at my website starting on December 7th, but now, I'm going to put it off until next year to give you guys some time to work. The updates you've made sound great, and I expect you'll do even better.

As always, if you need a mirror for file hosting, drop me a line via PM or email.

[bradk]

Thank you for the offer and I very much appreciate you making my previous modifications available on your site.

In case you haven't seen the other thread announcing it, we're discussing the modifications here.

http://s15.zetaboards.com/Pacific_War_Update/index/

[demyansk]

I was unable to get this game working with Windows 7 64 bit. What do u guys think?

[bradk]

The Captain said in another thread only DosBox will make the game work under Win 7. Are you having trouble making it work with DosBox?

[demyansk]

I used to have dosbox, I will try it again, thanks

[bradk]

You said in another post you have XP on another computer. Have you made the game work with XP?

You can do that by making special config.sys and autoexec.bat files for the game. Take out everything you don't need, like joystick, sound, cd drive, etc.

[Rich Dionne]

ORIGINAL: demjansk

I used to have dosbox, I will try it again, thanks

demjansk, for me, Dosbox is the way to go. It's the only way I can run these "classic" DOS programs anymore. Give it a try, and let us know if you have any troubles.

Regards,

Rich

[demyansk]

Thanks rich, I had the game at one time, I still have the box, manual for War in Russia, I like it

[Rich Dionne]

I just posted at the Pacific War Update website version 3.2.8 of PAC.EXE along with Brad's latest updates to OBC_D. A list of ongoing fixes / modifications is also included in the zip file. You can download it here:

http://s15.zetaboards.com/Pacific_War_U ... m/3233699/

The latest version 3.2.8 EXE fixes / features are as follows:

28) Added impacts to air operations in the Monsoon Weather Zone (MWZ), similar to what already exists in the Arctic Weather Zone (although not as extreme). Existing code currently impacts ground operations in the MWZ: in the MWZ from June through September, LCUs that attack get a 75% drop in readiness, although a good leader can recover some of this readiness. The new code will now impact air operations from June through September as follows:

• If the target hex is in the MWZ, then each CAP fighter group has a 33% chance of aborting.
• If the origin or target hex is in the MWZ, then each attacking group has a 33% chance of aborting.
• If origin and target hex are in the MWZ, then each attacking group has a 67% chance of aborting.
• For carrier based air strikes, if the origin hex is in the MWZ, then the PP cost for launching the strike is multiplied times 1.5 (22 PPs for a full strike and 15 PPs for a half strike).

29) Altered the recently added MWZ and AWZ map indicators (see update 26). Now these weather zone map indicators will only show up when the actual weather impact is most prevalent (from October through April for the AWZ, and from June through September for the MWZ). This provides the benefit of teaching the players where these zones are located as well as the time periods when they are in effect.

30) Fixed an old bug that prevented switching the IJA 17th and 18th Armies from “Human Control” to either “Computer Control” or “Operational Control” starting in October 1942, when the 8th Area Army is activated. This bug was only seen in IJ Human vs. Allied AI (or Human) games (not secure PBEM). You can now set these armies to whatever level of control you wish without them being constantly changed back to human control.

31) Altered code to remove the restriction that prevented the Allies from providing routine supply to any bases in the range 140-167 (includes Perth, Cook Island, Nassau, and Kolombangara). These bases should now behave normally.

32) Fixed a number of newly created bugs around aircraft upgrades, including one that was allowing automatic aircraft upgrades and downgrades in the secure PBEM games. This should now be fixed. Also fixed a bug that was downgrading B-17s to Bolos in both PBEM and non-PBEM games.

33) Fixed another newly created bug that was allowing armor and other factories to be switched to aircraft factories.

34) Fixed the USMC aircraft manual selection list. You should now be able to select USN aircraft for USMC air groups.

35) Fixed bug that caused the following issue: when reading battle reports (accessed through circles, triangles and squares) and you right-click to exit, the map automatically centers on the Eastern U.S. base. The cursor should not move at all.

As usual, please let me know if you find any bugs or issues.

Happy Holidays everyone!

[Rich Dionne]

I just posted version 3.2.13 of PAC.EXE available for download. A list of ongoing fixes / modifications is also included in the zip file. You can download it here:

Pacific War Update

The latest version 3.2.13 EXE fixes / features are as follows:

Version 3.2.13

50) Fixed some bugs and made improvements to the division / recombination / replacements for LCUs as follows:
Fixed the bug that prevented many detachment LCUs from recombining with their parent LCU or other detachment LCUs from the same parent. Both types of LCU recombination should now occur reliably at the end of each turn.

Altered the naming of detachments to more naturally match the size of the unit. As before, parent units always keep their original size designation (div, bde, reg, bn, etc). Subordinate units previously took a size one size smaller than their parent (e.g. a detachment bde from a parent div). Now subordinates will take a size designation that more closely matches the number of infantry squads (or AFVs for tank brigades).

Detachment units that divide will split into equal size units as before, but now both name designations will be altered to reflect the new size of both units (e.g. one bde sub-unit will divide into 2 reg sub-units, etc.).

51) In an effort to provide more detachment slots for the division of units, I have altered the code so that all LCUs permanently lost in the game (e.g. Gull Force, Philippine units, etc.) now become open slots for new detachments.

52) New code now prevents LCU detachments from receiving replacements (previously detachments received replacements if their number of infantry squads dropped below 30). If due to combat, the LCU detachment infantry and AFV numbers drop below 10, these detachments will now combine with any other friendly LCU (parent or detachment) at the same base. Why was this done? To keep as many LCU slots open for LCU dividing as possible. This change will also encourage human players to keep their detachments closer to their parent LCU. This change does not appear to negatively impact performance of the AI.

53) As before, the size of LCUs will be limited to their TO&E levels when drawing replacements, but now new code will take into account the size of the parent and any detachments when determining whether the LCU can draw replacements. For example, a division that splits off a detachment brigade will not immediately start receiving replacements. The combined size of the parent division and subordinate detachment will both be considered when determining if replacements are provided. This change does not appear to negatively impact performance of the AI.

54) The experience, readiness, and entrenchment levels of LCUs that combine are now averaged. Previously, these combined factors took the values of the LCU higher in the display list.

55) New code was added to simulate the impact of disease / starvation on LCUs that are isolated from supplies for long periods of time. If an LCU’s readiness is below 49% at the start of a turn, the LCU will start to lose infantry squads as the readiness level continues to drop. Infantry losses will increase from 0% per week at a 49% readiness up to 8% per week for a readiness level of 0%. This new code will prevent the unrealistic hold-out of LCUs for many months on end when they are completely out of supply with a very low readiness. Bataan, for example, won’t hold-out as long as previously, although 3-4 months after losing Bataan is still quite possible with the new code.

56) Prevented an increase in range of the Wellington from 8 to 10 in 1944. The value will remain at 8. Thanks to Istfemer for pointing this one out.

As usual, please let me know if you find any issues / bugs.

Regards,

Rich

[Hattori Hanzo]

a GREAT Labour of Love !!!!! [&o]

[zeke99]

Bug: Flak of ships in harbour

Dear Rich,

first I'd like to thank you for your work. Just testing the latest version in the game with Istfemer.

One thing that needs to be fixed is the decrease in Flak value for ships in port. This is an old issue that could be circumvented by keeping ships in TFs. However, since now they degrade it needs to be fixed.

IMHO the Flak value should not go down in ports at all. What should increase instead is the hit probability of guns, bombs and torpedos due to stationary targets.

Just my 5cents,
Zeke

[Istfemer]

I can already sense the problems that will pop up if your suggestion becomes reality, Zeke.
Raid on Pearl Harbor will be a spectacularly costly failure for the IJNAF. Their bombers will all get shredded by Allied flak and Allies won't lose any ships. [:)]
With flak values not reduced, on 12/7/41 the ships in Pearl Harbor port will have a combined flak value of 5599.
(non-historical start, the flak value will be slightly lower in other scenarios)

[Capt. Harlock]

Raid on Pearl Harbor will be a spectacularly costly failure for the IJNAF. Their bombers will all get shredded by Allied flak and Allies won't lose any ships.
With flak values not reduced, on 12/7/41 the ships in Pearl Harbor port will have a combined flak value of 5599.

Interesting -- that much even before the upgrades? And isn't there an averaging algorithm to compensate for there being many more ships in harbor than are allowed in a TF?

[zeke99]

Hi Istfemer, I thought you will bring up this point [;)]

It can be dealt with algos like Capt.Harlock proposed but it brings up a very interesting point, the TF Flak value.
As I understand it, it is calculated by simply adding all Flak and use it against incoming aircraft. This is technically WRONG. Small calibres will only protect the ship they are installed on due to range and distance of the other ships. The bigger the TF the lower their impact on air defence. This could be taken care of by an algo too calculating the protection envelope.

[Rich Dionne]

ORIGINAL: Istfemer

I can already sense the problems that will pop up if your suggestion becomes reality, Zeke.
Raid on Pearl Harbor will be a spectacularly costly failure for the IJNAF. Their bombers will all get shredded by Allied flak and Allies won't lose any ships. [:)]
With flak values not reduced, on 12/7/41 the ships in Pearl Harbor port will have a combined flak value of 5599.
(non-historical start, the flak value will be slightly lower in other scenarios)

Thanks Zeke. Let me think about what can be done about this. Istfemer raises some very legitimate concerns about simply adding up all flak values for ships in harbor, and an algorithm such as Capt. Harlock mentions would probably be necessary, as well as taking into account the stationary status of the ships.

Others have mentioned a 2 part flak calculation: 1st part giving full flak credit for the individual ship under attack, and 2nd part modifying in some way the value of the other ships. Perhaps something like full flak for ship under attack plus average value of other ships times number of ships in the TF or port, up to a maximum of say 14. This would have the effect of reducing the value of flak in a port to a maximum of about 15 ships in close proximity to the ship under attack. This wouldn't account for your small calibre weapon effect, but it would perhaps be an improvement. We'd still need to account for stationary ships in port. Also need to account for the flak value of the port itself.

I'll dig into the code and see if I can find the existing algorithm, and what modifications are reasonably possible.

Regards,

Rich

[zeke99]

Dear Rich,

your approach with the 14/15 ships sounds OK for me.

To account for the stationary ships I suggest to use a multiplier for the hit probability of bombs and torpedos eg x2.

Thanks again,[&o]
Zeke

[Istfemer]

ORIGINAL: Capt. Harlock
Interesting -- that much even before the upgrades? And isn't there an averaging algorithm to compensate for there being many more ships in harbor than are allowed in a TF?

Actually more. 5671. I forgot to add the flak value of Gato-class submarines. (six subs should be worth 72)
Regarding the possible averaging algorithm you mention, no, I don't think there is such a thing in Pacwar.

[Capt. Harlock]

Regarding the possible averaging algorithm you mention, no, I don't think there is such a thing in Pacwar.

I'm a little surprised -- I think Gary Grigsby had such an algorithm way back in "Guadalcanal Campaign". Of course, in that game there was no effective limit on the number of ships in a TF.

[Rich Dionne]

Here’s what I’ve found out about flak for ships in port:

1) The AI cycles through all ships and only adds flak for the 1st 15 ships found to be in the port. So like TFs, a maximum of 15 ships can add their individual flak values for the total defense.

2) Low preparation points can lower a ships flak value. A TFs prep pts are compared against a random value between 0 and 50. If the random value is greater than the TFs prep pts, then flak is multiplied by a factor of 0.67. Ships in port have 0 prep pts, so their flak value is always multiplied by this factor.

3) Ships in port have an additional flak reduction multiplier of 0.125, so the combined flak reduction factor compared to TFs is 0.67 x 0.125 = 0.08375 (1/12).

4) The port itself does not add any flak of its own.


Other flak multipliers that apply to both TFs and ships in port consist of the following:

1) All Japanese ships and non-combat Allied ships (class types greater than 13) get a flak factor of 0.9.

2) In June 42, USN ships get a flak factor of 1.1.

3) In Jan 43, USN ships get a flak factor of 1.25.

4) Ships that are surprised get a flak factor of 0.25.

5) Ships with 0 ammunition get a flak factor of 0.25.

6) Japanese ships firing flak at night get a flak factor of 0.25, Allied ships at night get a flak factor of 0.5.

7) All flak against heavy bombers is reduced by a factor of 10.


So, as an example, in Jan 1943, a USN combat ship surprised in port would have applied the following flak factors: 1.25 (USN 1943) x 0.25 (surprise) x 0.67 (low prep pts) x 0.125 (in port) = 0.026.

The combined, factored flak value is compared against a random value between 0 and 8000. If the combined flak value is greater than this random number, the aircraft is hit, although not necessarily destroyed.

Another factor that affects the ability of aircraft to hit ships in port is the evasion rating, which is basically built around a ship's speed. Ships in port have this value divided by 10, making them 10 times easier to hit than ships in TFs.

Looking at the code, it would be very difficult to make any significant changes beyond adjusting the factors. I did run a few tests altering the port flak factor from 0.125 to 0.5, and there wasn't much impact on number of ship hits or aircraft lost...

Regards,

Rich