[1.8] [SOLVED] Push floating drops

[jeffryfisher]

I'm trying to design a block (redstone device) that will affect drops that are floating near it. Unfortunately, it is not detecting them. My bounding box looks right, but the entity list is coming back empty. This is the call I made; what bad assumption did I make?

 

   ArrayList<Entity> entityList = (ArrayList<Entity>) world.getEntitiesWithinAABB (EntityItem.class, aabb);

 

Is there an example I can see of a mod that acts upon drops in an area? When I search for one, I get so many hits about dropping items that I haven't found blocks that detect the drops after they're dropped.

[thebest108]

Don't use getEntitiesWithinAABB, use getEntitiesWithinAABBExcludingEntity(null, yourAABB).

[jabelar]

I think both methods should work. In both cases, if it doesn't work then it suggests that the aabb isn't correct. You should print out the values of the aabb to console to confirm they are where you expect. They will need to be world coordinates, not chunk coordinates and will have to be big enough to cover the actual area. Also pay attention to the Y-coordinate -- you might be searching on a layer above or below the entity item.

[perromercenary00]

yea rare i been using thath metod in my grenade entity 

 

        List lista=null;

    int f=10;

   

    BlockPos posMin = nucleo.add( -f, -f, -f);

    BlockPos posMax = nucleo.add( f, f, f);

       

    AxisAlignedBB boundingBox=new AxisAlignedBB(posMin, posMax);

    lista = worldIn.getEntitiesWithinAABB(EntityLivingBase.class, boundingBox);

 

yaa probably is the boundingBox wrong defined

[jeffryfisher]

I think both methods should work. In both cases, if it doesn't work then it suggests that the aabb isn't correct. You should print out the values of the aabb to console to confirm they are where you expect. They will need to be world coordinates, not chunk coordinates and will have to be big enough to cover the actual area. Also pay attention to the Y-coordinate -- you might be searching on a layer above or below the entity item.

That was exactly my thinking leading up to my OP. Printed aabb looks right, but I'll double check to see if the numbers are shifted somehow.

 

What I'm wondering is if I'm passing the right class. To detect drops, is EntityItem.class the right argument?

[jabelar]

What I'm wondering is if I'm passing the right class. To detect drops, is EntityItem.class the right argument?

 

I believe it is, but it is one reason to try the other method that excludes entity. You can then print out the list of entities found and see if something is there that isn't the class you expect.

 

[jeffryfisher]

Aha -- First try to get all entities and then discriminate. I like that strategy. I'll give it a go today and post my results when I learn more.

[jeffryfisher]

Don't use getEntitiesWithinAABB, use getEntitiesWithinAABBExcludingEntity(null, yourAABB).

Both methods return empty. I stepped through getEntitiesWithinAABB in the debugger (because that's the one that is supposed to give me the type of entities I am interested in). It started to find all of the EntityItem entities, but then it filtered them all out when a multimap method called func_180215_b called iterators.filter (iterator, clazz). What's weird is that the iterator had EntityItem entities in it, and it was supposedly filtering for EntityItem class, but it eliminated everything and returned an empty iterator.

 

I then ran using getEntitiesWithinAABBExcludingEntity(null, yourAABB). It too returned empty.

 

However, I verified that my bounding box has correct world coords.

 

I am beginning to worry that item drops are undetectable. When I leave my breakpoints active, I see these functions used only to detect mobs. It might be an unstated rule that they ignore debris.

 

Does anyone know how a mob picks up a loose EntityItem? Is it the mob that scans for the item, or the EntityItem that scans for a mob to pick it up? If the latter, then I may be looking at things the wrong way. I may need to find a way for drops to detect my fan and react to it. Such a burden would probably kill my mod.

 

However, before I give up, I am going to revisit the low-level method where I thought I saw my drops get filtered out. If there's public method I can call to bypass the filter, I may have an out.

[Draco18s]

Your best bet might actually be to look at the hopper.

[jeffryfisher]

Your best bet might actually be to look at the hopper.

Oooh... I hadn't thought of that, but (I think) I see what you mean. Will do.

[jabelar]

If you look in the EntityItem class there is a method called searchForOtherItemsNearby(). What is interesting is that it uses the getEntitiesWithinAABB() method to find other EntityItems.

 

So it definitely should work for EntityItems.

 

And regarding how players pick up items, the EntityItem has an onCollidedWithPlayer() method. So it is just a regular collision, triggered from the EntityItem side.

[jeffryfisher]

I have a suspicion... that I misunderstood how flexible bounding boxes could be. Based on how I am seeing them used by EntityItem, BlockHopper and their own expand method, it appears that it is not good enough to simply pick any two opposing vertices to define a box (as in all the graphics programs that have spoiled me). When passing aa and bb into the constructor, I had imagined that it would sort out each axis' min and max if necessary. Looking inside, I see that it assumes aa to be min values and bb to be max values.

 

Since I used offsets and rotateYCCW to produce my aa and bb, most facings of my block will invert min and max on either the X or Z axis. I now suspect that such an inverted bounding box will malfunction. I'll sort out my mins and maxes and let you know if that solves my problem.

 

EDIT:

 

Indeed, that was my problem. My bounding box looked okay to me because it fit my own bad assumptions. The examples I was working from were all block-centered, whereas my fan is directional, so I was offsetting off-center, and it wasn't quite obvious that the box wasn't sorted right.

 

Here's my sorting correction:

    aa = new BlockPos (Math.min (near.getX (), far.getX ()), near.getY (), Math.min (near.getZ (), far.getZ ()));
    bb = new BlockPos (Math.max (near.getX (), far.getX ()), far.getY (), Math.max (near.getZ (), far.getZ ()));

And its 4 lines in the log :

[11:44:17] [server thread/INFO] [sTDOUT]: [jrfinventions.classBlockBlower:windField:203]: near = 238, 64, 202
[11:44:17] [server thread/INFO] [sTDOUT]: [jrfinventions.classBlockBlower:windField:204]: far = 232, 66, 200
[11:44:17] [server thread/INFO] [sTDOUT]: [jrfinventions.classBlockBlower:windField:205]: aa = 232, 64, 200
[11:44:17] [server thread/INFO] [sTDOUT]: [jrfinventions.classBlockBlower:windField:206]: bb = 238, 66, 202
[11:44:17] [server thread/INFO] [sTDOUT]: [jrfinventions.classBlockBlower:updateTick:244]: Found entity = item.item.sulphur with motion 3.0027303737907635E-38, -0.0, -3.2726263473873886E-38
[11:44:17] [server thread/INFO] [sTDOUT]: [jrfinventions.classBlockBlower:updateTick:244]: Found entity = item.item.redstone with motion 2.9882014093001097E-96, -0.0, -2.795579597995496E-96

[jabelar]

Cool. Yeah it is hard to debug something when it is acting according to your own false assumptions. Glad you figured it out.