ZollaS's Arsenal

The mod id and entrypoints in fabric.mod.json

Must be zollas_arsenal, with net.zollas.arsenal.ZollasArsenal as main and net.zollas.arsenal.client.ZollasArsenalClient as client.

If a build ever loads a mod called "template-mod", a leftover template file has overwritten this one again.

ClientPlayNetworking comes from Fabric, not Minecraft

The import is net.fabricmc.fabric.api.client.networking.v1.ClientPlayNetworking. There is no such class under net.minecraft.client.network.

Got wrong twice.

Math.round on a double returns a long

Assigning it to the arrowsAmount int field needs an explicit (int) cast.

The abstract method is getDefaultItemStack

In 1.21.1 Yarn mappings PersistentProjectileEntity declares getDefaultItemStack(), not asItemStack().

A custom entity without a renderer crashes on sight

The EntityRendererRegistry.register call in onInitializeClient is load-bearing. Drop it and the game throws the instant an explosive arrow needs drawing.

Symptom to recognise: everything renders fine until the moment one is fired.

dimensions takes two floats

In this API version FabricEntityTypeBuilder.dimensions(...) takes width and height directly, not an EntityDimensions object.

Every spawned entity needs its own ItemStack copy

Passing one shared stack into many entities and then decrementing it empties the stack every one of them holds. Always hand each entity a copyWithCount(1).

This surfaced only much later, as "cannot encode empty ItemStack" on autosave — the longest hunt in the project.

Receiver callbacks hand you a PlayerEntity

Not a ServerPlayerEntity. Cast it explicitly before use.

Explosions shove arrows that are still in flight

The blast applies velocity to every nearby entity, arrows included. explode() snapshots nearby projectile velocities before the explosion and restores them after, so a chain detonation does not scatter the rest of the volley.

setVelocity does not take metres per second

It takes blocks per tick. One block is one metre and there are twenty ticks in a second, so the menu value is divided by TICKS_PER_SECOND in FireHandler before it reaches the arrow. The old hard-coded 3.0f was 60 m/s all along, which is now the slider's default.

The top of the slider is 500 blocks per tick, which carries the arrow past the loaded chunks before the next tick runs — it is culled, nothing lands, and the bow appears dead. FireHandler therefore caps what physics receives at MAX_BLOCKS_PER_TICK, currently 100. The menu still displays whatever the player chose.

An arrow's coordinates during a hit callback are stale

They describe where it began the tick, not where it struck. explode() takes its position from the HitResult, and snapTo() moves the entity onto the impact point before super runs — vanilla emits the landing sound at the entity's own coordinates, so the explosion and the sound each needed handling.

Found through the velocity slider: at the top of the range the detonation and then the thud both arrived next to the shooter, a whole flight behind the target. At vanilla speed the same bug was there and invisible.

A vanilla ArrowEntity cannot be corrected from outside, which first pushed the mod onto a bespoke entity — and that broke @e[type=arrow] and tipped arrows, since the selector matches one exact id and nothing can be aliased onto it. The mixin replaced that: the mod fires genuine minecraft:arrow entities again, and the patch supplies both the impact correction and the detonation.

Land the arrow a tenth of a block short of the impact point, not exactly on it. Vanilla reads a landed arrow's facing from the vector between its position and the hit point, then nudges it back along that vector so the shaft protrudes. Snap it exactly onto the hit point and that vector is zero — the arrow loses its orientation and lies flat in the surface.

Static maps outlive the world; world time does not

PlayerSettingsManager keys both its maps by player UUID in static fields, so they survive into the next world. getWorld().getTime() does not — it restarts near zero in a freshly created world. A fire tick recorded at 500000 in an established world therefore sits in the future of a new one, and the rate limiter refuses every shot until the new clock catches up.

The symptom was a brand new world where no toggle would fire, that healed after closing and reopening the game — because that is what clears a static map. canFireNow now treats any backwards jump as a fresh start, and per-player state is dropped on disconnect.

The client must push its settings on joining a world

The server's copy now resets per world, so ClientPlayConnectionEvents.JOIN has to re-send it. Any setting added later must ride along in that payload or it will silently run at its default.

Do not send directly from the JOIN callback: the channel is not reliably ready yet, canSend returns false, and the sync is dropped with no error. The join sets a flag and the client tick retries until it goes through.

Cancel blast push with the attribute, not a mixin

Vanilla's explosion scales its push on a living entity by one minus explosion_knockback_resistance, and explosion damage types sit in the no_knockback tag — so the blast push is the only thing that moves a player. No Blast Knockback adds a temporary +1.0 modifier to that attribute. Both facts were checked against the 1.21.1 jar.

Temporary modifiers never reach the save file, so they cannot outlive the mod — but they also vanish when a dying player's entity is replaced. ServerPlayerEvents.AFTER_RESPAWN reapplies it from the settings, which survive because they are keyed by UUID.

The impact correction is 1.21.1 only — on 1.21.11 it makes arrows bounce

Mojang's projectile rework changed landing. In 1.21.11, applyCollision moves the arrow onto the hit point before onBlockHit runs, so the stale position behind trap 10 no longer exists. onBlockHit then zeroes the velocity and never moves the arrow forward again.

Pulling the arrow back 0.1 block on 1.21.11 therefore left it hovering past the 0.06 margin shouldFall() checks: it dropped, landed, was pulled back, and bounced forever. The 1.21.11 build has no correction at all. The 1.21.11 behaviour was read from that version's bytecode. The 1.21.1 build keeps its correction because, there, the tick moves the arrow forward after the hit and cancels the pull-back out — reasoned from that version's landing code, not re-checked in bytecode, and no bounce has been reported on it.

In multiplayer, guests get limits and the host keeps everything

ArsenalPermissions.isTrusted is true for the world's host — the player whose game is the server, as when inviting friends through Essential — or anyone with operator level 2. Everyone else cannot use Clear Arrows or the weapon buttons, never fires explosive arrows, and is held to 20 arrows a volley and 5 shots a second. They are told once in chat. No Blast Knockback is unrestricted because it only affects the player using it.

Limits are applied when a shot fires, never written into the stored settings, so a later /op takes effect on the very next shot. The permission API differs per version: hasPermissionLevel(2) and isHost(getGameProfile()) on 1.21.1, getPermissions().hasPermission(new Permission.Level(PermissionLevel.GAMEMASTERS)) and isHost(getPlayerConfigEntry()) on 1.21.11. Every client-to-server message is now behind canSend, so the mod stays quiet on a server that lacks it. Everyone must run the same mod version — the settings packet layout changes between versions.