Reconstructing Autonomous Turrets (Part I): From Recovered Mechanics to a Playable UE5 Prototype

A turret detects a moving target, turns its barrel, and fires from the muzzle. Rebuilding that sequence means tracing target checks, barrel alignment, shot timing, and ammunition use, then identifying what handles damage or control status after contact.

Machine guns, mortars, lasers, and Tesla towers all attack autonomously, but their behavior requires more than a shared “wait for cooldown, then deal damage” loop. Automatic fire retains the remainder of its shot interval. Mortars process timed action events. Lasers preserve warm-up and heat-lock state. Tesla towers check eligibility again when an action finishes. The order in which these states update determines when an attack occurs.

This work continues the original prototype plan, the TPS camera and firing reconstruction, and the drone following, targeting, and attack reconstruction. This article follows the evidence from fixed-version configuration, offline decompilation, and bounded execution of original instructions to explain HD2’s autonomous attacks and the scene services added to run them. The follow-up covers Lyra equipment, deployment abilities, GAS damage, and lifecycle integration.

The fixed dataset identifies nine autonomous turret entities covered here: GPMG, ordinary and powered Gatling, rocket, flame, ordinary and static mortars, laser, and Tesla tower. The two Gatling variants share their principal projectile-stream mechanics, giving eight main attack mechanisms. These counts describe this investigation’s coverage, not a complete inventory across all game versions. Manned emplacements, tutorial objects, enemy turrets, and vehicle-mounted weapons are classified separately.

Video 1: The early mechanism prototype, approximately 107.967 seconds at 1920×1080 and 30 fps. The display cycles through the variants, with only the selected turret attacking. Models, targets, health display, and some scene services are validation adaptations. This build predates the later Lyra runtime backend. Individual clips are cuts from this same recording, not independent experiments. Video overlays remain in Chinese.

Identifying attack mechanics through entities and components

Searching resource names produces a mixed list: autonomous turrets, manned emplacements, tutorial objects, discoverable world objects, and names found only in icon or art paths. Names provide search leads; implementation coverage still needs individual confirmation. This investigation first locates entity keys in the fixed entity database, then follows component references to Behavior, weapon data, magazines, and attack payloads.

GPMG and Gatling turrets, for example, use the same ballistic payload family but differ in default firing rate, initial magazine state, and Behavior. Ordinary and powered Gatling variants share many component records while retaining differences in their behavior records. Projectile calculations can be reused; target selection, permission checks, and state exits must be checked against each variant’s behavior.

After reading configuration, the next step is to find the code that uses each field. Firing rate determines the attack interval. Magazine fields feed initialization and shot consumption. Launch nodes define payload origins, while Behavior decides when to request an attack. A static record saying “capacity 500” does not establish that 500 rounds are available at runtime. Executing the original Gatling constructor produced a count of 499, followed by the corresponding runtime magazine state. Ammunition figures in this article use that execution result.

Contents

• Identifying attack mechanics through entities and components
• Turning decompilation findings into reviewable evidence
• Separating muzzle geometry, traverse, and the request clock
• Ballistic execution: from configuration to firing and contact
• Flame: payload generation and fuel use have separate clocks
• Mortars: action requests, high-arc solutions, and fields
• Laser: warm-up and heat lock jointly control the beam
• Tesla: deciding whether to discharge or cancel after charging
• Improving observability also tests the implementation
• From observable mechanics to the runtime framework
• Variant video index
• AI collaboration retrospective

The mortar counts of 35 and 15 come from constructor execution. Whether chamber-inclusive totals should be 36/16 remains unresolved. The original flame capacity is also unconfirmed; the demo uses 80 fuel. Unknown source fields and demo defaults are recorded separately so their origins remain traceable during later integration.

Turning decompilation findings into reviewable evidence

This phase uses a fixed recovered DLL image from August 13, 2026, and a fixed BASE entity database. These differ from the August 19 copy used in later camera analysis. Their identities are retained in the internal source inventory; function addresses, constants, and execution results cannot be mixed simply because both builds date from August.

