Reconstructing Weapon Systems (2): Rebuilding Drone Following, Target Selection, and Attacks from the Original Mechanics

The player moves and the drone follows. An enemy enters range and the drone turns to fire. When ammunition runs out, it returns to the backpack for resupply. The loop is easy to recognize on screen, but its implementation spans several kinds of state: the backpack maintains attachment and supply relationships, the flying entity updates its position, the weapon decides whether it can fire, and target selection responds to death, occlusion, and status changes.

PVE Shooter Prototype—An Empirical Test of an AI-Assisted Development Pipeline sets out the project goals and framework choices. This article continues the autonomous-weapon work, examining configuration, mechanics, and UE integration for six drone variants. The previous article, Reconstructing Weapon Systems (1): Rebuilding TPS Cameras, Reticles, and Firing from the Original Mechanics, covers player-held weapons. This article follows drones through configuration, flight, target selection, firing, and resupply. The current work is validated in a standalone UE5.7 Lyra prototype and still awaits integration into the project version.

The prototype supports laser, assault-rifle, machine-gun, flame, gas, and arc drones. This article includes two compilation videos and six individual clips labeled Variant Videos A–F. The discussion distinguishes original configuration and calculations, UE scene adaptations, and test-arena settings. It follows configuration through following, approach, selection, and firing, then checks empty-ammo return and resupply against one rifle run. Each variant can complete its demonstrated sequence; this does not establish recovery of the original game’s full navigation, animation, effects, or damage systems.

Video 1: TPS demonstrations of all six variants, assembled from separate runs. Native 1920×1080, 30 fps, at original speed throughout. Finite-ammunition variants retain depletion, return, resupply, and a second attack; laser and arc show attacks and following after no live enemies remain. Encoding frame-by-frame renders does not constitute a real-time performance test.

Contents

• 1. Backpack, Flying Entity, and Mounted Weapon
• 2. Constructing and Updating the Follow Point
• 3. Following and Approaching Use Different Spatial Goals
• 4. Target Selection Needs Eligibility, Scores, and Persistent State
• 5. Obstacle Avoidance and Firing Positions Require Separate Checks
• 6. Firing Algorithms for Six Variants
• 7. Connecting Return, Docking, and Reload
• 8. What Videos and Logs Validate
• Relationship to the Prototype Plan and Previous Article
• AI Collaboration Retrospective

1. Backpack, Flying Entity, and Mounted Weapon

The backpack, flying entity, and mounted weapon jointly drive the drone on screen. Each manages a different part of its configuration and runtime state.

The backpack associates with the wielder and provides a docking point and supply context. The flying entity retains position, velocity, target, and behavior state. The mounted weapon retains firing cadence, ammunition or fuel, random state, and in-flight projectiles or particles. Switching variants resets the relevant state in the test panel. Ordinary firing, release, or brief occlusion must not use the same reset logic.

One parent behavior can serve different weapons. Laser and arc drones use the same parent-behavior family, while their firing backends produce a continuous beam and propagating arc segments respectively. Rifle and machine-gun drones share another parent-behavior family but differ in rate of fire, capacity, spread, and muzzle velocity. Flame and gas retain their own approach and eligibility branches; changing particle color alone would not reproduce them.

Capacity and firing-rate values take their meaning from the calculations that consume them. “Experimental heat cycle disabled” describes this formal laser recording only; the original mechanism still includes heat processing.

Resource identities and override relationships are checked before configuration enters runtime. The parent resource specifies behavior and the child resource specifies the weapon. Original defaults and runtime modifiers are recorded separately. The parameters here cover the bounded configurations that have been checked, without extending the conclusions to every upgrade or equipment modifier.

A candidate, an attack request, a weapon passing its checks, a spawned projectile, and a collision are different results within an update. An “attacking” panel label does not replace hit verification. A rising hit count does not establish that damage, burning, or gas status effects are connected. The videos and validation table use these stages to describe their scope.

Tracing Rifle Configuration into Runtime

Selecting the rifle makes the current UE prototype retrieve the prepared parent-behavior and child-weapon configurations by variant index. The parent behavior supplies candidate, entry, and exit rules. The child weapon supplies projectile type, capacity, firing rate, and muzzle velocity; spread widths come from separate spread data. The current implementation uses prepared C++ configuration. It does not reparse the original resources on every shot or implement the full original resource loader.

Reading configuration and initializing state are separate operations. The rifle’s runtime capacity of thirty combines the original twenty-nine magazine rounds with chamber state; the raw magazine field itself is not thirty. Initialization writes this total into remaining ammunition. Each shot then decreases runtime ammunition, leaving capacity unchanged. The machine gun similarly combines forty-four magazine rounds with chamber state to produce a runtime total of forty-five. Spare magazines start at six and decrease during resupply; reading configuration again must not restore them to six.

