Mob item pickup destroy controller
Ipsis opened this issue ยท 7 comments
The tryPickupModItems routine will pickup the mob controller if it is broken while the machine is learning and then delete it!
Need to ignore the controller in that function.
I cannot see anyway if identifying if a user dropped an item near the factory. The loot on the ground is just the entities in the area.
However if I was to kill the mob at bedrock level, then that would stop non-mob items from being identified, unless the user placed the mob factory at the same level.
By spawning the mobs at (factory.x, 0, factory.z) and checking for items at (factory.x, 0, factory.z).expand(2,0,2), then this seems to solve the issue.
The items will be dropped at y=0 and therefore it should be very difficult for anyone to spoof a drop.
Some more testing and I'll try and roll this into a quick release tomorrow.
Why does Woot have to go through the method of generating all of those mobs to learn their drops? Isn't there a method to just get them? If not, how does Just Enough Resources do it?
There is no way, to my knowledge, as each mod can add their own drops, at their own percentage chance, without telling anyone else about it. Enough Resources, I think just hardcodes the loot and the chance. It can also use the new json based loot tables, however this is new and not all mods use it.
This is the one thing I didn't want to do as I wanted it to work with mods as you added/removed them.
I think Forge should create a solution to that, like they did Ore Dictionary. They create a new table of some sort and add the vanilla ones, then mods can add to it, and it has methods to view the loot tables.
In the longer term that is what the vanilla loot tables will do. But mod authors will have to move their code over to the new loot tables. Some already have, but many other still hook into the LivingDropsEvent and either add to the drop list or spawn in the world. Some will actually check what item the user it holding to determine their loot. I think the vanilla system is flexible, but I don't know if it is flexible enough. The other issue with it is that the LivingDropsEvent still exists and all their code currently works, so it is probably not something most authors would want to rewrite for.