Fix yellow particle warning when Assaults spam the Inferno-X Cannon

[abielsaf]

Bug

Spamming the Inferno-X Cannon (device 2914) spawned a yellow engine warning on screen — Emitter spawn vertices: N (…kB of verts), clamp to 515 — visible to both the firing Assault and surrounding players.

Root cause traced in the client binary: it's UE3's native sprite-budget clamp in ParticleEmitterInstances.cpp (SpawnParticles), which fires when ActiveParticles + thisTickSpawn > GEngine->MaxParticleSpriteCount. The over-budget emitter is the charge-up burst inside PS_EFX_BeamChargeUpA.

The cannon's beam modes are continuous_fire but were also flagged interrupt_fire_anim_on_refire = 1. On a continuous beam that means the fire anim is torn down and restarted on every refire (~0.1s), and each restart re-spawns the charge-up burst. Rapid fire stacks bursts faster than the particles die, so ActiveParticles blows past the budget and the clamp warning prints. It replicates to everyone because the FX plays off flash/anim replication — which is why bystanders saw it too.

The client is byte-identical to the original-server era (same MaxParticleSpriteCount), so the only variable is server-driven fire cadence — this is a server-side data fix, not a client bug.

Fix

Clear interrupt_fire_anim_on_refire_flag (1 → 0) for the Inferno-X Cannon's two beam modes (3339 primary, 3409 alt). The beam anim now plays once per fire sequence instead of restarting every refire, so the charge-up burst no longer stacks. continuous_fire stays 1; firing behavior and damage are unchanged.

Applied as an unconditional, idempotent enforce in Database.cpp (mirrors the existing VR-heal-pad enforce), placed after the versioned if (version < N) gates and before the version_info update.

How it applies to an existing populated server.db

server.db is a generated artifact — it is not tracked or merged. The fix ships in code and runs on every server startup:

UPDATE asm_data_set_devices_data_set_device_modes
SET interrupt_fire_anim_on_refire_flag = 0
WHERE device_mode_id IN (3339, 3409)
AND interrupt_fire_anim_on_refire_flag <> 0;

Because it's outside the version gates, it doesn't matter that a live DB's version counter is already past them — it always executes against whatever server.db is present. On an already-populated DB (the normal case) the two rows exist, so the fix lands on the first restart after merge. The <> 0 guard makes every subsequent run a no-op (idempotent, zero rows touched). Clients pick up the corrected flag when they fetch device data on connect.

Edge case: on a brand-new empty DB, the device-modes table is populated by AsmDataCapture during the first game run (after startup migrations), so the enforce needs one extra restart to catch it. Irrelevant for any real deployment, which already has a populated DB.

Verified on VR with two Assaults firing side by side, spamming left- and right-click — no warning, weapon fires normally.

Related to : https://discord.com/channels/994691794627461211/1529815224671141908