Repository navigation
Network Protocol Error near hitboxes: armor-stand metadata applied to ItemDisplay (26.1.2) #445
Description
Summary
Players near a custom crocodile model repeatedly receive Network Protocol Error. The client receives metadata consistent with BetterModel's hidden armor-stand hitbox for an entity advertised as an ItemDisplay. Reproduced with different entity IDs, two launchers, and two client versions; unrelated to /shop.
Environment
- BetterModel
3.5.1-SNAPSHOT-525, Paper 26.1.2 build 74, Java 25, NMSV26_R1 - MythicMobs 5.13.0: model applied to a ZOMBIE on
~onSpawnand~onLoad - ProtocolLib 5.5.0-SNAPSHOT, ViaVersion/ViaBackwards installed
- Model has a
hitboxbone with a 44×16×39 cube and anh_headbone
Client error
ClientboundSetEntityDataPacket[id=288512, packedItems=[
DataValue[id=0, value=32], DataValue[id=4, value=true], DataValue[id=9, value=20.0]]]
IllegalStateException: Invalid entity data item type for field 9 on entity ItemDisplay:
old=0(Integer), new=20.0(Float)
Findings
From inspecting the installed plugin/Paper bytecode and V26_R1 source—not runtime instrumentation:
HitBoxImplextendsArmorStandthroughAbstractHitBoxand implementsHitBox. The NMSHitBoxInteractiondoes not implementHitBox(only its Bukkit wrapper does). The spawn rewrite therefore targets the armor stand.9=20.0matches LivingEntity health;0=32and4=truematch invisible/silent flags. My initial interpretation as Interaction height was incorrect.- The channel handler advertises a hitbox as
ITEM_DISPLAY, but metadata replacement withhitBoxDatadepends on registry/live entity lookup. If both lookups return null, the original packet passes through unchanged. - The live lookup uses the player's current world. Removal/despawn, chunk unloading, or world changes before queued packets are processed could therefore break the rewrite. The exact runtime trigger is not yet confirmed.
- Ordinary bundles are recursively handled; there is no evidence that disabling bundling fixes this.
Workaround
Renamed hitbox to hitbox_disabled and deleted its cube (renaming alone rendered a missing-texture cube), then ran bettermodel reload. The model looks normal and hits still register using the smaller vanilla mob hitbox. No further kick during a short test; long-term validation is pending.
Suggested fix (unverified)
Track IDs advertised as fake ItemDisplays per connection, rather than relying on live entity lookup for subsequent metadata rewriting. Use the same state for hitbox attribute/equipment suppression; clear IDs on outgoing removal in packet order and release state on disconnect.
Regression tests should cover despawn/removal with queued metadata, chunk unload/reload, world changes, and remove/re-spawn ordering, including bundles. Raw armor-stand metadata must never reach an entity advertised as an ItemDisplay.
Activity
[-]Clients kicked with "Network Protocol Error": Interaction entity data sent for hitbox faked as ItemDisplay (26.1.2)[/-][+]Clients kicked with "Network Protocol Error": armor-stand metadata sent for hitbox faked as ItemDisplay (26.1.2)[/+][-]Clients kicked with "Network Protocol Error": armor-stand metadata sent for hitbox faked as ItemDisplay (26.1.2)[/-][+]Network Protocol Error near hitboxes: armor-stand metadata applied to ItemDisplay (26.1.2)[/+]Rabusek commentedon Nov 1, 2026
Same crash on 26.2 (
V26_R2) with BetterModel 3.5.0 and MythicMobs 5.13.0 on a Purpur-based server. A packet capture on the backend shows the runtime trigger: the modeled mob despawns right after it spawns, and the hitbox's first metadata update is sent in the same burst as its removal.Trigger
Action: ADD, mob withDespawn: trueand a model with ahitboxbone) can place the mob more than 128 blocks away (3D, the hard despawn range) from every player. The server then removes it almost immediately, and BetterModel removes the hitbox with it.0=32,4=true,9=20.0) goes out just before the remove packet. As described above, the live lookup misses, so the raw armor-stand metadata reaches a client that knows the entity as anITEM_DISPLAY.Capture. Decoded backend traffic. Times are ms before the client closed the connection.
A second capture shows the same sequence 79 ms before the close (entities 2602310–2602319, again spawned at y = 62.5). A client report from a third occurrence has the error from this issue:
Invalid entity data item type for field 9 on entity <Item Display> ... at y=62.50: old=0(Integer), new=20.0(Float).Workaround without editing models: add
- playerwithin{d=100} trueto the conditions of every random spawn whose mob uses a model. Mobs then never spawn where they would despawn at once. MythicMobs'PlayerWithinuses 3D distance. We applied it today, so it isn't validated long-term yet.#468, which tracks the fake hitbox ids per connection until the removal is sent, covers this exact ordering: the entity is removed before its queued metadata is processed.