Docs · When something is wrong

In STYGION Keystone

When something is wrong

The handful of things that actually go wrong, and what each one looks like.

Updated

Every one of these is a thing that has actually happened, written as what you see rather than as a category.

The console never says "Keystone is running"

The file is for a different loader or a different Minecraft version. The four names differ by exactly those two words, and it is easy to take the wrong one from a list. The loader usually says so a few lines earlier, in its own words.

On Fabric the other common cause is a missing Fabric API — without it the mod does not load, and Fabric says so.

/keystone says you may not

Keystone has its own permissions and does not read Minecraft's operator level, on purpose — so that "may restart the server" and "may fly" are separate questions. From the console, which is always allowed:

keystone permission group admin add <your name>

On 0.1.0 you have to make the group first — the only one on a fresh server is default, which everybody is in:

keystone permission group admin create 100
keystone permission group admin allow keystone.*
keystone permission group admin add <your name>

From 0.1.1 admin already exists with keystone.* in it and nobody in it, so the one line is enough.

Mind the word in the middle: it is permission group, not group.

/keystone panel builds the link out of the address the local API listens on, and that is 127.0.0.1 by default — the machine the server runs on. On a hosted server you have two ways round it:

A tunnel, which exposes nothing and is the safer one:

ssh -L 25586:127.0.0.1:25586 you@your-server

Or (from 0.1.1) tell the mod the way in. If you move the API to 0.0.0.0 so it can be reached from elsewhere, the link itself would come out as http://0.0.0.0:25586/…, which opens nowhere. That is what api.reachable-at is for:

/keystone set api.reachable-at 192.168.1.100

Empty and listening on a real address → it uses that. Empty and listening on 0.0.0.0 → it asks the machine for its own address. Set wins, which is what you need behind a router, through a tunnel, or under a name you gave the machine. A new link is composed when you ask for it, so the change applies straight away.

Before you move the API off loopback, read the local API. It can do everything the mod can do.

Then click the link again — a new one, because they last five minutes and work once. If the port is not 25586 you changed it, and the console says which one it listens on at startup.

Discord is quiet

Three things, in the order they go wrong:

  1. The bot token is blank. It is a secret, so the editor shows whether one is set and never what it is.
  2. The bot has no Message Content or Server Members intent. Both are switches on the application where you made the bot, and without them the bot connects and hears nothing — which looks exactly like being offline.
  3. The channel ids are for a server the bot is not in.

The console says which of the three it is when the module starts.

A setting did not take

Nothing is ever half-applied: a value that does not fit is refused before it is written, with the reason and the field. Look at the console for the refusal — for example that every 6h is a schedule and 6h on its own is not.

A setting's name is the whole path — bench.share-live, not share-live. Get it wrong and the console names the nearest thing that does exist.

If it was applied and you want it back:

keystone set history
keystone set undo <number>

Every change is there with who made it, from where, and what the value was before.

The server is slow and you do not know why

/keystone test 20

It measures the server empty first, then places players in groups, and finishes with a sentence naming what gave out — the processor, memory, the garbage collector, or loading chunks. Those are four different problems with four different answers, and knowing which is most of the work. The report also says which mod the time went into, which world it went into, and what is standing on the server.

If it says the machine was already past playable with nobody on it, something is wrong that no number of players caused, and the console around the start of the run is where to look.

The assistant says there is nothing to ask

It is off until you fill in assistant.address, assistant.key and assistant.model. There is no key of ours and nothing routes through STYGION — you point it wherever you like, including at a model running on the same machine, in which case there is no key to fill in at all.

Something else

The console line is usually the answer, and Keystone's lines all start with [Keystone] and the part that wrote them, so you can tell which switch turns it off. If you want the machine's own view of it, the Console screen in the editor is the same lines with chat beside them, and /keystone assistant incident will read that stretch and say what looks wrong.

Did this page help?

Opens the feedback panel with this page attached, and lands in the same queue as everything else.