Patch 06 - Public Beta - Build 1108r9 updated 21 January 2012 (2nd part)

[michaelm75au]

If the unit has a delay defined in the editor, then it should keep some sort of delay if the arrival hex is an enemy base.

I am adding a check to set the delay to 2 if the reinforcement (as defined by a delay in the editor) is due to arrive on map at an enemy base at the scenario start. This will force it to stay in the queue until the arrival base becomes available. Should apply to LCU, groups and hopefully ships. (Not sure if ships will work that way as they are handled in a different way to the others).

[Pascal_slith]

This may be WAD but I have an F-4 Recon unit in Noumea that I've set to 'Naval Search' at full range with drop tanks (19 hexes; see first picture). However, when I look at the map and show the search arc, it is limited to 7 hexes (see second picture). Is this as it's supposed to be?

[Pascal_slith]

second picture...

[similar]

I'm playing the scenario 1 as the Japanese against the AI; it's just turned 11th December and I've had what I think are a couple of bugs with TFs. I've been playing 1108p5 and posted in this forum in case it's relevant. If not, please accept my apologies and I can post this elsewhere. 

-  TF5 the Surface Combat Heavy Cover force (2BB, 2CA, 1CL, 6DD) for the Kota Bharu landings was in Kota Bharu and fought a night time surface combat with an Allied TF of three DDs and the Repulse in the hex: 1 Allied DD and the Repulse was sunk and my TF got off lightly. At the start of the next turn TF5 was in Singora three hexes up the coast even though I had not set my TF to move. Is this possible in the normal mechanics of the game?

- In Babeldaob I have an Amphibious TF docked and trying to load Kure 2nd SNLF. The TF has troop/cargo capacity of 1815/15440 and the LCU's load is 1488/149 (and the TF already has c. 650 supplies). At the start of the next turn the TF is unloading (and has not picked up the LCU). This has happened a couple of times.

- Similarly in Amami Oshima I have a docked Cargo TF with one xAK set to load resources of which there are more than 6000 at the base, but at the start of the next turn it has reset itself and not loaded anything. This has happened two or three times.

Meanwhile other TFs are loading normally, for instance an Amphibious TF in Peleliu has successfully picked up some engineers.

I have the save games if required.

Apart from that I have to thank you for the amazing support you put into this game. Thanks for your help and insight on these issues too.  

[asdicus]

Have recently upgraded my pbm game to 1108p6 beta. The replay is now frequently showing graphical corruption. This is every turn replay using 1108p6. I have seen this problem in the past on previous patches but it always was a rare event. Screen attached showing an example of the problem.

[oldman45]

ORIGINAL: similar

I'm playing the scenario 1 as the Japanese against the AI; it's just turned 11th December and I've had what I think are a couple of bugs with TFs. I've been playing 1108p5 and posted in this forum in case it's relevant. If not, please accept my apologies and I can post this elsewhere. 

- 

- In Babeldaob I have an Amphibious TF docked and trying to load Kure 2nd SNLF. The TF has troop/cargo capacity of 1815/15440 and the LCU's load is 1488/149 (and the TF already has c. 650 supplies). At the start of the next turn the TF is unloading (and has not picked up the LCU). This has happened a couple of times.

- Similarly in Amami Oshima I have a docked Cargo TF with one xAK set to load resources of which there are more than 6000 at the base, but at the start of the next turn it has reset itself and not loaded anything. This has happened two or three times.

Meanwhile other TFs are loading normally, for instance an Amphibious TF in Peleliu has successfully picked up some engineers.

 

I can only speak for those 2 items, when I have had this happen its because I created the TF but did not give it a destination and it simply unloaded everything at the end of the turn. You might want to check for that.

[littleike]

I have observed that sometime mistakes are related to loading something on a human controlled tf without set the "do not unload" command, so the tf load things and then unload them.

Here is my question. If the program could automatically set tf to "do not unload" as soon as a user set a load command What contraindication would be? I seem that we could save some mistakes in this way.

Many thanks [:)]

[Theages]

You could forget to set it to unload when sending it to a destination. You would only exchange the possibility of making one mistake with making a different one.

[Itdepends]

Edit comment removed- commenting on previous page of thread- doh!

[michaelm75au]

ORIGINAL: Pascal

second picture...

It is searching out to correct range.
However, drawing of the arcs is not considering drop tanks.
Fixed in 1108p7

[PaxMondo]

ORIGINAL: michaelm

ORIGINAL: Pascal

second picture...

It is searching out to correct range.
However, drawing of the arcs is not considering drop tanks.
Fixed in 1108p7

