Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Retreat at medium damage" causes units attached to commander to freeze in place. #2634

Closed
will-ca opened this issue Mar 15, 2022 · 9 comments
Labels
Bug Outdated Old issues that may not be relevant for current releases. Marked issues are queued to be closed. type: micro-AI

Comments

@will-ca
Copy link

will-ca commented Mar 15, 2022

Describe the bug
Once damaged, units set to retreat that have been attached to a commander will often become unable to perform either automated or manual orders. They will stay in place, continuing to fire at the enemy while also ignoring explicit orders to move.

To Reproduce
Steps to reproduce the behavior:

  1. Set a direct fire commander group to "Retreat at medium damage".
  2. Get in a losing firefight.
  3. Wait for a unit to take enough damage to retreat. It may then start to retreat. It is normal if it does.
  4. Order the commander group to move forwards again, or to attack a target. If there was a retreating unit, it will now stop its retreat, and move to attack a target. It will not retreat again, no matter how much damage it takes.
  5. Wait for multiple units to have taken heavy damage.
  6. Order the commander group to move back. The damaged units will stay in place until they die. This behaviour is unexpected, and makes the commander group basically unusable.

Expected behavior
Units that have taken enough damage to trigger a retreat should not return until they are fully repaired.
Units should never ignore an explicit order to move out of enemy fire.
I am aware that these two behaviours may be contradictory in some cases.

Your System:
Version: 4.2.7

Additional context
The "Return for repair" order can sometimes (but not necessarily always) be used to dislodge frozen units.

Reported in 2009:
https://forums.wz2100.net/viewtopic.php?t=4089

@gantsevdenis
Copy link
Contributor

@highlander1599 what do you think of this?

Should "move" order be ignored by those units who are returning to repair, when attached to commander? I don't remember if current behavior is a bug, or a feature.

@simply-peachy
Copy link

It used to be that a vehicle retreating for repair would ignore all orders unless it was detached from the commander. This is beneficial because damaged vehicles will remove themselves from a battle whilst the rest of the unit can remain in combat.

@highlander1599
Copy link
Contributor

highlander1599 commented Aug 9, 2022

@highlander1599 what do you think of this?

Should "move" order be ignored by those units who are returning to repair, when attached to commander? I don't remember if current behavior is a bug, or a feature.

@gantsevdenis Were you able to reproduce the issue? In my Insane playthroughs, I have my units mostly set to retreat at medium damage and also mostly stay in motion in a fight. All damaged units are moving back to the repair facilities and move only back to my commander after they got fully repaired no matter how many move or attack orders I gave the commander meanwhile.
I would have to try to reproduce it following step by step but I never faced this issue in my playthroughs.

@gantsevdenis
Copy link
Contributor

@highlander1599 yes, very easily reproducible on 4.2.7.
I am kinda surprised, because, I have added an explicit check exactly to filter out "units moving to repair", and it doesn't seem to work (anymore? maybe it was was functioning before).

Anyway, yes, please try to reproduce it to see yourself, it's very straightforward:

2022-08-09.19-19-05.mp4

@highlander1599
Copy link
Contributor

@gantsevdenis Strange. I don't have the time to check it today, maybe tomorrow evening.

@highlander1599
Copy link
Contributor

@gantsevdenis Sorry Denis, I will not have the time to check it before my 2-week vacation starting this Sunday.
The wanted behavior is that units will go to repair and move back to the commander only after they got fully repaired, no matter what move/attack orders the commander gets meanwhile. Feel free to try a fix or wait until I'm back at the end of August.

@Lexus-3141
Copy link

I've got the similer bug. But with only artillary units.
When I try to attach them to commander (the indirect fire support is enabled) units freezed in place. They got *symbol, but without commander number next to it. Looks like they don't attach completely. You may check it in the saved game.
QuickSave.zip

@gantsevdenis
Copy link
Contributor

I've got the similer bug. But with only artillary units. When I try to attach them to commander (the indirect fire support is enabled) units freezed in place. They got *symbol, but without commander number next to it. Looks like they don't attach completely. You may check it in the saved game. QuickSave.zip

This has nothing to do with the issue mentionned above, what you are telling is completely normal; artillery doesn't ever get attached to Commander, it can only be in FIRESUPPORT mode, which is completely unrelated. They freeze because they aren't far enough from the Commander. So unless you add more information, everything you said is completely normal

@Lexus-3141
Copy link

Lexus-3141 commented Dec 22, 2022

No. Previously and in the next mission I got other behavior definitely.

Normally after attaching artillary units and commander move all together.
In the case I described units stayed frozen, but commander can move to clicked point. Indifferently to distance between them.

@KJeff01 KJeff01 added the Outdated Old issues that may not be relevant for current releases. Marked issues are queued to be closed. label Apr 13, 2024
@KJeff01 KJeff01 closed this as completed Apr 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Outdated Old issues that may not be relevant for current releases. Marked issues are queued to be closed. type: micro-AI
Projects
None yet
Development

No branches or pull requests

6 participants