Unpacked configuration establishes identity and inputs. Decompilation locates reads, branches, and call order. Bounded execution of original instructions then checks return values, memory changes, and request records under controlled inputs. “Bounded” means the inputs and external dependencies are specified in advance: the test harness supplies some world queries, entity registration, and scene services. Results establish behavior under those conditions; the original game’s complete world has not been started.

Recovered pure C++ kernels are compared with these execution records. They preserve explicit mathematics and persistent state: attack clocks, angular limits, flight integration, action events crossed between ticks, temperature, and arc-branch history. External interfaces supply target candidates, UE collision results, and presentation.

Test results need a stated comparison: integer state, floating-point error, float32 bit patterns, and complete JSON files each require their own criterion. Repeating a test in independent processes checks reproducibility. It does not establish unexecuted branches, or turn a no-candidate return into proof of a complete attack path with valid targets.

The rocket damage investigation illustrates the distinction. An early query returned a damage parameter of 525. A controlled contact weight later produced 524.8984375. This path applies floor to the nonnegative result and then converts it to an unsigned integer, yielding 524. Enqueuing the response, consuming the queue, and reading Health are subsequent steps. Only after observing 2400→1876 can this controlled input be said to have changed actual HP.

That 524 is not a universal rocket damage value. Later Lyra area damage explicitly uses 600, with different inputs and a different resolution path. The former demonstrates a controlled original response chain; the latter validates UE area-damage integration. They are not an accuracy comparison.

Separating muzzle geometry, traverse, and the request clock

The minimal prototype consists of a cylindrical base, a rotating barrel, and a separate muzzle. This simple geometry makes target position, barrel direction, and launch origin easier to inspect independently. Early attacks spawned at the wrong position, visibly disconnecting projectiles from the barrel. Later revisions use the actual muzzle geometry for attacks and presentation, and record the origin error.

Traverse separates yaw and pitch. Recovered angular state is stored in radians, while configured speeds arrive in degrees per second and require conversion. Yaw first resolves free rotation or limits, then calculates the permitted step. Pitch speed also depends on yaw alignment. Interpolating the axes independently would lose that coupling.

In a readable mathematical form, the error weight grows with angular error and saturates:

w = clamp(abs(errorRadians) × degreesPerRadian × 0.2, 0, 1)
maxYawStep = w × yawSpeedDegrees × radiansPerDegree × multiplier × dt
yawDelta = clamp(resolvedYawError, -maxYawStep, maxYawStep)

Near the target angle, the weight decreases; larger errors reach the configured speed. Free yaw requires angle wrapping, while limited traverse first clamps the target. Bitwise comparisons still use the implementation that preserves original constants, floating-point order, and boundary branches. These equations explain the weighting.

After yaw updates, the function returns an alignment factor. The pitch-speed limit is multiplied by that factor, so the barrel may elevate more slowly while yaw remains misaligned. Being a registered candidate, being tracked by a moving barrel, and being eligible for firing are separate stages.

The prototype gets target health, range, occlusion, and candidates from UE adaptations. Parts of original Behavior scoring, scanning, and state handling have bounded-execution evidence, but the prototype’s entire selection process is not a recovered original AI system. Resource and action permission must still pass before firing changes the counters.

The validation scene therefore lets one turret attack at a time. Several turrets firing at their own targets can reduce HP without making target retention, traverse, or reselection easy to judge. Shared moving targets and a single active turret expose those relationships. This display arrangement does not limit the eventual game to one deployed turret.

Ballistic execution: from configuration to firing and contact

From initialization parameters to per-shot state

For GPMG, capacity and firing rate are read during initialization. The instance then retains remaining ammunition, timer remainder, and projectile-cycle phase. The later Lyra integration calls the same recovered kernels, with UE scene services supplying eligibility and world queries. The table follows the current C++ call path; its interface names belong to the port, not the original field vocabulary.

For example, GPMG selects type 148 when pre-commit ShotCount=4. Once a flight entry is created, the count becomes 5, ammunition decreases by one, and the interval is added back to the clock. The next attack then selects 240 using the count of 5 and solves pitch with its launch speed. If eligibility fails, the count stays at 4; an attempted request does not advance the type cycle.

