testserver y_bows cannot shoot iron golem properly #6118

New Issue

AliasAlreadyTaken · 2024-01-28T12:20:04Z

AliasAlreadyTaken commented

2024-01-28 12:20:04 +00:00

For some reason, I cannot shoot the iron golem except when aiming for the feet. It does have a collision box, but it doesn't get hit anywhere but in a small area at the bottom of the model.

Could be an issue in the model or the collision box, not necessarily in y_bows.

Unfortunately I can't check whether x_bows can hit them, because they are currently broken, too.

For some reason, I cannot shoot the iron golem except when aiming for the feet. It does have a collision box, but it doesn't get hit anywhere but in a small area at the bottom of the model. Could be an issue in the model or the collision box, not necessarily in y_bows. Unfortunately I can't check whether x_bows can hit them, because they are currently broken, too.

AliasAlreadyTaken added the

1. kind/bug

label 2024-01-28 12:20:08 +00:00

flux was assigned by AliasAlreadyTaken

2024-01-28 12:20:13 +00:00

AliasAlreadyTaken referenced this issue

2024-01-28 12:20:27 +00:00

[testserver] y_bows: it's too easy to hit yourself #5974

AliasAlreadyTaken added this to the 1.1.123 milestone 2024-01-28 12:20:38 +00:00

flux added this to the flux's TODO list project 2024-01-29 01:55:37 +00:00

flux commented

2024-02-01 23:26:10 +00:00

verified that the arrow does go straight through them except for a small volume around the feet.

de04cacf7f/iron_golem.lua (L16)

the actual mobs seem to also have the proper collisionbox.

a lot of other mobs also let arrows pass through them. i thought it might correlate to visual_size but that doesn't seem to matter, or at least not in a linear way. simple raycasts seem to work fine, i'm not sure why the compound raycasts don't.

verified that the arrow does go straight through them except for a small volume around the feet. https://gitea.your-land.de/your-land/yl_nether_mobs/src/commit/de04cacf7f1aa27c256ce60c9a5e87aba7b79b28/iron_golem.lua#L16 the actual mobs seem to also have the proper collisionbox. a lot of other mobs also let arrows pass through them. i thought it might correlate to `visual_size` but that doesn't seem to matter, or at least not in a linear way. simple raycasts seem to work fine, i'm not sure why the compound raycasts don't.

flux commented

2024-02-02 00:51:54 +00:00

increasing the step size from .01 to .1 fixes the collision for some reason. i can't even begin to understand why that would be. needs a lot more investigation.

👀 1

AliasAlreadyTaken commented

2024-02-02 09:19:12 +00:00

increasing the step size from .01 to .1 fixes the collision for some reason. i can't even begin to understand why that would be. needs a lot more investigation.

Wat??

On second thought: WAT?!?

The step size is not some global or entity step, it's the height a mob will climb upwards, right?

> increasing the step size from .01 to .1 fixes the collision for some reason. i can't even begin to understand why that would be. needs a lot more investigation. Wat?? On second thought: WAT?!? The step size is not some global or entity step, it's the height a mob will climb upwards, right?

whosit commented

2024-02-02 09:54:41 +00:00

I think flux means integration step (the width of blue bars):

kinda "how often measurement is taken" XD

I think flux means integration step (the *width* of blue bars): ![image](/attachments/dd1dae39-29c7-438b-85dd-5a6bb199d1d5) kinda "how often measurement is taken" XD

image.png

17 KiB

👍 1

whosit commented

2024-02-02 14:51:41 +00:00

I've tried re-centering golem's collision box:
collisionbox = {-0.7, -1.31, -0.7, 0.7, 1.39, 0.7},
seems to work better?

And this may be why:
e10d8080ba/src/serverenvironment.cpp (L1838)

this function is used when initializing raycast in continueRaycast call)
e10d8080ba/src/environment.cpp (L131)

Note the length + 10:

// Size of node in floating-point units
// The original idea behind this is to disallow plain casts between
// floating-point and integer positions, which potentially give wrong
// results. (negative coordinates, values between nodes, ...)
// Use floatToInt(p, BS) and intToFloat(p, BS).
#define BS 10.0f

