Calling Plugin procedures from triggers

hi all,

First, let me say how great it is to be able to MUD again (now college is out for summer), and let me thank Nick for his work on the program. i'm glad I paid for it, regardless of its status now. Right - and so to my question.

perhaps because I haven't touched MUSHclient for a year I'm struggling with this, and don't know if its a bug or a feature.
I have a function in one of my global Plugins that tells my screen reader to interrupt whatever its saying and say something else instead. I want to be able to call it from a number of triggers - so if in a particular world a key event happens, I can just add something to a trigger's "script" box and have the event called.

however the function isn't in a locally-loaded script file, it's in a plugin loaded for all worlds, and so the triggers can't seem to find it. Any advice? is it just me?

Cheers,
Sean.

Sounds like CallPlugin is the way to go.

See http://www.gammon.com.au/scripts/function.php?name=CallPlugin

Hi,

Thanks - I guess that'll work as a last resort. my big problem with this is that The Plugin ID is necessary - this increases the time required to add the interruption to a trigger.

Eh.. how about adding an alias interruptspeech to your 'global' plugin, which you then call through either 'interruptspeech' (send to execute) or 'world.Execute("interruptspeech")' (send to script).

It should be a bit easier this way.

That's not a bad idea - the only one I could come up with myself. I could also add a parameter to the alias I guess so that you could either stop the speech directly or stop it and have it immediately say something else.

In what way? All you have to do is code the plugin ID of the relevant "stop speech" plugin into your other plugins. Or, even doing GetPluginList when required, and translating a plugin name to an ID would be pretty quick. But if you are going to hard-code in the name of the plugin you may as well code in its ID.

http://www.gammon.com.au/scripts/doc.php?function=GetPluginList

However the alias idea should work just as well, and doesn't rely upon plugin IDs. Also, you could also simply type it. Say you enter a room, and it starts speaking the description, which you have heard before, you just type "stop" or whatever you alias is, and the room description stops being read out.

Can you please post the method you use to interrupt speech? According to my research it would be something like:

I think the alias idea is going to win out for sheer simplicity. I like the idea of stopping speech directly, but that's a trickier concept than you know - so allow me to explain.

For those of us using screen readers, hitting the ctrl key is often all we need to stop speech. This is why interrupting or stopping is rarely an issue from within the code itself.

What I am attempting to create are three plugins:

1. One to work with JAWS (the most widely-used screen reader). JAWS com API supports sending text to interrupt anything presently speaking.
2. One to work with Window Eyes, which is also a commercial screen reader. I don't use it myself, but several MUSHclient users do.
3. Finally, one to use the SAPI system built-in to windows. While it's not advisable, with this plugin someone without a supported screen reader could use MUSHclient.

The third plugin will have to be the most complex because I'll need keys to skip forward and back through the items being read, as well as a way to adjust voice, rate, and volume.
Interrupting the thing is also problematic (as I can't assign an accelerator key to Ctrl (it's a windows limitation)) so I'll have to use something else. Anyway that's all doable, it'll just take some time. When it's done, MUSHclient will easily integrate with speech.

Finally, to your question.

The second parameter to the SAPI (SAPI.SpVoice) object's speak function is an integer. if this is set to 3, whatever text passed will be spoken immediately. So to use your code

will instantly silence the tts, disregarding the remainder of the text it was reading.

The solution to stopping text with a key hit is simple, bind the stop alias to your numpad. That way you'd be able to stop it with one key hit.

As per your third plugin, I have already created one, that allows ANYTHING (except skipping in either direction) to be triggered via a CallPlugin Procedure, that also allows altering that voice used, and the rate at which it is spoken. I left out the volume option, as I saw no use for it, who wants to have extremely loud or extremely quiet speech read out? Just set the desired volume in the windows settings, and forget it :)

Also mine makes use of the "Alert" queue feature, that allows a separate higher priority queue to be used, that will interrupt the item being read currently, and then read the alert, then resume from the beginning the section that was interrupted.

It even lists the EXACT syntax of the CallPlugin needed to use it, including the PluginID

I spent a good long time making it, and I don't even use it often, only created it to speak out warnings that I might have missed while it whizzed past in battle spam or other spam. I thank god that I am a sighted individual, but have made every attempt at making it as easy as possible to use said plugin for sighted, impaired, and (tries to find the most accurate and still polite term) those lacking sight.

It is hosted at the following URL...
www.torasin.com/~venificius/MUSHclient_ttsVB.xml

Do please take that apart, dissect it, disassemble it, anything that you want to it, that you may learn or be able to use it better.

Enjoy.

Laterzzz,
Venificius

Hello,

