Making a Custom Admin Panel in Fortnite (UEFN & Verse Tutorial)

Name: Making a Custom Admin Panel in Fortnite (UEFN & Verse Tutorial)
Uploaded: 2025-10-21T20:37:37.000Z
Duration: 2 h 4 min 21 s

Creating a Custom Admin Abuse System in Your Game

Introduction to the Admin Panel

The video introduces a custom admin abuse system that allows game creators to control various aspects of their game, including trolling players and granting special items.

Viewers are informed about free code and assets available by joining the community, with an emphasis on no strings attached.

The creator promotes the "Map Creator Success Program," which offers extensive resources for aspiring map creators, including scripts and tools.

Setting Up the Admin Panel

The tutorial begins with opening Verse Explorer to create a new script named "R admin panel controller."

A player map is established to track whether each player has admin abuse powers, initialized as true or false.

The process includes adding players into this map upon their entry into the game using an initialization function.

Player Initialization Process

The script iterates through all players in the play space during initialization, ensuring that newly joined players are also accounted for.

An event subscription is set up for handling players who join after the initial setup, linking them to the initialization function.

Creating Triggers for Admin Abuse

Two triggers are created: one for enabling and another for disabling admin abuse. These will allow toggling of powers for individual players.

The creator mentions using GitHub Copilot as a helpful coding tool while developing these triggers.

Functionality of Triggers

Event subscriptions are established for both enable and disable triggers, linking them to respective functions that handle activation and deactivation of admin powers.

In defining these functions, an optional agent parameter is included to accommodate scenarios where triggers may not be activated by a player directly.

Handling Player Activation

Inside the enable function, checks ensure that only valid agents (players) can activate admin abuse features; this involves converting agents appropriately.

Clarification is provided on differentiating between 'agent' and 'player,' emphasizing that only real Fortnite players can be used within certain contexts.

Admin Panel Creation in Game Development

Setting Up Admin Abuse Control

An agent can be defined as a guard or creature, and the admin abuse setting is adjusted from false to true for functionality.

A simple system is established to enable or disable admin abuse for each player using a logic variable, although it currently lacks practical application.

Creating the Control Panel

The control panel will allow activation of admin abuse through various triggers; a pin pad code is suggested for personal use.

An "open admin panel" trigger is created, which can be connected to different devices like buttons or input triggers.

Developing the User Interface (UI)

A custom class named admin panel is introduced to hold UI components, with an emphasis on accessing main creative device variables.

A function called add UI is created within the class to manage player UI elements without returning any values.

Building UI Elements

The player's actual UI is retrieved using a new library; errors may occur if this library isn't included properly.

A main panel canvas variable is established to contain all other widgets needed for the interface.

Designing Widget Blueprint

A mockup widget blueprint named mockup admin panel is created in UFN, serving as a template for further development.

The initial design includes dragging a canvas panel into place and adding an image widget that serves as a background with specific dimensions and opacity settings.

Player List Integration

A stack box widget will display all players in-game; its orientation will be vertical for better organization.

Each player entry will consist of a canvas panel containing their name, ensuring proper alignment and sizing for clarity.

Creating a Player Activation Interface

Setting Up the Button

The speaker discusses adding a button labeled "activate" beneath a canvas panel, ensuring it is centered and adjusting its size to fit the text.

The button's position is set to 200 on the right side of the screen, with both the button and text size adjusted to 40 for consistency.

Configuring Multiple Players

The speaker explains copying the stack box to create multiple player panels, emphasizing that each player can have unique triggers associated with them.

Adjustments are made to ensure the main canvas panel occupies the full screen (1920x1080), allowing for better organization of elements.

Trigger Mechanism Development

A focus on creating various triggers for players is introduced, including options like teleportation and freezing players.

Each trigger will be named (e.g., "trigger one") and linked to an activation button specific to each player.

Displaying Current Selection

A text block titled "currently selected" is added to indicate which trigger or action has been selected, enhancing user interface clarity.

Designing Additional Mechanics

Various buttons are created for different actions: teleporting players, freezing them, toggling invisibility, and activating all players simultaneously.

The speaker outlines additional functionalities such as flight controls and visibility toggles for comprehensive player management.

Admin Panel Class Implementation

Discussion shifts towards implementing these features in an admin panel class by defining background properties using color blocks.

A new stack box is created for organizing player elements vertically within the canvas panel structure.

Custom Class Creation

Introduction of a custom class called player select class, which includes attributes like player name and activation buttons without needing initialization.

An array of player select classes is established alongside necessary canvas panels for effective UI management.