Still don't have a clear picture in my head, but this is closest I could get to explanation...
So, when you make the step too short, golem is considered too far to add it to the list of possible collisions, because, again, not the collision box is considered, but the "position" of the entity (which is at the bottom of the golem)...

I've tried re-centering golem's collision box: `collisionbox = {-0.7, -1.31, -0.7, 0.7, 1.39, 0.7},` seems to work better? And this may be why: https://github.com/minetest/minetest/blob/e10d8080ba6e53e0f3c4b20b32304f8bb36e5958/src/serverenvironment.cpp#L1838 this function is used when initializing raycast in `continueRaycast` call) https://github.com/minetest/minetest/blob/e10d8080ba6e53e0f3c4b20b32304f8bb36e5958/src/environment.cpp#L131 Note the length + 10: ```C // Size of node in floating-point units // The original idea behind this is to disallow plain casts between // floating-point and integer positions, which potentially give wrong // results. (negative coordinates, values between nodes, ...) // Use floatToInt(p, BS) and intToFloat(p, BS). #define BS 10.0f ``` Still don't have a clear picture in my head, but this is closest I could get to explanation... So, when you make the step too short, golem is considered too far to add it to the list of possible collisions, because, again, not the collision box is considered, but the "position" of the entity (which is at the bottom of the golem)...

flux commented

2024-02-02 19:04:13 +00:00

but the "position" of the entity (which is at the bottom of the golem)...

but it's not 10 nodes away, is it? or is this one of those places where everything is scaled by a factor of 10?

> but the "position" of the entity (which is at the bottom of the golem)... but it's not 10 nodes away, is it? or is this one of those places where everything is scaled by a factor of 10?

whosit commented

2024-02-02 19:15:00 +00:00

but the "position" of the entity (which is at the bottom of the golem)...

but it's not 10 nodes away, is it? or is this one of those places where everything is scaled by a factor of 10?

see the BS definition and comments: one block is 10 units in C++ side of things.
(at least, as far as I can see)

> > but the "position" of the entity (which is at the bottom of the golem)... > > but it's not 10 nodes away, is it? or is this one of those places where everything is scaled by a factor of 10? see the BS definition and comments: one block is 10 units in C++ side of things. (at least, as far as I can see)

flux commented

2024-02-02 19:21:09 +00:00

verified that increasing the value to 100 fixes the problem... so this is an engine issue :\

flux added the

3. source/engine

label 2024-02-02 19:21:20 +00:00

whosit commented

2024-02-02 19:22:55 +00:00

You could just clamp the minimum length of your ray to some "largest hitbox" size...
And using larger step is probably ok too?

You could just clamp the minimum length of your ray to some "largest hitbox" size... And using larger step is probably ok too?

flux commented

2024-02-02 20:30:18 +00:00

upstream engine issue: https://github.com/minetest/minetest/issues/14337

flux commented

2024-02-02 20:31:47 +00:00

And using larger step is probably ok too?

tests show that the accuracy isn't great when lag, but it's acceptable given the alternative at the moment.

> And using larger step is probably ok too? tests show that the accuracy isn't great when lag, but it's acceptable given the alternative at the moment.

whosit commented

2024-02-02 20:38:54 +00:00

Then extending the ray length is the way. Set it to some minimal value, then while casting check if returned object is still within your required range and abort casting of it is not.

There's enough info returned:

pointed_thing.intersection_point: The absolute world coordinates of the point on the selection box which is pointed at. May be in the selection box if the pointer is in the box too.

Then extending the ray length is the way. Set it to some minimal value, then while casting check if returned object is still within your required range and abort casting of it is not. There's enough info returned: ``` pointed_thing.intersection_point: The absolute world coordinates of the point on the selection box which is pointed at. May be in the selection box if the pointer is in the box too. ```

flux commented

2024-02-02 20:46:57 +00:00

i've increased the step size to 0.1s for the time being: 1cfdcfc890

i've increased the step size to 0.1s for the time being: https://github.com/fluxionary/minetest-ballistics/commit/1cfdcfc890e905936e86bd155a48b0ad840733de

flux added the

4. step/ready to QA test

label 2024-02-02 20:48:09 +00:00

whosit commented

