MiniMOTD tasks

Task guides and troubleshooting for MiniMOTD. Check the installed release before changing configuration or data.

Verify every entry in a MiniMOTD rotation

A rotating server-list message can hide one broken entry among several working ones. Validate each candidate on its own before treating a few successful refreshes as proof that the complete rotation is ready.

Prepare the test

Test the address players use in their multiplayer list. A proxy can answer its own status request, so changing the backend file may leave the public listing unchanged.

Make the change

  1. Copy the current main.conf and list every configured MOTD entry in a private checklist. Mark time-sensitive claims, joining addresses and formatting tags so an old event message does not remain in the random pool unnoticed.
  2. On a staging instance or quiet test window, leave one intended entry in the motds list while preserving the others in your saved copy. Keep its line1, line2 and icon together as one entry.
  3. Apply the file through the installed release’s supported method and refresh the actual public address in a Minecraft server list. Inspect both lines, the icon and readability, then repeat this isolated check for each candidate.
  4. Restore the reviewed entries into the list and refresh several times. The documented rotation chooses randomly, so do not expect entries to appear in order or assume a missing entry is broken after only one refresh.

Check the result

Every isolated entry should display correctly, and the restored rotation should contain only reviewed messages. Keep the checklist with an expiry reminder for event announcements rather than relying on random refreshes to reveal stale wording later.

If the test fails

Restore the previous complete configuration if HOCON parsing fails. Compare the bracket and entry structure around the last edit instead of replacing the whole plugin or disabling its other player-count and icon features.

If the public message never changes during the isolated test, establish which proxy or backend answers the status request. Editing a backend’s file cannot validate a proxy-owned server-list response.

References and related help

Check the official MiniMOTD documentation against your installed release before using a command or setting from another version.

Pair a MiniMOTD message with the intended icon

An unexpected icon may be a deliberate random selection rather than a missing file. Check the installed configuration generation before renaming images, because older MiniMOTD icon-index instructions do not describe modern entries.

Prepare the test

Test the address players use in their multiplayer list. A proxy can answer its own status request, so changing the backend file may leave the public listing unchanged.

Make the change

  1. Record the installed MiniMOTD version and preserve main.conf plus the icons directory. Inspect the icon value inside the affected MOTD entry, keeping it alongside the two message lines it is meant to accompany.
  2. For the documented modern format, use the filename stem from the icons directory without its .png extension. A value of random deliberately selects from the available icons; a numeric index from an older tutorial is a different scheme.
  3. Choose an existing valid icon for the first test and assign it to one isolated MOTD entry. Apply the change using the supported method, then refresh the public listing without replacing every image at once.
  4. Once the pairing works, restore the rotation and inspect each message-icon combination independently. Check filename spelling and case exactly, especially when a file was uploaded from a desktop with different case-handling behaviour.

Check the result

The selected message should consistently display its intended icon in the isolated test. Random icon behaviour should remain only where you deliberately requested it, and the other reviewed message entries should retain their own pairing.

If the test fails

Restore the saved icon value if the test falls back or the configuration fails. Check file format, filename and log warnings before using an old index-based recipe; the official historic icon page explicitly marks that recipe obsolete for version 2 onward.

Keep source artwork that you own or have permission to use. A working image file is still unsuitable for a public listing if it includes another server’s branding or material you cannot publish.

References and related help

Check the official MiniMOTD documentation against your installed release before using a command or setting from another version.

Hide MiniMOTD player-name hover details while keeping honest counts

The player-count hover can reveal names to people who have not joined. You can review that exposure independently from the displayed total, rather than replacing names with an inflated online figure.

Prepare the test

Test the address players use in their multiplayer list. A proxy can answer its own status request, so changing the backend file may leave the public listing unchanged.

Make the change

  1. Inspect the public listing with a cooperating player online and record the hover response and counts. Decide whether your policy hides names only or hides the numeric count too, since those are separate choices.
  2. Preserve main.conf and review the installed player-count-settings section against the official template. The documented disable-player-list-hover and hide-player-count options have different visible effects; select the one matching your privacy goal.
  3. Review fake-player and maximum-count modifications already configured. Leave population inflation disabled and do not present a display-only maximum as a resource upgrade or a promise that the service supports more concurrent players.
  4. Apply the narrow change and refresh from a separate Minecraft client. Inspect the hover result, compare the visible total with actual connected players and check the normal server description still renders as expected.

Check the result

The listing should reveal only the intended public information and avoid misleading population claims. Test after an ordinary player joins and leaves so you see how the chosen count behaviour responds to a real change.

If the test fails

Restore the saved section if the count disappears when you meant to hide names only. If names still appear, identify another status plugin or proxy answering the request before changing player records or disabling normal game joining.

This controls one status response, not every source of player information. Review separate websites, Discord announcements or query features if your community policy also restricts those ways of publishing who is online.

References and related help

Check the official MiniMOTD documentation against your installed release before using a command or setting from another version.

Trace a MiniMOTD virtual-host message to the address players use

Two hostnames can point at the same proxy while intentionally showing different server-list messages. Test the hostname sent by the client before assuming a message came from an outdated backend configuration.

Prepare the test

Test the address players use in their multiplayer list. A proxy can answer its own status request, so changing the backend file may leave the public listing unchanged.

Make the change

  1. Record the exact hostname and port saved in the affected player’s multiplayer entry. Compare it with your published joining instructions and establish whether a proxy or a standalone backend answers that status request.
  2. Preserve the proxy’s MiniMOTD files and inspect the installed plugin settings for virtual-host mappings. Compare the documented hostname-and-port key format and the named configuration in extra-configs with the actual generated files.
  3. For a short controlled test, give the intended configuration a distinctive harmless label. Use the documented virtual-host test mode if needed, capture the relevant ping information and turn that diagnostic mode off afterwards.
  4. Refresh separate multiplayer entries for the intended hostname and the default route. Confirm the special message appears only for its mapped address and the fallback remains suitable for other legitimate joining paths.

Check the result

The intended hostname should select its reviewed message reliably, while unmapped addresses receive the expected default. Record the matching key and owning proxy so future message edits happen on the correct instance.

If the test fails

Restore the previous mapping if the trial affects the wrong listing. Check the hostname and port actually reported during the ping before changing DNS, moving the backend or making every virtual host use one generic configuration.

Keep the live configuration’s filename spelling as your guide. Documentation and older examples can differ in surrounding filenames, so locate the installed virtual-host block rather than creating a second similarly named file.

References and related help

Check the official MiniMOTD documentation against your installed release before using a command or setting from another version.