UEFN/Verse Limitations: Detecting Pickaxe, AFK, and Damage Causers, June 2025

1. Detecting If a Player is Holding a Pickaxe Using Conditional Buttons

Problem:

  • Many creators want to know if a player is holding only their pickaxe (and not another weapon) to trigger gameplay logic.
  • A common workaround is to place one conditional button device for every weapon in the game (excluding the pickaxe), configuring each to detect if a player is holding that weapon.
  • You then check: If none of these conditional buttons indicate the player is holding their configured weapon, the player must be holding their pickaxe.

Why This Is a Performance Issue:

  • Device Overhead: Placing and referencing many conditional buttons (one per weapon) dramatically increases both in-editor and runtime complexity.
  • Brute Force Polling: Your Verse logic must check every device for every player, often every frame or rapid interval, resulting in many function calls and device checks.
  • Scalability: As Fortnite adds new weapons or items, the number of devices and checks grows, further compounding performance costs.
  • Memory and Network: Each conditional button device is networked and replicated, using memory and bandwidth resources for something that should be a direct metadata lookup.

Underlying Reason:

  • There is currently no direct API method in Verse or UEFN for determining if a player is holding their pickaxe or which weapon slot is active.

Suggestion for Future Epic Updates:

  • Expose a direct Verse API such as IsHoldingPickaxe() or GetActiveWeaponType() on the player or character classes.
  • This would eliminate the need for brute-force device enumeration and make projects more performant, scalable, and maintainable.

2. Determining AFK Status (Player Inactivity)

Problem:

  • Creators want to track when a player is AFK (not interacting with the game for a set period) to, for example, hide UI, skip turns, or remove players.
  • Epic’s internal logic can detect AFK, but this state is not exposed in Verse or the UEFN API.

Current Workaround and Performance Issues:

  • Creators are forced to track all forms of “activity” themselves: view direction change, movement, input events, device interactions, etc.
  • This typically involves frequent polling, tracking timers, and maintaining separate AFK timers for each player.
  • With large numbers of players or complex logic, this can result in excessive code execution, state tracking, and increased chances for subtle bugs.

Suggestion for Future Epic Updates:

  • Expose an official, performant IsAFK() or AFKStatusChangedEvent in Verse or as a device/global event, giving creators direct, lightweight access to Epic’s internal AFK state.
  • This would allow efficient, robust inactivity handling across experiences.

3. Damage Causer Interface Not Implemented

Problem:

  • When handling a damage event (elimination_result, etc.) in Verse, creators want to know what caused the damage:

Was it a weapon, the environment, a trap, or another source?

  • Currently, while the elimination_result includes Source: ?game_action_causer, this field is not reliably populated or explained, and there is no standard interface to easily classify the causer.

Why This Is a Gameplay Logic Issue:

  • Creators cannot easily distinguish between different sources of damage, making it difficult to implement logic like “count only weapon eliminations,” “ignore environmental damage,” etc.
  • Quest and event logic may become unreliable or have to rely on hacky, indirect workarounds.

Suggestion for Future Epic Updates:

  • Fully implement and document the game_action_causer interface and its classification (weapon, environment, trap, ability, etc.).
  • Expose this in elimination and damage event APIs so creators can branch their logic cleanly on the type of causer.

Upvote