Why exact versions matter
Minecraft mods are compiled against specific game and loader APIs. “Fabric mod” or “Forge mod” is not enough information. A mod built for Minecraft 1.20.1 may not load on 1.21.1, and a loader release that supports one snapshot may not support the next. SPUDZWARE resolves compatibility using the selected game version rather than assuming the newest loader is always correct.
The five loader choices
| Loader | What SPUDZWARE treats it as | Common mistake |
|---|---|---|
| Vanilla | A real user-facing base-game choice. | Assuming an internal bootstrap means the user selected Fabric. |
| Fabric | Its own loader metadata, libraries and entrypoint. | Installing a Fabric mod for the wrong Minecraft version. |
| Quilt | A separate runtime adapter and Quilt metadata. | Assuming every Fabric runtime is automatically a Quilt runtime. |
| Forge | Forge metadata, libraries and processors. | Treating Forge as if it were a simple mod JAR. |
| NeoForge | A separate loader family with its own releases. | Relabeling Forge artifacts as NeoForge. |
What the launcher should resolve
For each selection, the runtime resolver needs the Minecraft version, loader type and loader version; the appropriate Java generation; libraries and assets; platform-native files; renderer requirements on mobile; VR components when VR is enabled; and final JVM/game arguments. If any required piece cannot be satisfied, the launcher should explain the missing requirement instead of producing a fake Ready state.
Mods add another compatibility layer
A mod can declare a Minecraft range, loader dependency, required API mod and other dependencies. SPUDZWARE should distinguish a top-level mod file from a nested dependency bundled inside another JAR. That distinction is particularly important for Fabric API modules and Modrinth packs, where naive scanning can produce false “duplicate mod ID” errors.
Modpacks should define their own instance
A Modrinth .mrpack contains a manifest that declares the game version, loader requirements and files. The importer should treat that manifest as the source of truth, stage downloads, verify hashes and apply overrides. If a pack asks for a different version or loader than the currently selected instance, the safer default is a dedicated pack instance rather than silently mutating an unrelated setup.
Java is part of compatibility
Newer Minecraft generations can require a newer Java runtime. The launcher manages Java as a runtime component so users do not have to manually point every instance at a system-wide install. Validation should know whether Java is newly installed, already present or missing; it should not show final validation as active while a required Java component is still genuinely queued.
VR adds platform requirements
On Meta Quest, a loader combination also has to satisfy Android ARM64, mobile rendering and OpenXR requirements. That is why the Quest runtime matrix is evaluated per exact version and loader instead of treating a desktop Vivecraft build as universally portable.
A practical decision order
- Pick the Minecraft version required by your world, server or modpack.
- Pick the loader required by the mods/modpack.
- Use a compatible loader version rather than “latest at any cost”.
- Install required APIs/dependencies only when the pack or mods do not already provide them.
- Validate the runtime before adding more variables.
- Change one major compatibility dimension at a time when troubleshooting.