1

I am writing a datapack with an item which functions like a sniper rifle - you can shoot it and a particle beam created by a recursive raycasting function will shoot out and any entities it encounters should die. However, entity detection is a big problem, because I can shoot right through a creeper's head and it doesn't die. You can download the datapack here if you want to test it out. Use /function rituals:give/sniper_rifle to get the item.

I noticed that this is true for almost every mob in the game greater than an endermite or silverfish: if you shoot it through the feet, it dies, but anywhere above that or else than that, it doesn't. Pigs, cows, zombies, evokers, drowned, wither skeletons, anything, only die when shot through the feet. I don't intend for it to kill bosses so they are not a problem, luckily.

I've been detecting mobs by having every iteration of the recursive function run kill @e[distance=..0.1], and it moves ahead by 0.25 blocks each iteration. I have tried to get around this difference in @e detection, mob hitboxes, and visible mob sizes (which for some reason are all different) by using scoreboards to give every mob a value equal to their approximate height, and then changing the distance based on what type of mob it is: kill @e[scores={mobHeights=2},distance=..2], but that is at best buggy and at worst making it so you can shoot next to a mob and kill it.

As you can see in this image, the cursor is well over the pig, yet it insta-dies because of this imprecision. Pig dying from sniper rifle.

If anyone knows a better way to detect mobs a raycasting function is moving through that would be great, because right now it is really frustrating to have to try to manually implement a fix which is really imprecise. Also, if anyone knows why the function only recognizes entities by their feet, that would also help a lot. I know that coordinates are also calculated at an entities feet, so maybe that has something to do with it.

3
  • Maybe summon an arrow? I haven't looked at your code, but maybe you could replace the entire logic with a NoGravity arrow with a high damage value. Jun 11, 2019 at 3:05
  • Yeah actually I originally tried that, but in the linked datapack there is another item called a fire staff. If you give yourself one of those, you should also get an item called a fire hose. Using this item will show you the issue: the item projected does not have a consistent and smooth trajectory, like shot from a bow, but instead is jerky and lags out the game. I would prefer to try to solve this raycasting issue than resort to using a physical projectile, because then I can also make the ray go through "soft" blocks (like cacti) to add some realism, too. Thanks for the suggestion, though.
    – Nik3141
    Jun 11, 2019 at 3:17
  • Maybe only summon an arrow when you're nearby a mob and then check if it's hit, otherwise kill it one tick later? Jun 11, 2019 at 10:54

1 Answer 1

1

distance tests if the target coordinates are less than some distance away, not if the nearest part of the mob is under the given distance. I'd suggest using the 3d bounding box selection (x,dx,y,dy,z,dz,), because it selects hitboxes. It would kill any mobs in an area similar to the bounding box of an entity - meaning you are now tracking a point using a box, instead of the ideal tracking a box using a point.
Here's an example command:

kill @e[x=~,y=~-1.5,z=~,dx=0.1,dy=1.6,dz=0.1]

This would still not work, let's say, for an Ender Dragon. Also, you would kill everything on the way, including items.

4
  • But this (if I'm understanding correctly) still has a margin of error (1.5 blocks?) for where the entity could be vertically, so it would assume the ray went through the head, and would also not be super accurate, not more so than my current method, which works basically the same: adjusting for the height of the mob. Is it possible to somehow track if a function is executed at a position inside an entity's hitbox?
    – Nik3141
    Jun 11, 2019 at 3:27
  • @Nik3141 It's just a partial solution, but IMO more convenient to use, as it would better simulate the entity hitbox shapes. Teleporting levitating arrows in combination to your particles is a great idea, as it uses already present mechanics to solve the problem. But, it would also use box-shaped detection areas, not spheres.
    – user143228
    Jun 11, 2019 at 4:02
  • So I was reading a different post gaming.stackexchange.com/questions/352682/… and saw that dx, dy, and dz track the hitbox, but distance doesn't. I think you said that in your answer but I just didn't understand, because I have never used dx, dy, and dz before. I edited your answer and my question to make it about detecting hitboxes, because that is really the essence of my question. If I change anything and it becomes incorrect, please change it.
    – Nik3141
    Jun 13, 2019 at 21:07
  • Also, the wiki on selecting targets by volume at minecraft.gamepedia.com/Commands#Target_selector_arguments is very confusing when it says "@e[x=1,y=2,z=3,dx=0,dy=0,dz=0] — targets only entities whose hitbox collects with the block region (1,2,3)." What does it mean by 'hitbox collects'? Does the whole hitbox have to be inside the volume or only part of it?
    – Nik3141
    Jun 13, 2019 at 21:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .