Move activity now uses ChildActivity #13749

forcecore · 2017-07-29T06:01:59Z

Removing THE obstacle for waypoint visualization PR #13336.

In line 245, the tick runs the child activity before returning. I commented why. However, what I didn't write there is that it changes the behavior when the move order has first ticked to that part. It used to return MoveFirstHalf and not tick it.

I also tried to make Move activity more understandable but, I failed because I couldn't understand Move.cs. I am not even 50% sure what MoveFirstHalf and MoveSecondHalf are. No comments and not self-explanatory :( I'll just make minimal changes.

pchote · 2017-07-29T07:13:48Z

OpenRA.Mods.Common/Activities/Move/Move.cs

+			// will not end up in an odd place.
+			if (ChildActivity != null)
+			{
+				ActivityUtils.RunActivity(self, ChildActivity);


Shouldn't this be assigning the returned activity back to ChildActivity?

I thought so, but in Transform.cs, they do this too.

I looked into RunActivity and ChildActivity getting set implicitly but when I look at it now it is completely different. What did I see yesterday xD I must had been looking into something else.

Seems to be OuterTick that is doing this child activity management.

https://github.com/OpenRA/OpenRA/blob/bleed/OpenRA.Game/Activities/Activity.cs#L180
I think it is wrong to do implicit management here

I strongly think it wrong because that would prevent an activity from running multiple children activities properly. They do run, as you might see in my simultaneous reload + resupply code but ChildActivity pointer is invalid.

https://github.com/OpenRA/OpenRA/pull/13733/files/a16b9b52c295ea5c24ed2bba71a159275bd260cc#diff-268b61855646bbc4ed78d90265240289R43

Shouldn't this be assigning the returned activity back to ChildActivity?

You can, but it's not necessary. As forcecore found out, OuterTick automatically makes sure that the parent's ChildActivity pointer gets updated.

I think it is wrong to do implicit management here

It has to be done there, as there is no other place where that could happen for a CompositeActivity. Your example shouldn't matter at all, as neither ChildActivity nor Tick's return value are used there. In fact, those resupplyActivities aren't even a part of the graph, and their Parent should be null. But let's discuss that in the other PR.

pchote · 2017-07-29T07:14:19Z

OpenRA.Mods.Common/Activities/Move/Move.cs

+			if (path != null)
+				path.Clear();
+
+			if (keepQueue == false && NextActivity != null)


if (!keepQueue && NextActivity != null)

pchote · 2017-07-29T07:14:54Z

OpenRA.Mods.Common/Activities/Move/Move.cs

+			// While carrying out one Move order, MoveSecondHalf finishes its work from time to time and returns null.
+			// That causes the ChildActivity to be null and makes us return to this part of this function.
+			// If we only queue the activity and not run it, units will pause for one tick!
+			ActivityUtils.RunActivity(self, ChildActivity);


Likewise here?

pchote · 2017-07-29T14:53:30Z

I am not even 50% sure what MoveFirstHalf and MoveSecondHalf are. No comments and not self-explanatory :( I'll just make minimal changes.

MoveFirstHalf moves the actor from its start point (either its starting subcell or the edge of a cell for chained moves) to the edge of the next cell. MoveSecondHalf moves the actor from the edge of the cell back to a defined subcell.

obrakmann · 2017-07-29T21:15:53Z

MoveFirstHalf moves the actor from its start point (either its starting subcell or the edge of a cell for chained moves) to the edge of the next cell. MoveSecondHalf moves the actor from the edge of the cell back to a defined subcell.

Suggestion: rename them MoveOutOfCell and MoveIntoCell, respectively, to make their purpose clearer?

forcecore · 2017-07-29T21:46:26Z

Suggestion: rename them MoveOutOfCell and MoveIntoCell, respectively, to make their purpose clearer?

I also tried to modify moveFraction to moveStep, TotalMoveFraction to TotalMoveSteps, as they have nothing to do with division. Then I changed my mind. I want to induce fewer changes so that the correctness is easier to be seen. I think it would be better to make rename PR right after this one.

obrakmann

Looks good so far, just one minor nit. Turning on the StrictActivityChecking setting doesn't crash in Move anymore, so that's a good. I'd like to do some more in-game testing, though.

obrakmann · 2017-07-29T21:30:10Z

OpenRA.Mods.Common/Activities/Move/Move.cs

+				path.Clear();
+
+			if (keepQueue == false && NextActivity != null)
+				NextActivity.Cancel(self, keepQueue);


Use NextInQueue here, not NextActivity. You don't want to match against the parent. You can also just set it to null, it's unnecessary to cancel it.

forcecore · 2017-07-30T01:29:24Z

Minor code correction reflecting comments above.

pchote · 2017-08-17T17:53:05Z

My understanding is that @obrakmann has made some progress here, but is currently stalled on an unknown but possibly unrelated crash issue:

From 2017-08-13 (#1, #2):

[16:13:50] <pchote> antares79: any new thoughts on #13749?
[16:14:34] <antares79> I think it's good. I'm gonna play two or three more games on it, but it looks good

[20:47:11] <antares79> I've been playtesting #13749 all evening and I get a SEGV on at least d2k after about 15min into the game
[20:47:29] <antares79> haven't yet been able to reproduce it on bleed or in other mods, but I'm still trying

pchote · 2017-08-17T18:10:32Z

OpenRA.Mods.Common/Activities/Move/Move.cs

+			// While carrying out one Move order, MoveSecondHalf finishes its work from time to time and returns null.
+			// That causes the ChildActivity to be null and makes us return to this part of this function.
+			// If we only queue the activity and not run it, units will pause for one tick!
+			ChildActivity = ActivityUtils.RunActivity(self, ChildActivity);


I'm seeing a lot of pauses/stalls when units move, so I don't think this is sufficient to fix whatever the real problem is?

Repro case: build a ranger in RA and order it to move across the map. Works fine on bleed, unit pauses for a tick every few cells on this PR rebased against bleed.

The problem might be with

https://github.com/forcecore/OpenRA/blob/ab536f5452da590ace46797e4bf22dd7753cc6df/OpenRA.Mods.Common/Activities/Move/Move.cs#L216-L218

If the path becomes invalid then it will stop and wait for the next tick before attempting to repath.

It actually turns out that it is related to Turn child activity.

forcecore · 2017-08-18T03:29:09Z

Rebased to take advantage of any other Mobile related fixes. Fixed "turn pause".

pchote

I have not tested this extensively (but someone else should!) but the code changes look sensible, and the basics (moving, turning, cancelling while moving or turning) all seem to work as expected.

Can you please squash your fixups in the the appropriate parent commits?

forcecore · 2017-08-19T13:24:05Z

Squashed

Mailaender · 2017-08-27T11:47:17Z

I played a small test game. No crashes. It seemed at one point a stop command was ignored and the unit was accepting orders only until it moved to its destination. I don't think I can reproduce and I am not sure if that is related. It happened only once with a large group and narrow corridors so units took a detour. Looks good I guess. ✅

forcecore · 2017-08-27T15:27:06Z

I see your bug: force fire on the ground to a place far away so that the unit will move. Then the stop order will be ignored.

forcecore · 2017-08-27T15:41:29Z

In MoveAdjacentTo (or any other activities that may use Move as its inner/Child activity), when Cancel() is called on Move, it will not think it is canceled as Move.cancel returns false. Is it possible to mark Move as "due to be canceled"?

obrakmann · 2017-09-10T15:41:28Z

[20:47:11] < antares79> I've been playtesting #13749 all evening and I get a SEGV on at least d2k after about 15min into the game
[20:47:29] < antares79> haven't yet been able to reproduce it on bleed or in other mods, but I'm still trying

Sorry for the delay. The crash I encountered is also happening on bleed, just took a bit longer to appear there (~1h).

obrakmann · 2017-09-10T15:43:59Z

Is it possible to mark Move as "due to be canceled"?

Not currently, but I've come to realize that we need something like this. Really it's just required for Move, but since any activity can have Move as a child, it's probably best to bake support for that into the Activity class.

pchote · 2017-09-10T15:47:06Z

The original goal was for the return value to be that check, and in cases like this Move (or docking, or whatever else) could return true to indicate that they are cancelling, even if they won't be canceled for another few ticks. This detail may not longer hold true in all cases, and would need some testing.

pchote · 2017-10-14T14:25:48Z

Any progress here @forcecore?

pchote · 2017-10-14T14:58:13Z

The best solution for now may simply be to lie: unconditionally return true; in Move.Cancel, with a comment explaining why. I suspect that the rest of the code will then just work in the way that we want.

pchote

I have pushed over your branch to rebase and fix the activity cancellation as mentioned above.

I did some (admittedly limited) testing, and it now seems to behave as desired so 👍

reaperrr · 2017-11-12T18:49:37Z

https://github.com/OpenRA/OpenRA/wiki/Changelog-(bleed)/_compare/aa6dd6f751c2606e17b5e1fd06f02dcaf6a70199...2377c394b41f820f2b851be5cd4bb18aa4bb24e1

forcecore force-pushed the MoveParChild branch 2 times, most recently from 6b8117c to c771c3f Compare July 29, 2017 06:31

pchote reviewed Jul 29, 2017

View reviewed changes

pchote requested a review from obrakmann July 29, 2017 07:16

obrakmann reviewed Jul 29, 2017

View reviewed changes

obrakmann mentioned this pull request Aug 6, 2017

Guard/Follow waits too often for repathing #13784

Closed

pchote reviewed Aug 17, 2017

View reviewed changes

forcecore force-pushed the MoveParChild branch from ab536f5 to ac99ca1 Compare August 18, 2017 03:19

forcecore force-pushed the MoveParChild branch 2 times, most recently from 704bd8b to 521f65d Compare August 18, 2017 03:45

pchote previously approved these changes Aug 19, 2017

View reviewed changes

pchote added the PR: Fixup requested label Aug 19, 2017

forcecore force-pushed the MoveParChild branch from 521f65d to d9074a2 Compare August 19, 2017 13:23

pchote added PR: Needs +2 and removed PR: Fixup requested labels Aug 19, 2017

forcecore mentioned this pull request Sep 7, 2017

Magnetron - enemy resists forcecore/yupgi_alert0#267

Open

reaperrr added the PR: Is Dependency label Sep 15, 2017

pchote added the PR: Changes requested label Oct 16, 2017

Move activity implementation now uses ChildActivity

bf9946b

pchote dismissed their stale review via bf9946b October 21, 2017 17:08

pchote force-pushed the MoveParChild branch from d9074a2 to bf9946b Compare October 21, 2017 17:08

pchote approved these changes Oct 21, 2017

View reviewed changes

pchote removed the PR: Changes requested label Oct 21, 2017

reaperrr merged commit d49c98c into OpenRA:bleed Nov 12, 2017

forcecore deleted the MoveParChild branch January 5, 2018 08:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Move activity now uses ChildActivity #13749

Move activity now uses ChildActivity #13749

forcecore commented Jul 29, 2017 •

edited

Loading

pchote Jul 29, 2017

forcecore Jul 29, 2017 •

edited

Loading

forcecore Jul 29, 2017 •

edited

Loading

forcecore Jul 29, 2017

forcecore Jul 29, 2017

obrakmann Jul 29, 2017 •

edited

Loading

pchote Jul 29, 2017

pchote Jul 29, 2017

pchote commented Jul 29, 2017

obrakmann commented Jul 29, 2017

forcecore commented Jul 29, 2017 •

edited

Loading

obrakmann left a comment

obrakmann Jul 29, 2017

forcecore commented Jul 30, 2017

pchote commented Aug 17, 2017 •

edited

Loading

pchote Aug 17, 2017 •

edited

Loading

pchote Aug 17, 2017 •

edited

Loading

forcecore Aug 18, 2017

forcecore commented Aug 18, 2017

pchote left a comment

forcecore commented Aug 19, 2017

Mailaender commented Aug 27, 2017 •

edited

Loading

forcecore commented Aug 27, 2017

forcecore commented Aug 27, 2017

obrakmann commented Sep 10, 2017 •

edited by abcdefg30

Loading

obrakmann commented Sep 10, 2017

pchote commented Sep 10, 2017

pchote commented Oct 14, 2017

pchote commented Oct 14, 2017 •

edited

Loading

pchote left a comment

reaperrr commented Nov 12, 2017

Move activity now uses ChildActivity #13749

Move activity now uses ChildActivity #13749

Conversation

forcecore commented Jul 29, 2017 • edited Loading

pchote Jul 29, 2017

Choose a reason for hiding this comment

forcecore Jul 29, 2017 • edited Loading

Choose a reason for hiding this comment

forcecore Jul 29, 2017 • edited Loading

Choose a reason for hiding this comment

forcecore Jul 29, 2017

Choose a reason for hiding this comment

forcecore Jul 29, 2017

Choose a reason for hiding this comment

obrakmann Jul 29, 2017 • edited Loading

Choose a reason for hiding this comment

pchote Jul 29, 2017

Choose a reason for hiding this comment

pchote Jul 29, 2017

Choose a reason for hiding this comment

pchote commented Jul 29, 2017

obrakmann commented Jul 29, 2017

forcecore commented Jul 29, 2017 • edited Loading

obrakmann left a comment

Choose a reason for hiding this comment

obrakmann Jul 29, 2017

Choose a reason for hiding this comment

forcecore commented Jul 30, 2017

pchote commented Aug 17, 2017 • edited Loading

pchote Aug 17, 2017 • edited Loading

Choose a reason for hiding this comment

pchote Aug 17, 2017 • edited Loading

Choose a reason for hiding this comment

forcecore Aug 18, 2017

Choose a reason for hiding this comment

forcecore commented Aug 18, 2017

pchote left a comment

Choose a reason for hiding this comment

forcecore commented Aug 19, 2017

Mailaender commented Aug 27, 2017 • edited Loading

forcecore commented Aug 27, 2017

forcecore commented Aug 27, 2017

obrakmann commented Sep 10, 2017 • edited by abcdefg30 Loading

obrakmann commented Sep 10, 2017

pchote commented Sep 10, 2017

pchote commented Oct 14, 2017

pchote commented Oct 14, 2017 • edited Loading

pchote left a comment

Choose a reason for hiding this comment

reaperrr commented Nov 12, 2017

forcecore commented Jul 29, 2017 •

edited

Loading

forcecore Jul 29, 2017 •

edited

Loading

forcecore Jul 29, 2017 •

edited

Loading

obrakmann Jul 29, 2017 •

edited

Loading

forcecore commented Jul 29, 2017 •

edited

Loading

pchote commented Aug 17, 2017 •

edited

Loading

pchote Aug 17, 2017 •

edited

Loading

pchote Aug 17, 2017 •

edited

Loading

Mailaender commented Aug 27, 2017 •

edited

Loading

obrakmann commented Sep 10, 2017 •

edited by abcdefg30

Loading

pchote commented Oct 14, 2017 •

edited

Loading