Ungodly Robot AI v1.3.0 · Overload

The short version of a long README

What actually changed

Stock Overload robots are individually competent and collectively simple. They know where you are at all times, they forget you the instant you break line of sight, they fight as independent units that happen to share a room, and they all shoot at once. This changes each of those.

Perception

Robots have to actually find you

A robot no longer queries your true position. It holds a belief about where you are, and that belief only updates through an event — it saw you, it heard your weapons, a squadmate radioed it, or you shot it. Everything downstream reads from that belief, which is what finally makes cover, silence and distance mean something.

Break line of sight and you are not forgotten; you are hunted. Robots move to your last known position, extrapolate the direction you were travelling, and fan out to check different corners rather than clumping into one searchable blob. Get far enough away and they give up and return — that distance is a setting.

Coordination

Groups behave like groups

Nearby robots share contacts, divide the angles around you between themselves, and take turns applying pressure. Each is given a job.

RoleBehaviour
AnchorHolds a firing line in front of you and keeps your attention
FlankerSwings wide to attack from your side or rear
HarasserDarts in, fires, withdraws before you can retaliate
SniperHolds maximum range and takes deliberate aimed shots
BlockerSits on your likely escape route instead of attacking head-on

Roles are assigned by distance rank, not at random — the robot already in your face makes a poor sniper, and a robot that suddenly turns and flies away to snipe looks broken. Roles are also committed for a number of seconds rather than re-rolled on every squad update, which is what stops a robot oscillating between approaching and standing off without ever completing either.

Aiming

Something you can play against

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:

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.

Pacing

A director that watches your state

Walk into a room at full armour and you steamroll it; walk into the same room at fifteen percent and it is an unavoidable death. Neither is interesting.

The director watches your actual state and nudges how many robots press an attack and how quickly pressure rebuilds after an exchange. It is a nudge, not a rubber band: it never makes robots miss on purpose and never grants you invulnerability. Everything it does is visible in the live status readout at the top of the panel, and it can be switched off entirely.

Abilities

Nine special moves, not granted to everyone

Each has a wind-up, a release and a recovery, on top of ordinary shooting.

AbilityWhat it does
VolleyFires a burst of shots in a spread instead of one aimed round
SuppressionSprays your last known position — needs no line of sight
ShockwaveDamaging pulse, strongest at point-blank, blocked by geometry
RepairRestores hull to itself or the worst-hurt squadmate in range
CloakTurns invisible for a few seconds to reposition or break your lock
DashBursts toward you to close, or away to disengage — never into a wall
RallyCalls nearby robots in and stiffens their resolve. No damage at all
OverchargeBriefly fires faster and straighter than normal
BulwarkHardens against incoming fire for a short window
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.
Three are withheld from melee robots
Abilities are classified by what they touch. Dash controls movement, and Volley and Suppression use a weapon — so on a Clawbot they would either fight its charge routine for the rigidbody or fire a gun it does not have. Those three are withheld automatically; the other six, being self-contained, are granted normally.
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.
Abilities and ordinary weapons run side by side
By default a robot only holds its normal fire during an ability's wind-up — a robot visibly charging something while also spraying its gun is not telegraphing anything — and resumes the instant the ability lands. AbilitySuppressesNormalFire lets you choose Never, so abilities are purely additional and robots shoot straight through their own wind-ups (more dangerous, much less readable), or ChargeAndRecovery, which makes an ability a bigger commitment and leaves the robot quiet and punishable afterwards.

Combat actions

Eight movement behaviours that compose

Actions are what a robot layers on top of wherever it is trying to be.

ActionWhat it does
StrafeSlides sideways around you while holding a firing position
WeaveJinks side to side while closing instead of flying straight
Vertical OrbitClimbs above or drops below you, off your horizontal plane
BackpedalRetreats to a comfortable range when you crowd it
Steady AimHolds still to shoot much straighter — and is much easier to hit
Break Line of SightDucks behind real cover when badly damaged
RepositionMoves to a fresh angle when its firing position has gone stale
RegroupFalls back toward a healthier squadmate when isolated

Actions do not move the robot themselves. Each contributes to a shared influence — a position offset, a speed scale, a turn scale, or a destination override — which the brain then sums and applies. That is what lets several run at once: a strafe and a weave compose into a spiral, instead of two systems fighting over the same rigidbody.

Loadouts

Two weapons, and a different way of fighting with each

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.

For other plugin authors

41 events you can subscribe to

Every meaningful thing a robot does raises an event.

33 per-brain events

Across seven groups — detection, combat, health, behaviour, movement, abilities, and weapons & actions. Every raise is guarded, because these fire once per robot per frame and an unguarded exception from a subscriber would fire sixty times a second per robot. A throwing subscriber is reported once and then ignored; the robot keeps thinking.

8 level-wide events

Static, on AIGlobalEvents — brain created and retired, any target detected, any robot death or damage, any ability invoked, player noise, level reset. Another olmod plugin can subscribe once at startup and never chase individual robot lifetimes. Subscribers are dropped when a brain retires, so a long-lived subscriber cannot keep a dead robot's whole object graph alive for the rest of the level.

Under the hood

Why a full replacement is safe here

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:

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.

Some robots are deliberately not driven

Replacing the mode dispatch is safe for a robot whose attack is a weapon, because firing lives elsewhere. It is not safe for one whose attack lives inside the movement routine itself. ApplyClawImpulse — the call that actually deals melee damage — sits inside DoModeClaw, and the same is true of DoModeGrind for Blade robots and ApplyDetonatorImpulse inside DoModeDetonator. Drive one of those with this brain and it loses its attack entirely.

They are classified as contact attackers — read from m_is_melee and AI_robot_detonator on the robot itself, so a custom or modified robot is judged by what it actually is rather than by a hardcoded list — and left with their own mode logic, exactly as bosses already were. They still get this mod's perception, evasion and aiming.

Getting unstuck is handed back to the base game

Destinations are no longer taken on faith. Every one is clamped to the last clear point along the way, and search and reposition points are sampled several times and scored on how far the robot can actually travel toward them — a geometric orbit position lands inside a corridor wall constantly, and a search point that was inside a wall used never to be reconsidered. A monitor then samples real displacement over a short window, so a robot that is being told to move and is not moving takes the nearest opening.

When that local recovery fails twice, the robot is handed back to Overload's own navigation for a couple of seconds. That is not a fallback for a broken feature — it is the right division of labour. The base game walks the level's segment graph and escalates to PATHFIND inside DoModeApproach, and it will route a robot out of a corner far more reliably than direct steering ever could. This mod is better at deciding what a robot should do; the base game is better at working out how to physically get there.