ORIGINAL: Arjuna
phoenix,
Finally got a moment to look into this issue. Interesting. I can confirm that it is not a formation lockup. From here on it gets complicated though.
You ordered the 2Bn to use the quickest route to the bridge and you authorised it to bypass if necessary. The problem is that the vanguard, B Coy, gets to a point or starts at a point where the route will cause him to head towards a visible enemy threat in the woods NNW of its position. wAt this point the respective unit radius are very close to each other. They are within the 250m standOff range. This is new code I introduced into BFTB to prevent units from crashing into each other. So it halts. Unfortunately I had failed to include a line of code that I use in similar reaction code to force a reassessment by the unit. In other words, if you are stopped then try and do something else.
So I added this line of code. Sure enough B Coy decides to reassess. But he fails to bypass on his own initiative and calls some code to bring his boss's reassessment forward. All good. However, two subsequent issues arose. First one was that you had issued a Quickest route task parameter and this was overriding the bypass option. I don't believe that it should do so. So I have changed that now for human players.
The second issue is more profound and I am going to have to spend more time assessing how best to address it. Basically it's due to the way we manage the end time of human player tasks. This code goes back to the dark ages as far as the code base for this engine is concerned and it has a history of sorts. Originally we set the end time of a task to be whatever the start was plus the likely duration. However, we found that if this was unduly short then we ended up with a lot of processing to continually slip the end. So we decided to instead set the end of player tasks to be that of the scenario. After all there can never be more than one player task per unit. This situation will have to change when we introduce sequential tasking for the player anyway. I probably need to bite the bullet now and do so because it is having a profound effect on the bypass code for player tasks.
The reason this happens is that we use a test to see if the force is making progress and if it's not then we test to see if we should bypass. Alas the code to determine if we are making progress relies on a comparison between the "remainingDuration" and the "estimatedCompletedDuration". If the remainingDuration is greater then we're ahead of schedule. If less then we're behind. With player tasks using the scenario end they invariable end up ahead of schedule and hence don't bother to tyest for the bypass.
This will have to change. But I need to think about this some more. I hope to do so and work up a fix next week.
Just curious as to how this might be panning out...............
Thanks!
Rob.[:)]
