More unit centre control

[imbaczek]

volume intersection is not so hard; large radius spatial queries are very expensive.

[Saktoth]

AOE is calculated from the model center using the radius, not the custom collision volume.

Turns out KDR was right, should have just listened to him. The problem is the models radius (as defined in the s3o) is not large enough.

No matter how high i offset the model centre in the s3o or with the modelCenterOffset tag, it will take damage if the s3o hitsphere is larger than the offset.

Picture:

(In that picture, the hitsphere covers half the map).

Note that the custom collision volume also has to be within the explosion radius to take damage. I suspect it uses one for detection, the other for damage (if the custom volume is particularly large, it takes more damage).

What do you hope to accomplish with a remark like this? There wasn't even any mention of a problem until you quoted what I said and took it (out of context) to mean something else entirely, based on your own misinformation and a flawed test that you assumed to be the ground truth. No technical solution there.

Google only made this thread in an attempt to address this problem, as he has said. I am hoping to accomplish only a clarification of the exact issue we are having so that we dont waste our time with hypotheticals that do not address it. There is no need to attack me.

[Google_Frog]

Your workaround with the large hitsphere has issues. The hitsphere is used for avoiding allies so no ally units will be able to fire.

[Kloot]

Turns out KDR was right

Partially; model radius (which you keep referring to as "the hitsphere") is used only along with the explosion radius for *finding* units to damage, not for the second step of applying any damage.

No matter how high i offset the model centre in the s3o or with the modelCenterOffset tag, it will take damage if the s3o hitsphere is larger than the offset.

Because the combined radius of the explosion and the model then exceeds the distance from the explosion center to the model's mid-pos, which means the engine will mark it for further processing.

Note that the custom collision volume also has to be within the explosion radius to take damage. I suspect...

Don't "suspect", read:

only [units whose central point happens to fall within the explosion's influence sphere ["within" being determined by the combined explosion and model radius, apologies if this was unclear]] are considered, and only these go through the AOE calculations as explained above and sketched in my diagram

where "the AOE calculations" are done with respect to the CCV's center and bounding radius.

Google only made this thread in an attempt to address this problem, as he has said.

In his initial post he made no mention of it, and I can't read minds (yet).

I am hoping to accomplish only a clarification of the exact issue we are having so that we dont waste our time with hypotheticals that do not address it.

Fair enough, though accepting the word of a dev who implemented most of this stuff (me) would help you there.

[Saktoth]

I said 'suspect' because i was trying to not be rude by making bold declarative statements contradicting you (something you dont seem to try to avoid...).

When i said:

This is a problem because we have offset the llt model centre so that if it can shoot, it can be shot at (to prevent it hiding behind terraform blocks and such). However, this means that the Wolverine/Shellshocker, which being inaccurate relies on hitting the ground near a unit and damaging it with the AoE, no longer hurts the LLT with anything less than a direct hit.

I was discussing why google made this post (We = CA/Google and I). You dont need to have read minds to understand that.
In response:

AOE is calculated from the model center using the radius, not the custom collision volume. I had trouble with that in THIS when the collision volume went outside the unit radius and explosives would fail to damage the unit after impacting.

This would have been enough to fix my problem. If KDR was wrong, it was only his use of 'calculated' rather than 'detected'. However, I 'took the word of a dev who implemented most of this stuff' when you contradicted him:

The radius used in the calculation is actually that of the collision volume (ie. of the sphere which minimally encompasses the custom shape) rather than of the model. But yes, AOE damage is applied spherically.

Basically, the radius of the .s3o is not used, the radius of the collision volume is. So changing it wont help me. This is where you draw your diagram to explain the situation (IE, how you 'misinterpret' the problem KDR is offering a solution to).

After attacking me for my 'flawed test', you tell me 'No technical solution there.' and that:

What you've just described is a completely separate (and not easily fixable) problem:

• 1) An explosion takes place somewhere
  2) Spring needs to *find* all nearby units to damage them in the first place
  3) The engine only has a record of where each unit is by its middle-position
  4) Because of #3, only those units whose central point happens to fall within the explosion's influence sphere are considered, and only these go through the AOE calculations as explained above and sketched in my diagram

It was very easily fixable, the middle position AND radius are used to record where a unit is.

"within" being determined by the combined explosion and model radius, apologies if this was unclear.

It was quite unclear. You said central point falls 'within' the explosions influence, not the intersection of the explosions infleunce sphere and the units radius. Apology accepted.

I appreciate you are trying to help, with diagrams and all. But you have aggressively told everyone here that they are wrong, then attacked me, when you have completely misunderstood the problem we are trying to address and offered false and misleading information about it.

[Saktoth]

Oh, doublepost because i didnt address this:

Your workaround with the large hitsphere has issues. The hitsphere is used for avoiding allies so no ally units will be able to fire.

Actually, based on some tests (which still might be flawed, misinformed, misleading and inaccurate, keep in mind!), it appears that Kloots 'sphere which minimally encompasses the custom shape' is used for avoidfriendly, not the model radius. This would tend to suggest that hitboxes that perfectly match the footprint are a very bad idea, and the factory-hax problem we've been having could be avoided with a spherical hitvolume.

Is there anything else that the model radius is used for, other than detection of AoE? What kind of unintended side-effects can we expect from this workaround?