Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/VazkiiMods/Quark/llms.txt

Use this file to discover all available pages before exploring further.

Quark maintains a high bar for contributions so that the codebase stays consistent and every change is genuinely worth the maintenance cost. Read this page in full before opening an issue or submitting a pull request — most rejected contributions can be traced back to missing information or unmet style requirements that are documented here.

​
Reporting Issues

Good bug reports let the team reproduce and fix problems quickly. Poor ones get closed. Follow the checklist below every time.
Always attach your log. Even if the game didn’t crash, the log often contains the information needed to diagnose the problem. Find it at:
  • Client: <instance folder>/logs/latest.log
  • Server: /logs/latest.log
Upload the file to pastebin.com and paste the link into your report.

​
What is accepted

  • Bug reports against the latest version of both Quark and NeoForge on the latest supported Minecraft version
  • Reproduction steps that work on a vanilla NeoForge installation (no other mods if possible)

​
What is not accepted

Issues filed against any version of Quark, AutoReglib, or Minecraft older than the current release are not accepted. Always update both Quark and NeoForge to their latest releases before reporting.
Bugs that only appear on Cauldron, Spigot, Sponge, or other hybrid server implementations are not accepted unless the issue can be reproduced on a standard NeoForge-only server.
Use the search feature before filing. Duplicates are closed without discussion. If the issue already exists but is still happening for you, comment on the existing report with the details you would have used for a new one. If the issue is locked, you may open a fresh report.
The issue tracker is for bugs only. Suggestions are not accepted here. Post them to the Quark subreddit (r/quarkmod) instead, unless a team member has specifically asked you to file one.

​
Pull Requests

​
Before you submit

Test on both client and server. Do not submit a pull request that you have only tested in singleplayer. Many Quark features touch server-side logic, and a change that works in a local world may break dedicated-server behaviour entirely. Use ./gradlew runServer to verify.
  • Do not use the GitHub web editor. Changes must be built and run locally before submission.
  • Small or superficial PRs that touch very few lines and are not flawless will likely be closed — it is often faster for the maintainer to apply the fix directly than to check out, review, and merge a partial patch.

​
Code style

Quark enforces syntax consistency across the entire codebase. Your PR must match the style of the surrounding code. The key rules are:
Write if(condition), for(...), while(...) — not if (condition). This applies to all control-flow keywords.
// ✅ Correct
if(stack.isEmpty()) {
    return;
}

// ❌ Wrong
if (stack.isEmpty()) {
    return;
}
Opening curly braces go on the same line as the statement, never on a new line.
// ✅ Correct
public void doThing() {
    // ...
}

// ❌ Wrong
public void doThing()
{
    // ...
}
Omit curly braces when a block contains exactly one statement.
// ✅ Correct
if(flag)
    doSomething();

// ❌ Wrong
if(flag) {
    doSomething();
}
All identifiers — fields, methods, local variables — use camelCase. Classes and interfaces use PascalCase. Constants use SCREAMING_SNAKE_CASE.
Indent with tabs, not spaces. The entire Quark codebase uses tab indentation. Configure your editor accordingly before committing.
You can check your code statically with the bundled PMD ruleset: 
./gradlew checkSyntax

​
Release Process

Releases are handled by the core Violet Moon team. The process is mostly automated once the release tag is pushed. The steps below are provided so contributors understand how version numbers work and what build.properties tracks.
1

Sync and verify

Pull master to make sure you are fully up to date, and confirm that all changes intended for the release are committed.
git pull origin master
2

Create the annotated release tag

Tags use the format release-<mc_version>-<build_number>. Look up the current values in build.properties if needed (e.g. mc_version=1.21.1, build_number=481):
git tag -a release-1.21.1-481
Git will open your configured editor. Write the changelog for this release in the editor, then save and close it.
3

Increment the build number

Open build.properties and increment build_number by one so the next development build gets a fresh version:
build_number=482
Commit this change:
git commit -m "Increment build number to 482"
4

Push master and the tag

Push both the updated master branch and the release tag together:
git push origin master release-1.21.1-481
5

Automated publishing

Shortly after the tag is pushed, the CI pipeline picks it up and automatically publishes the release to:
  • GitHub Releases — with the changelog written in step 2 attached
  • Modrinth
  • CurseForge
No manual upload is required.

​
Release Signing

All official Quark releases are signed with the Violet Moon signing key. This lets you verify that a downloaded JAR genuinely came from the Violet Moon team and has not been tampered with. See the Violet Moon security page for instructions on verifying artifact signatures.

Build docs developers (and LLMs) love

Get started for freeTalk to us