Feedback Public Beta BftB v4.4.264

[dazkaz15]

DefendDelay

[dazkaz15]

ORIGINAL: Arjuna

If you issue a Defend order and the force is already deployed within the perimeter then there is a very good chance it will stay put and take advantage of its current deployed state. The probability is increased if the force is dug in or entrenched. The Ai will search through the force and separate out any units that meet these conditions. It will then issue them with a Defend inSitu order and issue a normal Defend to the rest of the force.

Thanks Dave.

Its always good to read stuff that is gong on under the hood, that we are not aware of.
That makes perfect sense, even if it is a bit inconvenient if you want to adjust their position to better cover an approach or to move them into a cluster of buildings or something.
As I have said though, we can always use a move order to do that, so no biggie.

[BigDuke66]

Seems like dazkaz15 and my postings have the same target, I didn't check if really a second command delay is applied to the units, anyhow it is new that "This was introduced quite a while back", can't remember seeing such behavior in much earlier versions but I mentioned that problem already in the Feedback Thread for 262 in early may:
fb.asp?m=3321957
As said already there any order that involves a move task followed by a defend task as a huge delay between them where the units are simply "stuck in motion" as neither the very first nor the last units have reached their final positions, that makes simply no sense as task follows on task and the simple switch to a different task should lead to any delay at least not any big delay.

BTW we and such a delay thing with attack orders that one was killed any one of the earlier versions, just in case this might be a similar problem.

[BigDuke66]

So anything found meanwhile?

[wodin]

It's obviously adding the delay all over again for the defend par of the task. Obviously they would have been given their instructions before they set off..where as the game is working that they were told to move which they did then they waited for the command to defend to come along..obviously needs fixing. Becomes alot more obvious with a HQ who is over taxed so the delay is already long.

[Arjuna]

I have just fixed this issue. What was occurring was that when you issued an order like a Defend where the force was not at the objective location, the initial plan developed would first conduct a Move to the location. What should have happened when the force got to the obj loc was that it should have immediately conducted a defend task. However, it was in fact incurring a standard orders delay before starting the defend task.

I checked the code and found that while I was passing a NoOrdersDelay flag into the DevelopMissionPlan() and the DetermineMissionTask() I was not doing so for the DerivePlanTask(). The latter function creates the actual planTask that the force conducts. I have ensured that this flag is now passed down and a quick test shows that it all works as originally intended. Thanks for reporting this bug.

FIXED.

[BigDuke66]

Ah very good, Thanks!!!
Hopefully we see another beta soon.

[Arjuna]

Soon but there are a few more items to address first.