More unit centre control

[Google_Frog]

I would like to be able to manually assign many unit 'hotspots' in the unit defs. The 4 I can think of currently are aimpoint(the point that units aim to fire at), Radar Point (the point that radar dots are centred on), explosion damage point (the point used for AOE damage calculations) and the middle of the hitsphere(as well as the size). These values would be relative to the engine assigned middle of a unit and would default to the middle. There are probably more points that I'm not aware of (maybe some to do with LOS calculation).

Before anyone says 'use custom hitvolumes' instead of moving the hitsphere: The custom hitvolumes are not used for everything such as targeting.

[KDR_11k]

I'd also like a way to move those points with Lua once the unit exists.

[Kloot]

"hitsphere" is something of a misnomer, since detecting weapon hits is not what it's used for anymore. But in any event...

the point that units aim to fire at

... can already be moved via the modelCenterOffset tag. However, this will also move

the point that radar dots are centred on

the point used for AOE damage calculations

and

the middle of the hitsphere

because all of these are tied to the same notion of mid-pos. In the case of the point used for AOE damage calculations, you can compensate and set it independently by changing the collision volume offsets (which are defined wrt. the middle position themselves); the other two are not customizable yet.

[Saktoth]

I had been setting the model centre in Upspring then offsetting the collision volume, its good to know about the modelCenterOffset tag. (Also, while trying to search for where this was documented, i found this. Jesus christ, so many tags i had no idea we had).

In the case of the point used for AOE damage calculations, you can compensate and set it independently by changing the collision volume offsets

Are you sure of this? I just tried this, using modelCenterOffset = [[0 1000 0]] and collisionVolumeOffsets = [[0 -1000 0]], the unit takes no damage from AoE (less than 1000 at least, and reduced damage in that case)- only direct hits harm it.

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.

[Argh]

@Saktoth: go into UpSpring, move the centroid of the hitsphere up to the top of the model. Then in the unitDef, use a cuboid hit volume.

[Saktoth]

@Saktoth: go into UpSpring, move the centroid of the hitsphere up to the top of the model. Then in the unitDef, use a cuboid hit volume.

That was my origional solution to the problem, before i knew about the modelCenterOffset tag.

The results are identical in respect to AoE.

[KDR_11k]

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.

[Kloot]

AOE is calculated from the model center using the radius

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.

EDIT: in the diagram below, this means that the length of one of the yellow lines minus the radius of the green sphere must be LESS than the radius of one of the yellow spheres for a unit to take any splash damage.

[Argh]

Hmm. I really haven't noticed problems with cuboids and AoE, even with very large volumes.

Maybe the problem is that the volume isn't larger than 8 on a given axis? I have found that hitspheres with a radius smaller than 8 tend to have problems.

[Saktoth]

A highly exaggerated demonstration. The white dot near the top of the image is the model centre, thats a nuclear explosion next door- llt takes no damage.

Clearly this exact situation will never (...rarely) come up, but on a much smaller scale, with artillery using small AoE's, it is a problem when you're putting the model centre in a tall turrets firing point.

[Kloot]

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

Draw own conclusions wrt your LLT scenario.

[Google_Frog]

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

Draw own conclusions wrt your LLT scenario.

In summary the middle of the collision volume is used to apply aoe damage but it is only applied to units which have their middle(white dot in sak's picture) inside the aoe of the explosion?

If that's the case then store another middle value used for detecting nearby units for the purposes of explosions.

[Argh]

Uh, or just move that centerpoint down to a logical place.

I mean... wtf, it looks like it's 300 elmos in the sky, which you don't need for anything at all, unless you really wanted to make targeting / interaction fail.

I did stuff like that with things I *didn't* want to see interactions with... personally, I think that's a feature, not a flaw.

[Google_Frog]

A highly exaggerated demonstration. The white dot near the top of the image is the model centre, thats a nuclear explosion next door- llt takes no damage.

Really wtf Argh. Did you just skim the thread for pictures?

[Argh]

No, I saw that white dot of the centerpoint, way up in the sky. I'm just saying, "of course that will fail, the centerpoint is nowhere near the logical center of the object", is all.

It's annoying that the Unit centroid controls that much, don't get me wrong...

[Google_Frog]

No, I saw that white dot of the centerpoint, way up in the sky. I'm just saying, "of course that will fail, the centerpoint is nowhere near the logical center of the object", is all.

Here is a summary as to why the centrepoint is so high up.

* I request centrepoint control, AOE damage calculation centre among the points.
* Kloot claims that the AOE centrepoint is the middle of the custom volume "In the case of the point used for AOE damage calculations, you can compensate and set it independently by changing the collision volume offsets"
* Saktoth tests Kloot's claim (as Saktoth interpreted it) by moving the centrepoint far away from the middle of the custom volume.

Anyway what is a logical centre of an object?

[Saktoth]

I mean... wtf, it looks like it's 300 elmos in the sky

Its not actually that high in game, and the wolverine/shellshocker dont make nuclear explosions. Im not going to have it that high, and the explosions we're worried about are not nukes. Now, take that same situation, and scale it down until the white dot is in the firing point (at the very top of) the turret, and the AoE is slightly smaller than the turret is tall. Thats our problem

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

Well, what i am demonstrating is the problem we are having, not necessarily the problem you discussed.

[imbaczek]

the whole problem is that there are multiple centers of any unit, depending on needs. this particular case here is that spatial queries are done based on midpos, but aoe is based on a different center; if a spatial query fails (as in sak's example), aoe is not applied. consider this a technical limitation of the engine.

perhaps a possible solution would be to allow modders to provide their own spatial query radius.

[Kloot]

In summary the middle of the collision volume is used to apply aoe damage but it is only applied to units which have their middle(white dot in sak's picture) inside the aoe of the explosion?

Yep.

If that's the case then store another middle value used for detecting nearby units for the purposes of explosions.

That would cost at least twice as much memory just to handle situations which, to be honest, are the exception rather than the rule.

Well, what i am demonstrating is the problem we are having, not necessarily the problem you discussed.

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.

Anyway what is a logical centre of an object?

Unfortunately there is more than one for different purposes.

perhaps a possible solution would be to allow modders to provide their own spatial query radius.

A customizable query shape (box, cylinder, sphere) per explosion could also help, but it would obviously still be a bandaid.

[Argh]

No flamewar was intended, I think we're all on the same side here. A query shape would solve this problem, which (primarily) comes up with Really Huge Stuff, but IIRC, such volume checks are pretty slow- that's a volume intersection test, isn't it? Or are there any shortcuts? If not, that probably would need to be an optional flag, I would think, otherwise that's probably going to add a not-inconsiderable load per explosion. Small stuff doesn't really need that check, imo- if a Unit's hit-detection's screwed for a 16-elmo explosion, then the Unit needs to get fixed. For a 256, though, it would certainly be appropriate.