Description: Change the Time Dilation of the world
Command type: Parameter
Range: Min(0.05) Max(20.0-60.0)
Implementation details: This would modify the time dilation of the world so a creator can speed up processes while debugging
Use Case: If a random event happens in a map every 5 minutes instead of having to modify the code to make it happen more frequently to test or making many cinematic sequences of varying time dilation, the debug command can be used to simply speed up the game
Description: Trigger runtime visualization modes similar to those in the editor viewport (see image below).
Command type: Parameter
Label: Should reflect the name of the corresponding runtime view/visualization modes.
Range: N/A
Values: Enumeration values of possible modes
Implementation details: It’s possible to trigger visualization modes at game runtime to see otherwise hidden information that is useful for debugging and optimization purposes. It would be great to trigger these at runtime, which is especially useful when testing the same development session on multiple different platforms simultaneously. It would be great if all modes were available for us to trigger.
Description: Show profiling details both in the editor and in-game
Command type: Parameter
Label: stat unit, stat GPU and t.max FPS
Range: 0 - 999 for t.max FPS
Values: N/A
Implementation details: * stat gpu → Shows GPU performance stats (time in milliseconds each rendering pass takes). Good for spotting graphics bottlenecks.
stat unit → Shows frame time breakdown: Game thread, Draw thread, and GPU time. Helps you see whether CPU or GPU is the limiting factor.
t.MaxFPS → Sets the maximum allowed framerate (e.g., t.MaxFPS 60 caps at 60 FPS). Useful for performance stability or testing.
Yea i think showing the TPS ui would be good as currently its creating a verse device ect i feel if epic created a version for us it’d be more precise for sure but would also limit this need to create a device ect every map.
Bookmark/Teleport/Trigger/End, Time-Dilation, Give/Take, Spawn/Damage/Heal etc all can be done already from verse and custom menus / inputs can trigger them already.
I feel like a LOT of the above requests can be made moot just by having an isDebug[] function in verse, without needing those hard-coded by Epic.
They can then check if debug is active and can do most of these actions already from their own verse menus or input-button(s).
Not sure if this is possible, but it’s an idea. Allow creators that have access to the UEFN project itself (via team roles) to view the debug commands in playtest sessions, not just UEFN edit sessions.
Description: Enables print logs (visible to the current client)
Command type: Action
Label: Enable print / logs
Range: N/A
Values: N/A
Implementation details: When debug commands are available, the current user if they have the right permissions can explicitly request logs to be printed on their client while playtesting a playtest variant of the island.
Building on the same idea of being able to debug playtest islands.
Name: Connect editor for logging
Description: Connects the editor with the same project to enable capturing full range of logs.
Command type: Action
Label: Connect to editor for logging
Range: N/A
Values: N/A
Implementation details: Connects a running playtest session at runtime to an editor for a user if they have the right permissions in order to capture logs after the connection has been established.
Values: 1 - number 2 - graph 3 - list + tag_filter
Implementation details: Displays the current memory usage as a current / total in number mode , in graph mode show the memory with a graph of the past 5 seconds, in list mode show a list of objects sorted by memory usage, high memory first, the tag_filter should filter the objects by verse tag or scene tag.
this should help figuring out what objects are ‘heavy’ in term of performance when using verse and scene graph because right now there is no way of debugging scene graph at all
I definitely hope to see more commands created. In the meantime, I’m over here creating remotes to cover this. Made a custom player indexing system in Verse to dynamically fill the player list when selecting “Player Action”, when then takes you to a menu with various options to perform on that target player. It’s actually super neat. I’ve had this for about a year now or so.
Name: Debug Agents Description: Allows creators to spawn simulated player agents (dummy characters) that are treated as FortCharacter[] in scripts. Command type: Action Label: Spawn Debug Agent Range: N/A Values: N/A Implementation details:
When executed, the command spawns a debug agent (dummy player) into the current playspace. These agents are fully recognized as FortCharacter objects and included in queries such as GetPlayspace().GetPlayers(). They can be teleported, eliminated, and otherwise interact with Verse logic as if they were real players. This enables creators to test multiplayer mechanics (teleportation, triggers, elimination logic, etc.) in solo sessions without needing additional players. Debug agents would be accessible from Island Settings → Debug for easy management (spawn, despawn, reset).
Data:
Creators can optionally toggle AI behaviors: Idle, Attack Nearby Players, Roam, or Follow Player.
Debug Overlay (toggle via shortcut key)
Displays a floating notification above each debug agent showing real-time properties:
Health / Shields
CanAccessPickaxe? (true/false)
CanDestroyBuild?
CanJumpHere?
CanFireWeapon?
CanBuild?
CanEdit?
Inventory view: items, ammo counts, and building resources.
Use Cases
Test multiplayer mechanics solo (teleportation, elimination logic, mutator zone conditions).
Validate inventory systems, combat interactions, and build restrictions.
Debug mutator logic quickly by seeing whether conditions are enforced per agent.
Agents would be accessible from Island Settings → Debug for management (spawn, despawn, behavior toggle, reset).
Name: Screens Viewer (Replay Mode for Test Players)
Description: Allows to check the last 5mins of a test player screen, useful for multiplayers games where you would need to check if Verse UI/mechanics behave correctly.
Command type: Action
Label: Check Test Players Screens
Range: N/A
Values: N/A
Implementation details: This would appear in the top bar next to the “Current Active” users button once the game is ended, it would have saved on disk up to the last 5mins of test players screens. That would add a next/previous/pause/play buttons in the viewport and see their actual screen in the viewport itself, like a “replay mode” for test players.
Related to other features you mentioned (such as debug overlays with information about the agent): That would be a completely different debug command, since it is nothing related to test players at all… Nothing would prevent you to enable it to see actual real player data for example.
Name: [DEVICE FUNCTIONS/EVENTS]
Description: Manually activate a device function/event.
Command type: Action.
Implementation: allows the creator to search for a device, and activate a function or event (useful for testing timers or RNG-based events quickly, without changing the settings)