A variant reset also clears particles, arcs, timers, and some adaptation history for that test instance, and initializes the indexed random seed to one. This seed is a repeatable UE test input, not evidence that original random-state ownership has been recovered. Ordinary consecutive shots do not reset it; otherwise every shot would reuse the first samples in the sequence.

The firing clock retains its remainder. The current weapon step subtracts the fixed timestep from its timer. If eligible and due, a call creates at most one bullet and adds the interval back to the timer. When ineligible, a negative timer is brought back to zero so time spent not firing does not accumulate into a burst of catch-up shots. This differs both from assigning a full interval after every shot and from a while loop that emits every overdue event. This is the firing-clock update used by the current UE backend. Its validation does not cover the complete original caller schedule.

Checking whether 640 RPM takes effect requires tracing the selected backend, request validity, timer, continued random state, and projectile integration and collision. The panel value represents only the configuration input.

How One UE Update Connects the Objects

The current integration first processes motion goals and displacement from existing flight state, then checks candidates and attack conditions using the updated position, updates body rotation, and finally enters the weapon backend. This is the order at the current UE call sites, not a universal update order for the original engine’s complete World.

Order affects when inputs become available. If scanning changes the target this step, the earlier motion phase has already used the old target or follow point. The new approach position affects flight in a later update. State transitions also retain the branch selected at the beginning of the step: entering a lock state from following does not execute the entire lock, attack, and exit sequence in that same step.

The orientation displayed at the end of a step may differ from the orientation used for that step’s attack eligibility. Eligibility is calculated before body rotation, so completing a turn does not guarantee that eligibility has been recalculated with the new orientation. The weapon backend also checks the corridor and target validity, but those checks do not replace all orientation conditions. Debugging should retain both the checked orientation and the final displayed orientation; an aligned screenshot alone cannot establish permission to fire in the same step.

The player-held weapons in the previous article are driven by input, camera targets, and Ability submission. Drones use autonomous candidates, behavior state, and persistent weapon objects. Ballistics and spread can share mathematical modules, while target sources, random-state ownership, and firing eligibility still need separate connections.

2. Constructing and Updating the Follow Point

Building the Target from the View Basis

In early footage, some drones mainly rose and fell above the player, with little horizontal movement. The target construction used player position plus height, omitting the horizontal terms in the normal-view branch. The error was in the target input; increasing flight speed could not correct it.

The recovered follow target includes player position, view-right and view-forward directions, and height:

Pfollow = Powner + side × Right + 1 m × Forward + height × Up

This expression describes the corresponding recovered branch. Its forward term is one meter; it is not generalized to all poses and flight states. One normal branch uses a side offset of approximately 2.5 m and height of 2.9 m; another pose branch uses approximately 1.5 m and 2.6 m, with a condition that adds another meter of height. Shoulder side changes the lateral sign. The branches remain distinct; their specific character-action meanings have not been confirmed.

Turning the view changes Right and Forward. Even when the player stands still, the follow point can move around them. Distance to the player alone cannot establish correct following; the target point and actual flight position need to be displayed together.

For this validation, the default follow height is overridden to 1.5 m above the player Actor origin. This is a declared UE display setting, not the original default. The Actor origin is not automatically the feet; changing the reference point changes where the same height appears on screen.

Updating the Goal, Speed, and Position Separately

The follow point is a motion goal. The entity still computes speed from distance. The recovered branch slows within two meters and returns zero speed inside an arrival threshold of approximately six centimeters:

For d ≤ 2 m: speed = ((d − 0.05) / 1.95) × 6
For d > 2 m: speed = 6
For d ≤ 0.06 m: speed = 0

These relations describe the scalar output of the corresponding follow call. Return flight has a separate speed curve, and spray approach has its own handling. Six meters per second is not a constant for every state.

At an illustrative distance of one meter, follow speed is approximately 2.923 m/s; at two meters, it is 6 m/s. The stop condition truncates the linear expression near six centimeters. The port must preserve the comparisons rather than extrapolating negative values into reverse flight.

The UE adaptation additionally smooths the follow offset and limits acceleration and deceleration. It smooths the offset relative to the player, rather than the player’s world position:

Offset = Pfollow − Powner
alpha = 1 − exp(−dt / τ)
OffsetNext = OffsetOld + alpha × (Offset − OffsetOld)
Goal = Powner + OffsetNext

The follow offset currently uses τ=0.12 s, while approach-goal smoothing uses 0.18 s. Player translation therefore reaches the goal immediately, while offset changes caused by view rotation transition gradually. Both are UE engineering choices. Their improved response does not establish bitwise equality with the original motion trajectory.

Retaining Angular Velocity Before Computing the Turn

Turning also has persistent state. Recovered mode 6 uses a rate parameter of approximately 360°/s and acceleration/deceleration of approximately 150°/s². The former describes a target rate range; the latter controls its change over time. Neither means “turn 360° per frame,” and a single rotation-interpolation coefficient cannot replace them.