2024-02-02 20:55:40 +00:00

This is basically what is happening, as I understand it:

The radius of green circles is the length of the raycast.
Note that "getObjectInRadius" with ray's length will never reach the box's center... And golem has it's "pos" at the bottom of the box, so it's even worse.

This is basically what is happening, as I understand it: ![mt_raycast.png](/attachments/3b443e6d-4efa-4dc5-bc34-29d8cc121dbb) The radius of green circles is the length of the raycast. Note that "getObjectInRadius" with ray's length will never reach the box's center... And golem has it's "pos" at the _bottom_ of the box, so it's even worse.

mt_raycast.png

8.2 KiB

flux commented

2024-02-02 23:23:38 +00:00

Then extending the ray length is the way. Set it to some minimal value, then while casting check if returned object is still within your required range and abort casting of it is not.

i had the same idea, but i haven't implemented it yet :)

> Then extending the ray length is the way. Set it to some minimal value, then while casting check if returned object is still within your required range and abort casting of it is not. i had the same idea, but i haven't implemented it yet :)

flux commented

2024-02-02 23:55:08 +00:00

upstream PR: https://github.com/minetest/minetest/pull/14339

note that because this will be in the engine at earliest at 5.9, we still need the workaround whosit described.

upstream PR: https://github.com/minetest/minetest/pull/14339 note that because this will be in the engine at earliest at 5.9, we still need the workaround whosit described.

flux commented

2024-02-03 00:08:15 +00:00

the maximum extent of all our collisionboxes is currently {-4, -2.5, -4, 4, 9, 4} (the steampunk blimp), so if we want to be safe, the minimum length of a raycast is 10.5 O_O

the maximum extent of all our collisionboxes is currently `{-4, -2.5, -4, 4, 9, 4}` (the steampunk blimp), so if we want to be safe, the minimum length of a raycast is 10.5 O_O

flux commented

2024-02-03 00:35:49 +00:00

implemented raycasts that enforce a minimum length and ignore anything beyond the specified stop point: 36e344d490 5366499fb4

implemented raycasts that enforce a minimum length and ignore anything beyond the specified stop point: https://github.com/fluxionary/minetest-futil/commit/36e344d49035f7ddb33ae3c22d1f7f2b9ef60d4f https://github.com/fluxionary/minetest-ballistics/commit/5366499fb4072c6501b1b7d05faec514bd317994

AliasAlreadyTaken commented

2024-02-03 02:47:58 +00:00

Wait, they're using get_objects_inside_radius for raycasts?

whosit commented

2024-02-03 04:06:04 +00:00

Yes :3

whosit commented

2024-02-05 16:21:17 +00:00

ballistics 2024-02-04 on test:
I can headshot golems without problems... and ankleshot too.
Can also hit players.

ballistics 2024-02-04 on test: I can headshot golems without problems... and ankleshot too. Can also hit players.

👍 1

whosit added the

ugh/QA OK

label 2024-02-05 16:22:32 +00:00

flux commented

2024-02-08 22:40:31 +00:00

engine PR has been merged, but it's irrelevant for the time being.

AliasAlreadyTaken commented

2024-02-09 02:12:54 +00:00

Is this a commit we may want to cherrypick?

flux commented

2024-02-09 04:18:55 +00:00

Is this a commit we may want to cherrypick?

only if we suspect (or better yet, determine) that the fix to ballistics is creating lag. get_objects_in* is not efficient, particularly when every object is calling it every step, but arrows are much more limited - there should only ever be a handful of those calls on any given server step.

> Is this a commit we may want to cherrypick? only if we suspect (or better yet, determine) that the fix to ballistics is creating lag. `get_objects_in*` is not efficient, particularly when every object is calling it every step, but arrows are much more limited - there should only ever be a handful of those calls on any given server step.

flux added

5. result/fixed

and removed

4. step/ready to QA test

labels 2024-03-28 20:55:53 +00:00

flux removed this from the flux's TODO list project 2024-03-28 20:55:55 +00:00

flux removed their assignment 2024-03-28 20:55:58 +00:00

flux commented

2024-03-28 20:56:07 +00:00

this is live

flux closed this issue

2024-03-28 20:56:08 +00:00