New! v1127 Public Beta Available

[Tanaka]

I noticed this fix in a GGWITE2 patch and GGWITPAE has the same problems with music volume changing with mouse clicks etc different tracks etc. I wonder if this same fix could be applied to GGWITPAE to keep the music volume consistently the same level? Music set to 1 you can barely hear. Music set to 2 is too loud. Clicking buttons jumps the music volume up and down.

*Adjusting music volume doesn't take immediate effect/impacts mouse click. Fixed.

[Tanaka]

The Japanese "Emily" float plane still has no plane range circle that shows up on the map. This has still never been fixed.

[Tanaka]

It's a data error.

It's all to do with how minelayers recognise they are minelayers (6.6.1.3.1 and 6.6.1.3.2.2). The mine's ammo and armor attributes control this.

For regular minelayers the ammo slot should have a number indicating it normally carries mines and how many. Armor is irrelevant.
In auxiliary minelayers, which is what the Tenryu class is, the ammo slot should be zero indicating it does not normally carry mines. The armor slot is used to indicate how many it carries.

With the CL Tenryu class ammo says 24 when it should be zero, the 24 being in armor. This is confusing the programming by indicating it's regular minelayer but it's class designation is CL. The two thing are controdicting each other.

You can temporarily fix by creating a minelaying TF elsewhere, Truk, Shortlands for instance. It will be just escort but that doesn't matter. Move it to Rabaul and adding the two CLs and you'll have your M/L TF. Alternatively you can move the CL to a port were you can already create a minelaying TF.

If your going to ask why you can't created a minelaying TF in Rabaul, Pass! You can if you move ship from another location in, like the PB in shortlands. It doesn't have to be a M/L TF, any type appears to work. I did say the program get confused.

To permanently fix it the database needs correcting and not just for this scenario, s#1 is the same and probably all scenarios.

Don't know if this has been noted to be fixed but thanks to Chris21wen for pointing out. Database error effecting Guadalcanal scenario and thus probably all scenarios?

https://www.matrixgames.com/forums/view ... 3&t=396142

[Tanaka]

Don't get me wrong.

I understand the rationale for the changes. However, you would have to test if the 1944-45 convoys bring enough supplies/fuel to make up for the lost free supplies/fuel from the stock scenarios.

With the stock 65,000 supplies daily, Eastern USA generated about 106,000,000 supplies for the whole war (1640 game turns). Right now (1000 free supplies) it generates just 1,640,000 supplies. Changing the free daily allowance to 10,000 supplies per day, generates 16,400,000 supplies for the whole war. Couple that with the 1994-45 convoys, and you can probably hit 35,000,000 supplies for the whole war in the beta scenarios.

Thus, just change the Eastern USA allowance from 1,000 sup/fuel daily to 10,000 sup/fuel daily. USA will generate this way around 1/3 of the original value which was probably too high to begin with (106,000,000 supplies).35,000,000 translates into 21,000 supplies per day for US units to codnuct their operations. That value is for Eastern USA/convoys only. CONUSA also generates supplies on-map.

My initial thoughts were to set up a system for gradually increasing supplies and fuel using damaged industry centres that have to be repaired, but I now think setting that up is too complex, and best left for mods.

I will increase the daily fuel and supplies for the Eastern USA but will think about the best values to use. You make good points about possible values.

Interesting I guess you were going for something similar to what LST was doing in his Bottlenecks mod?

• To model the “on a shoe-string” condition of the Allies in regards to military supplies at the beginning of the war and the rising production over time, many Allied light industries and resource centers start 33% - 50% damaged. No 1945 production levels from Day 1!

[IslandInland]

I am currently using version 1.8.11.26a which isn't even available anymore either here or on the My Page entry for this game.

Should I update to this latest beta patch or wait until the next one?

Thanks for any help.

[RangerJoe]

Personally, I would wait or upgrade to the 1126b if you feel that you need to. My understanding is that the update should be finished "soon" but I don't know.

[IslandInland]

Personally, I would wait or upgrade to the 1126b if you feel that you need to. My understanding is that the update should be finished "soon" but I don't know.