The calculation first obtains and wraps the error between desired and current horizontal angles. If existing angular velocity would cross the remaining angle in this step, or the braking condition requires earlier deceleration, it takes the deceleration branch. The ordinary acceleration branch limits angular-velocity change and, near the target, limits desired rate to prevent overshoot.

Ordinary acceleration branch:
  ωdesired = sign(error) × rate
  Limit ωdesired when needed to avoid crossing the remaining angle this step
  ωnext = ω + clamp(ωdesired − ω, −accel × dt, accel × dt)
  turnStep = gain × ωnext × dt
  Finally clamp turnStep to the remaining angle

The expression covers ordinary acceleration. The full function also includes conditional overrides and deceleration. The deceleration branch orders the current output and subsequent angular-velocity update differently. Replacing both branches with one Lerp would change the result.

With zero initial angular velocity, a sufficiently large error, gain=1, and dt=1/60 s, the first step raises angular velocity to approximately 2.5°/s and turns approximately 0.04167°. This illustrates the buildup of angular velocity, not the full tracking time for a moving target.

For a teaching input that changes the desired heading to 90°, with initial heading and angular velocity both zero, the first twelve steps remain in ordinary acceleration at dt=1/60 s and gain=1. Retaining state gives the following values, converted to degrees and rounded for display:

The 3.25° at step twelve accumulates all preceding steps; it cannot be replaced by final angular velocity multiplied by total time. Subsequent acceleration depends on remaining error and braking conditions, so the table cannot be extrapolated linearly to alignment. Follow-offset smoothing, body angular velocity, and muzzle pitch have separate inputs. Slow turning on screen needs to be investigated at each layer.

This teaching calculation uses the inspected code and a specified initial state. It neither calls the original function nor samples UE footage. Agreement with the original mechanism is checked in separate bounded-input comparisons; the teaching table is not counted as validation cases.

Flight direction is handled separately. The relevant function constructs orientation from current velocity and desired orientation from the vector to the motion goal, blends directions, and multiplies by scalar speed. Replacing that chain with linear position interpolation changes the trajectory even if the endpoints agree. Its current blend input is approximately 0.9; that is not a 0.9-second arrival time.

Body yaw, velocity direction, and muzzle direction therefore need separate records. The muzzle-pitch fix supplies an explicit UE pose input without changing mode 6’s horizontal turning rules. Relaxing the firing-angle threshold would change attack eligibility and conceal the missing muzzle-pitch input.

3. Following and Approaching Use Different Spatial Goals

Flame and gas drones need to approach enemies rather than remain beside the player’s shoulder until a target comes close. Their branch selects an attack position along the horizontal line from enemy to player, while also calculating height.

Let T be the enemy position, O the player position, Dxy the horizontal distance, and R the positioning radius for the classification:

k = R / Dxy
Gx = Tx + (Ox − Tx) × k
Gy = Ty + (Oy − Ty) × k
Gz = Tz + (Oz − Tz) × k + height

This expression applies with valid scene inputs and a sufficiently large horizontal distance. Near-zero distance or unavailable scene inputs take guarded branches rather than dividing by zero.

An unknown classification uses a three-meter radius; other recovered classifications use four, eight, or twelve meters. Classification comes from the target query, not the weapon-variant selector. The spherical test targets lack full original classification. The twelve-meter example explains positioning geometry, not enemy size.

Height contributes separately. Three meters specifies the horizontal radius, not a three-dimensional spherical distance. Z also includes the player–enemy height difference and an added height of approximately 2.5 m by default. If player and enemy are level in a teaching example, the position lies three meters toward the player and 2.5 m above the enemy. Actual flight distance is measured from the current drone position to that goal.

After a position is generated, spraying still depends on drone-to-enemy distance, orientation, and corridor checks. A target within fifteen meters may fail the angle test, while an aligned drone may still be blocked by an obstacle. Checking these conditions separately helps locate input errors.

An earlier version sprayed once and stopped. Body yaw was being used as the actual muzzle direction without pitch, and the subsequent angular check blocked further emission. The UE fix supplies explicit muzzle-pitch adaptation while retaining the original distance and angle conditions. The fix supplies the required pose input. Original weapon animation remains absent, and the placeholder drone is not used to validate the original muzzle pose.

4. Target Selection Needs Eligibility, Scores, and Persistent State

Multiplying Candidate Weights

Distance is only one input to target selection. The recovered calculation includes angle, distance, relation to the current target, classification queries, and scene-eligibility inputs. The complete gameplay meaning of some fields remains unconfirmed. The discussion uses their verified computational roles without assigning them to specific enemy types.

In the corresponding ordinary candidate branch, angular weights at 0°, 45°, and 180° are 1, 0.8, and 0.6, with interpolation along the recovered curve. Distance weights at five, ten, thirty, and forty meters are 1, 0.9, 0.8, and 0.6. Weights and eligibility factors form the score:

