MUSHclient : Plugins : Calling Plugin procedures from triggers

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
MUSHclient
Plugins
Calling Plugin procedures from triggers

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

Calling Plugin procedures from triggers

Reply to this subject Start a new subject Refresh page

Pages: 1 2

Posted by

Sean Randall United Kingdom (14 posts)

Date

Mon 09 Jul 2007 05:04 PM (UTC) [ quote ]

Message

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.

Posted by KP (24 posts) bio

Date Reply #1 on Mon 09 Jul 2007 05:58 PM (UTC) [ quote ]

Message

Sounds like CallPlugin is the way to go.

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

Posted by

Sean Randall United Kingdom (14 posts)

Date

Reply #2 on Mon 09 Jul 2007 06:09 PM (UTC) [ quote ]

Message

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.

Posted by

Worstje Netherlands (867 posts)

Date

Reply #3 on Mon 09 Jul 2007 08:41 PM (UTC) [ quote ]

Message

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.

Posted by

Sean Randall United Kingdom (14 posts)

Date

Reply #4 on Mon 09 Jul 2007 08:57 PM (UTC) [ quote ]

Message

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.

Posted by Nick Gammon Australia (18,800 posts) bio Forum Administrator

Date Reply #5 on Mon 09 Jul 2007 09:36 PM (UTC) [ quote ]

Message

Quote:

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.

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:


jfwobject.Skip "sentence", 10

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by Sean Randall United Kingdom (14 posts) bio

Date

Reply #6 on Mon 09 Jul 2007 10:16 PM (UTC) [ quote ]

Amended on Mon 09 Jul 2007 10:19 PM (UTC) by Sean Randall

Message

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:

One to work with JAWS (the most widely-used screen reader). JAWS com API supports sending text to interrupt anything presently speaking.
One to work with Window Eyes, which is also a commercial screen reader. I don't use it myself, but several MUSHclient users do.
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.

Quote:

Can you please post the method you use to interrupt speech?

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

 jfwobject.speak "",3

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

Posted by

Cage_fire_2000 USA (119 posts)

Date

Reply #7 on Tue 10 Jul 2007 01:08 AM (UTC) [ quote ]

Message

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.

Posted by

Onoitsu2 USA (246 posts)

Date

Reply #8 on Tue 10 Jul 2007 09:01 AM (UTC) [ quote ]

Amended on Tue 10 Jul 2007 09:05 AM (UTC) by Onoitsu2

Message

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

Posted by

Sean Randall United Kingdom (14 posts)

Date

Reply #9 on Tue 10 Jul 2007 04:00 PM (UTC) [ quote ]

Message

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!

Posted by

Shadowfyr USA (1,774 posts)

Date

Reply #10 on Tue 10 Jul 2007 06:22 PM (UTC) [ quote ]

Message

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...

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Reply #11 on Tue 10 Jul 2007 06:49 PM (UTC) [ quote ]

Message

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

Quote:
You would need something more complex

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...

Quote:
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?

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...

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #12 on Tue 10 Jul 2007 08:55 PM (UTC) [ quote ]

Amended on Tue 10 Jul 2007 08:57 PM (UTC) by Shaun Biggs

Message

Quote:
Imagine for example crowd babble in a room that is "described" as being a busy market with hundreds of people in it.

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.

Quote:
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?

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.

Quote:
Damn I wish I knew enough about coding this kind of stuff to try some of the ideas I come up with. Sigh...

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.

It is much easier to fight for one's ideals than to live up to them.

Posted by Nick Gammon Australia (18,800 posts) bio Forum Administrator

Date Reply #13 on Tue 10 Jul 2007 09:42 PM (UTC) [ quote ]

Message

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:


(droning voice): Exits: north east south west.
(female voice): Nick says, (male voice) Hi there
(excited voice): The kobold attacks you!
(announcer's voice): <Room description>

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Sean Randall United Kingdom (14 posts)

Date

Reply #14 on Tue 10 Jul 2007 09:55 PM (UTC) [ quote ]

Message

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.

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

8,962 views.

This is page 1, subject is 2 pages long: 1 2

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )