MC-140959small_fireball entity ID is broken
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}
Linked Issues
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
Created Issue:
small_fireball entity ID is broken
The entity ID of the small fireball is broken. This first happened in 18w50a, as part of how
MC-138660was 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).
The entity ID of the small fireball is broken. This first happened in 18w50a, as part of how
MC-138660was 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{{/summonto 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).
The entity ID of the small fireball is broken. This first happened in 18w50a, as part of how
MC-138660was 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).
The entity ID of the small fireball is broken. This first happened in 18w50a, as part of how
MC-138660was 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{{/summonto 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).
The entity ID of the small fireball is broken. This first happened in 18w50a, as part of how
MC-138660was 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).
The entity ID of the small fireball is broken. This first happened in 18w50a, as part of how
MC-138660was 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}
discovered while testing
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
![[Mojang] Bartosz Bok](../../../data/avatars/users/10122.svg){kind=small}
[Mojang] Bartosz Bok![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
relates to