Score = Eligibility × AngleWeight × DistanceWeight
        × CurrentTargetWeight × ClassificationFactors × HelperFactors

The expression summarizes the factors. The full implementation retains multiplication order, guarded branches, and helper-query results; the expression alone is insufficient to recreate the entire procedure. An identical final product does not establish that upstream queries used identical data.

The current-target weight can encourage continuity in the ordinary branch. The subsequent UE stabilization policy has a separate hold time and switching threshold; together they cannot be called an original “lock-on duration.” Distance weighting and firing range also serve different purposes. A positive candidate score does not mean that firing-distance conditions pass now.

The spray branch uses another set of owner-distance curves: one within five meters, decreasing to 0.7 at twenty meters and zero at twenty-one. An exit-related curve rises from zero to one between twenty-one and twenty-two meters. Candidate suppression and an exit request are different conditions; neither means immediate docking beyond twenty-one meters.

Firing Eligibility Depends on Range, Angle, and Classification

Thirty meters in the configuration is not a self-contained attack range. The rifle/machine-gun branch first requires an angle no greater than ten degrees within five meters, or no greater than four degrees within thirty meters. It then applies finer conditions based on a classification query.

The current validation adapter supplies a true classification-query result for bullets. Its finer condition permits angles within five degrees, or within fifteen degrees at distances up to ten meters. The final result is the intersection of both layers. For example, twelve meters at three degrees passes these numerical checks; twelve meters at six degrees fails the base condition. Four meters at eight degrees passes the near-distance branch with this classification input. Other classification inputs impose stricter conditions, so these three examples do not cover every enemy type.

Distance is measured from the drone’s current position to the target. Player-to-target distance and maximum projectile travel are separate quantities. Comparisons use squared distance after unit conversion: fifteen meters corresponds to 225 m² and thirty meters to 900 m². Reading a squared-distance field as meters would expand the range incorrectly.

These examples check only distance, angle, and a given classification input. Death, occlusion, depleted fuel, or a firing timer that is not due can still prevent emission. The six-to-nine-meter target placements in the footage are arena settings for observing behavior, not original weapon ranges.

Comparing Scores and Switching Between Two Candidates

The following teaching inputs use the ordinary bullet-drone candidate branch to isolate angle, distance, and current-target weighting. A is the current target and B is a new candidate. Other eligibility and curve factors are set to one, with no exclusions. The two classification-permission inputs are true, downweighting and exclusion inputs are false, and both helper-angle inputs are 180°. These are specified teaching inputs, not samples of a real enemy’s complete state.

B stays at six meters with a scoring angle of zero. Its angular weight is one and distance weight 0.98. As a new candidate, its current-target relationship weight is 0.7:

ScoreB = 1 × 0.98 × 0.7 = 0.686

In the first case, A is twelve meters away at a scoring angle of thirty degrees. Angular weight is approximately 0.866667, distance weight 0.89, and current-target weight one:

ScoreA = 0.866667 × 0.89 × 1 ≈ 0.771333

Although B is closer, it scores below A. Selection therefore retains A even without additional UE stabilization. Changing A’s angle and distance in the second case gives B a small lead; this is where original candidate selection and UE stabilization need to be distinguished.

The third case still requires A to be alive, visible, positively scored, and eligible under the retention policy’s distance and status checks, with the forty-five-step hold period elapsed. This implementation explicitly supplies zero angle to the retention-eligibility check so it tests range and status only. Actual firing angle is evaluated separately by behavior. The third case explains switching; it does not authorize firing at 175°.

If A dies, is hidden, or loses eligibility, selection bypasses this retention comparison and uses the rescan result. If any of B’s eligibility factors is zero, its product is zero despite the shorter distance. The example’s 0.686 is not a fixed priority. These are three independently constructed inputs, not three measurements from one video.

Gas Status Filtering Does Not Apply Universally to Flame

The recovered gas branch reads statuses 42 and 43 during entry, candidate calculation, and exit. Active status affects eligibility or weight. Flame does not have the same complete exclusion rules, so one timed target-switch function cannot replace both variants.

The UE adaptation supplies these inputs through explicit tags and has been tested with explicit status conditions. Hits in the formal footage do not thereby implement the original status application, persistence, and expiry. The natural production of these statuses remains incomplete, and their gameplay meaning is unconfirmed. The IDs are retained without labeling them poison, confusion, or immunity.

Health is connected as arena feedback. At zero health, a target turns gray, stops moving, and leaves collision and selection. Death of the current target triggers a scan in the current step without waiting for the previously scheduled scan. The gray sphere remains visible to show the state change, not because it remains hittable.

Keeping UE Retention Separate from Original Scores

UE adds a retention policy to reduce oscillation between similarly scored candidates. The current target must remain valid, visible, positively scored, and eligible for the relevant distance and status conditions. Subject to those checks, it is retained for forty-five fixed steps; afterward, a challenger must exceed its score by 1.35× to replace it.

