[1.12] Replace EntityItem with new entity type, but keep motion when tossed?

[IceMetalPunk]

I'm trying to make certain item entities immune to fire. Turns out, that's not as easy as it seems. So for a first test, I'm trying to make *all* item entities immune to fire by creating a class, EntityItemFireproof, that extends EntityItem, but overrides its attackEntityFrom() method to ignore fire damage. Then I'm using the EntityJoinWorldEvent to "replace" all item entities with my Fireproof versions.

 

*EDIT* Okay, this particular issue has been mostly solved. But now I can't get the replaced items to properly copy the original item entity's motion when thrown, since it seems that's set *after* the EntityJoinWorldEvent fires; see this post for the current issue.

 

Previous, but related, issue:

 

Upon testing, I drop an item... and suddenly there are infinitely many copies being made, without stop, until the game slows and crashes from too many entities.

 

I'm canceling the Join World event and I'm not spawning more entities when my Fireproof entities are created, so what could be causing this?

 

Here's the event handler code:

 

	@SubscribeEvent
	public void onItemCreate(EntityJoinWorldEvent ev) {
		Entity ent = ev.getEntity();
		World world = ev.getWorld();
		if (ent instanceof EntityItem && !(ent instanceof EntityItemFireproof)) {
			EntityItem item = (EntityItem) ent;
			EntityItemFireproof fireproofItem = new EntityItemFireproof(world, item.posX, item.posY, item.posZ,
					item.getItem());
			fireproofItem.motionX = item.motionX;
			fireproofItem.motionY = item.motionX;
			fireproofItem.motionZ = item.motionX;
			world.spawnEntity(fireproofItem);
			ev.setCanceled(true);
		}
	}

 

And here's the EntityItemFireproof class:

package com.icemetalpunk.totemessentials.items;

import net.minecraft.entity.item.EntityItem;
import net.minecraft.item.ItemStack;
import net.minecraft.util.DamageSource;
import net.minecraft.world.World;

public class EntityItemFireproof extends EntityItem {

	public EntityItemFireproof(World worldIn) {
		super(worldIn);
	}

	public EntityItemFireproof(World worldIn, double x, double y, double z) {
		super(worldIn, x, y, z);
	}

	public EntityItemFireproof(World worldIn, double x, double y, double z, ItemStack stack) {
		super(worldIn, x, y, z, stack);
	}

	@Override
	public boolean attackEntityFrom(DamageSource source, float amount) {
		if (source.isFireDamage()) {
			return false;
		} else {
			return super.attackEntityFrom(source, amount);
		}
	}

}

 

So why on Earth would that little event handler lead to infinite item spawns when I drop an item?

 

*EDIT* A bit of debugging later shows that the duplicated entity is just an EntityItem, not an EntityItemFireproof. But how is that possible when I'm not spawning any more EntityItems, only an EntityItemFireproof? I thought maybe the vanilla drop code was detecting the failure to spawn an item and trying again repeatedly, but that doesn't look like the case as I look through the vanilla code (unless I missed where that happens?). So what's going on here?

Edited September 5, 2017 by IceMetalPunk

[shultzy]

Looking at your event handler, the original item is not destroyed when its duplicated. As for why its only spawning EntityItems, I'm not entirely sure, but my guess is how EntityItemFireproof's constructor is called. This essentially means that the item that spawns causes the event to fire again thus repeating indefinitely.

Hopefully this was some help.

 

*Edit* Something else I had thought of is you could change this line:

EntityItemFireproof fireproofItem = new EntityItemFireproof(world, item.posX, item.posY, item.posZ, item.getItem()); 

To this:

EntityItemFireproof fireproofItem = (EntityItemFireproof) ent;

 

Edited September 4, 2017 by shultzy

[IceMetalPunk]

And here I thought canceling the Join World event would kill the item inherently. Guess not. I've *almost* got it working with this code:

 

@SubscribeEvent
	public void onItemCreate(EntityJoinWorldEvent ev) {
		Entity ent = ev.getEntity();
		World world = ev.getWorld();
		if (ent instanceof EntityItem && !(ent instanceof EntityItemFireproof)) {
			EntityItem item = (EntityItem) ent;
			EntityItemFireproof fireproofItem = new EntityItemFireproof(world, item.posX, item.posY, item.posZ,
					item.getItem());

			// Age and pickup delay must be set so you don't immediately pick up
			// thrown items, but they're private values, so we use Reflection
			// for it.
			Field ageField = ReflectionHelper.findField(EntityItem.class, "age", "field_70292_b", "d");
			Field delayField = ReflectionHelper.findField(EntityItem.class, "delayBeforeCanPickup", "field_145804_b",
					"e");
			int age = item.getAge();
			try {
				int delay = delayField.getInt(item);
				delayField.setInt(fireproofItem, delay);
				ageField.setInt(fireproofItem, age);
			} catch (IllegalArgumentException | IllegalAccessException e) {
				e.printStackTrace();
			}

			// Here's where the motion is...
			fireproofItem.motionX = item.motionX;
			fireproofItem.motionY = item.motionX;
			fireproofItem.motionZ = item.motionX;
			world.removeEntity(item);
			world.spawnEntity(fireproofItem);
		}
	}

 