I'm probably being dumb but I don't see a 1126b patch available anywhere?

[RangerJoe]

Personally, I would wait or upgrade to the 1126b if you feel that you need to. My understanding is that the update should be finished "soon" but I don't know.

I'm probably being dumb but I don't see a 1126b patch available anywhere?

Stickied on the Tech Support section.

https://www.matrixgames.com/forums/view ... 4&t=226197

[IslandInland]

Personally, I would wait or upgrade to the 1126b if you feel that you need to. My understanding is that the update should be finished "soon" but I don't know.

I'm probably being dumb but I don't see a 1126b patch available anywhere?

Stickied on the Tech Support section.

https://www.matrixgames.com/forums/view ... 4&t=226197

Thanks.

I have had this game for years (and also Uncommon Valor, WITP and WPO) and after not having played for some years patching is always somewhat confusing to me.

[RangerJoe]

I'm probably being dumb but I don't see a 1126b patch available anywhere?

Stickied on the Tech Support section.

https://www.matrixgames.com/forums/view ... 4&t=226197

Thanks.

I have had this game for years (and also Uncommon Valor, WITP and WPO) and after not having played for some years patching is always somewhat confusing to me.

You are most welcome.

Too bad that the latest patches are not included in the download. (hint)

[Tanaka]

It's a data error.

It's all to do with how minelayers recognise they are minelayers (6.6.1.3.1 and 6.6.1.3.2.2). The mine's ammo and armor attributes control this.

For regular minelayers the ammo slot should have a number indicating it normally carries mines and how many. Armor is irrelevant.
In auxiliary minelayers, which is what the Tenryu class is, the ammo slot should be zero indicating it does not normally carry mines. The armor slot is used to indicate how many it carries.

With the CL Tenryu class ammo says 24 when it should be zero, the 24 being in armor. This is confusing the programming by indicating it's regular minelayer but it's class designation is CL. The two thing are controdicting each other.

You can temporarily fix by creating a minelaying TF elsewhere, Truk, Shortlands for instance. It will be just escort but that doesn't matter. Move it to Rabaul and adding the two CLs and you'll have your M/L TF. Alternatively you can move the CL to a port were you can already create a minelaying TF.

If your going to ask why you can't created a minelaying TF in Rabaul, Pass! You can if you move ship from another location in, like the PB in shortlands. It doesn't have to be a M/L TF, any type appears to work. I did say the program get confused.

To permanently fix it the database needs correcting and not just for this scenario, s#1 is the same and probably all scenarios.

Don't know if this has been noted to be fixed but thanks to Chris21wen for pointing out. Database error effecting Guadalcanal scenario and thus probably all scenarios?

https://www.matrixgames.com/forums/view ... 3&t=396142

Yep something is really bugged with these light cruisers now in all scenarios. You used to get the triple torpedo launchers which they are known for but now you only get mines and every time you transfer between task forces they use OP points loading and unloading mines. It's weird if you transfer the Katori to the Wake invasion task force all of the sudden the Tenryu and Tatsuta before had no mines but then they do after the transfer. They used to work correctly what was changed?

"The class also was the first to use triple torpedo launchers, with two centerline-mounted Type 6 533 mm (21 in) launchers. No reloads were carried."

[Moltrey]

Joe and fellow Devs:

Has there been any commitment from Erik and your team regarding a period of post launch support to fix, troubleshoot and iron out bugs and other issues?
While you guys have my full support I have to tell you that there are a lot of rattled players out there who likely need some reassurances that this won't get dropped too soon.

I understand long-term support is not really in the cards, but I am not interested in swapping one old beta and its issues for a new set that remain unsolved. As the saying goes, I prefer the devil I know over the one I don't know.
It may sound harsh, but there shouldn't be any misunderstandings about what the community is after here. If you guys had internal goals, fine. That's all good if we can make it work at the end of the day.

I don't have a problem with extending to complete the work that must be done. I know the team is working hard and I very much appreciate all the hours volunteered.
Looking forward to the release guys.

[Yaab]

And is AndyMac even alive at this point?

[btd64]

And is AndyMac even alive at this point?

Alive and kicking ....GP