While the current target is valid:
  elapsedSteps < 45 → retain
  challengerScore ≤ currentScore × 1.35 → retain
Otherwise select from the current candidate result

At sixty hertz, forty-five steps is 0.75 s. This UE policy does not alter original candidate scores. It must not retain a dead, hidden, invalid, zero-scored, or otherwise ineligible target just because time remains.

Occlusion also separates a retained target reference from new firing. A blocked corridor immediately prevents new emission, while the target is briefly retained for recovery or repositioning. Ordinary retention is 0.35 s; a reachable local firing position can extend it to 1.2 s. The duration therefore depends on the local-position search result.

These conditions constrain new firing requests. Existing bullets, particles, and arc branches retain their own lifecycles. Stopping new emission does not immediately delete in-flight objects or guarantee the complete absence of friendly fire.

5. Obstacle Avoidance and Firing Positions Require Separate Checks

Constraining Motion at Obstacles

UE first computes desired velocity and then limits its change per step. The acceleration limit is 24 m/s²:

vNext = vOld + clampLength(vDesired − vOld, aMax × dt)

Spray approach additionally limits desired speed using braking distance:

vBrake = sqrt(2 × aMax × distance)

The braking relation supplies a limit based on remaining distance. It is not part of the original follow-speed formula. The UE source calculates in centimeters; these expressions use meters consistently, including squared terms.

A regression exposed a direct reset of final velocity inside the arrival threshold, bypassing the acceleration limit. The fix sets desired velocity to zero within six centimeters, then applies the same limit. Free flight decelerates through retained velocity state. Collision-forced stopping is handled by an independent spatial constraint.

Spatial checks use a sphere sweep with a radius of thirty-two centimeters. Low obstacles can produce local clearance points no more than two meters above the original goal. High walls and ceilings remain blocking. On collision, movement also attempts a slide along the contact plane. Registered test targets are ignored by navigation queries; weapon collision still detects enemies.

This is local obstacle handling. The low-wall tests do not cover initial penetration, complex concave corners, or global pathfinding through arbitrary mazes.

Motion Reachability and Firing Clearance

The local firing-position search generates lateral and elevated candidates around the original follow or approach goal. Lateral offsets are ±1.5 and ±3 m, with elevations of zero, one, and two meters. Combinations are checked for range eligibility, a target ray, a firing corridor with width, and motion reachability.

Candidate cost is squared distance from the current position plus squared elevation. It favors closer, lower feasible positions and reuses a successful offset to avoid left–right oscillation. These are current UE search policies, not recovery of original global navigation.

In an early test, a center ray barely cleared a wall corner and the system accepted the position. The drone stopped within the six-centimeter arrival tolerance, but the ray was blocked again and firing did not resume. The fix adds twenty centimeters of geometric clearance to the future firing corridor and checks Pawn objects, rather than treating one passing ray as a robust firing position.

Keeping a candidate destination within twenty meters of the owner is a bound on this UE local search, not the maximum owner distance for every original flight state. Disabling attacks, recalling the drone, or losing the target clears its current tactical position. The original spray branch’s owner-distance exit curve still executes separately.

6. Firing Algorithms for Six Variants

Rifle and Machine Gun: Sample Each Shot, Then Integrate Its Trajectory

Both bullet variants read their own configuration through the same firing interface. The rifle uses 640 RPM, a runtime total of 30 rounds, and 900 m/s muzzle velocity. The machine gun uses 660 RPM, 45 rounds, and 1000 m/s. Similar names in the previous player-weapon table do not justify reusing those parameters.

interval = 60 / RPM
Rifle: 60 / 640 = 0.09375 s
Machine gun: 60 / 660 ≈ 0.090909 s

The checked default full angular widths are horizontal/vertical 2/2 mrad and 16/16 mrad, with mode zero. A mrad is a milliradian; the formula outputs angular offsets in radians. Both use the same radial-sampling form with different ranges. Each shot advances indexed random state twice without advancing the separate global random state.

r = U²
φ = 2πV
θx = 0.0005 × WidthX × r × cosφ
θy = 0.0005 × WidthY × r × sinφ

For the same teaching sample U=0.5 and V=0, the rifle’s horizontal offset is 0.00025 rad and the machine gun’s is 0.002 rad. This compares angular offsets under identical random inputs. It does not mean an actual shot drew those samples or estimate the full moving-arena impact distribution.

The sampled direction is multiplied by the configured muzzle velocity, then passed to ballistic integration and scene sweeps. Keeping spread, velocity, and collision separate helps locate discrepancies. The checked experiment holds dynamic modifiers neutral and covers 2304 direction vectors across both configurations. The script computes absolute differences for all three components of each vector and reports the largest component difference across the set: approximately 1.1921×10⁻⁷. This is a dimensionless direction-component difference, not an angle in radians or a 3D Euclidean distance. It compares C++ text output with records from original-mechanism execution under bounded inputs, not raw float32 bit patterns. It does not prove bitwise agreement for full dynamic pose modifiers, original seed ownership, or the entire firing call chain.

