FIXED 5.1.20 - Unable to move short distances

[Daz]

Hi Guys, I'm back.

Since 5.0.14 I have been unable to use the move order to reposition dug in units.

It has always been the case that once a unit has settled into its defensive position, a defend order was not effective in order to move that unit short distances in order to reposition it.
To get around this problem it was possible to reposition them with a move order instead.

Since patch 5.0.14 however, it is no longer possible to reposition units using this workaround.
The move order has the same effect as a defend order, where the unit will refuse to move if it thinks its in a better position than the one you have ordered it to move to.

This behaviour is very undesirable for me as I often want a unit that has been deployed by the Bn HQ under AI control to be repositioned, sometimes only a hundred meters from its current position, due to better cover or lines of fire.

Its not a bug per se, but it is a very serious problem in my opinion.

 

[Daz]

Any luck with sorting this problem out Dave?
I can do some more reserach on it and provide some saves if you need them?

 

[Dave 'Arjuna' O'Connor]

Saves wouyld be good. Thanks Daz.

 

[Kurt]

Hi Guys, I'm back.

Since 5.0.14 I have been unable to use the move order to reposition dug in units.

It has always been the case that once a unit has settled into its defensive position, a defend order was not effective in order to move that unit short distances in order to reposition it.
To get around this problem it was possible to reposition them with a move order instead.

Since patch 5.0.14 however, it is no longer possible to reposition units using this workaround.
The move order has the same effect as a defend order, where the unit will refuse to move if it thinks its in a better position than the one you have ordered it to move to.

This behaviour is very undesirable for me as I often want a unit that has been deployed by the Bn HQ under AI control to be repositioned, sometimes only a hundred meters from its current position, due to better cover or lines of fire.

Its not a bug per se, but it is a very serious problem in my opinion.

I agree strongly

 

[Daz]

I have just done a quick test to produce two saves for you.
The first is GnS D3 0645 ShortMoveTest.cog then another an hour later,
GnS D3 0745 ShortMoveTest.cog.

This is very easy to reproduce.
In this example some of the units were give short moves, others short defend orders.
One in the north is attacking as its a save from an on going game.
At least it was on going until I stumbled across a CTD bug, that wont let me progress any further until the next patch is released.

Out of the 7 orders given only 2 complied.

 

[Dave 'Arjuna' O'Connor]

Got 'em thanks. I'll look into this tomorrow but I won't hold up the current build for it.

 

[Daz]

I have also been noticing lately that when giving orders to formations, including attack orders, they quite often pull up short by up to 500m of the position that the task is set for.

For example giving a Bn a defend order in line formation, two of the units will move into the correct position but the third never finishes the order completely and stops short of the Task marker that the AI has set for it, leaving it out of position in the line.
I think this behaviour is also related to the problem above.

 

[Daz]

This is a screenshot to show what I mean by the formations not completing their orders fully.

The three Bn sized formations have been given defend in line formations and have been in location for quite a while.

The bottom formation and the top formation both have units that have pulled up short of their, (assigned by the AI) task markers and have no intention of completing the short moves.

 

[Dave 'Arjuna' O'Connor]

I believe you will find that the units have opted for a slightly alternate position suing the AI code GetSafestNearbyLoc() which looks around near the assigned obj loc and determines which of all of these is the best one for it to deploy to based on a set of criteria. So as such it's WAD. In RL local commanders adjust their positions based on what they can see once their at the location. There may be slight undulations in the terrain which make it better or worse etc.

 

[Daz]

Thanks for the reply Dave, I very much appreciate the time you put into this game and your excellent continuing support.

This is an image with the LOS Tool overlaid.
Could there be another reason that they are not completing the order maybe?
The way they have deployed on top of one another leaves them very vulnerable to enemy artillery in very open terrain.

 

[Daz]

Here is another image of the same formation moved forward a kilometre, but with a much larger frontage. (see task edit box upper left for order given)

 

[Velkan]

Got 'em thanks. I'll look into this tomorrow but I won't hold up the current build for it.

I've had the same problem, good to know it will be fixed in the future.

 

[Daz]

Could you give some priority to this issue when your back on your feet please Dave?

Its a bit of a game breaker for me, even more so than the supply, as this issue effects every scenario, where as the supply issues only effect the bigger longer ones.
Thanks mate.

As an example to what I mean:
I had pickets out in one of the scenarios in order to give me advance warning of an enemy approach as I wasn't sure what direction they were going to come from.

The base had been deployed on the wrong side of town by the AI out in the open, but I had more than enough warning in order to move it out of harms way, so I gave it a move order of about 500m to an area deep inside the town which I thought was far enough away for them to not get stuck, but sure enough they never budged an inch and subsequently took many casualties.

This wasn't the base freezing bug as reported in another thread, it was the bug from this thread.

Those poor bases have really got it tough in this game at the moment

 

[Dave 'Arjuna' O'Connor]

Daz,

I'm back on deck this week. I'm giving priority to the manual - should finish this by Wednesday. I will then check out this issue.

 

[Daz]

Thanks Dave.
If I can help in any way with more saves or testing of the issue let me know.

 

[Dave 'Arjuna' O'Connor]

After much stepping through the code I believe the issue arises because the ObjectiveAchieved() checks to see if it is at the objective (it's not). Then it checks to see if its within the objective radius (it is). So it checks to see if the formation typed is inSitu or retakePosition is unchecked - ie false - (it is false). So it returns true - is it has achieved the objective. Now the reason why we allow it to return true if it's within the radius is so we can handle cases where the user does not want the force to retake the position.

The problem is the fact that we have created the defend task within a Move mission and copied the thresholds. The default retakePosition value is true, but when I added the user option to specify the default retakePosition value I in effect reversed the default to false. I have changed that now. I have also ensured that it uses the user option when it creates a defend task within the Move plan. That should cover all bases I believe. I will test and report back.

 

[Dave 'Arjuna' O'Connor]

Seems to work now. Check out B.25 moving to its relatively nearby objective.

 

[Dave 'Arjuna' O'Connor]

I ran it a bit further till all three companies had reached their assigned objectives. Looks good now. FIXED

 

[Greg]

Sounds good to me...even though I didn't understand a word of it...

 

[Dave 'Arjuna' O'Connor]

Just a note that if you order someone to defend near where they are (ie within the task perimeter, which defaults to 500m) and you uncheck the retakePosition option then the unit will not move to the assigned location. Rather it will defend in its current location. That is the behaviour currently being coded. If you really want them to move, then check the retake position and wait till they get to the desired location, then uncheck it.