Resupply increases Ammo while preserving ShotCount, timer remainder, and existing Flights. Creating a new instance establishes fresh state. Implementing resupply by reloading all defaults would alter projectile phase and could remove projectiles already in flight.

Retaining interval remainder and projectile-cycle phase

GPMG’s 630 RPM gives 10.5 rounds per second and a nominal interval of 60/630≈0.095238 seconds. Gatling’s 1600 RPM gives approximately 26.667 rounds per second and a 0.0375-second interval. These rates determine uninterrupted firing intervals. Death, traverse, occlusion, and eligibility changes interrupt attacks, so footage totals also depend on actual eligible firing time.

The recovered automatic-fire clock first subtracts the current step. When eligibility holds and the timer is nonpositive, firing is due. An accepted shot adds the interval to the existing timer, preserving negative remainder rather than resetting a full interval after every shot.

timer = timer - dt
due = ready && timer <= 0

After accepting one shot:
    timer = timer + interval

When ineligible to attack:
    if timer <= 0, set timer = 0

Suppose a step starts with timer=0.005 seconds and dt≈0.016667 seconds. Subtraction gives −0.011667 seconds. Accepting a shot and adding the GPMG interval produces approximately 0.083571 seconds. Resetting directly to 0.095238 would add approximately 0.011667 seconds of waiting. Repeatedly discarding this remainder changes the firing sequence.

Clearing negative remainder while ineligible prevents a long pause from accumulating an unlimited backlog of shots. When eligibility returns, execution proceeds from the current timer and resource state. Rejected requests consume no ammunition. Accepted firing decrements resources and increments the shot counter.

The projectile cycle has an initial phase too. GPMG starts at ShotCount=0 and selects 240 when the pre-fire count satisfies % 5 == 0, otherwise 148. Its opening sequence is 240, 148, 148, 148, 148, 240, …. This count is evaluated before committing the shot; it is not a one-based projectile number. Ordinary and powered Gatling use % 5 == 1, opening with 148, 240, 148, 148, 148, 148, 240, …. Changing the initial count or condition changes the sequence even with the same projectile types.

Both Gatling variants retain the same nominal rate. The powered variant also takes an explicit permission input: without power it neither fires nor consumes ammunition. The ordinary variant is unaffected by that input. The original flag’s complete upstream meaning remains unconfirmed. UE supplies the permission for the recovered branch; its prototype switch is not a recovered original power system.

Flight, collision queries, and visible projectiles

The flight kernel preserves position and velocity and calculates gravity and drag in meters and seconds. UE uses centimeters, and the port also swaps horizontal axes. Conversion must cover origin, direction, and velocity together. Converting position while retaining centimeter-per-second velocity would introduce an order-of-magnitude error.

For one mathematical step, let k be the gravity multiplier, c the drag field, and m the mass field:

aGravity = (0, 0, -9.82 × k)
aDrag = -normalize(v) × (dot(v, v) × c / m)
a = aGravity + aDrag

pNext = p + (v + 0.5 × a × dt) × dt
vNext = v + a × dt

The implementation also retains small-speed checks, drag-enable branches, and excessive-acceleration safeguards. It performs the covered numerical integration, not spawning, collision, lifecycle, or damage. The dot-product notation here does not replace the original scalar arithmetic’s rounding order.

UE builds a collision query from the previous and next positions and the current step’s velocity. The integration builds the query segment from displacement length and the updated velocity direction, then passes the result to hit handling. Its endpoint therefore need not equal pNext. Display size, tracer length, and query geometry are separate. Making the rendered projectile thicker does not enlarge its physical radius.

Rockets also have launch nodes. The fixed data contains 16, and firing chooses an origin in node order. Local node coordinates must transform with the turret’s orientation; rockets cannot all spawn from the base center. The prototype compares actual tube endpoints with payload origins to check execution and presentation alignment.

Recovered rocket speed is 100 m/s, with gravity multiplier 0.1 and mass-field value 6. Mortars use the same initial speed but gravity multiplier 6, mass 70 in the meter-based port, and drag. Equal launch speed does not imply equal trajectory. Damage and blast radius retain separate provenance: later Lyra rockets use a 4.5-meter radius and 600 damage as UE configuration, not recovered source values.

