DefenceSystem_Modern is a Blueprint-based turret and automated defence framework. It provides reusable targeting, aiming, firing, damage, resource consumption, Niagara effects, and projectile behaviour that can be inherited by multiple turret types.

For shared setup guidance, see the Migration Guide and Integration Guide. Use the System Atlas to look up functions, variables, events, components, and ownership references. Use this page for Turret Defense system-specific setup, runtime behavior, extension points, and integration notes.

This document is for Unreal Engine developers integrating or extending the turret system. It prioritises quick setup and safe extension points, while keeping the underlying Blueprint architecture and key identifiers easy to scan.

Scope: turret behaviour (targeting, firing models, resources, effects). Out of scope: placement/build menus, ownership rules, and wider buildable workflows (covered by the surrounding interaction/build systems).

The system is built around a shared turret parent, then specialised child Blueprints for area, hitscan, laser, and projectile behaviour. Common logic such as detection, target sorting, resource checks, fire timers, and base rotation lives in one place, while individual turret types only override what needs to behave differently.

• Uses BP_Turret_Base as the shared turret parent for detection, target selection, resource checks, firing events, audio, and base rotation.
• Supports area based damage, hitscan traces, laser beam visuals, and projectile or missile based attacks.
• Uses resource consumer helper objects to decide whether the turret can fire and whether ammunition/resources should be consumed.
• Supports inventory driven ammo, data-only ammo/resource child Blueprints, and an infinite resource consumer for power based or always-on examples.
• Uses Niagara components and Niagara user variables for continuous streams, beam endpoints, impact effects, and projectile trails.
• Integrates with the Hyper Attribute System when a target has an attribute manager, with a standard Unreal damage fallback where shown.

Quick Start

Use this section if you want to place a turret and confirm the system is working end-to-end before you dive into the detailed reference.

1. Place any supplied turret child Blueprint in the level (hitscan, laser, area, or projectile/missile).
2. Verify targeting: set Detection Sphere Radius high enough and confirm a pawn enters Pawns in Radius.
3. Verify firing gates: confirm Has A Valid Target becomes true and the turret turns until it is facing the target.
4. Verify resources: set Resource Consumer Class to BP_Turret_Resource_Consumer_Infinite for a first test, then switch to an ammo/resource consumer and add matching items.
5. Verify output: confirm the expected result for your firing model (hitscan damage, area DamageBox damage, beam visuals, or projectile spawn/impact).
6. If something fails, jump to Troubleshooting and follow the checks for targets, facing, and resources.

If you want to: create or change content quickly, go to Common Tasks (new turret, ammo, effects, power/infinite, new projectile). For deeper understanding, start with How the System Works. For tables and settings, use Reference.

How the System Works (Conceptual Overview)

At a high level, every turret follows the same pattern: detect targets, choose the best visible target, rotate toward it, check resources, then fire using a specific damage model (area, hitscan, laser hitscan, or projectile).

1. Detection: DetectionSphere maintains a list of candidate pawns.
2. Selection: candidates are sorted by distance and the closest visible pawn is chosen.
3. Aiming: SM_Turret_Rotator (and SM_Turret_Gun for hitscan) turns toward a predicted target position.
4. Gating: Can Fire checks target validity, facing state, and resources (external provider first, then local).
5. Firing: the shared fired event handles consumption/effects, then the child turret applies damage (trace, overlap, beam visuals, or spawned projectile impact).

Next, Adding the Turret System to the World covers how to use the supplied turret actors. Later, Detailed Targeting and Firing Flow breaks down the shared Blueprint logic step-by-step.

The demo world presents the system as a collection of turret archetypes. These examples share parent behaviour and specialise only the firing model, resource style, projectile setup, or visual effect required by that turret.

Adding the Turret System to the World

Turret actors are intended to be placed in the world as defence actors. BP_Turret_Base is a child of BP_Interact_Location_Base, so it inherits the wider interact-location behaviour from the surrounding Hyper framework.

This document focuses on the turret system itself. Placement, construction, build menus, ownership rules, and wider buildable workflow should remain in the documentation for the wider interaction or building system unless a project intentionally extends this turret system to own that workflow.

