Modded Minecraft Wiki
LogoAutoModpack

Building the modpack

The server builds a candidate generation from two sources. Both map onto the client's game directory, laid out like a .minecraft folder.

  • The group directory automodpack/host-modpack/<group>/ is included in full unless excluded. Files go here when the server itself has no use for them, for example client-side mods or when clear separation is needed.
  • The group's from-server rules pull files out of the server root. This is how the pack picks up the mods, configs, and scripts that already live on the server.

The default group id is main. After changing files or rules, publish a new generation with /automodpack generate; clients pick it up on their next connection. Publishing is described in generations.

The optional waiting track is automodpack/host-modpack/waiting-music.ogg. Drop or replace that file, then generate (or restart with generate-modpack-on-start). Clients stream it during downloads. On an installed pack's details screen, the music-note button plays the current advertised track without reinstalling the pack.

Example

A server with this layout:

├── automodpack

│   ├── server.conf

│   └── host-modpack

│       └── main

│           ├── config

│           │   ├── my-super.conf

│           │   └── shadow.txt

│           ├── mods

│           │   ├── fabric-api.jar

│           │   └── herobrine-mod.jar

│           ├── options.txt

│           └── shaderpacks

│               └── the-ultimate-shader.zip

├── config

│   ├── ferritecore.mixin.properties

│   └── invisible-radio.json

├── kubejs

│   ├── client_scripts

│   │   └── welcome.js

│   ├── common_scripts

│   │   └── recipes.js

│   └── server_scripts

│       └── datapack_loader.js

└── mods

    ├── automodpack.jar

    ├── fabric-api.jar

    ├── ferritecore.jar

    ├── modmenu.jar

    └── sodium-fabric.jar

and this group declared in server.conf:

