MapTool Sounds

[LordAshes]

Is there any way to generate sounds in MapTools.

I while back I wrote a program somewhat similar to MapTools but geared more for Card Games than roleplaying. One of the features, for setting atmosphere, was to be able to send short WAV or MP3 clips to the other players.

I tried to accomplish the same in MapTools but was unsuccessful...

1. I tried sending an IMG tag with reference to the sound file in the parameter dynsrc directly to the chat window (i.e. output of the macro) but that did not work. No sound.
2. I tried creating a frame with the above IMG tag. The frame showed up but the sound did not play.
3. I tried creating a frame with a simple HTML page that included BGSOUND. The frame showed up but the sound did not play.
4. I tried creating a frame with a simple HTML page that included EMBED. The frame showed up but the sound did not play.

Anyone know of a way to do this? The sound file can be either local to the server, local to the server and clients or HTTP...I don't care...I'll take any solution.

[Azhrei]

External files are not accessible to MTscript. At all.

The best you could do would be to provide a URL link that causes the browser to open the file and play it. And you would still need to click the link yourself.

[LordAshes]

External files are not accessible to MTscript. At all.

The best you could do would be to provide a URL link that causes the browser to open the file and play it. And you would still need to click the link yourself.

That is a real shame. I can see why this might have been done (i.e. for security reasons) but it would be great if MapTools implemented a simple sound function.


Suggested Syntax:

playSound(URL)

playSound(URL,Loop)

Where the URL is a legal URL to a WAV or MP3 file. If URL is empty (=="") then the current sound, if any is playing, is turned off (i.e. used to cut off sound before the number of loop itterations are complete).

Loop would be an optional parameter indicating the number of times the sound is played. Default is 1. Supports keyword "Infinite" which repeats the sound until the sound is cut off with a subsequent play commmand (with URL="").

Subsequent call to play (with a non empty URL) would cut off the previous sound and start the new sound.

Example,

playSound("http://www.MyFreeSounds.com/SoundEffects/Clapping.wav")

[LordAshes]

External files are not accessible to MTscript. At all.

The best you could do would be to provide a URL link that causes the browser to open the file and play it. And you would still need to click the link yourself.

I am not up on my Java. I used it a bit a long time ago but have not really used it since. How difficult would it be to add code to MapTools that would launch a real webbrowser page instead of using the MapTools frame? If MapTools was able to launch a regular webpage then you could do all of the options supported by your web browser (i.e. including sound) but still keep all the security that web browsers have built in.

Edit:

To implement such a feature one would need two commands at least...

launchPage(URL); or launchPage(URL,State);
closePage();