Because the Blueprint design is inherited, changes made in a parent can affect every child. Users should usually avoid editing BP_Turret_Base unless they want to change behaviour for all turret types. For a new weapon, create a child from the most suitable base and only override or change defaults on that child.

Reference

Use this section when you need a specific setting, component, event, or function name. The goal is fast lookup: skim the headings, then use the tables for details.

Provided World Turret Types

The demo world describes the intended design purpose for each turret category. These examples also make good starting points for users who want to customise the system.

Core Components

Turret actors use a consistent component layout. Use this table to understand what each component does and what child Blueprints may safely customise.

Example component hierarchy from an area turret child.

Details Panel / Important Variables

The screenshots show several important variables and settings that are likely exposed on the turret or its children. Exact defaults can be adjusted per child Blueprint.

Resource Consumer Architecture

The resource system is intentionally modular. A turret does not need to know whether ammo comes from local inventory, a connected ammo box, electricity, fuel, missile ammo, or an infinite demo supply. It asks a resource consumer object whether resources are available and asks it to consume a resource when the turret fires.

Ammo resource consumer checking the owner inventory for the Accepted Ammo gameplay tag.

The local resource consumer is created on BeginPlay if Resource Consumer Class is valid. The connected external resource provider path can also construct a resource consumer object when a compatible provider is connected. The external provider is checked first. If it cannot consume or is no longer valid, the turret can fall back to its local Resource Consumer Reference.

Damage Types and Firing Models

DefenceSystem_Modern supports several firing models. The main difference between them is how they decide what receives damage.

All firing models are designed to be driven by the same Can Fire pattern. A turret should only fire when it has a valid target, is facing the target, and has enough resources according to its resource consumer logic.

Detailed Targeting and Firing Flow

BP_Turret_Base owns the shared targeting and firing logic. This is the core layer that child turrets inherit before adding their own damage style.

BP_Turret_Base Can Fire checks resources, target validity, and facing state.

Target detection

DetectionSphere overlap events add and remove pawns from the Pawns in Radius array. On begin overlap, the turret can run an affiliation check before adding the actor. If the array was previously empty, it starts the target-looking timer. On end overlap, the pawn is removed from the array.

Target sorting

The Sort Based On Distance function sorts the Pawns in Radius array using squared distance to the turret. This allows the turret to attempt closer targets first without using expensive distance square root calculations.

Line of sight target selection

Get Closest Visible Pawn loops through the sorted array and checks whether each candidate has line of sight from the barrel. The first visible pawn becomes the active target and Has A Valid Target is set true.

Base rotation

Start Looking At First Target runs on a timer using Look At Update Rate. It calculates a target rotator and turns SM_Turret_Rotator toward the target either with smoothed interpolation or constant interpolation. The system also supports target prediction so moving targets can be led instead of aiming only at their current location.

Fire event

When the turret can fire, it triggers the turret fired event, consumes resources, plays sound, spawns Niagara where appropriate, and allows child Blueprints to continue with their own damage implementation.

Area Based Turrets

BP_Turret_Area_Base is used for turrets that damage an area in front of the turret rather than firing a single ray or projectile. The demo examples include flame and gas style turrets.

Area turret damage override: overlapping actors inside DamageBox are damaged.

Flamethrower child configured with a flame Niagara system and a forward damage box.

Gas blower child configured with a gas Niagara system and a forward damage box.

Hitscan Turrets

BP_Turret_Hitscan_Base is used for instant-hit turrets. It adds gun pitch aiming on top of the base rotator aiming so the gun mesh can track targets vertically.

Hitscan trace and damage logic from End Of Barrel forward.

Hitscan turrets are a strong base for bullets, energy shots, sentries, or any weapon where projectile travel time is not required.

Laser Hitscan Turrets

BP_Turret_Hitscan_Laser uses the hitscan model but adds constant beam visual updates. The laser is not a separate damage model; it is a hitscan turret with laser-specific Niagara behaviour and fire timing.

Laser endpoint update: trace forward and set the Niagara Beam End vector.