Creating a Trigger System

Setting Up the Trigger Sack Box

The process begins with creating a "trigger sack box," which is similar to an existing player select class but specifically for triggers.

The trigger select class will be assigned to a trigger device, and the button type can be modified as needed.

Configuring Text Blocks

A text block named currently selected text is initialized as a string, starting with default text set to "N/A" since no initial text exists.

An error arises due to the need for this text block to be of type message; thus, it must be created and localized properly.

The default text color is set to white, although it's noted that this may not be necessary since white is typically the default.

Creating Buttons for Actions

The first button created is labeled "teleport to," with its type defined as button loud. Default text can also be customized.

Additional buttons are added, including options for freezing/unfreezing players and toggling invincibility on/off. An "activate for all" button is also included.

Adding UI Elements

The next step involves adding these buttons into the main panel canvas by utilizing add widget functionality.

A background color block is established within the canvas slot, ensuring proper alignment and layering of UI elements.

Configuring Canvas Panel Properties

Anchors are set up using vector 2's for both minimum and maximum values at (0.5, 0.5), centering them in the script.

Offsets are defined using margin values corresponding to specific positions on the screen (left: 0.0, top: 0, right: 1920, size Y: 1080).

Finalizing Widget Setup

Z-ordering ensures that the background remains at layer zero while other elements are placed above it at layer one.

To streamline code efficiency, repetitive lines are minimized by copying existing configurations while maintaining necessary adjustments like offsets and widget types.

Creating and Initializing Widgets in Canvas

Setting Up the Second Canvas Slot

The process begins with copying and pasting to create a second canvas slot, emphasizing the importance of maintaining the Z order for proper layering.

Adjustments are made to widget values, specifically setting left and top positions to 575 and -100 respectively, while changing the widget type to "player stack box."

Adding Widgets and Buttons

The next step involves copying values from a trigger stack box into new widgets, ensuring all necessary buttons are created efficiently.

After creating all buttons, attention shifts to initializing these buttons within their respective stack boxes.

Handling Player Data

A challenge arises when trying to access player data due to naming conflicts; renaming variables helps resolve this issue.

It is noted that accessing play space requires referencing a creator device located within it, leading to adjustments in how player data is retrieved.

Initializing Player Select Classes

For each player in the game, a new player select class is instantiated with specific initialization values including player details.

Various components such as player name text blocks and activate buttons are defined for each player's canvas.

Finalizing Widget Setup

Both the player name text block and activate button are added to the player's canvas; careful attention is given to ensure proper alignment of elements.

The newly created player canvas is then added back into the main stack box with default fill settings for horizontal and vertical alignment.

Text Initialization Functions

To set up text properties for players' names and button labels, functions are created: one converts agents into messages while another converts strings into messages.

These functions streamline assigning default texts based on assigned players or button actions.

Player Selection and Trigger Setup

Implementing Player Selection Functionality

The term "select" is chosen for the button functionality, which is shorter than "activate" and fits well with the widget blueprint.

The onclick event for the activate button will send a widget message but won't provide the specific player selected; thus, an alternative approach is needed.

A new function named track player selected button is created to handle player selection, taking in the entire new player select.

A loop is established to wait for button presses, calling a function named handle player selection each time a button is pressed.

The setup ensures that when the UI closes, it stops subscribing to events by implementing a race condition with a custom event called UI closed event.

Setting Up Admin Triggers

A new class called admin triggers is introduced to manage trigger devices associated with players' selections.

An editable property for selecting trigger types and names as strings is defined within this class.

An array of these admin triggers is created in the main device class to facilitate multiple trigger management.

A loop iterates through all admin triggers, creating instances of a new class called trigger select, which includes necessary components like canvas and buttons.

Each trigger's canvas receives its corresponding button setup, ensuring that text reflects each admin trigger's name accurately.

New Trigger Selection Implementation

Function Setup for New Trigger Selection

The new trigger selection function is created by copying an existing function, modifying its name and parameters to accommodate the new trigger select of type trigger selected class.

The handling mechanism shifts from player selection to button selection, with a focus on setting the new trigger select name.

Handling Button Selection

Inside the button selection handler, the currently selected text is retrieved and updated using set text to reflect the new name.

An error is identified due to a missing name in the trigger select class, which is resolved by utilizing the activate button's text instead.

Updating Trigger Select Classes

The array of trigger select classes is updated with the newly created trigger select, while player data management is simplified by removing unnecessary elements.

Button Configuration and UI Adjustments

Adding Additional Buttons

