MSP: MUD Sound Protocol

MSP stands for MUD Sound Protocol. It is a way for a MUD itself to tell a compatible client to play sounds or music, instead of relying entirely on a local soundpack watching text and firing triggers.

That distinction matters. A normal soundpack usually says: “when this text appears, play this file.” MSP is more direct: the MUD sends a special instruction such as !!SOUND() or !!MUSIC(), and the client or client script plays the named audio file if the player has the right sounds available.

MSP versus soundpacks

How MSP works

1. The MUD sends normal text to your client.
2. When the MUD wants audio, it sends an MSP command, commonly using !!SOUND() for effects or !!MUSIC() for music.
3. Your client, plugin, or script recognises the MSP command.
4. The client looks for the requested sound file in the folder you configured.
5. If the file exists and the client can play that format, the sound plays.

Some setups expect players to download a bundle of sounds first. Others may provide URLs or instructions for where the audio files should live. If the files are missing, MSP commands may appear to do nothing even when the MUD is sending them correctly.

Why some MUDs use MSP instead of soundpacks

For the MUD owner, MSP can be cleaner than asking every player to install a different trigger pack. The game can decide exactly when a sound should play. That means a door sound can come from the door system, a spell sound can come from the spell system, and a music change can come from the area or room system.

For players, MSP can feel more official and less fragile than matching text. A text-triggered soundpack can break if the MUD changes wording. MSP is less dependent on prose because the MUD sends an explicit sound instruction.

Accessibility notes

MSP can be useful for blind and visually impaired players, but it is not automatically a full accessibility solution. A MUD might use MSP for ambience or flavour while still missing important alerts such as low health, afflictions, tells, or exits. A local accessibility soundpack can still be useful on top of MSP.

The best setup is often a mix: MSP for official game sounds, plus client-side triggers for personal accessibility cues.

Client support and practical notes

• zMUD/CMUD-style clients: MSP originated in the same old-school ecosystem as zMUD and similar clients, so older MSP documentation often focuses there.
• MUSHclient: MSP may be handled through plugins or trigger/script setups depending on the world and package you are using.
• TinTin++: MSP can be handled by scripts, but you usually need the correct audio tools installed and the sounds placed in the expected directory.
• Modern clients: support varies. Some communities now prefer newer media approaches such as GMCP-based media protocols, while others keep MSP for legacy compatibility.

Troubleshooting MSP

• Check whether the MUD actually supports MSP and whether it is enabled for your character.
• Check whether your client supports MSP directly, needs a plugin, or needs a script.
• Make sure the sound files are in the exact folder the client or script expects.
• Check file names carefully. Some systems are picky about case, spaces, and extensions.
• Make sure your system can play the file type being requested, such as WAV, MP3, OGG, or MIDI.
• If nothing happens, turn on logging or error output in your client and check whether MSP lines are arriving.

What to list on Soundpack Vault

If a MUD uses MSP, the Vault can still list the download as an MSP sound set. In the pack description, say that it is MSP-based, name the client or clients it has been tested with, and include setup instructions for the sound folder.

Find soundpacks Compare MUD clients