Area resolution deduplicates targets within each explosion. One contact may affect several targets; several collision shapes belonging to one target must not cause repeated damage. The current area path also checks eligibility and occlusion and does not add a separate direct-hit damage event. Firing, contact, and actual damage are counted independently.

Flame: payload generation and fuel use have separate clocks

Continuous flame comes from payloads that are repeatedly generated, move, and expire. Each has its own initial velocity, age, and lifetime. The turret retains the current emission age, random state, and fuel. Existing payloads continue their own flight and contact after emission stops; hiding the stream does not end those calculations.

The recovered first emitter includes local velocity, curves, random-number calls, damping, and lifetime calculations. Its initial speed ranges from 33–50 m/s. Local vectors transform through the muzzle’s right, forward, and up basis into world space. Random call order affects speed and lifetime, so equal seeds alone do not establish equal particle sequences.

Fuel is not consumed once per visible particle. The recovered condition recognizes first emission, then checks whether emission age crosses a 0.125-second boundary:

fuelDue = firstEmission
          || fmod(age, 0.125) < fmod(float(age - dt), 0.125)

Both age and dt are stored as float. On the left, age is promoted to double before fmod. On the right, age−dt is evaluated as float, then promoted to double. The 0.125 constant is double, so both calls use double remainder calculation. Numerical comparisons must retain that float-subtraction rounding point. Stopping resets the current emission age; restarting consumes fuel on first emission again. A fixed “eight fuel units per second” model therefore misses start/stop behavior.

Original capacity remains unconfirmed; the demo uses 80 fuel. The later Lyra adaptation schedules 120 payload births per second and configures contact damage separately. Generation rate, fuel-consumption rate, contacts, and damage events are distinct measurements, not interchangeable definitions of flame “firing rate.”

Early particles were difficult to see at distance. Later revisions improve display visibility while retaining actual contact points. Display size does not expand the recovered effect range. The flame is not original VFX; complete burning, material interaction, and damage-over-time services remain outside this phase.

Mortars: action requests, high-arc solutions, and fields

Action events and the next-cycle gate

The ordinary mortar does not emit shells at a uniform sustained rate. Its recovered action requests one shot at ticks 120, 180, 240, and 300, then ends at tick 301. The static action requests once and ends at tick 120. At 60 ticks per second, ordinary requests occur approximately 2, 3, 4, and 5 seconds into the action.

Action advancement processes each event crossed between the previous and current time. If one update crosses two event points, both callbacks need checking in order; testing whether the current time exactly equals an integer misses them. Actual firing also checks pause, action completion, and ammunition. An active action does not guarantee a shell is emitted.

firstTick = floor(timeBefore × 60) + 1
lastTick  = floor(timeAfter × 60)
Process each crossed action event in [firstTick, lastTick].

The next cycle has its own gate: 8 seconds for ordinary and 6 for static. Action completion still leaves the cycle condition to satisfy. Once due, ammunition, target, and action-idle conditions must also pass. Treating “four shots one second apart” as sustained 60 RPM would discard the gap between groups.

An ideal trajectory without drag provides a starting point for the high-arc solver. Given horizontal distance r, height difference z, launch speed v, and downward gravity magnitude g:

D = v^4 - g × (g × r^2 + 2 × z × v^2)
tan(thetaLow)  = (v^2 - sqrt(D)) / (g × r)
tan(thetaHigh) = (v^2 + sqrt(D)) / (g × r)

These equations explain the two initial solutions, assuming nonzero horizontal distance and a nonnegative discriminant. The recovered solver also handles failure fallback, initial angular bounds, drag simulation, and iterative correction. The ideal equations cannot replace that implementation.

The solver uses flight time divided by 100 as its simulation step, with at most 125 steps per pass. Quality level controls outer iterations. Samples crossing target height or distance then correct the angle. The mortar configuration also affects a low-speed early-return branch; using ordinary projectile flags initially could terminate the solver incorrectly. Reproduction requires those branches and position-update order.

UE additionally iterates to correct for muzzle offset from the rotation pivot and limits elevation in the validation scene. These are scene adaptations separate from the recovered solver. The full-arc view uses actual flight samples for a short trail; the later version retains up to 0.4 seconds of history. A camera-distance-dependent minimum display size does not alter collision or impact timing.

