single-player server · 3.3.5a
Sign in
Guides › Development

Publishing a package

Before you start

Your plugin follows the plugin format: a folder with a plugin.json that has "format": 1, an id and an x.y.z version, built for the core ABI of the current LonelyIce release. Its source must be in a public repository, and you need a GitHub account to sign in here.

Pick the id carefully: it cannot change later. The first upload of an id makes it yours, and only you (and the moderators) can publish new versions of it. Ids are lowercase letters, digits, dots and dashes; third-party plugins use the author.feature style.

Pack it

LonelyIce.exe --pkg pack path\to\your.plugin out

This writes out\your.plugin-1.0.0.zip: the plugin folder under a top folder named after the id, without debug and link files (.pdb, .ilk, .exp, .lib, .a). Add an icon.png (64×64) to the plugin folder to have it shown in the catalog and the launcher. Upload the zip as --pkg pack made it; do not repack it by hand.

Upload

Sign in, open Publish a package and upload the zip (the size limit is shown on the form). The site reads it the way the launcher does and runs the automatic checks. These stop the upload:

  • the zip has no plugin.json, or it is not valid JSON;
  • id or version is missing, the id has characters other than lowercase letters, digits, dots and dashes, the version is not x.y.z, or the top folder is not named after the id;
  • format is missing or not 1 (the server's plugin loader skips such a manifest: unsupported manifest format 0);
  • the id belongs to someone else, the version is not newer than the one in the catalog, or the same version is already in review or hidden. The catalog keeps one package per version number: a rebuild for a new core ABI, or with more platforms, is a new version too (When the ABI changes);
  • a plugin with server code has no core.abi or no platforms, the ABI is not one the launcher releases use, or a listed platform has no library at server/<platform>/<library>;
  • a platform is not one the core knows (windows-x64, linux-x64, linux-arm64, macos-x64, macos-arm64), or platforms is given without server (the launcher would take the package for server code and hide it wherever core does not match);
  • a dependency's range is not syntax the launcher reads, or the catalog has no published version of the dependency in that range that the launcher can install next to yours (for a package with server code: built for its core ABI and each of its platforms, or without server code);
  • the zip contains game client archives (.MPQ), paths that leave the plugin folder, or files outside it.

Warnings do not stop the upload; the moderator sees them. They are raised for a missing name, license, locales or icon.png, files that look like extracted client data (DBC, maps, models; client changes go through patch recipes), and a new id without a dot.

A package that passes is kept as a draft; you can upload another file or discard it.

Source and details

On the draft page give:

  • the https address of the public repository the zip was built from. It is prefilled with the repository you gave for your previous submission of the package, else with homepage when that is a repository on GitHub, GitLab or Codeberg;
  • the tag or commit it was built from, prefilled with v<version>;
  • the category and what changed;
  • a confirmation that the source is public and that you may publish it under its license.

For a wrapped module, source.repo and source.commit name the module, not the repository the zip was built from, so they are never prefilled, and neither is a homepage that points at the module; the draft shows the module as "Wraps". Give your wrapper repository and its tag.

Then submit it for review. The moderator reads the code at that tag and compares the files with your previous version. There is a limit on how many of your submissions can be in review at once.

Review

Your submissions are on Your packages. A moderator either publishes the version, asks for changes with a note, or rejects it with a reason. When changes are requested, upload a fixed zip of the same version and submit it; the earlier submission is closed. While a version is in review or waiting for changes you can withdraw it with Withdraw on the Submissions tab.

Once published, the version is in the catalog's index, /packages/index.json, and its zip is served next to it. Published files never change: a fix is a new version. A moderator can yank a version, which hides it from the index while its file stays downloadable.