Hello Epic team,
I am developing a Box Fight training island and need to clarify whether a Guard or custom NPC can use Fortnite’s actual player-building mechanics in a publishable UEFN experience.
The required behavior is:
- Place genuine Fortnite walls, floors, ramps and cones using the native building grid, structural rules, material costs and team/ownership rules.
- Take an opponent’s wall by destroying it and placing the NPC’s own wall in the freed slot, following normal building rules.
- Edit an owned wall into a valid native shape, such as a window.
- Reset that edit to the full wall.
Spawned creative_props, hidden/swapped mesh variants, teleporting prebuilt props, and portable-fort items do not meet this requirement. The NPC must perform the actions itself; controlling a separate player client is also outside the scope.
Environment
- Windows; UEFN build ++Fortnite+Release-43.00-CL-59596594.
- Tests included NPC Spawner Guards and a standard Guard Spawner with default AI.
What we have verified in a running session
- A player could place a native brick wall, edit a window and reset it in the same test environment. This was a player control test, not an NPC success.
- We transferred the four actual native build-tool items from the player’s inventory to a fort_inventory_build_hotbar_component under the Guard’s inventory root using AddItem. The items reported the Guard’s inventory as their parent. They were returned to the player after testing.
- The Guard was configured to receive 500 wood, stone and metal; runtime inspection confirmed three resource stacks. Equip succeeded and the Guard visibly held the native building blueprint.
- In the clearest run, all 208 Equip calls succeeded and all 600 IsEquipped samples were positive across 12 scenarios. These are equipment/holding checks, NOT 600 placement commands.
- We tried one-time and repeated equip, retaining/removing normal weapons and the pickaxe, default Guard AI, ForceAttackTarget, incoming damage, and positioning near the player. No new native structure was observed in the inspected area. This was visual observation, not a continuous recording or an exhaustive BuildingActor counter.
- A Guard could damage and destroy a player-built wall in a separate test, but replacement by a new NPC-owned wall was not achieved. Several sequenced wall-take setups did not satisfy the destruction prerequisite, so those were not completed takeover tests.
- The native build-tool entities exposed no fort_weapon_component/fort_trace_weapon_component in the inspected hierarchy, so BeginFire was not available through that route. Searches for public fort_item_ability_component/ability-effect components did not expose a usable build ability. This does not establish that internal GAS abilities are absent.
Compiler/editor checks and unverified cases
- Calling Signal on a listenable input event failed with compiler error 3506 (unknown member Signal). Casting it to signalable(tuple(player,logic)) failed with error 3502 (unsupported dynamic cast to a parametric type).
- A direct guard_actions_component.Attack probe against a detected target compiled, but its runtime execution was not verified. We are NOT reporting that particular probe as a failed runtime test.
- The editor’s component listing exposed Building_building_component, but adding it was rejected as excluded by the project’s class filter. We did not bypass that restriction.
- We reviewed the generated Verse API digests, inventory documentation, Guard actions, input APIs and custom abilities. We did not find an exposed native placement/edit/reset operation or a way to select a native building actor and submit an edit shape.
Native-code context
For comparison only, we inspected the public Project Reboot source, which contains ServerCreateBuildingActor, ServerBeginEditingBuildingActor, ServerEditBuildingActor and ServerEndEditingBuildingActor handlers, plus a ReplaceBuildingActor call. This was read-only inspection of legacy third-party server code; it was not compiled, loaded or injected, and we do not assume it represents current UEFN behavior. Its EndEditing handler clears editing state rather than restoring wall geometry. We are asking for a supported UEFN mechanism, not a way to load that server code into Fortnite.
Questions for Epic
- Is there currently any supported way for a Guard or custom NPC to perform each of the four actions above in a publishable UEFN island?
- Could an existing NPC type, native item, inventory configuration, exposed ability or device provide this behavior indirectly? If so, what exact configuration/API and minimal example should we use?
- Does equipping native build tools on a Guard only expose inventory/visual behavior, or is a construction activation path intended to be available? What additional component, controller capability, input or ability would be required?
- Is Building_building_component deliberately unavailable to project-authored runtime entities, and is there a public equivalent?
- If the full mechanic is unavailable, could you confirm which operations are unsupported and whether there is a public roadmap item or existing feature request for native NPC building/edit/reset access?
References
Fort inventory documentation:
Guard actions:
Public source reviewed for comparison:
An explicit capability clarification, or a minimal supported native-building example, would help determine whether this training mechanic is feasible. Thank you.