Updated Scen 1 and 2

[RangerJoe]

They used to but that got changed in an update . . .

[btd64]

News to me....GP

[BBfanboy]

ORIGINAL: Yaab

Silly me. I thought changing routing for off-map TFs results in routing errors.

It results in errors if the convoy is already in the holding box (i.e. has left the off-map port or gone from on-map to off-map). Instructions that change home port or destination will get messed up because the off-map movement is not hex by hex, but by a table that says when and where to put the TF on the map or at an off-map port. It does not know where the TF should be in its movment if you change the parameters during the time in the holding box. Things like speed and fueling instructions do not cause problems.

[Yaab]

TF422 starts in the small holding box adjacent to the map. Is it safe to change its routing or not?

[btd64]

If you set historical first turn to off, you can change the destination while the TF is at Capetown. Otherwise no, you can't change the destination....GP

[Yaab]

Thanks.

Damn, now I see why I have missed this TF. When you click on it, it seems the TF is routed to Singapore through the Strait of Malacca, while 100% of my manual TFs go through Merak to Singapore.

[Treetop64]

ORIGINAL: RangerJoe

They used to but that got changed in an update . . .

...and I am just now learning of this fix. Thanks.

Still, I might continue avoiding changing routing of off-map TFs due to well-established paranoia. And their routing is still kinda weird-ish. For example, off-map supply TFs (manual or continuous) that are returning to the off-map base after dropping off an on-map load, still show the on-map location as the current destination, even though they're now returning from that location. Usually just manually reset the return trip anyway just to make sure nothing breaks.

[Treetop64]

ORIGINAL: BBfanboy

ORIGINAL: Yaab

Silly me. I thought changing routing for off-map TFs results in routing errors.

It results in errors if the convoy is already in the holding box (i.e. has left the off-map port or gone from on-map to off-map). Instructions that change home port or destination will get messed up because the off-map movement is not hex by hex, but by a table that says when and where to put the TF on the map or at an off-map port. It does not know where the TF should be in its movment if you change the parameters during the time in the holding box. Things like speed and fueling instructions do not cause problems.

Thanks for the clarification. [:)]

[orabera]

Possible update for the next update. Minor change, the USCGC Tiger should be on ASW patrol around Oahu.

https://pearlharbor.org/us-coast-guard-cutter-tiger/

[Yaab]

Scen 001v5, Allies

Choybalsan has duplicate LI centers

[Yaab]

Scen 001v5.

Played on Normal vs Jap AI until January 1, 1942. No suicide AI behaviour observed. No deep invasions, good fighter coverage of amphibious landings. Very enjoyable.

[Nomad]

Andy Mac, just wanted to tell you that one of the new bases in Burma causes an issue with Combat Reporter. The base Arakan Yoma (C) is the one that causes the problem It reads the (C) as the copywrite symbol.
Also excel does the same thing so making a Tracker region file is a problem. I have found workarounds, but it is a problem.

[Yaab]

Andy, I wanted to try your scen007, but whenever I copy the scen007 files into the WTIP:AE's SCEN folder I get an error message for the CMT file. I redownload your RAR file but still get the same error message.


Error 0x80070570 The file or folder is damaged and cannot be read

[Yaab]

Andy, I cannot comment on scen007, but in secn001v5 I noticed some things in Burma

In Burma there are now three kinds of bases:

-the original stock bases with supply caps between 250-1050 based on their development level
-your new fort-6 bases with supply cap of 250
-your new undeveloped bases with 0 forts and 0(1) airfield with supply cap of 1000(sic!).

I think the new bases needs to be aligned with the original bases in terms of their supply caps.

[Andy Mac]

Huh I will check that out that is not intended

[Andy Mac]

OK its fixed in 7 which is the scenario I am using as baseline - not sure how that happened in 1v5 but its definitly ok in 7

[OnWargaming]

Any issue to update an ongoing game?

[Yaab]

I had to re-install Witp:AE. I was able to load the lastest version of scen007.

Andy, the problem is still there.

This is one of your fort 0, airfield 0(1) bases.

Daik-u has a supply cap of 1000. Stock base of Pegu with airfield 1(7) has 500 supply cap, while Toungoo with airfield 1(7) has 250 supply cap. All of your bases in Burma with airfield 0(1) have supply caps of 1000.

I vaguely remember this is so because the Editor automatically assigns 1000 supply cap when you set a base port/airfield to 0(1) value and forts to 0(9). Each potential fort/airfield/port level is worth 100 supply cap. I guess you have to manually decrease the 1000 supply cap to something like 100-200 in the Editor.
Once you set a base to 1(9) forts and 0(1) airfiled the supply cap is lowered to 150. This can be observed in your new bases in China - each constructed fort level ups the supply cap by 150 points, downgrading the automatic 1000 supply cap.

[Andy Mac]

Yeah thanks got it and fixed it ta

[Yaab]

Actually, for some bases in the Burma-India region the problem of 1000 supply cap has existed since 2009!

Burma:

Kalemyo
Warazup
Katha
Bhamo
Ramree Island

India:

Rangpur
Silchar
Tezpur

Australia:

Fenton


Those bases start with airfield 0, forts 0, but somehow have 1000 supply caps. Mind you, only Mandalay at start has a 1050 supply cap owing to its arfield 2, forts 1. It seems those bases need to have their supply caps downgraded both in scen001 and scen007 to 100-150 supply caps.

EDIT: Added Bhamo and Ramree Island.

EDIT2: Added Fenton in Australia.

Andy, it is working!

Here is an amended DBB-C scen028v15. I added forts 1 to Ramree Island in the Editor. This changed Ramree Island's supply cap from 1000 to 100 on map. I amended all eight bases that start with augmented supply caps. Now all eight are in 400-100 range.