Ask a simple question, get a simple answer

[Isaac]

Is that used in the base game?
(...and what are some uses for it?)

* A low ceiling restriction in onThink for monsters too tall to fit beneath, is all that comes to mind offhand.

[zimberzimber]

Currently I am using monster:getCapsuleHeight() + monster:getCapsuleRadius()/2, it feels ok, I tested if in the arena of orrr3, but it was still a little too low for the mosquitos!

You could add an offset

[AndakRainor]

Currently I am using monster:getCapsuleHeight() + monster:getCapsuleRadius()/2, it feels ok, I tested if in the arena of orrr3, but it was still a little too low for the mosquitos!

You could add an offset

The problem with an offset, is that I want the particle effect to start as near as possible of the "center" of any monster, including rats swarm, mosquitos, turtles, medusas, ... So I need a different value specific to each monster.

[Isaac]

Aha.. That's a practical use for it.

*About the monsters [worst case] you could use a table of monster.name keys for the offset; or for that matter no offset, just the best value for each monster. Obviously it's preferable to avoid the need for a table; and the need to update it for new monsters.

[minmay]

getCapsuleHeight() seems too low because the capsule moves with the monster's capsule node, and the capsule node is almost never on the ground. The center of a slime's capsule is about 0.37 meters above the floor, the center a crowern's capsule is about 1.62 meters above the floor.
The capsule radius is only the radius in the x and z dimensions, it won't give you more accurate results for the height of the monster. The capsule moves with the animation (especially noticeable with animations that move the monster, especially ones like the swamp toad's jump) so unfortunately finding its position with the scripting interface is not practical right now.

The only way I see to approach this is to add a disabled ParticleComponent to every monster with "capsule" as its parentNode. Then you can enable it when life drain is used on the monster.

ModelComponent:getNodeTransform(name) would be a nice method to have...

[Isaac]

How about creating the Particle component on demand for those monsters affected by Life Drain?
(and removing it after)

[minmay]

How about creating the Particle component on demand for those monsters affected by Life Drain?
(and removing it after)

You can't give a parent node to dynamically created components.

[Isaac]

How about creating the Particle component on demand for those monsters affected by Life Drain?
(and removing it after)

You can't give a parent node to dynamically created components.

Now that you mention it... I may have known (and forgotten); I'm sure I've tried it before.

I would have thought that getBoundBox() or getHeadRotation() could have helped, but they only seem to return nil when I tried them.

[AndakRainor]

So I opted for the worst case scenario for now. Because orrr3 has a lot of custom monsters and I should edit them all, including the potential future ones to add the particle component to them. Also, the monster's "center" position I try to set for this particle effect is a starting position, the particles then move toward the "center" of the party (party world position +1 on the y axis is visually pleasing to me, higher it would be annoying even with strong transparency).

I do it this way: I get the value from the table if it is defined, if not I use a default value of 1.5 for flying monsters and 0.75 for other monsters. I have defined 4 monsters in the table so far... I am lazy!

[minmay]

So I opted for the worst case scenario for now. Because orrr3 has a lot of custom monsters and I should edit them all, including the potential future ones to add the particle component to them.

You can just shadow defineObject() like I did for the diagnostics and add the component there, that way it will be on all future monsters. Just make sure to choose a unique name for the component.