Presentation had also been misleading. Persistent lines for every integration step made bullets resemble lasers: at 900 m/s and sixty hertz, one step covers approximately fifteen meters. The display was changed to brief, collision-clipped tracer pulses. Current source limits pulse length to approximately eighty centimeters and display life to fifty milliseconds; bullet-impact debug points last twenty-five milliseconds. These UE presentation settings do not reduce physical muzzle velocity or extend the firing interval.

Alongside firing logs, the encoded video is checked for readable tracers and intervening frames without tracers. Media checks use the delivered video, not just source captures.

Variant Video A: Assault rifle, a separate TPS run of approximately 25.7 s. The clip retains initial hits, depletion of 30 rounds, return/resupply, and subsequent hits without speeding up the waits.

Variant Video B: Machine gun, a separate overhead run of approximately 35.9 s. Runtime capacity is 45 and the post-docking reload is 2.5 s, using this variant’s configuration. It is not synchronized dual-view footage with the rifle.

Flame and Gas: Separate Clocks for Birth, Fuel, and Contact

During sustained spraying, fuel is deducted at time boundaries, not on every frame. The recovered rule consumes one unit on first emission or when emitter age crosses a 0.125-second remainder boundary:

Due = First
   or fmod(Age, 0.125) < fmod(Age − dt, 0.125)

A call deducts at most one unit, even if a long step spans several periods. Replacing it with an accumulator and catch-up while loop changes the logic. The age subtraction occurs in float before double-precision remainder evaluation; numerical comparisons must retain that order.

Particle birth uses three random values in order for initial speed, cone angle, and azimuth, then samples a birth curve using emitter age. Flame’s initial-speed range is approximately 28–35 m/s, with the curve rising from approximately 0.3667 to one over 0.0278 s. Gas uses approximately 12–15 m/s and a different curve. The curve age belongs to the emitter; every particle does not restart that wait.

Flame’s resulting first-frame speed range is approximately 10.27–12.83 m/s. The gas curve has different control points, and the current evaluator supports nonlinear branches, so all resources cannot be treated as piecewise-linear curves.

Each motion step updates particle age, evaluates damping, scales velocity, applies axial acceleration, and updates position:

q = dampingCurve(age / life)
base = clamp((60 − damping × q) / 60, 0, 1)
v = v × base^(60dt)
vZ = vZ + acceleration × dt
pNext = p + v × dt

Flame and gas use different damping and axial acceleration. Signs require the coordinate conversion to be understood; colors or signs alone do not establish recovery of complete buoyancy, diffusion, or gas physics.

The integration covers birth and motion calculations for the selected emitter. Count scheduling, some lifetime handling, and scene collision still use UE adaptations. Original models, complete flame/gas effects, and natural status application and expiry are not fully connected. The footage shows sustained emission, fuel use, and test-target feedback, not a complete burning or gas-damage system.

Variant Video C: Flame, a separate TPS run of approximately 22.967 s. Observe continuous particles, depleted fuel, and recovery after resupply. The clip does not validate complete burning damage.

Variant Video D: Gas, a separate overhead run of approximately 27.133 s. Shows the current emitter, fuel, and test-target feedback; it does not establish natural application and expiry of the original statuses.

Arc: Child Segments Propagate Before Querying

An arc can be drawn as one polyline connecting every enemy, but the mechanism retains a root, propagating segments, query depth, and branch history. One breadth-first traversal over all targets changes collision timing and depth budgets.

The root may enter its first query directly. Non-root children first propagate at their velocity and perform the next query after a physical hit. Recovered initial propagation speed is approximately 300 m/s, or five meters per step at sixty hertz, with the last step clamped to remaining distance.

ratio = (Chain + 1 + Bonus − Depth) / (Chain + 1 + Bonus)
range = ratio × 55 m × scale
step = min(range − travelled, |v| × dt)

A nonpositive step takes the termination path instead of reversing the segment with a negative distance. Numerator and denominator originate in unsigned state arithmetic. The expression applies to legal depths, not arbitrary extrapolation into a negative budget.

Before querying, a non-root node increments depth, then requires Depth < Chain + Bonus. With the teaching values Chain=2 and Bonus=0, the root queries at zero, the next query at one can continue, and a query at two stops. This check differs from the range denominator. Remaining positive range does not authorize another branch.

The first query can accept at most one branch; later configuration permits at most five. Actual candidates, distance, angle, history, and collision still constrain acceptance. A branch cap does not guarantee five hits per query.

Each parent maintains its own history of accepted targets. A new child retains Previous and starts with an empty history. Filtering also rejects zero IDs. A global visited set would make another branch reject targets it could otherwise accept, changing the propagation tree.