[Tanaka]

This happened to me in my PBEM as well as the Heiden PBEM: https://youtu.be/ekf639y-diM?list=PLFaQ ... pBVV&t=863

For some reason Makassar flips to British for no reason randomly.

Gasmata flips British as well: https://youtu.be/BtKcjys1IzA?list=PLFaQ ... E0k4eXpBVV

[Yaab]

Tanaka, some time ago I reported that leaders with British-sounding names are elligible for leading Dutch units. See here:
https://www.matrixgames.com/forums/view ... 5#p4942315

I guess the code treats your Dutch units as British units for purposes of switching empty bases to the Allied side. Thus Makassar switched to the British. Had your two Dutch units been assigned to i.e. ABDA, then empty Makassar would have switched to the Dutch. At least this is my theory.

[Tanaka]

Tanaka, some time ago I reported that leaders with British-sounding names are elligible for leading Dutch units. See here:
https://www.matrixgames.com/forums/view ... 5#p4942315

I guess the code treats your Dutch units as British units for purposes of switching empty bases to the Allied side. Thus Makassar switched to the British. Had your two Dutch units been assigned to i.e. ABDA, then empty Makassar would have switched to the Dutch. At least this is my theory.

Interesting. So a bug creating another bug eh?

[Yaab]

Probably.

Someone could test it by switching an empty Dutch base in Java vicinity to Jap ownership at start and running turns. The base should switch to British ownership if Dutch units are assigned to KNIL HQs.

[Kull]

A couple years back, Blackhorse created a thread on "how to fix the US TD units". Should definitely be added to v1127:

https://www.matrixgames.com/forums/view ... t=369068se

[Kull]

There's also a HUGE bug (for me, anyway) which affects the "foldered ship art system". Some history. The first "foldered art" applied to air units and was a smashing success (see "AE Art modifications.rtf" in the Manuals folder). At some point, MichaelM expanded the code so it would apply to shipside art as well. I'll spare you the details on how the system works, as it was intended to operate much like the air art system described in the referenced document. It's not an obvious bug, even for those who have installed some of my ship art mods, which make extensive use of the new system. It was invisible even to me, until my last game reached mid-1943, and I noticed that some of the ship art wasn't appearing "on schedule". It's an insidious bug, and it took me almost a week to finally track it down and determine what is going on.

I'll just note that foldered ship art is not part of the basic game, but is a feature which allows modders to apply different color schemes to the same ship class, without having to change the associated bitmap number in the database. A ship class that has only a single bmp number can display MS-2 coloring in 1941, MS-12 blotch camo in 1942, MS-21 "all blue" in 1943, MS-32 Dazzle in 1944 and ultimately MS-22 (grey upper, blue lower) in 1945. To say nothing of adding gun mounts/changing funnel count, Radar masts, etc.

In a nutshell, here's the bug: When you have foldered ship art that appears in one of the "month folders" (all those numbered "02" thru "12") from an earlier year AND if that month is the same or earlier than the current game month (in a later year), than the code will default to the art files in the "old month".

Here's how the bug presents, using an example I recently created:

EXAMPLE: The "C3-A Pres. Jackson" class AP (0445.bmp) has an MS-12 camo shipside in the "04" subfolder under the AlliedShip_Back42 folder and also in the top level AlliedShip_Back43 folder. In March 1943 the class upgrades to APA and so a new "all-blue" MS-21 shipside is placed in the "03" subfolder under the AlliedShip_Back43 folder and another is placed in the top level AlliedShip_Back44 folder. All this is exactly in keeping with the instructions.

From April 42 thru February 43, the MS-12 shipside is visible. On 3/1/43 the shipside changes to the MS-21 version, and that lasts for the rest of the month. However, promptly on 4/1/43, the art REVERTS BACK to the MS-12 shipside!!!

Apparently (and here I am just guessing) the code is confused by the fact that all the "numbered month" subfolders have exactly the same numbering (regardless of year), so it "thinks" that the "04" month in 1942 is LATER than the "03" month in 1943.

Since MichaelM is apparently back in the "coding saddle", hopefully this is something he can look at and fix!