Refactor handling of hit radii in projectiles. #14742

alercah · 2018-01-18T02:07:10Z

This pull request is intended as a premilinary review of the code changes I'm proposing. I haven't yet done extensive testing or written the necessary upgrade rules. If it does what I expect, it's possible that, as a result of this, shots that weren't previously blocked will now be blocked, but if that's true, it was a bug.

The performance cost from not having a separate radius for blocking actors is easily fixed by storing that on the ActorMap as well, and then having a flag to pass into FindActorsOnLine, if that's a concern.

penev discovered that the RulesetLoaded functions of projectiles were
never being called, meaning that their blocking calculations were not
properly accounting for actors with large hitboxes.

The best fix for this is to change FindActorsOnLine to always account
for the largest actor's hit radius, rather than forcing callers to pass
the largest radius. Per the comment in Util.cs, as a result, move this
computation to ActorMap. I decided to simplify by not making a separate
calculation for actors that block projectiles only; this may cause a
small performance degradation as the search space is a bit larger.

Similarly to this, I've removed the ability to specify a search radius
manually. Because this is only a search radius, setting a value smaller
than the largest eligible actor makes no sense; that would lead to
completely inconsistent blocking. Setting a larger value, on the other
hand, would make no difference.

CreateEffectWarhead was the only place in core code any of these search
radii were set, and that's because 0 was a mysterious magic value that
made the warhead incapable of hitting actors. I replaced it with a
boolean flag that more clearly indicates the actual behaviour.

Fixes #14151.

abcdefg30 · 2018-01-19T17:29:10Z

