Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Refactor handling of hit radii in projectiles. #14742
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
The best fix for this is to change FindActorsOnLine to always account
Similarly to this, I've removed the ability to specify a search radius
CreateEffectWarhead was the only place in core code any of these search
Sorry, that doesn't sound right to me. :?
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.
referenced this pull request
Jan 20, 2018
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