The arc comparison covers 357 output records, including step distance, accumulated travel and position components, plus ID filtering, depth advancement, branch budgets, and child inheritance. The script calculates absolute differences between corresponding fields and takes the largest across them, reporting approximately 4.633×10⁻⁸. It likewise compares C++ text output with records from original-mechanism execution under bounded inputs. The metric mixes fields; it cannot be called a pure position error, direction error, or proof of identical floating-point bits. Its scope is the bounded calculation module, not UE candidate ordering, original component-slot scheduling, or complete physics-service agreement. A three-target test separately checked depth limits through propagation and collision, while the formal six-variant demonstrations check natural firing requests. They cannot be combined into one complete original-runtime experiment.

Arc has unlimited ammunition and does not return because of depletion in this test. Its 12 RPM means a five-second interval, so the absence of repeated shots in a short observation window is not automatically a failure. Checking a second target requires an observation period long enough to cover a firing cycle.

Variant Video E: Arc, a separate TPS run of approximately 16.667 s. Shows discharge and following after no live enemies remain. Ammunition is unlimited; no empty-ammo return is forced.

Laser: Connected Preheat Does Not Complete the Heat Cycle

Laser integrates following, candidate requests, turning, preheat, and beam presentation. Heat initialization, firing eligibility, return, and reset have undergone segmented execution analysis and explicit experiments. The complete natural sequence of heating, overheating, return/resupply, and reset is not fully connected.

The formal demonstration disables the experimental heat cycle and does not force overheating. It shows current laser attacks and following without live enemies, not restored natural overheat return. Experimental heat curves can help investigate dependencies but cannot replace natural-run evidence.

This also governs clip selection. Four finite-ammunition variants show empty-ammo return. Laser and arc use their own no-enemy follow segments; forcing recall for a uniform six-clip ending would conceal their differences.

Variant Video F: Laser, a separate TPS run of approximately 8.333 s. Shows attacks after preheat and following after both targets die. The experimental heat cycle is disabled; natural overheat return is not demonstrated.

7. Connecting Return, Docking, and Reload

Target Invalidation and Empty-Ammunition Return

Death or invalidation first leads to target reselection. With no live enemies, new emission stops and the flight goal returns near the player. When finite ammunition is depleted, the weapon sets an empty-ammo state, then enters resupply through return and docking.

The internal no-enemy state may retain a search grace period. In the natural-combat footage, targets recover after five seconds and can become candidates before that grace period ends. A short clip need not already display a particular follow-state number. Checks should jointly establish no live target, no new firing, no approach or empty-ammo request, a player-relative goal, and actual following.

A dedicated all-invalid test holds that condition long enough to check stable following. Its inputs differ from natural combat. Footage that manually disables targets cannot be inserted into normal combat and presented as one natural kill sequence.

Docking Must Reach the Actual Attachment Point

Return flight may pass through local avoidance waypoints. Reaching a temporary waypoint is not reaching the backpack; completion must use distance to the actual docking point.

The final attachment interpolation also respects collision. The current adaptation checks both the four-second interpolation time and actual arrival at the attachment point before docking. If a wall blocks the drone, merely waiting out the timer and assigning the backpack position would still cause a visible teleport.

Motion calculations, execution comparisons for attachment-related functions, and UE scene binding each have separate validation scopes. The current run supports the docking description here, not a claim that original animation, all scene queues, and wielder services are reproduced one for one.

Reload Duration Excludes the Return Flight

After docking, a finite-ammunition variant checks spare magazines, waits its configured reload duration, consumes one spare magazine, and restores capacity. The current test starts with six spare magazines. With none remaining, ammunition cannot be restored unconditionally.

Original records contain twenty-nine rifle magazine rounds and forty-four machine-gun rounds. Combined with chamber state, these yield UI totals of thirty and forty-five. Displaying only the internal magazine count would omit a round. Spray fuel has a separate record and does not use bullet chamber-counting rules.

Machine-gun reload is configured as 2.5 s. The current rifle, flame, and gas configurations use zero, but empty-to-attack time is not zero: actual return, docking, and redeployment still occur. A 30 fps video may not show a distinct backpack-wait frame. The run records confirm docking and resupply without adding an artificial wait for a visible pause.

The original-mechanism resupply comparison executes bounded portions for reload, spare-magazine deduction, and attribute publication. External inventory and some services come from test interfaces; the comparison does not cover the entire function’s return path or natural animation requests. UE connects actual return using the confirmed rules, with this service adaptation still explicit.

Attacks and Resupply in One Rifle Run

Variant Video A records target selection, firing, and resupply in one TPS rifle run lasting 25.7 s. Seconds in the table are relative times from that recording’s event log. Fixed-step numbers check adjacent states; neither represents machine wall-clock time.

After the first target dies, the next fixed step selects the other target. This supports invalidation-triggered rescanning in this scene, not immediate same-step firing after a switch. The new direction must still satisfy turning and eligibility conditions. The wait with both targets dead does not trigger empty-ammo return: no enemies and no ammunition occur separately in the records.

