Movement problem (clearest foolproof?)

[johndoesecond]

Hi,

Here is an example of a movement problem, to my memory the clearest example so far.

We're in "Dinant - Do or Die" here.

You can see the 2 Pz Recon Bn HQ commanding over its organic subordinates except for the 2 Coy 2 Pz Recon Bn, which has been detached since the begining of the game.

I've given the 2 Pz HQ the order to move (you'll see where), and soon thereafter the whole group started to move. But then, for no apparent reason, they stopped where you see them, and wouldn't move.

You can run the game for very long, but they just stay there (I've tried for more than three days!).

If I give them another order, they replan, move a bit, and then stop again.
Only by reataching the 2 Coy 2 Pz Recon Bn does the whole group behave as expected.

Is this by design (some sort of special doctrine for Recon Bns?), or a bug?

If it is a bug, it's not only annoying but above all it gives you the impression something's broken in a way to make you feel you can't rely on the game engine/AI to do its work, and makes you anxoius to fight not just your opponent, but also these sorts bug. True party breaker.

Thanks for you attention.

[simovitch]

Definitely a bug here, but a rare one I think. As you said, as soon as you re-attach 2 Coy to the Recon Bn HQ they all move to their objective location almost immediately.

I'll make sure Dave knows about this. Thanks for posting.

[Merv0728]

Hi johndoesecond,

there may be a problem in that at the top of the map there is a village named Ciney & in the game there is what seems to be an orphan engineer unit.I've searched thro' the OOB's for both sides but can't find it.It doesn't show in the SM either.

For some reason I can't read your attachment so can't move to where you do but I seem to be able to move the 2nd Recon Bn HQ & its units anywhere.

Alan

PS the 2 Coy 2nd Recon Bn is attached when I start the game

[johndoesecond]

ORIGINAL: Merv0728

Hi johndoesecond,

there may be a problem in that at the top of the map there is a village named Ciney & in the game there is what seems to be an orphan engineer unit.I've searched thro' the OOB's for both sides but can't find it.It doesn't show in the SM either.

That's maybe because there isn't any orphan engineer unit, but just a flawed intel report you're seeing.

Anyway, I see what you're hinting at: a group usually halts if it has a close encounter with an enemy unit, and if there is for some reason a bug somewhere in the engine tricking the HQ by making it believe is has encountered an enemy unit, something along these lines may be a possible diagnosis of the problem I encoutered.

Hm, quite an audacious and not exactly an Occam's razor hypothesis, but still maybe possible.

I really don't have such an insight into the deep internal functioning of the BTFB engine to be able to tell if you're on to something here.

For some reason I can't read your attachment so can't move to where you do but I seem to be able to move the 2nd Recon Bn HQ & its units anywhere.

Strange you can't open my attachment. Do you have the latest BFTB update?

Anyway, I too am able to move the 2nd Recon HQ and its units under other circumstances. But in this particular situation I cannot. You really should check my saved game to see the point.

PS the 2 Coy 2nd Recon Bn is attached when I start the game

Indeed it is. I detached it myself at the beginning, and that triggered the problem. I don't know whether it's due to detaching the 2 Coy, or due to setting that particular move destination for the HQ, or due to the combination of the two, or due to some other cause.

Thanks for your feedback.

[Merv0728]

johndoesecond,

sorry I havn't answered before but having troubles with my broadband & technicians,something to do with a piece of equipment in the local exchange.

Re the attachment, I've attached a file of wnat I get when I D/L it (Dinant.zip).

Alan

[johndoesecond]

ORIGINAL: Merv0728

johndoesecond,

sorry I havn't answered before but having troubles with my broadband & technicians,something to do with a piece of equipment in the local exchange.

Re the attachment, I've attached a file of wnat I get when I D/L it (Dinant.zip).

Alan

Maybe you just have to unzip the .cog file somewhere and then open it from BFTB.
Or am I missing something else?

[johndoesecond]

ORIGINAL: simovitch

Definitely a bug here, but a rare one I think. As you said, as soon as you re-attach 2 Coy to the Recon Bn HQ they all move to their objective location almost immediately.

I'll make sure Dave knows about this. Thanks for posting.

simovitch

Hi simovitch,

Did you have chance to have Dave have a look at this?
Did he confirm it's a bug? What could have been the cause of this behavior?

Thanks for your attention.

[Arjuna]

I haven't had a chance to look at this yet. But I suspect it maybe a formation lockup. These can occur occassionally when moving large formations ( eg 40 or more units ). Forcing a revamp of the formation by attaching or detaching a unit or by shifting a waypoint usually fixes this problem.

[johndoesecond]

Hi Arjuna,

Thanks for answering.

Could be, but here we're having only a small Recon Bn (3+1 companies). Really puzzling ...

[johndoesecond]

ORIGINAL: Arjuna

I haven't had a chance to look at this yet. But I suspect it maybe a formation lockup. These can occur occassionally when moving large formations ( eg 40 or more units ). Forcing a revamp of the formation by attaching or detaching a unit or by shifting a waypoint usually fixes this problem.

Hi Dave,

Sorry for bothering again. I understand there can occur formation lockup for large formations (even though it's a pitty that they do), but did you have chance to have a look at this one?

As you'd see, we're talking about 3-4 organically related units here, so nothing large nor esoteric.

It would really be useful, I believe, to pin down the causes of this one, so that we (and possibly you) have a clearer understanding of the the "deep" though processes the AI is going through.

Thanks again.

[johndoesecond]

Hi Dave, hi Simovitch, hi all,

I’ve written before about problems with formation movements and halting, and here’s another one.

Open the attached saved game and look at the I Bn 77 Gren Regt. (that's 26th Volksgranadier Division). As you can see, it’s an ordinary or the ordinariest battalions, reasonably rested, never seen fighting, just 2-3 hours after the scenario start.

But you’ll notice that it seems something went wrong. Notwithstanding its move order, it’s stuck, apparently caught is some strange formation lockup or pathfinding scrum. You can run it for many hours and on my machine the behaviour of the battalion gets stranger and stranger (HQ and arty running moving forward while line units stay still and deployed, ...)

What do you think? Do you believe it's behaving just ok?

There does not seem to subsist the reason mentioned by Dave few message earlier (formation lockup with large 40+ units formations), as this is just a plain vanilla battalion.

Does it have something to do with the problem with the “based” units Dave talked about in another thread?

Is it related to the “cosmic halt” I described in the first message of this thread?

There has been some talk about a new patch. I just want to tell you my personal feelings and opinion on how important it would be – at least for me – to check and if necessary to fix these movements oddities.
You see, the philosophy of BftB is fundamentally grounded on the idea that “you can rely on AI to do the reasonable job” while commanding at higher echelon levels. Hence, the worse thing that can happen is that you lose that confidence not due to AI “humanly erring” (which would be OK), but due to some kind of software glitch. Of course, there is no such thing as bug-free software, but for me, too many of such issues would defeat the whole purpose of the thing.

Thank you for your attention.

Have a good new year.

[Arjuna]

Downloaded and looking into it now.

[Arjuna]

JohnDoeSecond,

I have identified the cause of the problem. It is a formation lockup and it occurs because the vanguarg ( 3.77 Coy ) has an incorrect value assigned to its nextBossIndex. This is should indicate what index along the route it's boss should be at before it can move forward. Now what I can't determine from the saved game is why it got that wrong value. This would have been calculated when the 3.77 Coy received its orders, which was at 05:31 to my best calculation. I realise that is one minute after the start of the game. Do you have a saved game from that time, preferably with the order you gave but before it was received by the 3.77 Coy?

[Arjuna]

JohnDoeSecond,

I ran through that scenario from the start, giving a Move order to 1.77 Bn HQ as per your saved game. It all went well with no lock up. I did, however, step through the code and found one spot where it might cause an error. It didn't go into this code in my run through and would only occur if the advance guard had left the bossRoute before the end of the bossRoute. Why that should happen I can't discern without a saved game. In any event I have corrected the code and will keep a watch on this.

[johndoesecond]

Hi Dave,

Thank you so much for your prompt answers. I really appreciate.

I myself will play with it some more, trying to reproduce the problem with all the relevant saved games before and after.

In the meantime, would you please be so kind also to check the "total and permanent halt situation" from the first message of this thread?

Did the changes you've just put in the code solved that problem as well?

Thanks.

[johndoesecond]

I believe I pinned it down, and it's a big one!

It's perfectly and easily reproducible everywhere.

In short: you get this kind of lockup when you move waypoints.

Here's the full story. This is how you get it:

1. pick a HQ with some subordinates;
2. give it a move order with one or more intermediate waypoints;
3. wait until the orders are processed (i.e. paths calculated);
4. move a waypoint by dragging;

... and enjoy the show!

I'm not acquainted with the internal mechanincs of the engine, but to me it looks like it triggers exactly the mess with the correct sequence of waypoints to pass through (this is how I understood that "index" and "nextBossIndex" thing you were talking about in your previous post, Dave).

In other words, at least so it seems to me, the HQ coy (together with some support units) thinks it has to go all the way to the final destination but without "stamping" intermediate waypoints as it passes through, and that makes other subordinates think they have to wait for the HQ at the first waypoint: lockup.

Indeed, there is a clear way to check if this sort of lockup is present: when you click on the HQ Coy, it should show the computed path only to the first subsequent waypoint; if you see it plotted all the way to the destination point through all the intermediate waypoints, chances are this sort of lockup has occured.

The same problem occurs if you add intermediate waypoints between two already existing ones. Also, it happens with all the other orders when intermediate waypoints are used: for example, try to set a move waypoint before the FUP of an attack order, wait the routes are traced, then drag a bit that waypoint, and see how nasty things can get, with HQ and artillery heading forward to the FUP while the line units holding still way behind.)


Is that that, Dave?

P.S.
BTW, I loaded few old saved games of mine, and the issue seems almost omnipresent: likely has to do with my style of playing.

[Arjuna]

JD2,

Thanks for the feedback and observations. I was discussing this issue with Paul last night and he too thought it might me tied up with the waypoints. I'll check out the waypoint adjustment code today.

[simovitch]

I've noticed this too, but thought it was WAD for BFTB. I used to shift waypoints all the time in COTA and HTTR which would allow me to change the course of a moving force without command delay. When this wasn't happening in BFTB I would just give them a new order, or cancel and order them to rest.

Needless to say I'm glad this is being looked at for the patch.

[johndoesecond]

Hi Simovitch,

To me the way it behaves looks just broken, rather than WAD.

And yes, indeed, the feature is potentially very useful. I way relying on it a lot, and found it particularly useful since it doesn't trigger replanning with all the related order delay (it is explicitly documented and advertised in that way in the BftB user manual).

However, once fixed, maybe such a "generous" behaviour isn't so realistic after all, and may be exploited in gamey ways: for example set the final destination to some far away point and use an intermediate waypoint (moving it always before the unit reaches it) to pilot rapidly its movement without incurring into any order delay. This would be very useful for, say, snappy gamey recon missions.

So maybe this kind of order change would require at least some (a fraction of?) order delay.

My point being is that as the things stand now, the functioning seems broken to me. But assuming it gets fixed in the next patch, and putting the whole discussion into perspective (let's say for future directions and improvements), maybe some calibration of what triggers and what doesn't trigger (what kind of possibly differentiated) order delays is something to think a bit more about.

Thank you for your attention and your always useful and informative posts.

[Arjuna]

OK I've finally fixed the issue and will put it out for beta testing next week. ( I want to address the Exit issue before I do another build. )

What I found was that whenever you adjusted a waypoint ( eg moved it ) it would force a recalc of the route. Alas this was not using the new code inside PlanMove that segments the route if there are members of the forceGroup that cannot reach a waypoint for any reason. As a consequence it was adding in all the waypoints for the bossTask route to each of the planTasks, rather than restricting it to just the segment that particular planTask was addressing. This could then cause loopbacks and all sorts of funny routes to be generated. It also resulted in screwing with bossIndexes used by the formation code. Definitely not good!

After thinking about the comments above re waypoint adjustments being too easy, I decided to force a replan now with any waypoint changes. This has the added advantage of avoiding these problems. In addition I added some smarts to the new PlanMove code so that it only segments a route where part of the force cannot reach it. Previously it was doing this for each waypoint and as a result you would get the force deploying off the road once it finished the planTask for that segement. Now it will only generate one planTask for the entire route if all units can reach all waypoints. Result is that it speeds up movement and that's a good thing.

We'll need to test this and confirm it's all go. Stay tuned.