The launchPage function would just open up the indicated URL in the client`s default web browser. The URL parameter would be the URL of the webpage you want to launch which would be constructed outside of MapTools as opposed to the frame roll option which allows the construction of the frame within MapTools. State would be an optional parameter which would indicate if the Web Browser should be launched Normal or Minimized. Normal state would be used for showing webpages to the users (such a images from a online file server). The Minimized state would be used for sound based webpages.
The closePage function would close the last launched page. It would be used to close unused Pages (e.g. after the sound has finished playing).

[jfrazierjr]

I am not up on my Java. I used it a bit a long time ago but have not really used it since. How difficult would it be to add code to MapTools that would launch a real webbrowser page instead of using the MapTools frame? If MapTools was able to launch a regular webpage then you could do all of the options supported by your web browser (i.e. including sound) but still keep all the security that web browsers have built in.

It would be fairly trivial, but we are not going to do it in the main code branch. There is just way to much security concern.

Post 1.4, sound may be supported by either including the file in the campaign or repository files, but a remote URL, I just don't see happening.

[Azhrei]

If MTscript could force browser windows to open, it allows a DoS attack. That won't happen.

As Joe says, we might build a UI to allow sound files to be added to the campaign as an asset. Then the asset:// URL or something similar would work to reference the file.

But Java's built-in sound support isn't very good. There's a free library out there that provides both a framework API and a UI that looks good and we may use that. (Don't recall the name off-hand and I can't find it in my bookmarks right now.)

[LordAshes]

I am not up on my Java. I used it a bit a long time ago but have not really used it since. How difficult would it be to add code to MapTools that would launch a real webbrowser page instead of using the MapTools frame? If MapTools was able to launch a regular webpage then you could do all of the options supported by your web browser (i.e. including sound) but still keep all the security that web browsers have built in.

It would be fairly trivial, but we are not going to do it in the main code branch. There is just way to much security concern.

Post 1.4, sound may be supported by either including the file in the campaign or repository files, but a remote URL, I just don't see happening.

Hmmm...I am not sure I understand the security implications. Assuming that the URL had to be a remote address (i.e. not local) then your web-browser security should already take care of all the security.

[Azhrei]

I am not sure I understand the security implications.

I'm pretty sure this has been discussed already. A search would probably find it. You might look for "ddos" as I believe denial-of-service attacks were mentioned in the thread (they're the easiest to perpetrate).

[LordAshes]

I am not sure I understand the security implications.

I'm pretty sure this has been discussed already. A search would probably find it. You might look for "ddos" as I believe denial-of-service attacks were mentioned in the thread (they're the easiest to perpetrate).

I found some of the security issues (DDOS) discussions related to allowing full web contents and here are my thoughts...

My understanding of DDOS attacks are just from what I have heard (never having participated in such an act) and my understanding of MapTools is also somewhat limited so please feel free to correct any of my statements if I am wrong...

As far as I understand, A DDOS attack is typically comitted by a large number of computers (or more accurately internet connections) to a single source in an attempt to overwhelm the server and/or tie up connections to the server. In order to accomplish it, teh attack needs many connections (typically by many computers), timing co-ordination so that all the attacks happen at relativly the same time, and possibly quick repeatability so that the same computer can participate in the attack multiple times if the server is not knocked down on the first strike.

First I would like to agree with some of the other posters that, if one wanted to make such an attack, MapTool would probably not be the medium to do it in. Lets consider why:

1. Without any disrespect to the MapTool programmers, the Macro language inside MapTools (as far as I know) is an interpreted language. MapTools interprets the macro line by line as it executes it (with possibly some general checks before hand to ensure that the code is basically valid). This means it will naturally run slower than code that is compiled. So this bring into question how well the Macro language of MapTools could be used to get the "repeatability" component of a DDOS attack. In addition, the way that I proposed to implement the web page function, was to have the OS launch its default browser. Now I can not speak for operating systems like Linux but on a Windows machine, even if you have a leading edge computer system, it takes time to bring up the default browser. This means that in order to peform multiple connection requests, one would need to launch multiple browsers and the delay in bringing up the browser would probably mean that the time between connection attempts would be too long for a solid DDOS attack.

2. Although the MapTools server, with a web page function, could make many client connect to the same site (thus participate in a DDOS attack) it is important to remember that the clients would have to be willing participants. Unless the MapTool server has control of the client's machines through alternative means (in which case MapTools would not be needed), the MapTool server can not make client connect to it. The client needs to initiate the connection to the server. If you don't trust the owner of the MapTool server, then you probably should not be connecting to the server in the first place.

3. I am not sure how well MapTools could be used to co-ordinate the timing of a DDOS attack. When I used MapTool for one of my sessions, sometimes there was considerable lag involved. For using MapTools this is annoying when it happens but acceptable. However, if you are trying to co-ordinate a DDOS attack where you need all clients to make the attack at the same time, this lag could be disasterous especially if the clients could not quickly repeat the attack (see point 1).

So in my opinion, the fact that MapTools would be used to make some kind of a DDOS attack is fairly remote. There are probably a tonne of programs better suited for it and, probably, just as readily available on the net.

In addition, almost anything can be used in some evil unexpected way. Look at PING. It was intended as a testing tool but it can be used to create the PING OF DOOM. Someone wanting to make a DDOS (or similar) attack will find the tools to do it anyway, so why hold back on some very powerful yet easy to implement functionality just because someone might use MapTools in a evil way. We aren't all throwing away our cars just because someone could kill someone else with a car, are we?

Plus there are some basic percautions that we an take to try to minimize the ability for MapTools to be used for attacks. For example:

1. Limit the amount of web pages that can be launched. Thus one would need to first close the last page before launching a new page (thus introducing more delay).

2. Limit how frequently pages can be launched. If, for example, there would be a 3 second period before any page can be launched, the effects on MapTool usage would be minimal but it would make it almost useless as a DDOS platform.

3. You could even implement some sort of checks to see if the same pages is being requested frequently but this could cut into legitimate use (e.g. if the users, for example, frequently go to the same page because it is a battle sound).

[CoveredInFish]

That sounds like a lot of work for - forgive me - little gain.

My computer can already open web pages and with maptool i can share working links. Not really good embedded, but I can point players to net-bits.

There are some mighty solutions for sound - probably better than maptool ever can do it. I think in the forums are instructions for setting up some kind of web radio (eg)

It might be a problem (call it security, call it principle) if someone can open websites on my computer without my control. I usually play with friends - so I had no concerns there - but there is no only-friends-policy in maptool

[LordAshes]

That sounds like a lot of work for - forgive me - little gain.

You are entitled to your opinion but I think that it is actually little work (someone indicated popping up a webpage in the default browser is fairly trivial...I can't speak for Java...but I know it is fairly trivial in other programming languages). The launching of the default web browser already causes a delay without even coding one, so that is a freebie. The only work might be in doing a check to see if the default web browser is already active (with a MapTool launched page) to prevent the multiple launches.

I think that it actually is a fairly large gain because not only would you be able to do sound, you would also be able to do video. Imagine a roleplaying session where the players meet a horde of goblins and the GM presses a button launching the default browser on the client's computer which displays a short video of a goblin horde coming over the hill...wow!

My computer can already open web pages and with maptool i can share working links. Not really good embedded, but I can point players to net-bits.

Yes with MapTools you can send player's the link but, IMHO, that just doesn't have the same feel. I mean think of a suspensful campaign. The players are sneaking around trying to be undetected. Suddenly the GM plays a "Halt! Who goes there?!" audio...It would be priceless.

There are some mighty solutions for sound - probably better than maptool ever can do it. I think in the forums are instructions for setting up some kind of web radio (eg)

Point taken. We usually use MSN or Skype when playing (one of my players is Dyslexic so chat typing is not a good idea) and I already wrote a MSN audio clip launcher which allows you to store and playback up to 20 audio clips through a simple button menu. So there are ways around the sound issue.

It might be a problem (call it security, call it principle) if someone can open websites on my computer without my control. I usually play with friends - so I had no concerns there - but there is no only-friends-policy in maptool

Point taken...so why not make it an option which each client (when connecting) could turn on (make it off by default). Then, if you trust your GM, you can turn the feature on? Sounds like the best of both worlds.

[aliasmask]

I wouldn't mind having a sound assetId. We can keep it simple and just use .wav (I think that is universal enough). The pain is that it's not compressed and if it's going to be hooked with an event should probably be cached which will take up potentially a lot of memory.

I played this game called Subspace (now called Continuum, very old school game) and they make use of .wav files, but are limited to 32k and only loads 10 (plus a couple of specials). Warning this game is super awesome and super addictive. Anyway, having some sound event handler IMO would be cool, where a playlist is added to campaign (like a table) and sound effects can be played. Now for actual music, that would be nice too to have a mp3 assetid and a built in player (super generic) where the music can be muted or stopped, but is controllable by gm to schedule a new event (client server allowing).

[Azhrei]

There are some mighty solutions for sound - probably better than maptool ever can do it.

This is the kicker.

Do you want the dev team working on doing something that other programs will (likely always) do better than MT will? Or would you rather we work on things directly related to gaming, such as MBL, user-defined layers, and so forth?

Not to be rude, but it's rather pointless to continue discussion since the current dev team isn't giving sound (or external access) any kind of priority at this time.

However, everyone is welcome to contribute patches to MapTool. They will need to convince the team on a number of points, already discussed above, before those patches will be accepted into the code base. In the mean time you can run a custom build (similar to what Joe plans to do). There are a few people here who have contributed patches who are aware that not everything is accepted.

[LordAshes]

I wouldn't mind having a sound assetId. We can keep it simple and just use .wav (I think that is universal enough).

This was why I was thinking of implementing it through the default browser because then MapTools could let the browser figure it all out. You would not need to write code for actually playing the various audio files because the default browser already has the functionality...the up side would be that you could then handle any type of file that your default browser can handle. The downside would be that various players might not have the plugin for that particular file type installed - if you start playing with odd file types.

If you start to make assetID for various file types (such as WAV or MP3) there will always be someone asking for more (e.g. what about video files?). If you use the default browser, it solves this problem for most common file types.

The pain is that it's not compressed and if it's going to be hooked with an event should probably be cached which will take up potentially a lot of memory.

I don't think we would necessarily need a event handler for it. Typically the GM runs everything anyway so he could have, for example, a token (not visisble to others) which would have macros for launching the WAV files. Problem solved: your GM is the event handler. Ofcouse you could still write macros using the MapTool provided events and thus, for example, honk at the player when he tries to exceed his/her move.

[LordAshes]

There are some mighty solutions for sound - probably better than maptool ever can do it.

This is the kicker.

Do you want the dev team working on doing something that other programs will (likely always) do better than MT will? Or would you rather we work on things directly related to gaming, such as MBL, user-defined layers, and so forth?

Not to be rude, but it's rather pointless to continue discussion since the current dev team isn't giving sound (or external access) any kind of priority at this time.

However, everyone is welcome to contribute patches to MapTool. They will need to convince the team on a number of points, already discussed above, before those patches will be accepted into the code base. In the mean time you can run a custom build (similar to what Joe plans to do). There are a few people here who have contributed patches who are aware that not everything is accepted.

I agree with you 100% percent. This is why I was suggesting the default web browser approach because it would be fairly trivial to add (at least according to the opinion in this post). The only thing that the code team would have to do is add the conditional statement that launched the default web browser (with the desired URL) only if the Client option is turned on.

This way the feature could be implemented with the least amount of work (instead of coding actual sound and/or video assets) and get the code team working on the important stuff.

Maybe, if I get some time, I will look into the possibility of adding it myself and see how it flies.