VyroAI

Loading...

Build History

Every past build of a project with its result, duration and .jar size, the success rate at the top, starring the builds that must stay downloadable, and rolling back to one.

Where to find it

Open the Build & Export menu in the toolbar and pick History to see the project's past builds — when each one ran, whether it succeeded, and how long it took.

The three figures at the top

Above the list sit three figures: Total Builds, Success Rate and Avg Duration. They are worked out from the builds the panel has loaded, which is the project's 20 most recent, so Total Builds stops at 20. The success rate is coloured: green at 80% or more, amber from 50%, red below that. A project that has started failing more often shows it at a glance.

Each build in the list also shows its own .jar size, so a build that suddenly doubled in size stands out.

Unstarred builds expire

A recent build is not kept forever. The History panel in the Code Studio does not say so — the warning lives on your project's public page, where the Builds list marks them RECENT · auto-expire — star ★ to keep. Once one has expired, its download button is replaced by a grey Expired label that cannot be pressed, and its star is switched off: rebuild to get a fresh one. If the .jar from an earlier build matters to you, star it while it is still there.

Favorite the ones you want to keep

The recent list is a rolling one: older builds drop off it as new builds push them down. A build you want to keep for good becomes a favorite — press the star (★) on your project's public page under Builds, and the app confirms it is saved as a permanent favorite. Favorites are permanent — they never expire, they stay downloadable no matter how many times you rebuild, and they sit at the top of the list where visitors can find them.

This is the one to remember before a release: favorite the build you are shipping.

Free accounts can keep 5 favorite builds per project. Reaching the limit does not delete anything — it just refuses the sixth favorite until you remove one. VyroAI+ removes the limit entirely.

Rebuild and Rollback

Open a successful build in the Builds tab and two more buttons sit under Download JAR:

Rollback asks first: "Rollback to this build?" — "This will restore your project files to the state they were in when this build was created on … Your current work will be saved as a new version first." Press Rollback and the files are swapped, the panel closes, and Project rolled back to build state confirms it.

This is the one-click answer to the last build worked and the AI has broken it since. Nothing is thrown away on the way: what you had is saved in Version History first, as Before restoring to v…, so you can go forward again.

A greyed-out Rollback means there is no snapshot

Every build files a copy of your project in Version History, named Build snapshot: <project>, and Rollback restores that copy. A build without one — an older build, or one whose snapshot could not be saved — shows the button greyed out, with No snapshot attached to this build when you hover it.

Delete that version in Version History and the build loses its snapshot as well: the next time the Builds tab loads, its Rollback is greyed out in the same way. A build so old that its snapshot is past the 50 newest versions the panel loads is different: there the button stays lit but does nothing when you press it.

Comparing builds

The panel can compare two builds against each other, which is the quickest way to answer what changed between the version that worked and the one that does not.

Compare sits at the top of the History panel, and it is only there once the project has two builds or more. Press it, then tick two builds in the list — a line reads Select 2 builds to compare (1/2) as you go, and ticking a third quietly drops your first pick. Press Compare Selected to open it.

The result replaces the list, headed Build Comparison, with the older build on the left and the newer on the right however you ticked them. Four rows change hands: Build Duration, JAR Size, Errors and Warnings, each written as old → new with the difference beside it — a jar that grew is amber, one that shrank is green. If the newer build failed, its errors are listed underneath as New Errors. Close it with the × in the corner; that clears your ticks and switches Compare off again.

Building automatically

For plugin and mod projects, an AI run usually ends with a Build check: the server compiles the finished files itself and puts the result under the reply, either the .jar or the errors with an Auto-Fix button. If the check fails, the server first tries to repair the build itself, and the line says so when it succeeds. When the build check has given its verdict, nothing is compiled a second time, so you get one build card per run.

In the Build & Export menu, Auto-compile after AI covers the runs that end without a verdict (the check was skipped, timed out or couldn't run): those are built as soon as the run finishes, instead of waiting for you to press Build. Next to it, Stop on error (no auto-fix), which is on by default, stops the AI from patching a failed Auto-compile build by itself, for when you'd rather read the error first.

After a failed build check, Auto-Fix never starts by itself, whatever these switches say. Press Auto-Fix on the build check's card when you want the AI to try, or Build to compile again yourself.

Since the build check already compiles most plugin and mod runs, Auto-compile mostly matters when a run ends without one. Leaving it on costs nothing extra, because it no longer builds a run the server has already built.

Also in Code Studio (IDE)

24 of 37 in Code Studio (IDE) · Last checked 17 September 2026 · Previous: Version History