Undo and Staying Safe
After this page you will know how to reverse anything Revix does, which few things undo will not save you from, and the working habits that keep a big place out of trouble.
Undo is real Studio undo
Every change Revix makes lands on Studio's own undo stack as its own step, labelled with Revix: and a short note of what it did. Steps where it only looked at something are left off the stack, so browsing your game never clogs it up.
That means Ctrl+Z works exactly as it always has. Press it repeatedly and you walk back through the build, one change at a time. Ctrl+Y (or Ctrl+Shift+Z) walks forward again.
Or just ask
You do not have to leave the chat. Revix can drive Studio's undo for you, up to 20 steps in one go:
Undo thatUndo the last 5 things you didThis is the same undo — it is not a separate history. Whichever way you do it, the result is identical.
One undo step can be a lot
Revix batches work. A curved wall, a whole tower, a facade of windows or a row of lamp posts is often built in a single operation, so all of it is a single undo step. That is efficient, but it means one Ctrl+Z can remove a hundred parts.
Undo one step, look at what disappeared, and only then decide whether to keep going.
What undo will not save you from
Generating a map clears the existing terrain first. A new world wipes what was there before it builds. Do not treat undo as a safety net for this one. Generate your world before you build anything on it, and if you already have a place you care about, try it in a fresh place first. The same applies to a request to erase the world.
A step that timed out may still be running. Any single piece of work is cut off after 60 seconds and reported as failed — but Studio may still be finishing it in the background. If you see a timeout, look in the Explorer before you re-send the same request. Re-running something that actually succeeded gives you two of everything.
Saved animation clips are not a workspace change. A generated animation is saved onto the rig, in its AnimSaves folder. If you do not want it, delete it from there.
Once you save and close, you are on Studio's terms. Undo lives in your Studio session. Close the place and the stack goes with it. Revix does not keep a copy of your game to restore from.
Stopping a run
The send button becomes a red Stop button while Revix is working. Press it and everything built up to that point stays in Studio — you get a note saying so.
Two things worth knowing:
- Closing the browser tab does not stop the build. It keeps running, and reopening the dashboard reattaches you to it live. If you actually want it to stop, press Stop.
- If the plugin disconnects mid-build, Revix force-stops itself and shows a card headed Plugin Disconnected. That is deliberate — it stops half-finished changes and wasted credits.
When a long build runs out of room, it does not silently abandon the work. It tells you what landed and where, and you send continue to pick up from there. Nothing is rolled back.
Habits that keep a big place safe
Save before a big ask. One keystroke, and it turns "I have to undo carefully" into "I can just reopen the file".
Work in chunks. "Build the shop screen" then "now wire the buttons" beats "build a full shop system with data saving and a UI". Smaller turns are easier to review, cheaper, and far easier to undo when one part is wrong.
Review before you publish. Revix edits your open place; it never publishes for you. Nothing reaches your live game until you press Publish yourself. Use that gap — press Play, click the thing, read the Output window.
Ask it to check its own work. This is free advice it will act on:
Scan the castle for problems — gaps, unanchored parts, anything overlapping — and list what you findBelieve the "heads up" section. Every finished build ends with a note about anything it could not verify. Anything that only happens for a live player — buttons, camera, input, respawning — is checked by reading code, not by running it. That part is your job, and one playtest usually settles it.
Try risky ideas in a spare place. Terrain generation, a big restructure, a sweeping refactor — do it once in a scratch place, see what you get, then do it for real.