When changing the laser Niagara system, keep the user variable name consistent with the Blueprint. If the Niagara asset uses a different parameter name, either rename the Niagara parameter to Beam End or update the Blueprint node that sets the Niagara variable.

Projectile Turrets

Projectile turrets differ from hitscan turrets because they spawn an actor rather than applying damage immediately. The turret-side firing logic uses the same parent Can Fire flow, then spawns a projectile actor at End Of Barrel and passes all required movement, homing, damage, impact, and audio settings into the spawned actor.

Projectile turret firing on a timer and spawning the missile projectile actor.

Projectile Actor / Missile Setup

The projectile actor owns the behaviour that happens after it has been spawned. The missile example contains a static mesh, Niagara trail, ProjectileMovement component, and impact logic.

BP_Turret_Projectile_Missile visual setup with mesh and Niagara trail.

Projectile impact damage supports both radial damage and direct attribute damage.

Niagara and Audio

The system uses Niagara in several different ways: muzzle effects, continuous area streams, laser beams, impact effects, and projectile trails. Audio is similarly split between turret firing sounds and projectile impact sounds.

Base Niagara spawn from End Of Barrel.

The area examples show Niagara user parameters such as ConeAngle, FireSpawnRate or SpawnRate, Lifetime, and Velocity Speed. These parameters belong to the Niagara asset. If a different Niagara asset uses different parameter names, users should adjust the Niagara asset or Blueprint references accordingly.

Functions to Use

These are the functions you will most often call, override, or debug when extending turret behaviour.

Events and Multicast Flow

The turret system uses events to keep common firing behaviour and child firing behaviour separated. The parent can handle shared effects and resource consumption, while children perform their own damage or projectile logic.

Ammo and Resource Types

Ammo/resource selection is gameplay-tag driven. The ammo consumer does not need to know a specific item class. It only needs the Accepted Ammo gameplay tag. If the owner inventory has at least one item matching that tag, the turret can fire. When the turret fires, one matching item can be removed automatically by gameplay tag.

Because these are data-only children, users can make additional ammo types very quickly. A new bullet, rocket, battery, shell, crystal, or fuel type only needs a new gameplay tag and a data-only child with Accepted Ammo set to that tag.

External Resource Providers

The base turret can support an external resource provider through AC_Connectable. When a connection is made with a provider, the turret constructs a resource consumer object for that external provider and sets it as External Resource Provider. This external provider is checked before the turret local resource consumer.

Connection flow creating and initialising an external resource provider consumer.

This makes it possible to support external ammo boxes, power supplies, fuel tanks, or other connected providers without changing the core turret firing logic.

Hooking into Other Systems

DefenceSystem_Modern is designed to interact with other Hyper systems without forcing them to own turret logic.

Common Tasks

Use these step-by-step procedures to extend the system without modifying shared parent logic. Each task starts with the intended outcome so you can confirm you are in the right place.

Add a New Turret

Outcome: You will end with a new child turret Blueprint that uses the correct firing model, consumes the intended resource, and plays the intended effects.

The safest way to add a new turret is to create a child from the base that already matches the damage model you need.

1. Decide the firing model: area, hitscan, laser hitscan, or projectile.
2. Create a child Blueprint from BP_Turret_Area_Base, BP_Turret_Hitscan_Base, BP_Turret_Hitscan_Laser, or the projectile turret setup.
3. Rename the child clearly, for example BP_Turret_Hitscan_Railgun or BP_Turret_Area_AcidSprayer.
4. Open the child Blueprint and adjust the visual mesh components, especially SM_Turret_Rotator, SM_Turret_Gun, and End Of Barrel alignment.
5. Set Detection Sphere Radius, Fire Rate, Damage Amount, and any damage-specific settings such as DamageBox size or radial damage radii.
6. Choose the Resource Consumer Class. Use Infinite for testing, Ammo for inventory resources, or a data-only ammo child for fuel, power, missiles, or your own tag.
7. Assign Niagara and audio assets. For area turrets, configure the Niagara component. For projectile turrets, configure projectile impact and trail assets.
8. Test the turret in the demo map against a visible target. Confirm it detects, rotates, consumes resources, plays effects, and applies damage.
9. Only move shared logic into BP_Turret_Base if every turret type should inherit that change.
10. For most users, creating a child Blueprint is enough. Avoid editing the parent base unless the goal is to change all existing turret children.

