Throwable/Projectile entity item model not apply CustomModelData from model
Lists of affected
- Ender Pearl
- Experience Bottle
- Firework Rocket
- Egg
- Fire Charge
- Ender Eye
- Snowball
Steps to reproduce
- Download the test resource pack.
- For example. Use
/give @s snowball{CustomModelData:1} - Throw it into the air or put it in the dispenser.
- And you will see the entity doesn't apply CustomModelData from current model.
Environment
OS : Windows 10 Pro 64bit
CPU : AMD FX(tm)-6300 Six-Core Processor 3.50 GHz
RAM : 8 GB DDR3
Java : JDK 1.8.0 Update 181 x64
Graphic Card : GeForce GTX 750 Ti/PCIe/SSE2
Linked Issues
testing discovered1
Created Issue:
Snowball (entity) model not changed when Snowball (item) has CustomModelData
Steps to reproduce
- Download the test resource pack.
- Use {code:java} /give @s snowball{CustomModelData:1} {code}
- Throw it into the air.
- And you will see snowball still uses original model.
Environment
OS : Windows 10 Pro 64bit
CPU : AMD FX(tm)-6300 Six-Core Processor 3.50 GHz
RAM : 8 GB DDR3
Java : JDK 1.8.0 Update 181 x64
Graphic Card : GeForce GTX 750 Ti/PCIe/SSE2
Steps to reproduce
- Download the test resource pack.
- Use {code:java} /give @s snowball{CustomModelData:1} {code}
- Throw it into the air.
- And you will see snowball still uses original model.
Steps to reproduce
- Download the test resource pack.
- Use
/give @s snowball{CustomModelData:1}- Throw it into the air.
- And you will see snowball still uses original model.
Steps to reproduce
- Download the test resource pack.
- Use
/give @s snowball{CustomModelData:1}- Throw it into the air.
- And you will see
snowball still uses originalmodel.Lists of affected
- Ender Pearl
- Experience Bottle
- Firework Rocket
- Egg
- Fire Charge
- Ender Eye
- Snowball
Steps to reproduce
- Download the test resource pack.
- For example. Use
/give @s snowball{CustomModelData:1}- Throw it into the air or put it in the dispenser.
- And you will see the entity doesn't apply CustomModelData from current model.
Snowball (entity)model notchanged when Snowball (item) hasCustomModelDataThrowable/Projectile entity item model not apply CustomModelData from model
Lists of affected
- Ender Pearl
- Experience Bottle
- Firework Rocket
- Egg
- Fire Charge
- Ender Eye
- Snowball
Steps to reproduce
- Download the test resource pack.
- For example. Use
/give @s snowball{CustomModelData:1}- Throw it into the air or put it in the dispenser.
- And you will see the entity doesn't apply CustomModelData from current model.
Lists of affected
- Ender Pearl
- Experience Bottle
- Firework Rocket
- Egg
- Fire Charge
- Ender Eye
- Snowball
Steps to reproduce
- Download the test resource pack.
- For example. Use
/give @s snowball{CustomModelData:1}- Throw it into the air or put it in the dispenser.
- And you will see the entity doesn't apply CustomModelData from current model.
relates to
relates to
testing discovered
relates to
The entity ID of the small fireball is broken. This first happened in 18w50a, as part of how MC-138660 was fixed.
To reproduce
First, try a regular fireball:
/summon fireball ~ ~ ~ {direction:[0d, 0d, 0d]}
/say @e[type=fireball]
/say @e[type=small_fireball]
/summon will produce "Summoned new Fireball" and the first /say will produce the fireball, and the second /say will produce nothing. This makes sense.
Remove the fireball by typing /kill and then shift-clicking the output of /summon to get the UUID.
Next, try a small fireball:
/summon small_fireball ~ ~ ~ {direction:[0d, 0d, 0d]}
/say @e[type=fireball]
/say @e[type=small_fireball]
/summon will still produce "Summoned new Fireball", instead of "Summoned new Small Fireball", and both /say commands produce no results, although /say @e[distance=..5] will include the fireball. This is very strange behavior.
Remove the fireball by typing /kill and then shift-clicking the output of /summon to get the UUID. Note that like with /say, type selectors will not remove the fireball; it must be removed using its UUID.
Code analysis
Both the small fireball and the regular fireball have the entity type set to that of the regular fireball in the constructor for their parent class.
fireball is aro, and has an entity type ID of agz.J. small_fireball is art, and has an entity type ID of agz.ap. Both of them extend arl, which in turn extends arg (which is also used by dragon fireball and wither skull). However, arl's constructor always uses agz.J (fireball); it should instead get the entity type from the subclasses (especially since it's an abstract class).
Note
Note that regular fireballs don't come from an item, only small ones (which are used for fire charges in addition to blaze projectiles). So, it isn't strictly necessary to keep the input item, since there is no input item. However, it does allow for some cool things such as this, so it's probably worth preserving:
/summon fireball ~ ~ ~ {Item:{Count:1b, id:"minecraft:tnt"},NoGravity:1b,direction:[0.0,0.0,0.0],ExplosionPower:5}








This issue relates to
MC-138892.Tridents appear to still have this issue. I'm not entirely sure it's related to it as it uses a different type of model.
@MukiTanuki the "different type of model" is an entity model; thrown tridents are entities. That would be kind of the same as reporting that arrows are unaffected by the fix of this bug, but I'd report the trident one, just to be safe.
This appears to still be an issue if the item is the last item in a stack of projectiles, specifically when the hotbar slot for that projectile becomes empty. Since the hotbar never empties in creative mode, this can only be accomplished in survival/adventure mode. Projectiles from dispensers still render properly, even as the last projectile in a stack. I've attached a video of gameplay from 1.14.3 pre release 3 demonstrating this bug in action.
Minecraft 1.14.3 Pre-Release 3 6_18_2019 12_45_02 PM.mp4