Game Catalogue

What the catalogue is

The catalogue is the list of games you can sell. Nothing in game hosting is sellable until a catalogue entry for it exists: a plan points at an entry, and the entry is what tells a machine how to build and run that game.

It has two levels. A title is the game itself. An entry is one sellable version or flavour of that title — a particular server build, a particular mod loader, a particular major version. A plan binds to an entry, never to a title.

How to reach it

Open VPS → Game Hosting → Catalogue. The page is titled Game Catalogue, subtitled “Titles, the variants that can be sold, and anything waiting on approval”.

What an entry defines

An entry is a complete recipe. You do not author most of it, but knowing what is in it explains almost every refusal you will meet elsewhere.

What a catalogue entry carries

Part	What it decides
The runtime image	The container image the game runs in, either named for an image already loaded on your machines or published as a download with a checksum. Where an entry names an image with no download address, that image has to be present on every game node.
Install steps	The declarative steps that fetch and lay down the game's own files on first build. Every download is pinned to a checksum — an unpinned download is refused rather than fetched.
Startup command	The command line the container runs, with the entry's variables substituted into it.
Stop command	What is sent to the game to ask it to save and quit, rather than killing it outright.
Ready marker	What the game prints when it is genuinely up. This is what lets the panel report the game as running rather than merely the container.
Ports	The ports the game needs and what each is for — the main connection port, a query listener, a remote-console listener, voice. The entry's own default port count is the floor a plan's extra ports are added to.
Variables	The start-up settings the game exposes. Each carries a label, a description, a default, and three flags: whether the customer may edit it, whether it reaches the installer, and whether it is a secret.
Config files	Which of the game's own configuration files the platform writes values into — player slots, for example, are written into the game's own configuration rather than merely counted.
Protected files	Files a customer may not change from the panel's file manager on this game. It is a panel filter, not a file permission; the file is still theirs over SFTP.
Resource shape	Minimum memory the game needs to start, a sensible default memory, its install footprint, and how many player slots each gigabyte of memory can reasonably carry.
Mod placement	Where mods go for this game, and which mod sources carry mods for it. Without it, mods cannot be offered on that game.

Minimum memory is the field you will meet most often: a plan below it is refused when you save it and again if an order ever reaches it, because a server built there could only fail to boot.

Where entries come from

Two sources, shown in the Source column.

Vendor entries

Marked Vendor. These are authored centrally and arrive with your licence heartbeat, the same way operating-system images do. They are read-only here on purpose: an edit that would not survive the next update is worse than no edit control. You do not curate them — you decide whether to accept what they publish.

Your own entries

Anything you import yourself is yours: you activate it, you edit it, you delete it. Importing is the only way one gets here — see Importing a game below.

The page

Tiles

Titles, Entries, Awaiting approval (new executable content that is not running yet) and From the vendor (maintained upstream and pulled on the licence heartbeat).

The approval queue

When entries are waiting, a highlighted panel leads the page: Waiting on your approval. Each row names the entry and how many of your servers are pinned to the version you already approved, with a Review button. This queue leads the page rather than sitting in a tab because an unreviewed approval quietly costs money — every affected customer stays on old content for as long as it is ignored.

The entry table

Catalogue columns

Column	What it shows
Entry	The entry name with its title underneath. Retired entries and incomplete templates are marked here.
Source	Whether it came from the vendor or was added on your own installation.
Approval	Approved, Awaiting approval or Rejected.
Memory	The entry's default memory, with its minimum on hover.
Plans	How many plans point at it.
Servers	How many live servers run it.
Updated	When it last changed.

A search box matches entry name, slug and title. Refresh re-reads the list.

Two kinds of inactive entry

They look similar and mean opposite things:

• Retired — the entry has been withdrawn upstream. There is nothing for you to do. A plan that already sells it keeps showing which game it sells.
• Incomplete template — the entry is a starting point that is waiting on you. It names the field it needs and says what to put in it. Reading this as “retired” is how an entry that needs ten minutes of work sits dark for a release.

Approving a change

When new content is published for an entry, nothing changes on its own. Every server built from that entry keeps running the version you already approved, and the change waits.

Review opens a side-by-side comparison titled “Review the change to <entry>”, subtitled “What is running now, beside what the vendor has published”. Each differing field is shown with its running value against the published one, and each is tagged either Executes or Description only. A count says how many of the changed fields decide what actually executes; the executable ones are listed first.

Fields that count as executable are the install steps, the startup command, the stop command, the runtime image and its checksum, the configuration files written, the protected-file list, the ready marker, and the entitlement the entry requires.

Two buttons finish the review:

• Approve — every server running that entry moves onto the published version. Where the change alters what executes, the dialog is a danger confirmation and you must type the entry's name. The warning is exact: this alters what executes on customer servers and it cannot be undone from here; the publisher would have to publish again.
• Reject — the change is refused and servers stay where they are.