modpack {

  name: ""

  General {

    main {

      from-server: [mods/*.jar, kubejs/**, emotes/*]

      exclude: [kubejs/server_scripts/**]

      editable: [options.txt, config/**]

    }

  }

}

produces this pack for clients:

├── config

│   ├── my-super.conf      (editable)

│   └── shadow.txt         (editable)

├── kubejs

│   ├── client_scripts

│   │   └── welcome.js

│   └── common_scripts

│       └── recipes.js

├── mods

│   ├── fabric-api.jar     (the host-modpack copy)

│   ├── ferritecore.jar

│   ├── herobrine-mod.jar  (from host-modpack)

│   ├── modmenu.jar

│   └── sodium-fabric.jar

├── options.txt            (editable)

└── shaderpacks

    └── the-ultimate-shader.zip

What the example shows:

  • mods/*.jar matches every jar in the server's mods folder. The AutoModpack jar itself stays out: clients update it through Modrinth to match the version the server runs, never through the pack. See AutoModpack's own updates.
  • Both sources contained mods/fabric-api.jar with different versions, and the host-modpack copy won. When the same path exists in both sources, the group directory decides.
  • kubejs/server_scripts/** is excluded, so the server's scripts stay on the server.
  • options.txt and everything under config in the pack is editable because editable says so.
  • config/ferritecore.mixin.properties and config/invisible-radio.json exist on the server but not in the pack. editable marks files that are already in the pack; it does not pull files in.

Editable files keep their copy in the game directory, mods included: a mod matched by editable, say mods/customizable.jar, materializes in the player's mods folder where they can edit or remove it. /automodpack generate warns when an editable rule matches active mods: a mod loaded from the standard mods folder needs a restart to update and sits outside AutoModpack's in-place mod management. Keep editable for configs and options. Use it for a mod when players are expected to replace that jar themselves, or when the mod breaks when loaded in place. Leave it out and the jar stays in the projection, untouched.

The exclude list in the example is trimmed for readability. The shipped default also excludes hidden files and *.tmp, *.disabled, and *.bak files (**/.*, **/.*/**, **/*.{tmp,disabled,bak}); replacing the default list drops that filtering.

Which files reach clients?

A file reaches clients when one of the two sources provides it: the group directory includes everything it holds, and from-server pulls matching files from the server root. AutoModpack does not care what a file is; the same rules move mods, configs, and everything else.

  • Keep a server file off clients: add its path to exclude. A server-side mod, for example, is kept off with mods/the-server-mod.jar. Each group also has auto-exclude-server-side-mods: the default METADATA drops jars whose own metadata says they are server-only. PLATFORMS also asks Modrinth and CurseForge. DISABLED ships every jar in that group.
  • Give clients a file the server does not need: put it in the group directory, for example automodpack/host-modpack/main/mods/.
  • Split fully: remove the mod rules from from-server and put every client mod into the group directory. The pack's mods then come only from host-modpack, and the server's mods folder stays server-only.

A ! rule inside from-server also skips a path, but only for the server root; the group directory can still provide the file.

File rules

from-server, exclude, and editable live on each group and are documented with the group settings. All three lists speak the same glob language, described in globbing.

One rule worth knowing early: the group directory is included in full, so exclude is the only way to keep a file there from reaching clients. Inside from-server, a ! rule skips a path only for that list; the group directory may still provide it.

Deleting content

Remove the file from the server, or keep it on the server and add it to exclude. On the next update, clients delete their copy. Updates replace files by the same rule: a file that changed on the server is replaced by the pack's new bytes, and the old copy is not kept in the game folder. The full rules are in client updates.

The editable policy

editable marks pack files that players may change. The default list is options.txt and config/**. The flag decides how a file behaves on the client:

  • An editable file is delivered as a real copy in the game directory. An editable mod jar lands in the player's standard mods folder and loads from there, so the player can replace or remove it.
  • Player edits survive updates until the server changes the file's content or removes the path from the editable list; either one delivers the pack's version exactly once.
  • The first install already counts as a delivery. A player who already has a file with the same name, a tuned options.txt for example, gets the pack's copy once, and the player's previous bytes land on the instance timeline first. The install review's "Keep existing mod files" consent covers mods only; files like options.txt are replaced without their own checkbox.
  • A non-editable file is kept identical to the pack.

editable never pulls a file into the pack, and an editable rule that matches no pack file only produces a warning at publish. The client-side mechanics are in client updates.

Default settings and keybinds

To give players default keybinds, settings, or config files, ship the files themselves. Put a prepared options.txt into automodpack/host-modpack/main/, or into any group folder. options.txt is on the default editable list. AutoModpack installs the pack's version when the player first gets the pack, and it never re-delivers that file over a player's edits. The pack's version comes again only when the server changes the file's content or removes the path from the editable list; in between, players own their edits.

To prepare the file, set the keybinds and settings in a plain Minecraft client, then copy that client's options.txt into the group folder. The keybinds are the key_... lines in that file, one per key. AutoModpack does not read or change options.txt; it delivers it like any other editable file.

Mods that inject default configs do not work here. A mod like Default Options applies its jar-embedded defaults only when the target file is missing, and AutoModpack writes the pack files during prelaunch, before any mod initializes, so the file already exists by then. If such a mod overwrites a pack file later anyway, the editable flag decides what happens: a non-editable file is silently reset to the pack's bytes on the next launch, and an editable file keeps the overwrite until the server changes the file. Ship the file itself, not a mod that pretends to ship it.

Resource packs and shader packs

Files in resourcepacks/ and shaderpacks/ ship like every other pack file, and /automodpack generate creates both folders in automodpack/host-modpack/main/ for you.

AutoModpack does not enable delivered packs, and there is no built-in Paxi integration. Vanilla does not turn on a pack just because the file exists. A player enables a resource pack in Options once, and the choice sticks, because their options.txt is editable. The choice sticks until the server changes options.txt's content; the server's version then replaces the player's file exactly once.

Two ways to auto-enable resource packs:

  1. Ship an options.txt that lists the pack under the resourcePacks key, and keep the file editable. Vanilla reads that key at startup.
  2. Ship Paxi as a client-side mod in automodpack/host-modpack/main/mods/, and put the resource packs in automodpack/host-modpack/main/config/paxi/resourcepacks/. Paxi loads that folder automatically.

Shader packs have no auto-enable. The player picks one in the shader mod's own menu.

Waiting music

Drop an .ogg at automodpack/host-modpack/waiting-music.ogg and players hear it during downloads. The file must stay under 5 MiB; publish refuses a bigger one. A player turns the music off with the play-music setting in the client config.

What never ships

  • AutoModpack's own jar. /automodpack generate never packs it and never publishes its updates: clients follow the AutoModpack version the server runs and pick the matching release up from Modrinth. To update players, update the jar on the server, restart, and clients sync to it on their next connection. The details, including sync-automodpack-version and self-updater, are in AutoModpack's own updates.
  • Mods whose metadata declares them server-side, when a group's auto-exclude-server-side-mods is METADATA or PLATFORMS (default METADATA). PLATFORMS also drops universal mods that Modrinth or CurseForge says clients never load. A preview reports those platform verdicts but keeps the jars, so you see what a publish would drop.
  • Hidden, .tmp, .disabled, and .bak files. The default exclude rules carry these patterns and can be edited; the automodpack/ namespace and Windows-reserved device names are always left out and cannot be turned back on. Empty files are not filtered out.
  • The paths saves/, screenshots/, logs/, and automodpack/ can never be claimed by the pack.

Groups

Groups split a modpack into parts: a required core plus recommended and optional bundles that players pick in the in-game "Group Selection" screen, with the choice sticking across updates. Two groups that players could select together cannot ship different content for one path, and breaks-with or different compatible-platforms is what makes variants legal. The groups page covers declaring groups, worked examples, the player-facing screen, and how conflicts resolve.