Ordinary mortar contact produces area damage. Static contact instead waits 0.5 seconds before creating a field lasting 7 seconds. The target retains control status, while the field retains position and effect time. When the field expires it stops applying effects; previously applied target status continues until its own remaining duration ends.

The recovered Static38 kernel accumulates positive application rate, activates at the test harness’s threshold, and refreshes remaining duration under continued application. It also has separate decay and expiry. Threshold 1, randomness 0, and multiplier 1 are test inputs, not every enemy’s original configuration. Application rate also depends on distance and target radius. Range, accumulation threshold, and status duration all require calculation; objects inside a circle cannot simply be assigned a permanent stop.

The static variant stops movement and later permits recovery rather than reducing health. Later independent Lyra tests record firing and status activation with zero HP damage. Explosion and control-field attacks can share high-arc flight while retaining separate post-impact handling.

Laser: warm-up and heat lock jointly control the beam

The laser has no finite magazine consumed per shot, but it retains attack-resource state. Warm-up q must reach 100 before continuous-beam eligibility. In the currently recovered path, temperature T reaching 250 establishes heat lock; the confirmed explicit replacement interface can clear it. Temperature, target availability, and beam visibility require separate state.

The recovered warm-up function adds 200/s while active and subtracts 500/s while inactive. Temperature reads the current warm-up: at 100 it rises by 8/s; only at zero warm-up and without heat lock does it cool by 5/s times the applicable multiplier. Other conditions preserve temperature.

qActiveNext   = min(q + 200 × dt, 100)
qInactiveNext = max(q - 500 × dt, 0)

q >= 100:                   TNext = min(T + 8 × dt, 250)
q == 0 and not heat-locked:  TNext = max(T - 5 × multiplier × dt, 0)
Otherwise:                  TNext = T

Approximately 0.5 seconds is the nominal warm-up time under continuous activation. First actual illumination also depends on fixed steps and update order. The current adaptation updates temperature and heat lock using old warm-up, then updates warm-up. Beam eligibility also reads the old value. Updating everything first and then testing would change boundary steps.

Heat lock persists when the target disappears on the next step. Explicit replacement resets temperature and clears the lock; it does not reset every state field. Original resource services and upstream operations remain incomplete. Triggering replacement in a demo is not a recovered full original reload lifecycle.

Continuous damage is resolved over actual valid illumination time. The later Lyra setting is 600 DPS, submitting the corresponding amount per valid 1/60-second step. Ineligibility, occlusion, or heat lock stops valid illumination accumulation. Short clips show warm-up and tracking; independent long runs check overheating and replacement.

Tesla: deciding whether to discharge or cancel after charging

The fixed data gives the Tesla tower a separate structure without the Turret component used by ordinary turrets. The prototype preserves that difference and adds no barrel traverse. Its cadence depends on candidate eligibility, scan deadlines, charge actions, discharge or cancellation actions, and recovery state.

Under the validated inputs and update order, the action updates before Behavior. Search begins charging when eligibility and the scan deadline allow it. Once charging finishes, eligibility must be checked again at the appropriate scan time. An eligible target starts discharge; lost eligibility starts cancellation. Discharge completion returns to search.

Charging completes at tick 91; discharge/cancellation completes at tick 15. Float action clocks, scan gates, and state transitions all contribute. Under continuously valid eligibility, the observed cycle is approximately 122 fixed steps, or 2.0333 seconds. This is a result for the stated inputs and ordering, not a universal two-second Timer.

Random call order must persist across steps too. In the recovered path, even a zero-amplitude sample advances the LCG. Removing a call that appears numerically irrelevant changes later random values. The port maintains local random state for covered calls; the original complete world’s shared random stream is not integrated.

Visible arcs follow actual flight and contact. The first query creates a flight node for an eligible target. Only after contact does it query subsequent candidates. Each hop rechecks health, team, range, direction, and occlusion rather than drawing a tree first and damaging every node afterward.

