Forking

Taking Vantage's code and making it your own mod - what the licence asks, what to rename, and every place the code still points at Vantage's own infrastructure.

This page is for you if you want a mod of your own built from Vantage's code. It covers what the licence lets you do, how to get the code, what to rename so the result is plainly yours, every constant that still points at Vantage's own servers and what to do with each, and the licences of what ships inside the jar. How to build it is on the next page, Building; the short version of all of this is on Fork it.

Why fork at all

A hobby mod that lives in one repository lives exactly as long as its maintainer's interest. Forks keep ideas alive: someone who wants a different feature, a different look or a different game mode can take the code and ship it, without asking and without waiting. Vantage is MIT-licensed so that you can.

You do not need permission, and you do not need to send anything back. If you do want to send a change back, Contributing says how.

What the licence lets you do

The licence is MIT. In plain words, you may use the code, copy it, change it, merge it into something else, publish it, distribute it, sublicense it and sell copies of it. There is one condition: the copyright notice and the permission notice go with every copy, or every substantial portion, of the software. The line to keep is the copyright line in the repository's LICENSE file:

Copyright (c) 2026 CherishEv

Keep the LICENSE file in your repository as it is. You do not have to do anything to keep it in the jar: the jar block in build.gradle copies LICENSE into every jar, renamed after the archive's base name.

jar {
    from('LICENSE') { rename { "${it}_${project.archives_base_name}" } }
}

So a jar built as vantage carries LICENSE_vantage, and once you change archives_base_name it carries the licence under your name instead, with no further edit.

Get the code

The mod's repository is public at gitlab.com/Ekoss/vantage, and its default branch is main. Either fork it on GitLab, which gives you a copy under your own account with the history intact, or clone it and push it wherever you like:

git clone https://gitlab.com/Ekoss/vantage.git my-mod
cd my-mod
./gradlew compileJava test

The last line is the check the project itself treats as the gate. If it passes on your machine, your toolchain is right and you can start changing things. If it fails, Building lists what you need and the usual reasons.

Only the mod is a public repository. The service behind the profile viewer, bug reports and Vantage Stats, and the Discord bot, are not public. A fork does not need either of them to build or to run; the section Point it at your own things says exactly what changes without them.

Make it yours

Renaming is not something the licence asks of you. It is what makes your mod a different mod: to Fabric, which loads mods by id, and to players, who should be able to tell your jar from Vantage's at a glance.

Name and id

These are the values that decide what Fabric and players see. Change them together.

Vantage.MOD_ID is more than a label. Vantage.configDir() resolves <minecraft>/config/<mod id>, so changing it moves your mod's settings folder away from Vantage's. Vantage.id(path) builds every identifier in the mod's resource namespace, so the folder src/main/resources/assets/vantage/ has to be renamed to match.

Resources that name the namespace

Inside assets/vantage/, a few files spell the namespace out as text rather than asking Vantage.id:

• font/ui.json names its typeface as vantage:inter-medium.ttf.
• lang/en_us.json holds the two key mapping names, key.vantage.menu and key.vantage.hud_editor, and the controls category key.category.vantage.vantage. The first two are written in core/ui/UiBootstrap.java; the category key follows from Vantage.id("vantage").
• vet.key is read by path in build.gradle (filesMatching('assets/vantage/vet.key')), in features/vet/VetCard.java, and in tools/release.py.

The mixin configs (vantage.mixins.json and one vantage.<area>.mixins.json per area) and the access wideners (src/main/resources-mc<version>/vantage.accesswidener) are file names, named in fabric.mod.json and build.gradle. You may keep them or rename them; if you rename one, rename its reference too.

Package

The Java package is dev.cherishev.vantage. You may keep it. If you rename it, these files name it as plain text and will not follow an IDE's refactoring:

The processor matters most. It reads @FeatureInfo by its fully qualified name, because it compiles before the mod and cannot import it. With the old name in FEATURE_INFO it finds no features, writes no GeneratedFeatureIndex, and features/Features.java, which iterates that index, stops compiling.

