Stalled actions?

[vj531]

Just started using .258 after some time away from BftB.
I'm using 'Spearhead v Reich'by way of a refresher coarse - which I really needed.

I'm getting many messages "move task has stalled and it waiting".

Can some kind sole tell me the best way to avoid this happening so frequently?
Do I need to extend the order end time?

hope that makes sense.

[dazkaz15]

Quite often this happens when trying to move a depot or a regimental HQ with no line units in the formation.

It's not a bad thing, it's just letting you know that there is enemy somewhere on the route so its waiting for a clear path.

I have seen a number of attacks stall or get stuck now, and that is a different issue. I sent Dave a saved game of one such attack.

You also need to allow plenty of time now for your move orders as the AI will automatically put in the finish time for the move for you, and it's very rarely enough time. If the time expires you are given a message in the log that is very easy to miss, as there is no pause on message option in the game. This can be annoying as it usually abandons the move, and reverts to defend in situ, thus losing 30-60min in orders delay waiting to get going again. I quite often click the end time up a few days, then select no rest, just to make sure it still moves if it gets dark. You need to remember to set it back to normal though when they get to the destination or they will end up fatigued.

Not a problem if you go really slow, and follow everything in the message log, but this is usually not desirable as its spammed with resupply reports.

The message log is one of the things I have on my list for a new concept design thing.

It needs more colours, filters, and pause options.

Hope this helps.
Daz

[vj531]

Thanks Daz

Its a real pain.....

[dazkaz15]

ORIGINAL: Arjuna

The messages "stalled and waiting", "stalled and bypassing" an "stalled and replanning" were introduced in the last build. These all relate to cases where the subject of a Move task comes within threat range of an enemy ( 1000m plus unit radius ) and where the subject is a senior HQ (ie. Bde and above) or a Base for any type of Move task or is a support unit or any type of HQ conducting an advance to the Reserve position as part of an attack. If Bypass is allowed they will try to bypass. They may get several attempts at bypassing as sometimes the bypass route may not get them out of threat range. In such cases they will wait till the next attempt. With each attempt they increase the caution factor of the route thus giving a wider berth around known threats. If they can't bypass either because the option is not checked on the order setting or they just can't get a suitable route, then they will replan. This may not help. It depends on the orders they have and the situation around them.

So if you see these messages take a good look at the subject's situation and if necessary change its orders. HQs and support units are not meant to be placed in harms way.

The message "stalled attack" has been in the engine in for quite some time and relates to cases where an attack has failed to make progress. If the stalled force is part of a complex attack then it will bunker down leaving other subAttacks to continue. If it's just part of a basic attack then it will replan.

Ahhh

That explains what I have been experiencing a lot, that I thought was a bug.
It happens quite often when I try to start new attack orders while the HQ is still on route to the new FUP.
It just stops and waits for hours.
Would it be possible to turn down the range for Bn HQ from 1000m to say 500m as when in close terrain, like the forest here, I quite often have my FUP close to the enemy, or should we just get into the habit now of setting it further back now?

Think this belongs here too [;)]

[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.

[Phoenix100]

Just like that, Daz! Now that's development interaction and keeping the customer happy.

Can you do one for me, Dave? I'd like to be able to pin my command to a unit of choice on the map (a Bn, say) - as if I'm travelling around with it - and have virtually no orders delay for just that unit, for the period I'm with it. Representing the situation where the commander lands in the embattled area and chivvies things along....

Just joking. It would be nice to have a kind of fast action fire brigade capability owing to my actual presence, but I realise things are never that simple...

[dazkaz15]

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.

Wow[X(]

Thanks Dave [:)]

[wodin]

ORIGINAL: phoenix

Just like that, Daz! Now that's development interaction and keeping the customer happy.

Can you do one for me, Dave? I'd like to be able to pin my command to a unit of choice on the map (a Bn, say) - as if I'm travelling around with it - and have virtually no orders delay for just that unit, for the period I'm with it. Representing the situation where the commander lands in the embattled area and chivvies things along....

Just joking. It would be nice to have a kind of fast action fire brigade capability owing to my actual presence, but I realise things are never that simple...

Just give an order at the level you want and you already have that..the delay is you say Give an order to a Btn and your the Btn commander giving out the orders to the Coys (thats the delay we have now) and the men sorting themselves out. No commander can instantly give out an order and all his men are ready before he can blink.

[Bazza042]

Arjuna,

I am slightly puzzled by this.

In your original response you specifically stated that the 'stalled' messages related to a senior HQ (Brigade and above) which was the 'problem' I experienced and which prompted your initial response. But this later reply relates to a Battalion HQ, which doesn't fall into your earlier definition of a 'Senior HQ'.

So three questions, just to clarify please:

a)does the HQ radius+1000 yards apply to all HQ's - subject to the change you have outlined above?