I'm amazed at the response here - MUSHclient is an extremely accessible program as is, but like any client, will need modifications to work for the blind. of course how they want to use it is their own choice, which is why there are a number of Plugins written, I guess.

Thanks for showing the Plugin you wrote - I like it, and while I wouldn't use it precisely as you do its still got a lot of great code!

I don't know.. Would be interesting if you had a screen reader as a standard thing for a mud and used an MXP extension to determine what the voice "sounds like" and how far away it is from you, and maybe even location relative to you. Even if its whispering vs. talking out loud. I mean, its got to be a lot easier to do that, with the right software, than to try to add most other MMO features, and having voices and environmental sounds for a mud would add layers to things. Imagine for example crowd babble in a room that is "described" as being a busy market with hundreds of people in it.

Mind you, I doubt screen readers *can* do what is needed to support anything beyond the basics of what single individuals are doing. You would need something more complex, which could handle multiple voices, on the user end to manage it, possibly even a separate connection, so you don't hog the bandwidth on the main player channel with speech/sound codes. In some ways, that is one of the flaws with MXP, it tries to cram all the data into the same stream as the text, which works OK, as long as the data is *small*. Do anything more complex and... you start lagging the player.

The only question is.. Would it be easier to have a client extension to handle the environmental and speech stuff on the user end, or would it be easier for some of that to be handled server end, then streamed to the client? Damn I wish I knew enough about coding this kind of stuff to try some of the ideas I come up with. Sigh...

I fear that this discussion is going off-topic, but here we go...


You mean like, umm, a sound card? :-)

What you're talking about (environmental effects, position...) isn't at all what a screen reader is meant to do, to my knowledge at least...


Under almost any definition of 'easy', the answer would be that it would be better to do it client-side, no questions asked. I don't even want to think about burdening the server with having to mix sounds for the clients and deal with streaming them separately. That would increase the MUD's processor load and bandwidth needs by several orders of magnitude. Bad idea...

This seems like a great idea for people who can read the text fine. If you can't, which is the target audience for the readers, then it will just make it more difficult to get room descriptions and such. Minor effects might be ok, but anything that would interfere with understanding the speech would interfere with how people that can't turn off sound and scroll back a bit can play.


I agree with David... the answer is undoubtedly clientside. This way the files are downloaded once, and the client can muck about with mixing them however it's needed.


Well, with this sound issue, and all the 3d stuff you were talking about several months ago, you can try it all right now. Just walk into your nearest video game store and pick up a 3D MMORPG. They have all the 3d graphics you could want, some sounds tossed in, and they are nearly impossible for anyone visually impaired to play, although I'm sure someone must have figured out a way somehow.

I am sure there is scope for improving the user interface for people who have trouble seeing the screen. For one thing, colour is used on the screen to add extra information for sighted people. You could achieve a similar effect by using different voices (or different speeds / inflexions) depending on the context.

For example:



Probably an ideal would be to have male voices speak when male characters speak, and female voices when female characters speak. This might be hard to arrange, but maybe an internal database could be maintained of who is what gender.

If someone speaks who is not in the database, a quick bit of code could fire off a "look" or similar appropriate command to determine their gender, and save that in the database. These could be suppressed from output so it happens in the background.

Other sound effects could be used to good effect (eg. door opening sound, footsteps, water lapping).

I don't know how much of this would really be wanted, but if it was, it would be an interesting project.

Switching voices for different things is something we use now, on a limited basis. The big thing for us though is speed, and having different voices in the mix slows things down. After all, things scroll rapidly on some MUDs, and we have to keep up.

Sounds we also use - various people create "sound packs" for various games. While it's true they are useful just for fun, for us, they are much more than that. If we're reading a long room description and get attacked, a sound is oftentimes our primary way of finding out about it.
Similarly, if we get a message over a com channel, if our spaceship gets hit... you get the picture. it's also useful if we're turning our attention elsewhere (to check mail, whatever). Sounds are a lot quicker to process than a babbling voice. Of course we need multiple sounds playing at once, so that one doesn't stop another. A quick Plugin takes care of this - although I aim to eventually write one with some more features. The basic idea of having a trigger play an audio file is nothing new though.

As a rule, having games or programs talk to us (enabling special "blind" modes) is irritating. We tend to have our own screen readers, with voices and rates of our choosing. this is why i'm creating several plugins to cater for a variety of screen reading programs.

Of course there are some people who simply will not know how to setup plugins and whatnot. They'll learn, though; and I hope to get a web page set up with some help if there's demand for it.

MUDs may be a somewhat quaint form of gaming compared to the MMORPG genre, but for us, they are almost natively accessible. of course you need your client the way you like it, and prompts are the bane of our existence - but we manage.