A series of buttons are configured quickly; starting with copying an existing teleport button and renaming it appropriately.

A close button is added following similar steps as previous buttons, ensuring proper positioning within the UI layout.

Finalizing Button Text Assignments

All buttons are assigned their respective texts through a streamlined process before final adjustments are made.

Subscription Management for Buttons

Tracking Button Events

A tracking mechanism for all buttons is implemented to ensure they unsubscribe when the UI closes.

The subscription setup includes event handlers that link each button's click action to their respective functions.

Handling Player Activation

For activating actions across players, logic ensures that only players other than the one who opened the UI are affected. This involves retrieving player messages correctly.

Closing UI Functionality

Implementing Close Functionality

A dedicated function for closing the UI is established, ensuring it properly handles player messages during closure events.

Final Steps in Subscription Management

With all subscriptions set up effectively, attention turns towards ensuring that actions correspond with selections made in the interface.

How to Implement Teleportation and Player Control Features

Setting Up Button Logic

The process begins by comparing the selected text with the button's text, specifically for the teleportation feature.

A rollback effect is not applicable here; thus, a direct string comparison is used to ensure consistency in button functionality.

Accessing Player Information

To implement teleportation, access to the admin player is required. This involves capturing the message from the click event.

The function must be updated to include parameters for both the admin player and the selected player.

Teleportation Mechanics

A teleporter device needs to be integrated into the main device setup for executing teleportation commands.

The code structure includes defining variables for both admin and selected players' characters to facilitate accurate teleportation.

Additional Player Actions

If conditions are set up for various actions like freezing or killing players based on selected text inputs.

Specific functions are defined for freezing (putting in stasis) and unfreezing (releasing from stasis), ensuring correct capitalization in function calls.

Class Changes and Visibility Controls

The script allows toggling flight mode by changing classes through a class selector device based on user input.

Invisibility features are implemented using visibility settings, while invincibility toggles vulnerability states without hiding characters.

Trigger Activation Logic

Admin triggers are activated by matching trigger texts with button texts, allowing specific actions tied to each trigger.

Performance can be optimized by implementing return statements within loops or using else-if structures to minimize unnecessary checks.

Admin Panel Development Process

Adding UI Elements

The process begins with adding the user interface (UI) for the admin panel, specifically integrating it into the player’s UI by using player UI add widget to attach it to the main panel canvas.

The input mode is set to UIinput, ensuring that the player's mouse control is captured effectively when interacting with the admin panel.

Handling UI Closure

To manage closing the UI, a function is implemented that removes the widget from the player’s view and signals a close event, which cancels ongoing processes or races.

Admin Panel Functionality

A new instance of an admin panel class is created within an open admin panel function, allowing for dynamic interaction as players access this feature in-game.

Testing of these functionalities occurs within a game environment, where an admin panel controller is enabled through a trigger device.

Trigger Device Setup

An enable button for the admin panel is created alongside its corresponding trigger device. This setup helps players understand when they can access administrative features during gameplay.

Duplicate triggers are established for enabling and disabling functions, ensuring clear labeling and functionality for both actions.

Custom Triggers and Effects

Two custom triggers are introduced: one displays a HUD message while another provides a speed boost effect. These demonstrate how various functionalities can be integrated into gameplay.

Additional devices like teleporters and class selectors are incorporated to enhance player experience further, allowing for more complex interactions within the game environment.

Final Adjustments and Testing

An input trigger device is added to facilitate quick access to open the admin panel anywhere in-game. It requires players to be registered before accessing these features.

Before finalizing testing, checks are implemented to ensure that only players with appropriate permissions (admin abuse turned on) can access certain functionalities of the admin panel.

Admin Panel Functionality Overview

Setting Up the Admin Panel

The admin panel is designed to manage device access, requiring integration with the admin panel controller for functionality.

Before testing, it's crucial to clear any existing triggers from the admin panel button to ensure a clean start.

Testing the Admin Panel Features

Upon enabling the admin panel, an input trigger appears, allowing access to various options within the panel.

Users can teleport between players by selecting them from a list; this feature enhances gameplay interaction and dynamics.

Advanced Admin Controls

The admin can enable flight mode for themselves or other players, showcasing flexibility in game mechanics.

Additional features include invisibility toggles and player elimination capabilities, providing extensive control over game scenarios.

Customization and User Interaction

The admin can send messages (e.g., "hi") to specific players and apply speed boosts for enhanced gameplay experience.

Custom buttons can be added manually for tailored functionalities within the admin panel.

This structured overview encapsulates key functionalities of an in-game admin panel as discussed in the transcript.