The bug
I shot a regular arrow on the ground and reloaded my world, the arrow now has particles as if it's a tipped arrow, yet when I pick up the arrow it gives a regular arrow.
Code analysis
Based on 1.11.2 decompiled using MCP 9.35 rc1
The Color tag is only written if the arrow has a custom color. The problem is that the game calls the method net.minecraft.entity.projectile.EntityTippedArrow.refreshColor() when an arrow without Color tag is loaded. This method sets the color to the water color.
This could be fixed by always writing the Color tag to make sure tipped water arrows keep their particles as well. Additionally the check if the Color tag exists when reading the NBT data can be removed then.
Related issues
is duplicated by
MC-107969
No gravity arrows
MC-111533
Arrow has water potion when summoned or updated
MC-111730
Arrows turn into potion arrows with no effect when unloaded
MC-111804
Normal arrows look into arrows of water breathing after relogging
MC-112036
Arrows with NoAI tag gain a blue particle effect
MC-112166
Arrow
MC-112617
Tipped Arrow effect
MC-113833
Arrow particles bug in Singleplayer / Multiplayer
MC-114997
Summon arrow Particle
MC-116012
When exiting a world and reopening it, skeleton arrows will appear to have potion effects
MC-117070
Arrow turns into Tipped Arrow (?) when entering Nether Portal
MC-117863
Arrows in the nether get weird particles
MC-118225
Arrow has water potion when summoned
MC-118689
Arrows with effects
MC-120522
If you shoot an arrow then leave and re-log on a singleplayer world, the arrow will become a tipped arrow with no effect
MC-120694
entitydata command makes bugs with arrows
MC-120701
entitydata command make the arrows bugged
MC-121484
Arrows without potion effects creating particles on reload
MC-124224
Summoned arrows always have effect particles
MC-125438
Normal skeletons sometimes shoot arrows that have blue potion particle effects
MC-128620
Arrows creating particles
MC-131509
Arrows reset upon restarting a world
MC-136490
Arrows Have Particles When Summoned
MC-136705
Magic Arrows
MC-136828
Exiting and reentering while arrow is in flight causes it to appear tipped
MC-137447
Arrows have an effect after disconnection
MC-138943
All arrows shot in 18w44a will show a blue potion effect upon relog
MC-142626
When shoot an arrow with bad omen effect then rejoin the game, the arrow produces splash water particle.
MC-144351
Arrow NoGravity changes texture and gets potion effect
MC-145510
Normal arrows have a particle animation after entering again
MC-147580
Arrow entity affected by potion effect
MC-147717
Arrows get effect particles when you re-log
MC-150323
NORMAL arrows have potion particles???
MC-154039
Some arrows fired by skeletons have potion effects attached to them
MC-154694
Normal arrow to effected arrow
MC-154967
Summoned Arrows have particles
MC-157341
Arrows with pickup set to 0b emit particles
MC-157358
Arrows gain particle effects after re-logging into a world.
MC-157393
When exit the game and join in again, the normal arrow entity will become tipped arrow but no effects
MC-157862
Arrows in bamboo stay if you log out before they despawn
MC-164600
MC-107941 reopen
relates to
Attachments
Comments
migrated
migrated
Simply summoning an arrow also gives it particules, and without having to reload the world.
[Mod] Neko
Back in 16w50a. Possibly related to MC-108943.
migrated
Confirmed for 17w06a
11people5
Confirmed for 17w17a.
migrated
Editing the NBTdata of an arrow using /entitydata also triggeres this bug. (1.11.2)
[Mod]Les3awe
@unknown, you are talking about MC-111533.
11people5
Confirmed for 1.12-pre4.
migrated
confirmed for 1.12 pre7
migrated
Confirmed for 1.12.
SunCat
@unknown, it was already marked as affected.
NeunEinser
Can confirm for 17w47b
migrated
Confirm for 18w03b
migrated
confirmed in 18w07b. Using /data get entity @e[type=arrow,limit=1,sort=nearest] does not show anything unusual, not even a potion related tag when the bug is active.
migrated
Merged MC-111533 into this one, as it's the same cause: reading from NBT will create the particles:
reload -> needs to be loaded from nbt and created in an entity
edit -> the entity is (basically) changed to it's NBT data, changes applied and read from NBT data again
summon -> entity is created with nbt data applied
migrated
Affects 18w11a
migrated
Affects 18w21b
migrated
Confirmed for 18w22c
NeunEinser
Can confirm for 1.13-pre1
migrated
Easy fix to summon arrow with no particles!!!
summon arrow ~ ~ ~ {Color:-1}
If you set the color value to -1 the particles are invisible, no worries anymore 😃
They can fix this bug by giving it that value as default
migrated
Can confirm for 1.13.2 release and 1.14 snapshot 18w43c.
muzikbike
Affects all 1.14 snapshots even without exiting the world first.
migrated
There's a more specific bit of code at the root of this bug. (Basing this off the source of 1.12.2.) When writing an arrow entity to NBT (i.e. on save or when modifying the data), it only writes the color tag if its fixedColor property is true. This property is only set in the setFixedColor and refreshColor methods, the latter of which sets the color to the default blue. This means that for normal arrows, it's false by default, and will never be written to NBT data; so when it reloads, the color tag isn't there, and it's refreshed to blue.
Â
The fix to this is quite simple, and requires only two small changes. In the tipped arrow entity's setPotionEffect method, instead of setting the color directly on the data manager, it should call setFixedColor to do this, which will then set the boolean flag properly and allow -1 to be written with the arrow's NBT, fixing the issue for bow-fired arrows.
The second change is to fix the issue for dispenser-fired arrows. In the registerDispenserBehaviors method of the Bootstrap class, when it registers the arrow behaviors for normal arrows, it just needs to call entitytippedarrow.setFixedColor(-1) somewhere between creating the entity and returning it. (The method is currently private, as is the flag, so this would need to actually call a new setter or just make the setFixedColor method public.)
Those small changes should fix this long-standing bug for good 🙂
migrated
Can confirm for all versions 1.14
Erik Broes