I am not sure if it is a bug or a feature, but I find it a bit strange that infantry cancels their order once they dodge a vehicle.
Example:
Grenadier rush, you focus on ref. Enemy harvester tries to crush them. Grenadiers walk to the side and start aiming at the harvester instead of continuing the attack on the ref. I observed that now in a couple of RAGL matches :/
Attack building with inf, enemy harvesters tries to crush your inf. Your inf dodge and stops attacking the building, but whatever is around.
Infantry should keep the focus on whatever they were trying to do before.
Good Impact:
Bad Impact:
Bad Impact:
- Rockets in blob vs blob attack: Instead of aiming at Tanks, they might continue to fight the Rifles in the distance. Not sure if that is so great. Currently they would focus on the close tank instead.
It doesn't seem like bad impact. It's usually up to the player to retarget or force a retarget with a stop command. I don't see why needs to be different
Comment by Orb in Kautions stream:
Orb370: Units have autotargetting on attack-move and when idling
Orb370: That should stay the same
Orb370: You can also give specific attack order
Orb370: Which are erased when units dodge
Orb370: That should be changed
Related: #5968
IIRC this is caused by pathfinding nudging logic.
I'm not sure how we could simply and safely implement this without completely changing how crushing works (i.e. removing the dodging completely).
Did you have any specific thoughts on how to do this on a Next Release timescale @reaperrr?
Not really, I guess we can delay this to Next+1 if there's no easy/quick fix.
The issue happens because Mobile.Nudge uses self.QueueActivity(false, MoveTo(cell.Value, 0));, which cancels the activity queue.
My first thought for fixing this would be to instead do something like:
public void Nudge(Actor nudger)
{
if (IsTraitDisabled || IsTraitPaused || IsImmovable)
return;
var nudgeActivity = self.CurrentActivity as IActivityNotifyBlockingMove;
if (nudgeActivity != null)
nudgeActivity.OnNotifyBlockingMove(self, nudger);
else if (self.IsIdle)
{
var cell = GetAdjacentCell(nudger.Location);
if (cell != null)
self.QueueActivity(MoveTo(cell.Value, 0));
}
}
and then implement IActivityNotifyBlockingMove on activities where it makes sense (e.g. AttackMove, FindAndDeliverResources, the attack activities) to queue a child move activity. If the activity can't respond to nudging it is probably better to ignore the request (and then probably die) than to cancel the activity queue.
Note that we already have Mobile.IsBlocked for cases like this. The nudging logic could also use some refactoring in general. I might take a look at fixing this.
then implement IActivityNotifyBlockingMove on activities where it makes sense
Would be beneficial for Enter (including the capture usecase) and Demolish too.
I dont think this is a bug, and to my knowledge there is not any rts game that allows units to avoid getting crashed and then continue their given order, usually they get crushed or move away via player input. And to be honest by removing this, you also remove the Command And Conquer spirit with it in my opinion (too automated)
I dont think this is a bug, and to my knowledge there is not any rts game that allows units to avoid getting crashed and then continue their given order, usually they get crushed or move away via player input. And to be honest by removing this, you also remove the Command And Conquer spirit with it in my opinion (too automated)
Obviously trolling. 2/10
In case not: IMO it is a bug because i only see the following reasonable alternatives:
So if you were asking to remove the auto-dodging completely I'd probably support that, but don't see any value in not fixing the IMO undesired side-effects of the current behavior.
Order canceling after dodging is consistent with aircaft canceling their orders on auto-rtb. Both are actions made independant of players will
So I don't have any fundamental opposition to either of the ways it can work
Order canceling after dodging is consistent with aircaft canceling their orders on auto-rtb. Both are actions made independant of players will
These are two different cases: RTB is an activity that is triggered when the aircraft is out of ammo and the specific deliberately chosen behavior is nothing anyone desires but a result of an unsolved conflict in design ideas, that auto-RTB should be part of the game, which circling yaks are the main offender for. Such a conflict does not exist in this issue and there is no reason to make one up. The queue cancellation here leads to units becoming idle, resulting in target-loss and #5968. These are clear bugs, while deliberately configuring aircraft to auto-RTB when out of ammo is not.
@matjaeck
Obviously trolling. 2/10
Obviously you try rediculate my opinion, without having an argument to even backup your claim.
The question is why you try to offend me though?
Any way, having units being automated like that is simply not within the command and conquer game mechanics we have seen so far, that includes all C&C titles. Player units either continue with their given orders and get crushed or move away via player input and break their original order.
And the fact that in OpenRa player units automatically avoid getting crushed some times, like in the case of grenadiers mentioned, that by it self is against the known C&C unit behavior, to start with.
This is a :-1: from me for the reasons I mention.
My 2 cents:
I think we do need to properly support nudging without canceling current activity queue for other things than infantry dodging (movement through narrow passages and such), but it would be more true to the original if only infantry that is AI-controlled and either a) idle, or b) attacking (but not moving) was allowed to dodge.
And rather than making it chance-based, like in the originals for AIs that have it activated it should depend on _how far the infantry managed to move away before the crusher entered the cell_. Chance-based dodging is... just dodgy and annoying, in my opinion.
I think we do need to properly support nudging without canceling current activity queue for other things than infantry dodging (movement through narrow passages and such)
This use-case is already supported as per #16408, but only for the Move activity. My idea was to just expand on this in other relevant activities as pchote suggested, but using similar methods to those already employed there.
And rather than making it chance-based, like in the originals for AIs that have it activated it should depend on how far the infantry managed to move away before the crusher entered the cell
AFAIK crushing has no chance attached to it, dodging has. If a unit is idle it has a dodge chance, but if it starts moving chances are no longer at play. So units can get crushed even if they rolled a dodge chance
Moving to a hitshape based crushing check would be a good move, independently of anything happening here. If we did one day remove the default dodge chance we will want to keep the plumbing so that the harder AI bots can use it.
And the fact that in OpenRa player units automatically avoid getting crushed some times, like in the case of grenadiers mentioned, that by it self is against the known C&C unit behavior, to start with.
@KOYK well yeah, just like I said in my previous comment, I'd support changing this. I'm not sure why you only notice now that the key OpenRA mechanics have nothing to with the old originals and find it extremely suspicious that the "not true to the original" card is played in this context and consider it quite bizarre, since the for this context way more relevant question "Do we want auto-dodging at all in the RA mod?" is not even asked... I actually find the trolling attempts and mental acrobatics (especially when reading against older comments of the same people) here quite entertaining, whatever decision is made is meaningless to me so go on, I enjoy it :)
And the fact that in OpenRa player units automatically avoid getting crushed some times, like in the case of grenadiers mentioned, that by it self is against the known C&C unit behavior, to start with.
@KOYK well yeah, just like I said in my previous comment, I'd support changing this. I'm not sure why you only notice now that the key OpenRA mechanics have nothing to with the old originals and find it extremely suspicious that the "not true to the original" card is played in this context and consider it quite bizarre, since the for this context way more relevant question "_Do we want auto-dodging at all in the RA mod?_" is not even asked... I actually find the trolling attempts and mental acrobatics (especially when reading against older comments of the same people) here quite entertaining, whatever decision is made is meaningless to me so go on, I enjoy it :)
You make no sense, I wonder who trolls who in here.
Also the "not true to the original" card will be played all time by me since I like the original, so no idea whats your suspicious point there. Stop making a fool of your self, its so bad that I actually feel sorry for you.