Recovered arc nodes preserve depth, extra chain budget, previous target, and parent-local history. Accepting a child adds it to its parent’s history to avoid selecting it twice in that query. A new child retains its source target and starts its own history empty. A global set of every target visited by the attack imposes stronger exclusions and changes reachable branches.

This Tesla configuration uses a 20-meter initial range, chain budget 2, and subsequent split 2. Initial and later fan-out differ; every node does not immediately split in two. UE supplies candidate ordering and physical queries. The recovered kernel handles confirmed budget, local-history, and numerical rules.

Video 2: A 9-second Tesla branching test with five deliberately arranged moving targets. Same-run records contain four discharges and twelve actual hits, including eight child-arc hits and four dual-branch queries. It belongs to the early mechanism build and does not replace the later Lyra build’s independent acceptance tests.

Branching may not occur during the overview’s Tesla segment, so this dedicated clip is retained. Arcs are brief and periodic screenshots can miss them. Video and per-hop records together establish whether child arcs, contacts, and damage actually occurred.

Improving observability also tests the implementation

Early simultaneous firing made traverse difficult to inspect, so the scene began cycling through the active turret variants. Uneven enemy motion also made tracking errors hard to separate from target-update problems. Later revisions preserve continuous movement curves while treating death waits and static control as legitimate stopped states. Spawned and respawned targets must occupy the current curve position on their first frame rather than jumping there one frame later.

These changes address execution, presentation, and scene orchestration separately. Muzzle origins and firing state affect execution. Thicker visible projectiles, floor adjustments, and full-trajectory cameras help observation. Respawning and variant switching belong to the test scene. Calling all of them recovered algorithms would obscure their origins.

Video 3: A 12-second ordinary-mortar segment showing elevation, grouped firing, and high-arc attacks. It comes from the early lineup overview, not an independent run of the later Lyra backend. A full-arc view and longer segments appear in the next phase.

Separate panels read variant, cadence, ammunition or fuel, heat, target HP, and control status directly from runtime state. Together with the logs, they show whether depletion stops firing, target death triggers reselection, and heat lock persists. Shot totals come from recorded events, not estimates based on demo duration.

The mortar’s distant view has another limitation: fitting the full trajectory shrinks ground targets and impact points. Close views explain state; distant footage shows the complete arc. Camera adjustments retain flight time, speed, and gravity. Short trails from actual flight samples aid visibility but remain presentation adaptations.

From observable mechanics to the runtime framework

This phase delivers an observable UE prototype of autonomous turret mechanics. Recovered kernels provide checked numerical calculations and state. UE supplies candidates, collision, and placeholder presentation; the test scene supplies movement and respawning. Complete original Behavior, World perception, shared randomness, all resistances, and original VFX/SFX remain unrecovered. Manned turrets are outside this scope.

Later Lyra work connects equipment grants, deployment abilities, independent world turrets, actual GAS damage, and HealthComponent death handling. The follow-up explains that integration. The two batches of footage use different builds; their shared R16 label does not allow numerical results or test counts to be combined.

The next article explains how configuration enters data assets, whether equipment and deployed turrets share a lifecycle, how contact creates GameplayEffects, what recall does to attacks in flight, and why correct Owner assignment does not establish player kill rewards. Normal deployment flow in the main project, networking, and packaging still require separate acceptance tests.

Variant video index

These clips are all cuts from this article’s lineup recording. The index supports mechanism-specific viewing without embedding every clip again. All are actual UE footage at 1080p and 30 fps, with no audio. Encoding specifications do not establish real-time performance. Original video overlays are retained.

AI collaboration retrospective

AI assisted with resource relationships, decompiled paths, bounded execution, pure C++ ports, and UE prototype iteration. Human review identified observation problems that affected conclusions: attacks starting away from the muzzle, simultaneous firing, hard-to-see projectiles, discontinuous target movement, and screenshots missing short arcs. Fixes addressed launch geometry, scene orchestration, display visibility, and sampling time rather than altering recovered parameters to hide problems.

Analysis also initially conflated generating damage parameters, consuming the response queue, and reducing health. Later checks followed target registration, response dispatch, and final Health readings separately. Later integration can use these records to identify reusable results and remaining tests. Each local conclusion retains its specified inputs and execution scope.