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.