MSP

I installed the plugin for MSP. The msp_path is set to c:\Program Files\MUSHclient\msp, where the MSP files are located. When I use the restore command that has a sound attached to it, I get the following:

!!SOUND(action/restore.wav V=75 L=1 P=50 T=action)Ok - restore done on Vector.

Did I miss something in the instructions?

Looks like the trigger isn't firing, however when I installed the plugin and tried that exact line (copied from your post) it worked.

Did you actually install the plugin? Is it in the list of plugins?

It is in the list of plugins.

Name Purpose Author Language
msp Emulates MSP (MUD) Nick G vbscript

Could it be a problem with MUSHclient?

I assume you are using a recent version?

What sort of problem? I copied your string:


!!SOUND(action/restore.wav V=75 L=1 P=50 T=action)Ok - restore done on Vector.


I hit Shift+Ctrl+F12 to bring up the "debug" window. I pasted that into it, and hit OK. With the MSP plugin installed I see this:


Ok - restore done on Vector.


I hear a "ding" because I don't actually have that file on disk. So as far as I am concerned, it works. Can you try those steps and report what happens?

MUSHclient - Version 3.45

I pasted the string into the Debug window, and hit OK. With the MSP plugin installed, this is what I see:

!SOUND(action/restore.wav V=75 L=1 P=50 T=action)Ok - restore done on Vector.

I hear no sound. The MSP files are in C:\Program Files\MUSHclient\msp\.

The sub-directories in msp are: action, skills, weather, combat, and spells.

Do I need to turn on sounds in the client? I have turned on MSP in the mud with "msp on".

If the plugin is handling other sounds properly, it may be that this is simply a file the plugin cant handle for one reason or another - bad sample rate, bad compression ratio, whatever. I had something similar with 2 sounds that just refused to play in MC though media player handled em just fine - turned out they had bad sample rates for the plugin as far as I remember. If the plugin isn't playing other sounds, Id recommend double checking your actual install path for MC vs the path in the file. I have a fairly odd file structure on my machine so I had to do a bit of fiddling with the path to get any sounds at first.

The plugin is not handling any sounds. I used set_msp in the client to set the path for MSP sounds. The path is the following:

set msp_path c:\program files\mushclient\msp

Can you go into more detail about checking the actual install path versus the path in the file? I also hit "Reinstall" on the Plugins window to see if that would fix the issue.

Are triggers enabled? :p

I see only one ! here, which is a slight problem.

One possibility is that you have another trigger that matches on !(something) which gets picked up before the !! trigger for the MSP sound.

Let's stay focussed on the real problem here.

The problem is not ...

• Where your sounds are - if it can't find the sound file it plays a ding. However the !!SOUND string should still be suppressed. The fact that you see it means the trigger is not firing - that is the problem.
  
• Whether MSP is on at the MUD or not. The fact that you see !!SOUND on your screen shows it is.

Forget the MUD for the moment. Pasting in the string into the debug window (with both !! in it) should simulate receiving it from the MUD.

The problem was triggers were not enabled. I pasted the string into the Debug Window, and I hear a "ding". So, I set my msp_path to the location where the sound files are, and MSP is working now.

Thanks.

I've found two issues with the MSP pluging distributed with MUSHClient

1) It appears to assume that an mp3 will be played, or that a filetype for the sound file will be specified, I'm not sure which. Either is contrary to the MSP protocol spec. There is no requirement to specify the sound type in the !!SOUND line, and the file may be in a format other than mp3. For example, Medievia uses WAV files, and the !!SOUND line does not contain the filetype. I've managed to hack the current MSP plugin to handle this, but it makes it Medievia specific, and that doesn't seem right.

2) It is not required that their be text to display before or after the !!SOUND line. On muds that don't do this (again, like Medievia), this means the MSP plugin outputs a blank line, breaking up the formatting of the normal text on the screen. I fixed this by commenting the output bit entirely, but I don't think this is really the right way to do this, either.

--Kernighan

I have looked around and I cant seem to find this error which Iam getting... Actually I just dont understand what it is saying.

I am playing a SWRs mud... SWReality 1.0, codebase to be exact. And I have the MSP plugin and it is enabled and the triggers are enabled... but I get this error:

http://www.wheelmud.org/odomus/Images/mspprob.jpg

This is the best way of giving it to you, so you know exaclty what iam talking about.

I have the MSP setto that above all correct and such and for some reason it jsut doesnt want to read form there or something.... I cant figure out what is wrong. Device Type? It is a .WAV file and I dont know why it isnt working at all... NEver used MSP frainkly, and I wanted to try it now iam getting this blecy thing can anyone of you guyshelp me?

-Kethlar

Whats the line that it's triggering on? (you'll have to disable the plugin or whatever to see the full text with all the technical goodies.)

Kethlar,

If you read my post (immediately preceding yours), you'll note that I stated that the msp-plugin as distributed by MushClient won't work for WAV encoded sound files. You can fix this manually by editing the plugin, and having it append ".WAV" to the filename (but I view this as a hack, and not a great solution). By default, mushclient will only play mp3 based sound files with its current MSP plugin.

It should also be noted that 'most' systems that play back content will correctly run an mp3, even if it is incorrectly named '.wav', so appending it might work with both, even if wrong. Other formats...


The "let me guess what the file is from the internals, instead of supplying me with actually information about what it "should" be" is a Microsoft aberration. In general, its safer to 'tell' an application what it is looking at, not expect it to guess. Though, the most common case of it causing problems it trying to download a .zip from a site running and MS server, which incorrectly uses the default "text" type. Any non-MS browser assume that the type is right, and tries to display it, instead of downloading it. Can drive a person totally nuts and also creates a 'huge' security hole, since the OS can take a file that looks like .zip, decide its a .mp3 when it arrives, from the file name, try to play it and suddenly decide that no, its a .avi, with some imbedded HTML, which then loads a web page, probably without you having the slightest idea it happened. Not real great design... And MSP having been created first for use on Windows applications, continues this insane trend. :p

The plugin does not claim to fully implement the MSP protocol, which has stuff like "sound level" and so on.

There is also no reference in the plugin to MP3, so I assume that Windows is assuming that a file name without an extension is an MP3 file.

Plugins like that are intended to be building blocks for adapting to your own circumstances. Since the source is supplied, and is very readable, you can simply make minor amendments like adding ".wav" to the file name, or suppressing the send if the resulting line is blank.