What actually changed

The intercept problem is solved properly — four fixed-point iterations against the actual projectile speed for that robot type — and then deliberately degraded with error terms you can influence:

• Aim tightens the longer a robot holds sight of you, so sitting in one firing lane gets progressively more punishing.
• Aim loosens when the robot itself is moving fast, so keeping them chasing is worth something.
• Lead error scales with your speed, so changing direction defeats prediction while moving predictably does not.

A robot that always leads perfectly is not difficult, it is just unfair — there is no counterplay. This model gives you something to actually do about it.

Not everyone gets everything

Each ability is rolled per robot against AbilityGrantChance, capped by MaxAbilitiesPerRobot, using that robot's own seeded RNG — so its loadout is stable for its whole life, and two Grunts in the same room can be genuinely different opponents. Granting everything to everyone would flatten Overload's bestiary into one enemy with nine buttons.

The wind-up is the point

An ability that arrives with no warning is not a mechanic, it is just damage. During a charge the robot slows and its headlight comes on; that window is your opportunity to break line of sight. The recovery afterwards leaves it committed and punishable. AbilityChargeScale at 0 removes the tell entirely — harsher, and arguably unfair.

A robot winding up does not also shoot

That would erase the tell the whole design rests on.

Overload gives a robot exactly one weapon, described by public fields on Robot: projectile, upgrade level, spread, firing distribution, burst delays, fire distance and fire angle. A weapon "type" here is a snapshot of exactly those fields, and switching is writing them — so after a swap the game's own firing code reads the new values and behaves accordingly, because they are the same fields it always read.

Slot one is native

The robot's own weapon, captured as it spawns rather than hardcoded — so it survives custom levels, robot data overrides and olmod's own robotdata.txt, and can always be restored exactly.

Slot two is derived

Scaled from slot one by config rather than invented, so a Grunt's secondary is still a Grunt's secondary and cannot accidentally out-gun a Hulk.

Lead stays correct after a swap

The game's own projectile speed table is indexed by robot type and was built from each prefab's native weapon, so it is simply wrong for a robot carrying its secondary. The loadout reads the real number from ProjectileManager.proj_info instead, which is indexed by projectile.

The native weapon is restored on retire

A robot is never left holding a mod-assigned weapon in game state that outlives this mod's involvement.

The brain replaces Robot.DoAIModes via a Harmony prefix. That hook point sits inside Robot.FixedUpdate after the game has refreshed the robot's transform, target distance, visibility and stun state, and before pathfinding and flocking run. Two things follow from that position:

• Everything the brain reads was freshly computed by the game a moment earlier, so there is no duplicated work and no disagreement between the mod's view of the world and the game's.
• Returning false skips only the mode dispatch. Pathfinding, flocking, teleporting, wind tunnels, stun handling and the death sequence all still run afterwards, because they live outside that method.

All movement routes through the game's own MoveTowardsPoint and AimTowardsPoint, which apply forces to the robot's rigidbody exactly as the stock AI does. The mod never bypasses the physics — it only decides where to push and where to look. Navigation between rooms is left entirely to the stock pathfinder, so locked doors, keyed segments and matcen routing behave as their designers intended. Firing is intercepted rather than reimplemented: the prefix decides whether a shot happens and adjusts spread and refire timing, then the game's own firing code does the work.