Fixed issue with unit ready when capturing #14220

NethIafin · 2017-10-19T19:33:30Z

Fixes #14219 and #13983 , hopefully without breaking anything else

Issue was with Actor.ChangeOwner being always scheduled last (since it was using World.AddFrameEndTask inside World.AddFrameEndTask) Modified the code so it now accepts current frame as an optional parameter and moved the actual transition of ownership to the bottom of the code.

Now... I don't know if this is the best solution, but it feels that way. Maybe we can move more actions inside of an Actor to proper "chain" from World.AddFrameEndTask. Maybe all this is a bogus idea, and should be denied

Either way - this fixes the issue, and initial tests shown that everything else works

abcdefg30 · 2017-10-19T20:43:04Z

OpenRA.Game/Actor.cs

@@ -279,30 +279,38 @@ public void Dispose()
 			});
 		}

-		// TODO: move elsewhere.
-		public void ChangeOwner(Player newOwner)
+		private void ChangeOwnerInternal(Player newOwner, World world)


Explicit private should be removed.

abcdefg30 · 2017-10-19T20:44:15Z

OpenRA.Game/Actor.cs

+		public void ChangeOwner(Player newOwner, World externalWorld = null)
+		{
+			if (externalWorld == null)
+				World.AddFrameEndTask(w =>


You should add braces to the if here as the body spans over multiple lines, imho.

abcdefg30 · 2017-10-19T23:11:15Z

OpenRA.Game/Actor.cs

@@ -280,29 +280,34 @@ public void Dispose()
 		}

 		// TODO: move elsewhere.
-		public void ChangeOwner(Player newOwner)
+		public void ChangeOwner(Player newOwner, World externalWorld = null)


This change/parameter doesn't seem to be used anymore.

netnazgul · 2017-10-20T05:57:29Z

So, now captured player will be punished twice - losing his building and producing a unit for enemy?

Also, what if player has multiple production buildings of that type and switches priority before the unit is finished?

Overall I'd suggest just destroying unit whatsoever instead of transferring ownership.

NethIafin · 2017-10-20T07:22:05Z

@netnazgul it does not give unit to the player. If that was your last Barr or WF you lose the unit and unit queue, but refund your money. If this is not your only production building of this type, most likely you already produced it from another building

netnazgul · 2017-10-20T07:55:14Z

Totally fine then

NethIafin · 2017-12-26T20:48:00Z

can someone review this? @pchote @penev92 @MustaphaTR

GraionDilach · 2017-12-27T04:23:58Z

See #11987 (comment) why this is a bad idea.

In any case, the issues feel like sideeffects of that goddamned hardcoded lock mechanism and that should be axed in favor of conditions or something, the power refactor should have brought in the necessary prerequisites.

pchote · 2017-12-29T14:17:22Z

IMO that example actually demonstrates why this is a good idea.

Right now ExternalCapture/Production is not robust against the order that notifications are called, which leads to #14219. A less invasive mod-level fix would be to wrap everything after the ChangeOwner in another FrameEndTask, but the fix here makes for cleaner code and logic. Because we are already inside a FrameEndTask there is no need to add an extra level or indirection.

pchote

LGTM, just two minor style nits.

To other reviewers: Add ?w=1 to the url to see that this is doesn't change anything outside the ExternalCapture case.

pchote · 2017-12-29T14:23:46Z

OpenRA.Game/Actor.cs


-				var oldOwner = Owner;
-				var wasInWorld = IsInWorld;
+		public void ChangeOwnerSync(Player newOwner, World world)


Style nit: we tend to put World first in methods like this.

pchote · 2017-12-29T14:24:09Z

OpenRA.Game/Actor.cs

@@ -284,25 +284,30 @@ public void ChangeOwner(Player newOwner)
 		{
 			World.AddFrameEndTask(w =>


Style nit: omit the braces for single line statements: World.AddFrameEndTask(w => ChangeOwnerSync(w, newOwner));

pchote · 2017-12-29T14:28:52Z

This is a pretty straightforward bug fix, so i'd like to get this in for the playtest. I won't add it to the milestone though, as I don't want to force delaying that any longer.

pchote

I pushed a fixup with my requests above. LGTM now

GraionDilach

Ah, I can see now why this will work - that call was already within a FrameEndTask by then.

LGTM.

pchote · 2018-01-01T12:57:30Z

https://github.com/OpenRA/OpenRA/wiki/Changelog-(bleed)/_compare/6a08735c401073f7662e518eb50d4a4a8ff30cfd

MustaphaTR · 2018-01-02T09:43:40Z

Errm, isn't this PR meant to cancel the unit when the capture is done. Not tested on main mods yet, but on my mod (rebased it to bleed today), i'm getting enemy units while tring to capture them. Maybe related to ClassicProduction -> NormalProduction. I'll test on RA too.

MustaphaTR · 2018-01-02T10:01:52Z

Can not confirm on RA, but TD (after changing capturing to External). Looks like indeed something to do with Normal Production.

NethIafin force-pushed the EnemyUnitReady branch 2 times, most recently from b2358ff to 2154dbb Compare October 19, 2017 20:09

abcdefg30 reviewed Oct 19, 2017

View reviewed changes

NethIafin force-pushed the EnemyUnitReady branch from 2154dbb to d13e83e Compare October 19, 2017 22:37

abcdefg30 reviewed Oct 19, 2017

View reviewed changes

netnazgul mentioned this pull request Oct 20, 2017

Enemy unit exits captured WF #14219

Closed

NethIafin force-pushed the EnemyUnitReady branch from d13e83e to b6de1f0 Compare October 20, 2017 17:44

pchote mentioned this pull request Oct 30, 2017

Brainstorming for a potential late-2017 fixup release. #14242

Closed

pchote mentioned this pull request Dec 25, 2017

GetActors() get the actors that changed owner in the same tick it is called #14575

Open

pchote modified the milestone: Next release Dec 29, 2017

pchote previously approved these changes Dec 29, 2017

View reviewed changes

pchote added PR: Fixup requested PR: Needs +2 labels Dec 29, 2017

Fixed issue with unit ready when capturing

052b8a8

pchote dismissed their stale review via 052b8a8 January 1, 2018 11:13

pchote force-pushed the EnemyUnitReady branch from b6de1f0 to 052b8a8 Compare January 1, 2018 11:13

pchote removed the PR: Fixup requested label Jan 1, 2018

pchote approved these changes Jan 1, 2018

View reviewed changes

GraionDilach approved these changes Jan 1, 2018

View reviewed changes

pchote merged commit 11db40a into OpenRA:bleed Jan 1, 2018

penev92 mentioned this pull request Jan 1, 2018

RA capturing barracks while building unit bug? #13983

Closed

MustaphaTR mentioned this pull request Jan 2, 2018

After capturing a NormalProduciton factory with External Capture, production is still done #14632

Open

MustaphaTR mentioned this pull request Jul 17, 2018

Trigger.OnRemovedFromWorld (and probably other stuff related to INotfityRemovedFromWorld) triggers on capture. #15355

Open

pchote mentioned this pull request Nov 25, 2018

Undeploying a chrono MCV at just the right moment duplicates the MCV #15793

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixed issue with unit ready when capturing #14220

Fixed issue with unit ready when capturing #14220

NethIafin commented Oct 19, 2017

abcdefg30 Oct 19, 2017

abcdefg30 Oct 19, 2017

abcdefg30 Oct 19, 2017

NethIafin Oct 20, 2017

netnazgul commented Oct 20, 2017

NethIafin commented Oct 20, 2017

netnazgul commented Oct 20, 2017

NethIafin commented Dec 26, 2017

GraionDilach commented Dec 27, 2017

pchote commented Dec 29, 2017 •

edited

Loading

pchote left a comment

pchote Dec 29, 2017

pchote Dec 29, 2017

pchote commented Dec 29, 2017

pchote left a comment

GraionDilach left a comment

pchote commented Jan 1, 2018

MustaphaTR commented Jan 2, 2018 •

edited

Loading

MustaphaTR commented Jan 2, 2018

		@@ -284,25 +284,30 @@ public void ChangeOwner(Player newOwner)
		{
		World.AddFrameEndTask(w =>

Fixed issue with unit ready when capturing #14220

Fixed issue with unit ready when capturing #14220

Conversation

NethIafin commented Oct 19, 2017

abcdefg30 Oct 19, 2017

Choose a reason for hiding this comment

abcdefg30 Oct 19, 2017

Choose a reason for hiding this comment

abcdefg30 Oct 19, 2017

Choose a reason for hiding this comment

NethIafin Oct 20, 2017

Choose a reason for hiding this comment

netnazgul commented Oct 20, 2017

NethIafin commented Oct 20, 2017

netnazgul commented Oct 20, 2017

NethIafin commented Dec 26, 2017

GraionDilach commented Dec 27, 2017

pchote commented Dec 29, 2017 • edited Loading

pchote left a comment

Choose a reason for hiding this comment

pchote Dec 29, 2017

Choose a reason for hiding this comment

pchote Dec 29, 2017

Choose a reason for hiding this comment

pchote commented Dec 29, 2017

pchote left a comment

Choose a reason for hiding this comment

GraionDilach left a comment

Choose a reason for hiding this comment

pchote commented Jan 1, 2018

MustaphaTR commented Jan 2, 2018 • edited Loading

MustaphaTR commented Jan 2, 2018

pchote commented Dec 29, 2017 •

edited

Loading

MustaphaTR commented Jan 2, 2018 •

edited

Loading