b)if not, are there greater limitations on 'Senior HQs'?

c)does the 'covered terrain' relaxation outlined above, apply to Senior HQ's?

I am absolutely not trying to nit pick but this is quite a change to what was allowed 'pre-patch' and I suspect will cause quite a few people to have to modify their approach so I think it needs to be clearly understood.

Congratulations on the timeliness and for the excellent support you continue to offer.

[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?

[Bazza042]

Arjuna,

Many thanks for the prompt, and clear, response.

I will certainly have to change my approach to take account of this, otherwise the HQ's risk not being able to 'finish' their move
unless the attack has cleared the enemy well away from its 'final' destination.


Up to now I've let the AI pick the best formation for the assault: it looks as though I may have to delve into the formation options a bit more carefully now.....

Good stuff.

Thanks again

[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.

[Bazza042]

Thanks for the advice and your involvement.

Something else to try........

[vj531]

thanks for that also Dave!

Nice and easy to understand.

[Bazza042]

May I just revisit the issue of 'stalling' and, above all, the 'replanning' aspect.

Arjuna gave some good advice as to how to minimise the possibility but I am still seeing two issues.

1. The 'friendly' HQ seems to have better intelligence on the whereabouts of enemy units than does either the player
or the units under its control. This problem arises when you have, essentially, an isolated unit roaming about in your
rear area which is 'invisible' in that there have been no current or recent sightings. This is exacerbated in some
scenarios, such as 'Joe's Bridge', where enemy 'reinforcements' come on behind the 'front lines'. So the HQ 'knows'
that there is an enemy unit out there, within the 1000m plus unit radius distance, somewhere even though it is not shown on any
intelligence report.

So the HQ seems to have more information than the player and also, as no sighting appears, seems reluctant to pass on its intelligence.
And, if it hasn't sighted the enemy unit and none of its subordinate units have, how does it 'know' the enemy unit is there?

2. I think that the replanning in these circumstances may also be flawed.

As I stated earlier, an attack is planned and is proceeding well and achieves its immediate objectives. But because of the above,
the reorgnising task on the objective cannot take place because the HQ is stranded (stalled) and cannot move forward. After about 30 minutes
or so, and a number of warning messages, the HQ duly replans. This involves the attacking units who were on their objectives being
'recalled' to an FP and after a short hiatus the re-planned attack goes in again. But this attack takes no regard of the 'invisible unit'
that is stopping the HQ from moving forward in the first place, so although the attack is 'successful' the HQ cannot move forward,and the
whole cycle begins again.

Most scenarios are not affected by this, I accept.

Whilst accepting that a change to the replanning code is probably too difficult to seriously contemplate I would like to see:

1. The unit, that is preventing the move of the HQ, being 'sighted' or being capable of being found by looking at the threat level
from the HQ.

2. The replanning not taking place if the HQ 'knows' that the limitations on it moving forward still exist or alternatively a longer
period before the HQ decides to replan. The problem at the moment is, with the lack of sighting information, by the time you have mounted a sweep
to clear the enemy the HQ is already in replanning mode.

The replanning, I think, came in with the new release but the HQ 'failure to complete its move/assault' task also seems far more
prevalent in the new release although I had seen it, occasionally, before.

[Arjuna]

Bazza042,

Please clarify whether you are talking about a stalled attack or a stalled move.

[Arjuna]

If this is for a stalled move I can confirm that it is only triggered if there is either a visible or known enemy within the designated range.

A stalled attack is not triggered by the presence of enemy rather by the lack of progress by the attacking forces.

[vj531]

Dave

What are the criteria for failed moves?

[Arjuna]

For stalled attacks you will get a stalled attack message in the unit log. For a stalled move it will be either a stalled and waiting, stalled and bypassing or stalled and replanning message in the log.

[vj531]

I have had failed move- then I had to re-input the move.

Is this normal and just me forgetting something after sometime away from the game?

What causes this if this is the case.