The look

Vantage draws everything with its own glass toolkit, and every colour comes from core.ui.Theme at draw time. You can keep the toolkit and change a preset, or replace it. The UI toolkit explains the contract it keeps, so you know what you are changing.

Point it at your own things

A handful of constants still point at Vantage's own infrastructure. Left alone, your players would be told about Vantage's releases, shown Vantage's announcements, and send their bug reports to Vantage's maintainer. Java paths below are under src/main/java/dev/cherishev/vantage/.

For each, either put your own value in, or switch the feature off. The update checker and the announcements are both features that are on by default (enabledByDefault = true in their @FeatureInfo); setting that to false ships them off. Their reference entries are Update checker and Announcements.

tools/release.py also hard-codes the jar prefix vantage-, the package name vantage in the generic package registry, and the assets/vantage/vet.key path inside the jar. If you renamed archives_base_name or the namespace, change those three as well.

The service

SyncEndpoints.DEFAULT_HOST is the one host for Vantage's own service. It is one constant on purpose: the rate limiter in Http.java is configured for the same name, so changing the constant moves both. Three things in the mod talk to it, plus the Check button beside Where profiles come from in API & Data Sources, which asks it whether it holds a Hypixel key; nothing else does.

Prices, the Bazaar, auctions, the item repository, the datasets, the mayor, the update checker and the announcements do not go through the service; they read public sources directly.

You have three choices: run a service of your own and change the constant; switch the two features off and leave the bug command unused; or leave them reaching Vantage's service. The repository does not say a fork may keep using Vantage's service, so this page does not assume it. For development, the JVM property -Dvantage.api=<url> points a running game at another base URL without a rebuild; there is deliberately no in-game option for it. The service describes what the mod expects from the other end.

The Vet card

The Vantage Vet feature signs a short code, the Vet card, that Vantage's Discord bot reads. The signing key is baked into assets/vantage/vet.key at build time from -PvetKey or the VANTAGE_VET_KEY environment variable, and is never committed: the file in the repository is the template ${vetKey}. A build with neither falls back to a development key, says so once in the log, and signs cards that a real bot rejects.

Vantage's bot is private and holds Vantage's key, so it will not accept your fork's cards whatever you do. What does matter to you is that tools/release.py refuses to publish any jar whose vet.key is not 64 hexadecimal characters. Either set VANTAGE_VET_KEY to 64 hex characters of your own, for a bot of your own if you have one, or take the check out of check_jars in release.py and ship the Vet feature off.

The CI pipeline reads three variables a fork would set or drop:

Releasing covers the release job in full.

Rules that come with the code

Three rules are not in the licence but come with the code, and a fork inherits them.

• No Hypixel API key in the mod. Hypixel's developer policy asks that API keys are not entered into publicly available mods. Vantage removed its key field for that reason, and its changelog entry for that release quotes the policy. Profile data therefore comes through a service that holds a registered key, not from the client.
• Read other mods for facts, never copy them. Skyblocker and SkyHanni are LGPL. Vantage's architecture notes allow reading them to learn facts - chat message formats, item data keys, dungeon room data - and forbid copying their code, because Vantage's licence is MIT.
• One place touches the Minecraft session. core/stats/sync/IdentityProof.java is the only code that reads the access token, and only to hand it to Mojang. Architecture explains the release check that keeps it that way.

Licences inside the jar

The jar carries more than Vantage's own code. Keep these licence files with the assets they cover.

Some data is not in the jar at all. Skyblocker's dungeon room data, the SkyHanni constants and the NotEnoughUpdates item repository are downloaded at runtime into config/vantage/data/ and config/vantage/repo/, so the jar carries none of them.

Then build it

Your fork is a fork once it builds under its own name. Building has the commands, the one flag to remember, and the second Minecraft target.

Related

• Building
• Architecture
• The service
• Releasing