Create a New Ammo Type

Outcome: You will have a new gameplay tag and a data-only resource consumer child that enables the turret to fire by consuming that tag from inventory/providers.

A new ammo type is mainly a gameplay tag workflow. The ammo consumer already searches inventory by gameplay tag, so users do not need to write new firing code for each ammo type.

Change a Turret Ammo Type

Outcome: The turret will only fire when the new ammo/resource tag is available, and it will consume one unit per shot via the assigned resource consumer.

To change what a turret consumes, change the resource consumer class or change the Accepted Ammo tag on a data-only child.

When to use: when a turret should consume a different gameplay tag or draw from a different provider style without changing fire logic.

1. Open the turret child Blueprint you want to change.
2. Find the Resource Consumer Class setting.
3. Assign the consumer child that matches the desired ammo/resource type. For example, use BP_Turret_Resource_Consumer_Ammo_Projectiles for missile ammo.
4. If no suitable consumer exists, create a new data-only child from BP_Turret_Resource_Consumer_Ammo and set Accepted Ammo to the desired tag.
5. Compile and save the turret child.
6. Place the correct item/resource in the turret inventory or connected provider inventory.
7. Test firing and confirm one item/resource is consumed per shot.
8. Do not hard-code item classes into the turret. The intended pattern is gameplay-tag based because it keeps the turret generic and makes new ammo types easy to add.

Change Niagara Effects

Outcome: The turret or projectile will use the new Niagara assets while still matching the Blueprint-driven user parameters (for example beam endpoints).

Niagara effects can be changed per turret child without changing the base system. The exact workflow depends on whether the effect is a component, a spawned muzzle effect, a laser beam, or an impact effect.

When to use: when you want different visuals (stream, beam, muzzle, impact, trail) while keeping existing firing/damage logic.

Change an area turret stream effect

1. Open the area turret child, such as the flamethrower or gas blower child.
2. Select the NiagaraSystem component.
3. Change Niagara System Asset to the new Niagara asset.
4. Check the Niagara user parameters. The demo examples use values such as ConeAngle, FireSpawnRate or SpawnRate, Lifetime, and Velocity Speed.
5. Make sure Auto Activate is disabled if the Blueprint is meant to activate the stream only while the turret can fire.
6. Adjust DamageBox size and position so the damage volume matches the visible stream.
7. Compile and test the turret against a moving target.

Change a laser effect

1. Open BP_Turret_Hitscan_Laser or its child.
2. Select the laser Niagara component.
3. Change the Niagara System Asset.
4. Confirm the new Niagara asset has a Vector3 user parameter for the beam endpoint.
5. Use the same parameter name as the Blueprint node. The shown setup writes to Beam End.
6. If the Niagara asset uses a different parameter name, update the Set Niagara Variable node in Update Laser End Point.
7. Test against a wall and a pawn to confirm the beam ends at the trace hit point.

Change a projectile trail or impact effect

1. Open the projectile actor child, such as BP_Turret_Projectile_Missile.
2. For the trail, select its NiagaraSystem component and change the Niagara System Asset.
3. For impact effects, update the Impact Niagara variable passed into or stored on the projectile.
4. Adjust any Niagara user parameters such as Duration, Fireball Scale, or Ribbon Length.
5. Compile and test projectile spawn, flight, and impact.

Make a Power or Infinite Turret

Outcome: The turret will fire without consumable ammo (infinite) or will be ready to consume power via a dedicated resource consumer implementation.

The demo includes a power based turret idea where the turret uses a fake infinite resource. This is useful for showing a turret that is powered by an outside system without building that full power grid into the turret itself.

