Pro Tip · EXTRA

Referencing Your Own Modules Across Folders, the Right Way

Lesson 3 taught you to using the official modules — but the moment a project splits into multiple folders, "how do I reference my own module?" becomes the question asked over and over on the forums. This page distills the community's battle-tested rules into a cheat card: four rules covering same-directory, subfolder, and nested-module scenarios.

1. A Two-Level Example Project

First, set up a target. Say your project's Content looks like this — recall from Lesson 3: every folder automatically becomes a module of the same name:

hub_device.verse — the main device, sitting at the top level
combat/ — a folder, i.e. the module combat
- damage.verse — defines a damage-calculation function
- skills/ — a subfolder inside combat, i.e. the nested submodule skills

The goal: let hub_device.verse use the function in the combat module, then work out how the nested skills should be imported.

combat/damage.verse

# The folder combat is the module name; definitions in this file fold into combat automatically
# To be usable from outside, members must be marked public (the module's own visibility is covered in extra x2)
CalcDamage<public>(Base:int, Bonus:int):int = Base + Bonus

(Reading the graph: this is simply a Blueprint function, CalcDamage — two integer input pins, Base and Bonus, outputting their sum; <public> hangs the "visible to the outside" sign on the function.)

Opening the member's door isn't enough — the combat module itself must be visible to the outside too. Place a same-named .verse file next to the combat/ folder and give the module its explicit declaration (the two-doors logic is explained in Rule 4 below):

combat.verse (sibling of the combat/ folder)

# A same-named .verse file declares visibility for the folder module; combat goes from default internal to public
combat<public> := module:

hub_device.verse

using { /Fortnite.com/Devices }
using { /UnrealEngine.com/Temporary/Diagnostics }
using { combat }

hub_device := class(creative_device):

    OnBegin<override>()<suspends>:void =
        Print("Total damage: {CalcDamage(10, 5)}")

(Reading the graph: this main device's three using lines tick three drawers open, one of which — combat — is your own; inside Event BeginPlay a Print String prints "Total damage: 15", where the 15 comes from calling CalcDamage(10, 5) out of the combat drawer on the spot.)

Look at line three: modules inside your own project need no domain-style long path — at the same level, the bare module name using { combat } is all it takes. This is one of the most common rookie mistakes: imitating the official modules with a made-up path like using { /combat.com/... }, which of course finds nothing.

2. The Cheat Card: Four Rules

Rule 1: same-directory modules — just write the name. using { your_module }, no slash, no domain.

Rule 2: modules in subfolders — use a local path. Shaped like using { /YourFolder/your_module }: it starts with / and is written from the project's code root downward. As for the full project path that includes your account, the exact form varies by account and project — don't memorize a template; go by the actual path generated in Verse Explorer.

Rule 3: nested modules — outer layer first, submodule second. This is a forum-verified hard rule: flip the import order and you get an outright error.

Import order for nested modules

using { combat }           # import the outer module first
using { combat.skills }    # then the submodule — flipping the order errors out

# You can also import only the outer module and reach submodule members with dot-qualified names:
# combat.skills.SomeClass

Rule 4: both the module and the member need public. Reaching a member across modules means passing through two doors: the module must be visible, and so must the member. Mark only the function <public> while the module stays default internal, and you still eat an access error — both doors have to open (for why the doors default to closed, see extra x2's history of the 23.20 overhaul).

Put the four rules together and you have the complete reference playbook for multi-file projects: names solve same-level, paths solve cross-level, order solves nesting, public solves permissions. However big the project grows, every reference problem falls under those four lines.

One last debugging tip: if the using errors with "module not found" no matter how you write it, stop and check two things — whether the folder name was changed recently (as Lesson 3 covered, the directory name is the module path, so renaming means moving house), and whether the error actually says "module not found" or "access denied". For the former, check the path and spelling; for the latter, check the two public doors. Telling these two error types apart will spare you most of the detours people take on the forums.

At the top of a file you write using { combat.skills } first, and only on the next line using { combat }. What does Build do?

Sources & Further Reading

Compiled from several highly active threads on the Epic developer forums: