SashegDev
04bad6f32b
Measured on zern.cc with 20 mineflayer bots on SNIPE, empty world and then with 625 entities clustered around them. getLungeTarget searched a 120x120x120 cube to find one entity inside a 5.7 degree cone, and ran TWO raytraces per entity inside that loop. The second one, rayTraceBlocks(eye, dir, 120), does not depend on the entity at all: eye, dir and the distance are loop-invariant, so the same answer was recomputed once per entity, each time walking up to 120 blocks. On a populated world that is up to 2N raytraces per call, and updatePreview calls it every 4 ticks per player holding a knife. Now the query is an AABB along the look direction, the block ray is computed once before the loop, and hasLineOfSight is only called on candidates in distance order - usually exactly once. The common case of zero or one target allocates nothing at all; tracking the two nearest inline avoids the lists and the sort entirely. Honest note on the measurement: this fix did NOT show up. 10.5 ms median before vs 10.8 ms after with 625 entities nearby. Working the numbers back, that path costs roughly 1% of capacity in this scenario, which is below the noise floor. The code change is correct by inspection, not by measurement, and it would matter far more in a world with thousands of entities than 625. LUNGE is removed. Its shockwave drew points = radius*6 and issued THREE separate spawnParticle calls per point, so a radius-10 ring sent 180 packets PER TICK, expanding, per cast. That is gone with the ability. Particle batching, which is the real cost in this plugin. Every spawnParticle is one packet per viewer. MagicListener's hit ring was 36 separate calls and its explosion shell was 72; the OVERHEAD aiming ring was 32 packets every tick. spawnParticle with count>1 spreads particles inside the offset volume, so a ring of radius r becomes a filled disc of the same radius - indistinguishable at half-block scale, and the particle count is unchanged. New Particles helper. TensionManager.updateBar ran every tick per player: String.format, two Component.text, and a progress packet. Now it repaints only when the whole percent changes, and the percent is computed with integer math. At 0.25/tick regen that is four repaints a second instead of twenty, and zero on a full bar. The percent cache is cleared on quit and resynced on death so the bar cannot get stuck. tickBattle copied the entire battleEnemies map, including every nested set, twenty times a second - purely so it could iterate and delete from the same map. Keys are now collected into a list and dropped after the loop. getMode now collapses an unknown stored mode onto STARS. Without that a knife issued before LUNGE was removed could not be mode-switched at all: the index lookup found nothing, stayed at zero, and the knife was stuck.