1. Open the turret child that should behave as power based or unrestricted.
2. Set Resource Consumer Class to BP_Turret_Resource_Consumer_Infinite if the turret should always be allowed to fire once target and facing checks pass.
3. If the project has a real electricity item in inventory, use BP_Turret_Resource_Consumer_Ammo_Power instead so it checks Items.Resource.Electricity.
4. If the project has a separate power grid system, create a new child of BP_Turret_Resource_Consumer_Base that queries that system in Has Enough Resources and consumes or reserves power in Try Consume Resource.
5. Keep the turret firing code unchanged. Only the resource consumer should know where power comes from.

This keeps the power system optional. Projects can treat power as inventory items, a connected provider, a true grid, or an infinite test supply.

Balance Targeting and Damage

Outcome: You will be able to tune feel and effectiveness (range, fire rate, turn speed, damage shape) using exposed values instead of rewriting Blueprint logic.

Most turret tuning can be done with exposed values rather than changing Blueprint logic.

Create a New Projectile

Outcome: You will end with a new projectile actor child and a turret that spawns it with the correct movement, damage, and impact effects.

A new projectile can be created by using the missile projectile as a starting point and changing its movement, mesh, damage, and effects.

1. Create a child Blueprint from the projectile actor base or BP_Turret_Projectile_Missile if that is the closest starting point.
2. Rename it clearly, for example BP_Turret_Projectile_Rocket_Fire or BP_Turret_Projectile_PoisonOrb.
3. Replace the StaticMesh with the new projectile mesh.
4. Update the NiagaraSystem component for the trail effect.
5. Set projectile movement defaults such as speed and homing settings.
6. Choose whether it should apply radial damage or direct damage on impact.
7. Set Damage Amount, Damage Inner Radius, Damage Outer Radius, and Damage Falloff for radial projectiles.
8. Set Impact Niagara and Impact Sound.
9. Update the turret-side projectile spawn class to use the new projectile child.
10. Test normal flight, homing flight, impact effects, damage, and cleanup after impact.

Example Flows (End-to-End)

Use these sequences to validate your understanding of the system, or to debug where a turret stops progressing (detection -> selection -> facing -> resources -> fire -> damage/effects).

Hitscan turret fires at a visible target

• Pawn enters DetectionSphere and passes any affiliation check.
• Pawn is added to Pawns in Radius.
• The target list is sorted by distance.
• Get Closest Visible Pawn confirms line of sight from End Of Barrel.
• Base rotator turns toward the target and hitscan gun pitch turns toward the target.
• Can Fire returns true when resources exist, a valid target exists, the base is facing, and the gun is facing.
• Try Fire runs, Multicast_Turret_Fired broadcasts, resources are consumed, sound/effects play, and Trace and Apply Damage traces forward.
• The hit actor receives attribute damage or standard Apply Damage fallback.

Area turret damages enemies in a cone/box

• Pawn enters DetectionSphere and the turret rotates toward it.
• Can Fire becomes true when the target is valid, the turret is facing, and resources exist.
• The area Niagara component activates.
• Trace and Apply Damage is overridden, so the turret does not use a single line trace.
• DamageBox gets overlapping actors.
• Each overlapping actor is checked for an Attribute Manager.
• Valid actors receive direct damage from the turret.
• When Can Fire becomes false, the continuous Niagara component is deactivated.

Projectile turret launches a homing missile

• Pawn enters DetectionSphere and becomes the closest visible target.
• Can Fire returns true after resource and facing checks.
• Try Fire multicasts the fired event and spawns BP_Turret_Projectile_Missile at End Of Barrel.
• The turret passes projectile speed, homing target component, starting velocity, damage settings, impact sound, and impact visuals to the projectile.
• The projectile starts with lower homing acceleration and ramps toward the goal acceleration.
• On impact, the projectile applies radial damage or direct damage depending on its setting.
• Impact Niagara and sound spawn, the projectile hides, disables collision, and cleans itself up with a short lifespan.

Turret uses external ammo provider

• A compatible provider connects through AC_Connectable.
• The turret constructs and initialises an external resource consumer for that provider.
• The provider health zero event is bound so the turret can clear the reference if the provider is destroyed.
• When firing, the turret tries to consume from the external provider first.
• If the external provider cannot consume or is invalid, the turret can fall back to the local resource consumer reference.

Troubleshooting