Hot Reload Without Restarting: Push Verse Changes and the Iteration Workflow
In the main lesson you learned the full Build → drag-and-drop → Launch Session pipeline. But if every one-line code change meant ending the session and relaunching, you would spend most of the day staring at loading bars. This page covers Push Verse Changes — the mid-session hot-reload button — plus the incremental cooking that makes iteration absurdly fast.
1. A Session Is Not a One-Shot Deal: Editor and Client Stay Live-Connected
Many newcomers assume Launch Session works like shipping a package: once the game is running, the editor no longer gets a say. It is exactly the opposite — during playtesting, the UEFN editor and the game client hold a live connection: move a wall in the editor viewport or tweak a device setting, and the change syncs instantly into the running client. Testing your island was always meant to be an “edit while it runs” experience.
For code, though, syncing is not fully automatic — you have to push it yourself. The toolbar has two relevant buttons:
- Push Changes — pushes all project changes: scene, assets, device settings, code — the whole lot synced into the session at once;
- Push Verse Changes — picks up and pushes only changes to .verse files: effectively a “Verse hot reload” — no session restart, the new logic just swaps straight in.
So the standard three-step move for changing code mid-session is: edit the .verse code → Build Verse Code (Ctrl+Shift+B) until it compiles → click Push Verse Changes. A few seconds later the session is running your new logic — no quitting, no reloading the whole island.
2. The 41.00 Speed-Up: From Full Cooks to Incremental Cooking
“Cooking” is the process of converting project content into a format the game can load — and it is the slowest step in pushing changes. Before version 41.00, every Push Changes meant a full cook: change even a single line of code and the entire project got re-baked; the bigger the island, the longer the wait.
In the 41.00 Fortnite ecosystem release notes, Epic announced that from that version onward Push Changes uses incremental cooking, baking only the parts of the project that were modified. For large projects this shrinks the push wait from “go pour yourself a drink” to “blink twice” — a dramatic boost to iteration speed.
String the machinery together and the efficient workflow looks like this:
- Small, fast steps: change one small piece of logic at a time, Build → Push Verse Changes, verify in the session immediately;
- Non-code changes (moving devices, swapping assets) proceed as usual; use Push Changes when they need syncing;
- Only big changes (say, renaming a class so the instances in the level lose their reference) warrant ending the session and relaunching.
- Only big changes (say, renaming a class so instances already placed in the level can no longer find the Blueprint they belong to — a broken reference) warrant ending the session and relaunching.
3. Hot Reload Is No Silver Bullet: The Fallback When It Fails
Time for a splash of cold water: Verse hot reload is not one hundred percent reliable. The forums carry plenty of Verse Hot Reload failure reports — clients crashing back to the lobby after a push, sessions stuck frozen at “Session Updating”, and so on. When that happens, don’t grind against it; the fallback is blunt and simple: end the session and Launch Session again. A freshly launched session is always clean.
A practical rule of thumb: if the game behaves strangely after a push (old logic haunting the place, state gone scrambled), suspect a failed hot reload first — restart the session to verify — and only then suspect your own code. That saves you enormous amounts of time otherwise spent “debugging a bug that does not exist”.
A session is running and you have changed logic in just one .verse file. What is the fastest correct way to get the new code in?
4. Sources
This page is distilled from official Epic documentation and the developer forums: