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

Fix actors in ReturnFire stance following targets #15567

Merged
merged 1 commit into from Nov 18, 2018

Conversation

Projects
None yet
7 participants
@reaperrr
Copy link
Contributor

reaperrr commented Aug 26, 2018

On bleed, current playtests and releases, if AutoTarget.AllowMovement is true, actors with ReturnFire stance will actually follow the acquired target, unlike in Defend stance.
This is at least unintuitive, since ReturnFire is expected to be more passive than Defend, going by their order in the UI.

Fix actors in ReturnFire stance following targets
On bleed, if AllowMovement is true actors with ReturnFire will actually follow the acquired target, unlike in Defend stance.
This is at least unintuitive, since ReturnFire is expected to be more passive than Defend.
@reaperrr

This comment has been minimized.

Copy link
Contributor

reaperrr commented Aug 26, 2018

Pinging @Smittytron and @AoAGeneral for feedback on how the community sees this.

If we can get a clear agreement that this is a bug fix and not just a matter of taste, it might still make it into the upcoming release.

Note: I know there are some other, larger flaws with the auto-targeting and stances, but they will require larger changes to adress them properly (and therefore take time).

@matjaeck

This comment has been minimized.

Copy link
Contributor

matjaeck commented Aug 27, 2018

"Fixes" #14341. I wholeheartedly support this change.

@Smittytron
Copy link
Contributor

Smittytron left a comment

Agree that this is a bug fix.

@pchote

This comment has been minimized.

Copy link
Member

pchote commented Aug 27, 2018

If we can get a clear agreement that this is a bug fix and not just a matter of taste, it might still make it into the upcoming release.

This would definitely require a new playtest, and i'm not keen on dragging out this cycle any further - if we don't have any other issues forcing a new playtest then I would rather ship a release-201809<midmonth> with what we have, and aim this for a shorter next + 1 cycle.

@GraionDilach

This comment has been minimized.

Copy link
Contributor

GraionDilach commented Aug 29, 2018

There is nothing else we could have for another playtest cycle. Starting another playtest cycle would just lead to stalling reviewing on features again in favor of a potential playtest - and will draw away contributor interest since it would just prove that there is no actual real development aside for all those wasted hours into a faulty but heavily advertised feature.

@pchote

This comment has been minimized.

Copy link
Member

pchote commented Aug 29, 2018

Please don't drag your grudge against the player badges here too. I am not a slave to OpenRA, and have no obligation "volunteer" my free time doing things that I don't want to do - time spent not doing badges would not have been equally spent on reviewing PRs.

@matjaeck

This comment has been minimized.

Copy link
Contributor

matjaeck commented Sep 2, 2018

Stance changes have disruptive character, need to be communicated properly and need to allow players to think about, test, and comment them. This fix is not as disruptive as #15566 is but both would fit nicely together and IMO it is a good idea to handle both simultaneously.

@reaperrr

This comment has been minimized.

Copy link
Contributor

reaperrr commented Oct 14, 2018

This fix is not as disruptive as #15566 is but both would fit nicely together and IMO it is a good idea to handle both simultaneously.

Ideally yes, I understand that, but I'm too occupied with other things of higher priority to me (not just OpenRA-related) for the forseeable future to tackle the rest of #15566 anytime soon, so if adressing both at the same time is considered a must, this will likely not make it into any release for the next 9-12 months.

@AoAGeneral

This comment has been minimized.

Copy link
Contributor

AoAGeneral commented Oct 16, 2018

The returnfire with units chasing seems fine to me as this shouldn't be a problem with long range artillery or MRLS. I am unsure how this affects with structures. (If they are even able to have a return fire logic on it and if they do would they get stuck trying to target that unit only and ignore everything else unless stopped?)

@matjaeck

This comment has been minimized.

Copy link
Contributor

matjaeck commented Oct 17, 2018

Chasing in return fire stance is also not a problem for harvesters getting stuck and it doesn't imbablance navy gameplay while the player can still select his favorite color. Seems fine to me.

Seriously, return fire is the more aggressive hold position but nothing more. It doesn't matter if it "works" for mrls and artillery because if you put them in return fire stance, you do it wrong. MRLS/artillery are related to #14816 but I object the assumption that return fire with chasing would be fine because it didn't affect a unit negatively you never would put in return fire stance.

Return fire would make sense for stanks for example. Return fire made sense for re-capturing enemy oil derricks (in RA) before the rework of the attack logic. Maybe it makes sense for units in D2k or in the missions. However, I can not imagine of a situation in that you would want your unit in return fire stance to track down the target automatically (and I'm ignoring here that it will die instantly because this is another issue, see #14816).

If you want a highly aggressive stance that makes units chase enemies, use attack anything.

@obrakmann
Copy link
Contributor

obrakmann left a comment

👍

@obrakmann obrakmann merged commit 7d695f0 into OpenRA:bleed Nov 18, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@obrakmann

This comment has been minimized.

Copy link
Contributor

obrakmann commented Nov 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment