Coordinating attack post beta v 4.4.259

[Phoenix100]

GBS. Try it with 'fastest' selected. Mine goes in ok if I do that.

[Phoenix100]

GBS, try these exact settings, and more or less exact placement - see if you can get the attack to go in. Mine works every time. The setting making the diff was 'fastest'. you need to select it.

[GBS]

I just tried the Tutorial witha coordinated attack. Both set at 8:03. 51st had basing and straggles unchecked and the 318th did not. As you can see it came off perfectly

[GBS]

Phoenix, the attack came off perfectly. It must be the placement of the FUP. I was using the Zinc Factory and half way down the highway to the objective as the FUP previously.

[Phoenix100]

I don't think so, GBS, since I tried it and had the same result as you, then checked 'fastest' and it went in ok. It's probably some issue, I would think, but hard to know without Dave looking at it. Meanwhile, I'm glad you got past it.

However, there's a separate thing about placing the FUP too close to your attack, which will likely cause your HQ to run into problems, I believe. So that might have been part of it. I'm a little confused about what's what with the 'stalled and waiting' messages which are likely to appear when the HQ feels threatened, but I think the FUP placement can have something to do with it. However, you weren't getting 'stalled and waiting' messages, just slipped task and task abandoned messages.

[GBS]

ORIGINAL: phoenix

I don't think so, GBS, since I tried it and had the same result as you, then checked 'fastest' and it went in ok. It's probably some issue, I would think, but hard to know without Dave looking at it. Meanwhile, I'm glad you got past it.

However, there's a separate thing about placing the FUP too close to your attack, which will likely cause your HQ to run into problems, I believe. So that might have been part of it. I'm a little confused about what's what with the 'stalled and waiting' messages which are likely to appear when the HQ feels threatened, but I think the FUP placement can have something to do with it. However, you weren't getting 'stalled and waiting' messages, just slipped task and task abandoned messages.

To be honest Phoenix I think I forgot to set fastest this last successful time, or maybe I did. I just moved the FUP back from where I was setting it previously.

[dazkaz15]

I think it is more to do with you guys placing your FUP to close.
Remember Dave has put a code in now that used to be 1000m for Battalion HQ but is now reduced to 500m but it is terrain dependant.
If the terrain is not covered I think the HQ will still not move to within 1000m, which will cause the staling, and then the abandonment.
Try setting your FUP in covered terrain, and/or at 1500m-2000m from the enemy.

[Phoenix100]

He doesn't get stalled messages though, Daz.

Am I right, GBS - no stalled messages?

And isn't that piece of code just for 'higher HQs'?

[dazkaz15]

I'm not sure mate.
All I do know for sure is its best to place the FUP at about the 2km mark from enemy during a long range move to attack, or use a move order first then convert it to an attack, but remember to change the end time to end of scenario when you do this.
Here is what Dave said about this issue, if it is indeed this that is causing your problems?

ORIGINAL: Arjuna

Yes we could do that and yes I have just done it. [:)]

If the terrain ahead along the route is covered for 500m then it will reduce the threat search range to 500m + unitRadius. Normally the threat search range is 1000m + unitRadius. For the route ahead to be considered covered 67% of the indexes ahead must be covered terrain. I use the route ahead rather than the units current loc because its current loc might be covered and then it would move into the open and then it would say no I can't move and the poor unit would be out in the open.

ORIGINAL: Arjuna

Bazza042,

Here's the if test used to check for a stall during a Move:

if( ( isASeniorHQ ||
isBase ||
( ( combatClass == kCombatClassSupport ||
combatClass == kCombatClassHQ ) &&
( planTaskType == kAdvanceToReservePlanTask ||
planTaskType == kIndAdvanceToReservePlanTask ) ) ) &&
routStatus < kRetreating )

So what that is saying is that if the unit is not reacting and is a senior HQ or a base ( regardless of what its doing ) or its any other HQ or support unit that is performing this move as part of and advance to the reserve location of an attack. This means that it always affect senior HQs and bases but only affects other support and HQ units if they are on their way to the reserve loc.

Once you get passed the if test the radius and covered terrain limits apply to all.

Does that explain it?

ORIGINAL: Arjuna

In general it doesn't matter for attacks because HQs are not committed to the assault. They go to the reserve loc. If your attack is conducted a short distance away from where the HQ is then you are unlikely to get stalled on the way to the nearby reserve. The problem occurs where the objective is a long way away. Then the force will often advance to an assembly area before deploying into the attack. It's this phase where you may encounter this problem. So it's important where you place any waypoints. Make sure these are well away ( ie > 1km ) from known enemy. Another way to avoid this is to conduct a Move first and then do your attack orders as they near the objective for the Move.

[GBS]

ORIGINAL: phoenix

He doesn't get stalled messages though, Daz.

Am I right, GBS - no stalled messages?

And isn't that piece of code just for 'higher HQs'?

Correct, no stalled messages.

[Phoenix100]

Very helpful, Daz. From those quotes it could certainly be something to do with that. Though there were no stalled messages. But maybe it just skipped that phase and went direct to abandonment.

[GBS]

Phoenix and Daz, just for information, the key is using "FASTEST". I have restarted the Joe's scenario at least 6 times using Fastest and it always coordinates with maybe a minute or two slippage by one of the Bns but that sounds pretty normal.

It may just be this scenario. I can have a successful coordination with the Tutorial without using FASTEST.

[Phoenix100]

Thanks GBS. I thought so. The setting - FASTEST - might, of course, affect where the AI decides to place the forming up point for the attack, ending up with it further away from the enemy (because they're rushed?) - in which case there might be a logical explanation for whhy you need to select it in just this tutorial. I'll experiment placing the FUP further away/nearer and not selecting FASTEST, just to see.

[dazkaz15]

I've just done this same test, and can confirm there is some kind of bug causing this in this particular scenario.
Unless I am also doing something wrong that is?
I think maybe leave it for now, and see what happens after the new patch is installed?

[Remmes]

I always have bad things happen when running the game at fastest speed. Played a couple of scenarios tonight with ctd's in about 2/3 of 'em. Let's hope it gets fixed in the new patch. (fingers crossed)

[Floyd]

As i understand, it is the speed of the unit (normal <> fastest), not the speed of the game (time acceleration).

[Remmes]

ORIGINAL: Floyd

As i understand, it is the speed of the unit (normal <> fastest), not the speed of the game (time acceleration).

You are totally right; I stand corrected.

[Phoenix100]

As i understand, it is the speed of the unit (normal <> fastest), not the speed of the game (time acceleration).

I have no idea what you're talking about. if you press the 3 arrows buttons it speeds the whole game up, right?

[wodin]

Mr P he is talking about fastest movement rate not fastest time accel.

[Phoenix100]

Ah. je comprends! many thanks, wodin.