Ok, first, I was thinking in terms of processor overhead, since you are **not** just mixing only premade sounds, but also possibly several dynamic speeches that have to overlap each other. That takes extra processing time for *each* "voice" that is going to be talking. A server might be able to use a separate sub-server to handle that, or actually have far more processing power at its disposal, maybe. Probably not with most normal muds though. MMOs get by with mixing it on the client end because a) they don't usually support spoken speech, unless its parsing the output in the chat window, so there is no simultaneous events, and b) they used canned speech, which obviously isn't going to be the case of 10 players are all in a room talking at once, like in a market. Mostly, they probably handle it by *not* having those things happen at the same time, so you could probably do that, but it takes away from some of the realism, and won't help you if you integrate something like real-time voice chat too. Mind you, that is probably going too far for a mud. lol

Second, nothing stops you, if the voices are distinct enough, or one is louder, from doing and people do naturally, and pick their own names out of speech in a crowd, or focus on a single speaker in the room. You could have 4-5 people speaking in the room, at different locations and distances and still follow what is happening. You could also have a quite distinct voice that is *only* used to do the equivalent of narration, for the descriptive parts. It can't be any harder than real life to follow, and last I checked, even blind people manage to do fairly well in crowds, despite all the noise. Why would it be different when the crowd "is" noiseless babble, with 2-3 real merchants and a few players talking to those? I think you exaggerate the problem a bit. Its all about the quality of the speech and how adaptive you can make it. Sadly, most probably use what isn't much better than 10 years ago, since that sort is simple to implement, so its uncertain how different you *can* make the voices. That is the only serious hangup I can see with it though.

Oh, and to add a bit, this idea would "require" males to use male voices, females to use female, etc. Making them distinct... Its a bit more complicated, but maybe you could take the NPC/Player name and use that to generate the "voice" that specific individual has. The problem is, again, finding a speech system that is a "bit" better than the old ones I have heard, so you can get a better variety and fewer, "Ugh, that combination of settings is horrible!", situations. lol

A hallmark of MUDs has been their ability to run on many systems, regardless of spec. I think in adding streamed speech per room detracts from that considerably.

I see the concept, but to be truly useful a whole new kind of client-server protocol would need to be negotiated and a client probably created from the ground up, with accessibility taken into consideration from the outset.

Do you have any idea what it would entail to mix any form of sound whatsoever on the server end for a game with several clients? It's not that MMOs "get by with mixing it on the client" -- it's that they cannot afford to mix it server side.

I will agree that it takes extra processing time for each voice used, which is why it would be so much more efficient client-side in terms of speed. If everyone logged into the game were forced to be in the same room or maybe just a handful of rooms, then having a sound server streaming sounds might not be a terrible idea. However, if you have a decently large game, the amount of sound generated will increase quite a bit per person (also taking into account that not everyone will have the same communication channels open), and that there will be several rooms that people could possibly be in.

For example, on Aardwolf right now, there are 347 players logged in. There are 28031 explorable rooms (a few thousand are flagged non-explorable). There are also 29 channels (not including say and personal tells and such), which are all individually able to be toggled on and off. Due to the variety, it would make much more sense to just send the text and let the client sort it out.

To expand that further to show why MMORPGs don't deal with sound like that, imagine something similar on the scale of 10,000 people on at any given time, having to deal with combat sounds, environmental sounds, and mixing people's speech. Not a terribly easy task server-side, unless you have a supercomputer dedicated to the task.

I'm having trouble understanding why it would ever be a good idea even for that kind of situation. You'd not have the processing problem (at least not as much) but you would still have all the bandwidth issues. This isn't just a speed issue; it's a load issue in general.

You're already talking about a special client that can play sound sent from the MUD. So just let the client mix sounds that are all client side. I honestly can't see any reason whatsoever for the server to bear all or even any load of mixing and broadcasting the sounds...

I was only referring to the processing issue in that post. I made no mention of bandwidth whatsoever, or I'd start talking about a game I play which has a chatroom and a shoutcast station, and how there is sometimes one is up to a minute behind the other. Not terribly effective in terms of communication, but you can get fun games of Marco Polo going. Granted, these two things are on different servers, so there won't be quite as big of an issue with lag time, but bandwidth is an issue for servers, which is why a lot of muds use mccp, which sacrifices minor processing time for huge savings on bandwidth. It's much more effective for the money in the long term.