Wow. Thanks for the great support!!!!

[jmalter]

ORIGINAL: michaelm
It is searching out to correct range.
However, drawing of the arcs is not considering drop tanks.
Fixed in 1108p7

good to know that they've been searching out to their set range, the display-fix will be appreciated, thanks.

[Pascal_slith]

ORIGINAL: jmalter

ORIGINAL: michaelm
It is searching out to correct range.
However, drawing of the arcs is not considering drop tanks.
Fixed in 1108p7

good to know that they've been searching out to their set range, the display-fix will be appreciated, thanks.

Yes, thank you very much. I'm seeing the same thing with a Vindicator squadron with drop tanks.

As usual, and I can't repeat this often enough, your support is AWESOME!!! [&o][&o][&o]

BTW, this also seems to occur between normal and extended range too. Arcs only go to normal range, not extended range.

[michaelm75au]

Search range actually can vary between AM and PM phases.
The drawing uses the minimum range of the player's max range and the normal range(with/out DTs).
The AM range is based on a 4-hour flight endurance, while the PM phase is to the full range if the plane didn't fly in the AM, otherwise the same 4-hour endurance.
[Bit too complicated for quick draw arc solution]
In WITP, this use to be a constant max hex range in both AM/PM phases from memory, based on 1/3 a/c max range and 1/10 a/c cruise speed.

[witpqs]

ORIGINAL: michaelm

Search range actually can vary between AM and PM phases.
The drawing uses the minimum range of the player's max range and the normal range(with/out DTs).
The AM range is based on a 4-hour flight endurance, while the PM phase is to the full range if the plane didn't fly in the AM, otherwise the same 4-hour endurance.
[Bit too complicated for quick draw arc solution]
In WITP, this use to be a constant max hex range in both AM/PM phases from memory, based on 1/3 a/c max range and 1/10 a/c cruise speed.

This is quite impressive - it means that search has more realistic constraints than we had thought!

[michaelm75au]

ORIGINAL: witpqs

ORIGINAL: michaelm

Search range actually can vary between AM and PM phases.
The drawing uses the minimum range of the player's max range and the normal range(with/out DTs).
The AM range is based on a 4-hour flight endurance, while the PM phase is to the full range if the plane didn't fly in the AM, otherwise the same 4-hour endurance.
[Bit too complicated for quick draw arc solution]
In WITP, this use to be a constant max hex range in both AM/PM phases from memory, based on 1/3 a/c max range and 1/10 a/c cruise speed.

This is quite impressive - it means that search has more realistic constraints than we had thought!

Yes. One thing I didn't like in the original was the extreme range some planes tended to fly search in both phases. Esp later on when the range of planes tended to improve.
Thus when AE come in, this was one item that I changed fairly early on. Not perfect, but more real than previously. I also hear less complaints about searches covering half the map now.[:D]

[PaxMondo]

ORIGINAL: michaelm

ORIGINAL: witpqs

ORIGINAL: michaelm

Search range actually can vary between AM and PM phases.
The drawing uses the minimum range of the player's max range and the normal range(with/out DTs).
The AM range is based on a 4-hour flight endurance, while the PM phase is to the full range if the plane didn't fly in the AM, otherwise the same 4-hour endurance.
[Bit too complicated for quick draw arc solution]
In WITP, this use to be a constant max hex range in both AM/PM phases from memory, based on 1/3 a/c max range and 1/10 a/c cruise speed.

This is quite impressive - it means that search has more realistic constraints than we had thought!

Yes. One thing I didn't like in the original was the extreme range some planes tended to fly search in both phases. Esp later on when the range of planes tended to improve.
Thus when AE come in, this was one item that I changed fairly early on. Not perfect, but more real than previously. I also hear less complaints about searches covering half the map now.[:D]

This also explains a lot about some of the results you see. Just because your Emily can search out +20 hexes, doesn't mean it is. You need to have better overlap and not try to depend upon one lone group. Again, much more like IRL. Superb.

[asdicus]

michaelm do you have any thoughts regarding the graphical corruption during replays using 1108p6 ? see screen on post #205. I have never had this problem occur in previous patches for every replay turn. Thanks.

[michaelm75au]

No.
The image looks like that caused by memory limitations due to DirectX or for image paging within the game.
Neither of which would be directly caused by p6, anymore than any other beta.
I assume that you have tried restarting the game and/or rebooting PC.
Only other thing that comes to mind would be to try to up the scroll delay (in the preferences).

[asdicus]

michaelm I will try the scroll delay change. Thank-you for your suggestions.