Decide later closes the review and leaves the entry in the queue.

Note: Description-only changes — name, description, icon — can be applied automatically. That is the Apply vendor description changes automatically setting in Game Settings, and it is on by default. Anything that executes always needs an explicit approval, whatever that setting says.

While an entry is pinned to an older approved version, every server running it shows a line saying so on its own page, with a link back here.

Importing a game

Import eggs at the top right of the catalogue page opens the import tool. It brings a game definition across from another game-server control panel — an exported egg file, or a whole panel read over its API — and converts each installer into declarative steps. Every line that cannot be converted is reported rather than quietly dropped.

The tool has three steps: Choose eggs → Read the report → Imported.

Step 1 — Choose eggs

Two sources.

Upload egg files

Choose one or more exported definition files, up to 512 KB each. A published definition is a few kilobytes, so anything larger is refused by size. An export from an older format is refused by name — re-export it from a current panel.

Read a panel

Point the tool at a live panel instead. It takes the Panel address (HTTPS only) and an Application API key with read access to that panel's nests, eggs, nodes, servers and users. A client-level key cannot read any of them.

Warning: An application API key is full administrative authority over that panel. The key is held only while the panel is being read and is then discarded — it is never stored, so a retry has to ask for it again.

The read is entirely read-only: nothing is written to that panel and nothing here is adopted. It reports through named stages — connecting, reading nests and eggs, reading nodes, reading servers, reading users, matching against what is here — and then shows what it found: how many eggs (and how many are already here), how many of that panel's users match a client of yours by email address, and the machines and servers it listed. Machines and servers are listed only. If it stops part-way, Retry the read resumes and only re-reads the parts that did not land.

The server list is a plan, not an adoption. A game node here is a machine running your own agent, built with the node wizard; there is no live connection to the other panel's daemon. Each server row names what is in the way — its egg is not imported here yet, its machine is not a game node here yet, no client here has that email address, or the panel did not report its egg. The route is: import the egg, bring the machine in as a game node, then sell the server here.

Then say where the imported entries belong: an Existing game, or Create a new game with a Name, a Slug and a Category. An entry always belongs to a title.

Approved download hosts appears when the installers download from somewhere. An install step may only download from a host you have ticked. A game published in the vendor catalogue is read-only, so its approved hosts cannot be changed — import under a game of your own instead.

Step 2 — Read the report

Convert and show the report runs the same conversion the import will run and writes nothing. For each definition you get: the container image, the variables, the configuration files, and the installer line by line, each line marked Converted, Absorbed or Blocked.

Four tiles summarise it: Ready, Blocked (something has to change first), Need a checksum, and Script only (these install nothing yet).

Downloads with no pinned checksum are called out individually. An exported definition never carries one and the runtime refuses an unpinned download — paste the checksum into the box beside the line and it converts.

Warning: Where none of an installer converted, no steps are kept. A server built from that entry comes up with an empty game directory until you author the install steps by hand. The original script is stored alongside it as a record; nothing executes it. Activating such an entry makes you tick an acknowledgement saying so.

Step 3 — Imported

The report says how many entries were created and which were skipped, and whether a new title was created for them. Every imported entry lands switched off. Read each report, then activate the ones you want to sell.

Imported variants

Below the wizard sits the list of everything an import has created here, with the decision that finishes each one. Columns: Variant, Game, Install (how many declarative steps, or Script kept as a record), State (Active or Switched off) and Actions.

• Activate — an active entry is one a plan can point at and a customer can buy.
• Delete — removes the entry and its variables. Refused while a plan or a game server still points at it.

How an entry reaches a customer

Three things decide which game an order installs, in this order of authority:

1. The plan's Catalogue entry. Pin the plan to one entry, or leave it open.
2. The product's Force this game, which overrides the plan for that product only.
3. The customer's own choice at checkout — honoured only when the product has Let the customer pick the game switched on. With it off, a choice sent with an order is ignored and logged rather than obeyed.

All three are set on the product — see Game Plans. A customer's choice is also checked against the plan's title: an entry from a different game than the plan is sold for is refused with a message telling them to order the product built for that game.

Common problems

• The catalogue is empty. Entries arrive on the licence heartbeat. An empty list on a freshly enabled module usually means the first update has not landed yet.
• An order was refused because the game is awaiting approval. Review and approve the change here, then retry the deployment.
• A plan will not save because of memory. The plan is below the game's minimum memory. The number is shown under the plan fields.
• A customer says mods are not offered on their game. The entry has no mod placement configured for that game yet, or no mod source you have enabled carries mods for it — see Game Settings.
• An imported entry builds an empty server. Its installer did not convert. Author the install steps, or import a definition that converts.

Related: Game Hosting Overview, Game Plans, Game Servers, Game Settings.