The only problem is that when the player tosses an item, the motion seems to be set *after* the spawning, so I can't actually copy the proper motion. Instead, the items just all fall the same way regardless of the direction the player is facing. How do I solve that order-of-events issue?

[IceMetalPunk]

8 hours ago, diesieben07 said:

• First of all, Forge already has functionality for this, override hasCustomEntity and createCustomEntity in your Item class.
• Do not look up the field instances every time. Do it once and store them in a static final field.
• You do not need to provide the completely obfuscated "notch names".
• You are setting motionX, motionY and motionZ of the new entity all to the motionX value of the old entity.

1. I can't use hasCustomEntity/etc. because I want the fireproofing to apply to all item entities, including  vanilla ones and ones from other mobs.

2. Thanks for the tip; I will be doing that going forward.

3. See #2

4. ... *facepalm*. This is what I get for having copypasta in a piece of code where I know what I meant so I didn't see what I actually wrote. Damnit. Thank you!

 

So now that I fixed those things, the items are thrown properly... but weirdly, they seem to stop rendering after only being a few blocks away. The EntityItemFireproof, that is. If I move only 5 or 6 blocks away, they stop rendering, and when I move closer, they render again. I'm pretty sure normal items render from farther away than that, don't they?

 

Is there some special rendering setup I need to do for custom item entities?

[IceMetalPunk]

I use this code, basically in the PreInit event:

 

EntityRegistry.registerModEntity(new ResourceLocation(TotemEssentials.MODID, "fireproof_item"),
				EntityItemFireproof.class, "fireproof_item", entityID++, TotemEssentials.instance, 5, 1, true);

 (entityID is a variable that starts at 0 and is only used here.)

Edited September 5, 2017 by IceMetalPunk

[Draco18s]

16 minutes ago, IceMetalPunk said:

basically in the PreInit event:

We would like to see the whole main class and the whole class where this line is in order to make sure that it is being called.

[IceMetalPunk]

Here's the repo and branch I'm working on this on: https://github.com/IceMetalPunk/TotemEssentials/tree/fireproof-items

 

The body of the pre-init handler in the main class instantiates the TERegistryEvents instance, and that constructor is where the entity registration happens.

 

*EDIT* (The git branch is deleted now that the issue was fixed thanks to jabelar's suggestion!)

Edited September 5, 2017 by IceMetalPunk

[jabelar]

For fast moving entities, I usually put 80, 10 where you put a 5, 1 in your entity registration.  I think your "5" means you'll stop tracking once it is 5 blocks away!

Edited September 5, 2017 by jabelar

[IceMetalPunk]

3 minutes ago, jabelar said:

For fast moving entities, I usually put 80, 3 where you put a 5, 1 in your entity registration.  I think your "5" means you'll stop tracking once it is 5 blocks away!

Ohhhh.... is that what "tracking range" means? I thought it had something to do with mob AI tracking for some reason. (I know, it didn't really make a ton of sense, especially since it's a generic entity registration and not just for mobs... but I couldn't figure out what it meant otherwise!)

Yep, changing that value did, in fact, fix the problem! Thank you so very much!

[jabelar]

Yeah, there is a whole system of which entities are "tracked" on each client since the world is so big that it doesn't make sense to have every entity sending info to the client continuously.

 

I have some flying entities where I have to put the range to 8000 because otherwise the disappear if they fly high and also at some distance. And the second parameter is also important as the value of 1 will mean the updates are sent very occasionally, but for fast moving ones you want them sent more frequently.

[IceMetalPunk]

...so, this appears to be not completely solved after all. And after I merged it into my master branch, too. (Lesson learned: do full testing before merging.)

So here's the newest code: https://github.com/IceMetalPunk/TotemEssentials/blob/827f3c291734ba60f102b464207252faf3806fad/src/main/java/com/icemetalpunk/totemessentials/events/TEEvents.java#L355

 

In this version, the only item entities replaced with the fireproof versions are the ones with the "Fireproof:1b" tag, and that tag is removed once the replacement happens. That much works flawlessly.

 

The issue is that if the player is given items with the /give command (or, I presume, an advancement reward, though I haven't tested that part), it duplicates the items. It's like the item entity spawned to give to the player is still added to the player's inventory even though the code is supposed to prevent it from joining the world at all; but it also still creates the fireprooof version, so the player picks up both.

 

I've tried testing the value of item.getOwner(), since that's used only in these give command scenarios, but that's not set until *after* the entity is spawned (it returns null in every case, even *with* the commands used), so that won't work here.

Edited September 5, 2017 by IceMetalPunk

[IceMetalPunk]

I realized that for the final product here, I was only going to need to replace entities from the PlayerDropsEvent list, and ultimately I got what I wanted working without having to deal with the /give issue.

 

But I'd still like to know how I might go about fixing the problem in case I do need a more general item-entity-replacement approach like this in the future?