After targets recover and re-enter selection, the retained ammunition continues to decrease until all thirty rounds are used. The approximately 7.333 s from empty to refilled includes return-request handling, flight, and docking; it is not configured reload duration. The rifle’s reload configuration is zero. The machine gun separately uses 2.5 s, but subtracting total durations from two independent runs cannot recover that field because their depletion positions, player movement, and target histories differ.

A new actual hit approximately 0.9 s after refill supports connected redeployment and attack in this run. It is not a universal drone startup delay: target changes, turning, corridor checks, and projectile travel can all contribute. After initial deployment, the recording contains no additional variant resets, ammunition injection, or manual recall replacing empty-ammo return. It is therefore the main demonstration of the natural finite-ammunition loop.

Separating Panel Inputs from State Feedback

The validation panel both supplies controls and displays runtime results. Variant selection, deployment, recall, follow-only mode, and automatic attack affect different conditions. Height changes only the follow reference; they do not change spray approach radius, original weapon range, or a global navigation altitude.

Input ownership also matters while the panel is open. F9 switches between widget operation and character control; F8 collapses the panel. These are UE validation tools. Mode switching must remain available after a widget gains keyboard focus, or a tester may conclude that the character or drone has stopped responding. Input checks and six-variant weapon checks are recorded separately.

8. What Videos and Logs Validate

The formal material comprises six variants and two views, for twelve independent scenes. The overhead compilation lasts approximately 136.367 s and the TPS compilation 135.567 s, both native 1920×1080 at thirty frames per second. The views come from independent processes, not synchronized cameras in one run.

Video 2: Complete 45° overhead compilation, showing player, follow point, approach position, and return paths. Six independently recorded segments are joined at original speed. It does not establish full-map navigation or real-time frame rate.

Early edits accelerated the no-target wait and empty-ammo return, speeding up the player along with the rest of the frame. That could be mistaken for unstable movement. The final material was re-recorded with all source frames retained and only chapter joins applied. Speed and return-time assessments should use this original-speed version.

Validation pairs footage with records from the same run. Finite-ammunition checks cover initial hits, depletion, the empty-ammo request, docking, spare-magazine consumption, restored capacity, and subsequent hits. A cumulative shot count above initial capacity cannot by itself rule out ammunition injection. These natural-loop recordings have no extra recall, reset, or resupply command after initial deployment.

Unlimited variants are checked for actual kills, zero live targets, stopped new attacks, and following error. In the health test, targets recover after three hundred fixed steps at sixty hertz: five seconds. Five seconds is the UE arena recovery setting, not an original enemy respawn rule.

“Original-mechanism execution under bounded inputs” means supplying explicit configuration, initial state, and scene-query results to the relevant calculations and recording their output. The C++ comparison then compares the port’s corresponding results with those records. External dependencies supplied by test interfaces are identified in the relevant sections.

The table below indexes the six individual variant clips. Durations are taken from the delivered encoded files. Video shows continuity; precise states and numerical conclusions remain tied to the same-run records.

Overhead and TPS clips come from different runs, so equal timestamps do not support synchronized comparison. Finite-ammunition loops, no-enemy following, obstacle tests, and numerical examples also retain their own input scopes.

Test-sphere HP, per-weapon damage, and recovery policy all come from arena settings. Spray hit counts may count particle contacts rather than distinct damage events. Gray marks a dead test target; it does not establish migration of a complete original enemy death animation.

Remaining gaps include the natural laser heat cycle, original models and complete effects, natural status application and expiry, dynamic modifiers, full navigation, and original runtime services. The evidence supports specified paths through a six-variant mechanism prototype, not complete reconstruction of every drone combat system.

Further work will address these dependencies and runtime paths. Turrets have their own deployment, turning, supply, and target lifecycles and will be covered separately.

Relationship to the Prototype Plan and Previous Article

The overall prototype plan defines scope and method for subsequent implementation and experience checks. The previous weapon article explains player observation, aiming, and firing. This article extends that work to autonomous selection, motion, attacks, and supply.

The three articles cover project goals, player-weapon mechanics, and autonomous weapons respectively. Drone spread, ballistics, and spray calculations build on earlier mechanism analysis; wielder relationships, target selection, and resupply are the new focus here. They remain in a standalone Lyra prototype. Project integration must still check input, animation, damage, resources, and network-state connections.

AI Collaboration Retrospective

AI helped map configuration to calculation modules, organize original-mechanism execution results, read C++ integration points, and arrange diagrams and recordings. Human inspection found problems that logs did not readily expose: missing horizontal motion, interrupted spray, tracers that looked like continuous beams, and accelerated edits that also sped up the player.

Those problems came from missing goal inputs, pose inputs, tracer display duration, and media processing. Fixes required separate checks of calculations, state records, and the final encoded clips. This article retains each experiment’s inputs and scope, and identifies mechanism explanations, UE optimizations, and arena settings separately.