OpenRA.Mods.Common/Traits/World/ActorMap.cs

 	{
 		[Desc("Size of partition bins (cells)")]
 		public readonly int BinSize = 10;

+		// The largest hit radius for any actor.


You can include that as Desc. Edit: Wait, actually is this exposed to yaml?

abcdefg30 · 2018-01-19T17:29:49Z

OpenRA.Mods.Common/Traits/World/ActorMap.cs

 		public object Create(ActorInitializer init) { return new ActorMap(init.World, this); }
+
+		public void RulesetLoaded(Ruleset rules, ActorInfo info) {
+		  LargestActorRadius = rules.Actors.SelectMany(a => a.Value.TraitInfos<HitShapeInfo>()).Max(h => h.Type.OuterRadius);


The brace should be on it's own line. Also spaces -> tabs, please.

abcdefg30 · 2018-01-19T17:30:18Z

OpenRA.Mods.Common/WorldExtensions.cs

+		/// </summary>
+		public static IEnumerable<Actor> FindActorsOnCircle(this World world, WPos origin, WDist r)
+		{
+		  return world.FindActorsInCircle(origin, r + world.ActorMap.LargestActorRadius);


Again spaces before return instead of tabs.

pchote · 2018-01-19T17:31:57Z

OpenRA.Mods.Common/Traits/World/ActorMap.cs

 	{
 		[Desc("Size of partition bins (cells)")]
 		public readonly int BinSize = 10;

+		// The largest hit radius for any actor.
+		public WDist LargestActorRadius { get; private set; }


This needs a [FieldLoader.Ignore] and then doesn't need a Desc.

That's an error because the attribute isn't valid on properties.

It might be better to move this to ActorMap to avoid confusion.

I was thinking to avoid recalculating it more than once, but since this is a World trait, you're probably right. It's not going to have many instances constructed over the life of the game like another Actor might.

Ah wait, but is there a way for the ActorMap to get access to the Ruleset?

Yes, via the world.Map.

penev92 · 2018-01-19T18:30:50Z

The best fix for this is to change FindActorsOnLine to always account
for the largest actor's hit radius, rather than forcing callers to pass
the largest radius.

Sorry, that doesn't sound right to me. :?
With the callers providing the extra search radius you have more flexibility, while otherwise you have some borderline hardcoded implicit extra value that nobody knows of or expects :S

alercah · 2018-01-19T18:46:16Z

It's not an extra value. The behaviour of the function as documented is "find all actors whose hit radius intersects a line". It should do that.

The problem is that, for efficiency reasons, the function doesn't want to look at all actors and check their radii. So instead, it looks only a certain distance away from the line. Except it actually doesn't do that, it looks inside a bounding box that contains all points a certain distance away from the line. If this distance is at least as big as the largest actor's radius, it's guaranteed to meet its contract and find all actors.

The code as-is does not do this. It only looks slightly beyond the line. You have to pass it an additional parameter. If the parameter is too small, its actual behaviour is "find all actors that fit inside this kinda arbitrary bounding box that doesn't have much to do with this line and whose hit radius intersect it." If the parameter is too large, it is just a waste of time because it will meet its contract, but it will look at actors it doesn't need to. In other words, there is never any reason for the parameter to be anything other than the exact correct value, and so as a result, it should never be used.

pchote · 2018-01-20T10:24:17Z

Does this fix #14151?

alercah · 2018-01-20T14:41:09Z

I've done some rudimentary testing with walls, and it appears they do block projectiles correctly.

alercah · 2018-01-20T19:25:47Z

I think this is now ready for integration.

GraionDilach

Looks good to me, although I'§m not sure where we are now with the upgrade rules.

I also wouldn't merge this into the playtest, inb4 actual balance regressions.

👍 nevertheless.

reaperrr · 2018-02-18T22:57:28Z

Haven't tested this yet, but looks good to me.

Since there's currently no telling when/if the current upgrade rule system will be replaced, this PR should get a simple upgrade rule that replaces the VictimScanRadius: 0 entries with ImpactActor: false, though.

alercah · 2018-02-18T23:14:07Z

Oops, I forgot to push the updated version with an upgrade rule. I pushed it so you can take a look; I'll make sure it rebases cleanly and then repush when I'm done.

reaperrr · 2018-02-18T23:30:02Z

OpenRA.Mods.Common/UtilityCommands/UpgradeRules.cs

@@ -1796,6 +1796,27 @@ internal static void UpgradeWeaponRules(ModData modData, int engineVersion, ref
 					}
 				}

+				if (engineVersion < 20180120)


Now that the release is out, please change this to a date after the release (exact day doesn't really matter, 20180219 would be enough).

reaperrr · 2018-02-18T23:30:42Z

OpenRA.Mods.Common/UtilityCommands/UpgradeRules.cs

+							{
+								node.Value.Nodes.Add(new MiniYamlNode("ImpactActors", "false"));
+							}
+							node.Value.Nodes.Remove(victimScanRadius);


OpenRA.Mods.Common/UtilityCommands/UpgradeRules.cs:L1809: [SA1513] Statements or elements wrapped in curly brackets must be followed by a blank line.

Single line if statements should not have curly brackets in the first place.

Ok, but for readability ther should be an empty line between the .Add and the .Remove either way.

MunWolf · 2018-02-18T23:39:22Z

OpenRA.Mods.Common/UtilityCommands/UpgradeRules.cs

+					if (node.Key.StartsWith("Projectile"))
+					{
+						node.Value.Nodes.RemoveAll(n => n.Key == "BounceBlockerScanRadius" || n.Key == "BlockerScanRadius" || n.Key == "AreaVictimScanRadius");
+					}


Remove curly brackets

alercah · 2018-02-19T00:23:06Z

Addressed comments.

reaperrr · 2018-02-19T23:47:16Z

OpenRA.Mods.Common/UtilityCommands/UpgradeRules.cs

@@ -1796,6 +1796,24 @@ internal static void UpgradeWeaponRules(ModData modData, int engineVersion, ref
 					}
 				}

+				if (engineVersion < 20180129)


typo? should be 0219.

penev discovered that the RulesetLoaded functions of projectiles were never being called, meaning that their blocking calculations were not properly accounting for actors with large hitboxes. The best fix for this is to change FindActorsOnLine to always account for the largest actor's hit radius, rather than forcing callers to pass the largest radius. Per the comment in Util.cs, as a result, move this computation to ActorMap. I decided to simplify by not making a separate calculation for actors that block projectiles only; this may cause a small performance degradation as the search space is a bit larger. Similarly to this, I've removed the ability to specify a search radius manually. Because this is only a search radius, setting a value smaller than the largest eligible actor makes no sense; that would lead to completely inconsistent blocking. Setting a larger value, on the other hand, would make no difference. CreateEffectWarhead was the only place in core code any of these search radii were set, and that's because 0 was a mysterious magic value that made the warhead incapable of hitting actors. I replaced it with a boolean flag that more clearly indicates the actual behaviour. Fixes #14151.

alercah · 2018-02-20T01:28:45Z

Oops, fixed.

reaperrr · 2018-02-21T22:26:22Z

Does this fix #14151?

Yes. 👍

reaperrr · 2018-02-21T22:30:09Z

https://github.com/OpenRA/OpenRA/wiki/Changelog-(bleed)/_compare/0416f4b379717409506c6ab1b5ef53d4cdc5b2a2...a633e97a16dd2e5f63c96297cf12ce6ca030d197

abcdefg30 requested a review from reaperrr January 19, 2018 16:31

abcdefg30 reviewed Jan 19, 2018

View reviewed changes

pchote reviewed Jan 19, 2018

View reviewed changes

alercah mentioned this pull request Jan 20, 2018

TS disc grenades don't explode when hitting enemy building #14151

Closed

GraionDilach approved these changes Jan 21, 2018

View reviewed changes

abcdefg30 added the PR: Needs +2 label Jan 21, 2018

reaperrr added the PR: Fixup requested label Feb 18, 2018

reaperrr reviewed Feb 18, 2018

View reviewed changes

MunWolf reviewed Feb 18, 2018

View reviewed changes

reaperrr reviewed Feb 19, 2018

View reviewed changes

abcdefg30 removed the PR: Fixup requested label Feb 20, 2018

reaperrr approved these changes Feb 21, 2018

View reviewed changes

reaperrr merged commit 08ad7d7 into OpenRA:bleed Feb 21, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor handling of hit radii in projectiles. #14742

Refactor handling of hit radii in projectiles. #14742

alercah commented Jan 18, 2018 •

edited by reaperrr

abcdefg30 Jan 19, 2018 •

edited

abcdefg30 Jan 19, 2018

abcdefg30 Jan 19, 2018

pchote Jan 19, 2018 •

edited

alercah Jan 19, 2018

pchote Jan 20, 2018

alercah Jan 20, 2018

alercah Jan 20, 2018

pchote Jan 20, 2018

penev92 commented Jan 19, 2018

alercah commented Jan 19, 2018

pchote commented Jan 20, 2018

alercah commented Jan 20, 2018

alercah commented Jan 20, 2018

GraionDilach left a comment

reaperrr commented Feb 18, 2018

alercah commented Feb 18, 2018

reaperrr Feb 18, 2018

reaperrr Feb 18, 2018

MunWolf Feb 18, 2018

reaperrr Feb 18, 2018

MunWolf Feb 18, 2018

MunWolf Feb 18, 2018

alercah commented Feb 19, 2018

reaperrr Feb 19, 2018

alercah commented Feb 20, 2018

reaperrr commented Feb 21, 2018

reaperrr commented Feb 21, 2018

Refactor handling of hit radii in projectiles. #14742

Refactor handling of hit radii in projectiles. #14742

Conversation

alercah commented Jan 18, 2018 • edited by reaperrr

abcdefg30 Jan 19, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pchote Jan 19, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

penev92 commented Jan 19, 2018

alercah commented Jan 19, 2018

pchote commented Jan 20, 2018

alercah commented Jan 20, 2018

alercah commented Jan 20, 2018

GraionDilach left a comment

Choose a reason for hiding this comment

reaperrr commented Feb 18, 2018

alercah commented Feb 18, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alercah commented Feb 19, 2018

Choose a reason for hiding this comment

alercah commented Feb 20, 2018

reaperrr commented Feb 21, 2018

reaperrr commented Feb 21, 2018

alercah commented Jan 18, 2018 •

edited by reaperrr

abcdefg30 Jan 19, 2018 •

edited

pchote Jan 19, 2018 •

edited