To be fair, I am not talking about mixing everything, just speech, in a stream. Environmental sounds, music, babble, etc. are are possible to handle without the overhead on the client end. The biggest worry is, what happens on the client end when you have 10 people speaking in the same room as the player, and you need to map all those voices, in real time, into the sounds... Each of those has to take process time to convert from text to speech *before* you can hear them. But yeah, there is the point about how big of a mess it would be with a lot of rooms, each with a player in them, each hearing 4-5 voices. The issue is if the client end could handle 4-5 in a room well either, given some of the hardware a person might be using to run the client.

I mean, its a lot easier with real voice over IP, where people just talk, but you still have the problem of NPC speech there, which isn't as solvable. For a text mud, its unlikely anyone is using voip, so the problem is just amplified. Short of a hardware based solution, like a special translation card that you could feed text and parameters, which would then dump that through something like the CD audio connector, you are going to be looking at the OS trying to sort it out. A real mess, if you have dozens of voices involved.

MMORPGs try hard to get the client to do as much as they can. After all, a single game server is likely to have 1000 clients hanging off it. Any job the server takes on has to be multiplied by 1000. Streaming audio (or video) must be one of the most data-intensive jobs you could choose to do.

In fact, MMORPGs download as much as they can (or install off the CDROM), like scenery, mob images, sound effects. After that they try to make the client do things that it safely can without compromising security (allowing cheating), such as letting characters move locally, and sending updates to the server about where the character is now.

They try to predict which way a mob will run when it attacks you, so it looks smooth. Sometimes they get it wrong and the mob gets suddenly readjusted to somewhere else.

In fact, I was thinking if I ever redid a MUD server, I would use a custom protocol so that if you walk in and out of a room a dozen times, it doesn't have to resend a 5-line room description each time (after all, the room itself hasn't changed).

That would make stuff like "look" and "inventory" very fast, because it would simply be displaying its local copy of the information. Then you could even have the client display the room description, inventory, equipped items, known skills, etc. in special dialog boxes, since they would be unambiguously identified for what they were, rather than relying upon complex triggers to try to decode incoming text.

Actually, Aardwolf does something similar to this already. It gives you options for what to see when you enter a room, with the 'look' command always displaying the full room description.

The amount of bandwidth this saves is amazing. The only drawback is when wandering into a new mazed section. You can always tell when you've entered a new room when you have brief set to 1, so it's a bit harder to trick the people with this setting.

Brief is a more or less standard feature, isn't it?

Yes, the part about not being able to fool players is the only big problem I can see. (Same thing about showing vnums or not.) If that was really a problem, you could set up a flag that effectively ignored the middle brief setting, and always considered that you'd never been in the room before.

No idea if it's a standard feature or not. It's the only mud I've been able to stick with for any decent length of time in the past 10 years. As for the explore issue, I'd rather see the flag do the opposite, make it always look like the room has been visited before, then process as normal. At least for every room except for the first one. That way people might not notice something is up if they drop an item, then walk into the room again from another room.

But until this is implemented, I have to result to my other ways of torturing people trying to figure out the area quests... Muhahaha! erm... I mean, I have ways to add unique and creative challenges to enhance the playing enjoyment of others.

Well. I think it is probably pretty standard. When pathing I use brief all the time, since the buffering for command *and* text don't work well on the mud I play at, so if you move more than, I think, 10 rooms, while in verbose it chops most of the rooms that follow, including the one you arrive in. As a result, I do stuff like, "brief, 20 s, 4 n, 3 ne, 5 s, brief, 1 s", this eliminates the buffer glitch for all the rooms in between, but still lets the last room you arrive in be visible. Mind you, a mud+client that stored descriptions locally, like Nick is talking about, could display them all, if you have been there before, without doing brief, but most are going to choke in the middle of a long walk if you don't add a command delay into the mix.

In any case, we have as options:

1. Show short description (room name).
2. Show short long description.
3. Show both.

It has no way to do something like showing only "new" rooms. And frankly, for that to be reasonable, I would expect a sort of negotiation like, client: "I want to move to x.", server: "ACK Unchanged #", or server: "ACK Changed # + data". For clients with no support for that, you would still need a "always show room contents."

As for triggers, etc. One could simply set the server to send something like: "NACK + data", meaning, "I am not going to tell you if this room changed or not, or even what its internal ID is, but here is the room.", for those areas that you *don't* want someone to map as easily.

Aardwolf solves this problem twice. First off, the brief command will check to see if you've been in a room before and display room descriptions according to the option you have set. Secondly, and more frequently used, there is a run command. You type in "run 2s10wn2wn4wn8wn14w12w8n" and the mud will move you there, just showing room names and how many moves you have left at each step. This also cuts back on data sent out from the mud. It's also displayed in a way that screen readers can be set to just plain ignore the output until you hit the last room.