*COMPLETED* MapTool b89 with Streaming Sound Functionality

Show off your RPG maps, campaigns, and tokens. Share your gaming experiences and stories under General Discussion and save this forum for things you've created that may help others run their own games. Use the subforums when appropriate.

Moderators: dorpond, trevor, Azhrei, Gamerdude

User avatar
Lord.Ashes
Dragon
Posts: 350
Joined: Wed Jul 03, 2013 5:58 am

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Lord.Ashes »

JamzTheMan wrote:Lord.Ash, suggestion. If you are using the same "asset" folder as MT, and you are going through the effort of creating something, can you put it in a separate patch?

If it can be used for all cache/asset items, it would be a welcomed addition to 1.3 and maybe Az can add it in. ;)
Please see http://forums.rptools.net/viewtopic.php?f=3&t=24102 for my clean Cache Cleaner implementation. Obviously I will soon post a version that is integrated into my 1-3.b89s version (i.e. my modified MapTool which implements sound functions) but I need to switch the caching to use the assetcache directory since my Cache Cleaner only cleans that directory.

If you have comments specific to the Cache Cleaner please use the other post (http://forums.rptools.net/viewtopic.php?f=3&t=24102) for discussion.

EDIT: I have decided to hold off a few days before adding the CacheCleaner to the MapTool-1.3.b89s build (i.e. my sound implementation build) so that I can get feedback on the CacheCleaner. I have already implemented a couple new features for it to make it appeal to more users. As was mentioned, MapTool currently does not have a cache cleaning mechanism and thus I'd like to get as many people's opinion on my implementation (please post those opinions in the CacheCleaner thread @ http://forums.rptools.net/viewtopic.php?f=3&t=24102) so that my implementation could, possibly, be used as the basis of the core MapTool cache cleaner (e.g. in b90).
"We often compare ourselves to the U.S. and often they come out the best,
but they only have the right to bare arms, while we have the right to bare breasts"
The Right To Bare Breasts by Bowser & Blue

User avatar
Lord.Ashes
Dragon
Posts: 350
Joined: Wed Jul 03, 2013 5:58 am

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Lord.Ashes »

MapTool-1.3.b89s Rev 5

Use same link as before but go to the Rev 5 section.
MapTool-1.3.b89s_Patch Rev5.txt
(32.13 KiB) Downloaded 47 times
How To Use MapTool-1.3.b89s Rev5.txt
(16.22 KiB) Downloaded 46 times
Everything is the same as Rev 4 with the following additions/changes:

* Added Rev 4 of CacheCleaner. The default settings are Warning at 1024MB, Cutoff (automatic cleaning) at 2048MB, Cleaning Down To 512MB. Notification mode "Warning". See Thread http://forums.rptools.net/viewtopic.php?f=3&t=24102 for details on what this means. The above "How To" file does not provide details on this feature since it is mostly a passive feature but the indicated thread can be used to understand how it works.

* For compatibility with CacheCleaner, Sounds are now cached in the MapTool assetcache directory (as opposed to MapTool resource directory).

* Server side no cache honorary system requests

This is a method for any audio server (with additional coding or special requirements) to make a request to MT indicating that the corresponding audio file should not be cached. This is NOT intended to prevent the USER from violating copyright laws, it is intended to prevent MT from violating copyright laws. It is a completely honorary mechanism since the server has not way to enforce it. My MT sound implementation, however, honors this mechanism.

Basically, in order to indicate that a sound file should not be cached, the file name extension, on the audio server, is changed from ".wav" to ".no-cache.wav". When MT is asked to play a sound file it first check (as it did in Rev 4) for a local copy. If it exists then the local copy is used and caching is not applicable. If the sound file does not exist locally, MT will try to play it from the repository. If the file does not exist, MT will try modifying the file name with the no cache addition. This means that the audio file on the server only needs to be there once, either with or without the ".no-cache" addition, and the MT streaming mechanism will find it and stream it. However, the MT cache functions strictly look for the file without the ".no-cache" addition. Thus if the file on the audio server contains the ".no-cache" addition, the MT cache functions will not be able to locate the corresponding audio file and thus the file will not be cached.

There are two main reasons for using this mechanism:

* Copyright files. If the server includes copyright files which the user has rights to mass play but not distribute, this mechanism can be used to tell MT not to copy the file to the local machine. As was mentioned above, this is not intended to prevent the USER from copying the copyright file...there are many programs that will allow users to get the copyright file if they choose to violate the copyright law. This implementation is just there so that MT does not help in terms of that endeavor.

* Since MT does not currently use any version method for cached sound files, it is not possible for MT to determine if the audio file on the server has changed. In such a case it will always play the local version regardless if the server version has changed. My making the server file non-cached, MT will be forced to re-stream the file from the audio server each time. Consider a very silly example, the audio server has a file called "Weather.wav" which contains the weather report for the day. If on day 1, MT is asked to play this file it will stream and cache the file locally. Now, on day 2, let us say that the weather had changed and thus the audio file on the audio server has been updated. Since MT currently does not do any kind of checking to see if the file has been updated, if MT was asked to play the weather file on Day 2 it would play the locally cached version which would not be correct (since it would be the weather for Day 1). If, however, the weather file on the server was changed to "Weather.no-cache.wav" then MT would stream but not cache the weather report on Day 1 and thus on Day 2 MT would need to re-stream the audio file meaning it would play the, correct, updated audio file.
"We often compare ourselves to the U.S. and often they come out the best,
but they only have the right to bare arms, while we have the right to bare breasts"
The Right To Bare Breasts by Bowser & Blue

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Full Bleed »

Lord.Ashes wrote:* Server side no cache honorary system requests

This is a method for any audio server (with additional coding or special requirements) to make a request to MT indicating that the corresponding audio file should not be cached. This is NOT intended to prevent the USER from violating copyright laws, it is intended to prevent MT from violating copyright laws. It is a completely honorary mechanism since the server has not way to enforce it. My MT sound implementation, however, honors this mechanism.

Basically, in order to indicate that a sound file should not be cached, the file name extension, on the audio server, is changed from ".wav" to ".no-cache.wav". When MT is asked to play a sound file it first check (as it did in Rev 4) for a local copy. If it exists then the local copy is used and caching is not applicable. If the sound file does not exist locally, MT will try to play it from the repository. If the file does not exist, MT will try modifying the file name with the no cache addition. This means that the audio file on the server only needs to be there once, either with or without the ".no-cache" addition, and the MT streaming mechanism will find it and stream it. However, the MT cache functions strictly look for the file without the ".no-cache" addition. Thus if the file on the audio server contains the ".no-cache" addition, the MT cache functions will not be able to locate the corresponding audio file and thus the file will not be cached.
Clever way to do it. You might want to consider offering a field in the macro call to cache or not cache, too:

[playSound("SongName", noCache)]

With the default being to cache.


Suggestion: The latest version of a mod is usually updated in the OP... the larger this thread gets, the harder it is for people to get at the latest version and observe necessary changes to the implementation. You might even want to think about using your second post (currently a bug report) as your running changelog if you'd like a history of the releases in one place (i.e. as you update the OP just cut and past the last update into your change log post. Then bump the entire thread with a note that the newest release is in the OP.)
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

User avatar
Lord.Ashes
Dragon
Posts: 350
Joined: Wed Jul 03, 2013 5:58 am

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Lord.Ashes »

Full Bleed wrote: Clever way to do it. You might want to consider offering a field in the macro call to cache or not cache, too:

[playSound("SongName", noCache)]

With the default being to cache.
Yes. I was already thinking of this but I figured that specifying it on the server is the better solution. That does not mean that I won't provide the no-cache option on the playSound in the future...but generally the only reason why you would not want to cache is either copyrights or changing audio content which are both more related to the server as opposed to the client. Even if you didn't want to cache due to privacy concerns (i.e. you are on a public machine) then you would want to turn caching off at the MT level as opposed to the playSound level because you don't want to have to use a modified campaign file. So I can't really think of a practical use of the no cache on the playSound function. It is more likely that I will implement a no-cache option for the MT client, first, before adding this option to playSound.
Full Bleed wrote: Suggestion: The latest version of a mod is usually updated in the OP... the larger this thread gets, the harder it is for people to get at the latest version and observe necessary changes to the implementation.
Sorry still a newbie to this forum, what is OP? Can you please explain? I wasn't sure the best way to do this. This is why I posted the link in the first article of this thread and when I release new releases, I just make a new sub-folder in that directory so the link remains applicable for any release. However if there is a more proper way of doing this which is more inline with the forum, please explain.
"We often compare ourselves to the U.S. and often they come out the best,
but they only have the right to bare arms, while we have the right to bare breasts"
The Right To Bare Breasts by Bowser & Blue

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by wolph42 »

Neat and clever!

So if a sound is cached, and a new but same name is used by the gm, is it possible to give a 're-cache' command, or some remote delete (the latter sounds a bit scary...)

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Full Bleed »

Lord.Ashes wrote:Sorry still a newbie to this forum, what is OP? Can you please explain?
Original Post (or "Original Poster" if you're referring to a person.)
I wasn't sure the best way to do this. This is why I posted the link in the first article of this thread and when I release new releases, I just make a new sub-folder in that directory so the link remains applicable for any release. However if there is a more proper way of doing this which is more inline with the forum, please explain.
Usually the first post in the thread will have the most updated installation and usage instructions and a link to the latest version of the mod. So you would just edit your first post and update it as you release new versions. Many people will not read very deep into a large thread, or will only read the last couple pages... which means they may be missing some important bit of information that came up along the way. So it's best to just put everything relevant in the first post. People can read through the thread if they really want to see how you got to the current stage.

If you want to maintain a change log, you could edit your second post and just cut and paste the contents of the first post into it as you replace it with updated information. That's totally optional though, as people can see the changes by going through the thread itself if they want to. Regardless, be sure to bump your thread with the new release notes in a new post as well (because if you just edit the first post without adding a new post to the thread it won't show up in a "View New Posts" forum search or show a history of your progress).

Take a look at Wolph's Bag of Tricks post as an example. Currently 73 pages and 25 versions with all you need in the first post every step of the way.

Aliasmask's RPEdit mod is also a good example where he uses some posts immediately after the OP to provide some other information (Version History and a FAQ).
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

User avatar
Lord.Ashes
Dragon
Posts: 350
Joined: Wed Jul 03, 2013 5:58 am

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Lord.Ashes »

Full Bleed wrote:
Lord.Ashes wrote:Sorry still a newbie to this forum, what is OP? Can you please explain?
Original Post (or "Original Poster" if you're referring to a person.)
I wasn't sure the best way to do this. This is why I posted the link in the first article of this thread and when I release new releases, I just make a new sub-folder in that directory so the link remains applicable for any release. However if there is a more proper way of doing this which is more inline with the forum, please explain.
Usually the first post in the thread will have the most updated installation and usage instructions and a link to the latest version of the mod. So you would just edit your first post and update it as you release new versions. Many people will not read very deep into a large thread, or will only read the last couple pages... which means they may be missing some important bit of information that came up along the way. So it's best to just put everything relevant in the first post. People can read through the thread if they really want to see how you got to the current stage.

If you want to maintain a change log, you could edit your second post and just cut and paste the contents of the first post into it as you replace it with updated information. That's totally optional though, as people can see the changes by going through the thread itself if they want to. Regardless, be sure to bump your thread with the new release notes in a new post as well (because if you just edit the first post without adding a new post to the thread it won't show up in a "View New Posts" forum search or show a history of your progress).

Take a look at Wolph's Bag of Tricks post as an example. Currently 73 pages and 25 versions with all you need in the first post every step of the way.

Aliasmask's RPEdit mod is also a good example where he uses some posts immediately after the OP to provide some other information (Version History and a FAQ).
Got it. So in this particular case the link in the first post is still correct but I should edit the original post with all the change log modifications. Got it. I will do that with the next release and update the first post with all changes.
"We often compare ourselves to the U.S. and often they come out the best,
but they only have the right to bare arms, while we have the right to bare breasts"
The Right To Bare Breasts by Bowser & Blue

User avatar
Lord.Ashes
Dragon
Posts: 350
Joined: Wed Jul 03, 2013 5:58 am

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Lord.Ashes »

As per the suggestion, I will be keeping the original post up-to-date with the latest version number, link and change log for my implementation. In this manner, user won't have to search through this thread to find the latest version. The link currently links back to a folder in which I am keeping all revisions (in their respective folders) but it should be obvious what the latest version is (i.e. the version with the highest revision).
"We often compare ourselves to the U.S. and often they come out the best,
but they only have the right to bare arms, while we have the right to bare breasts"
The Right To Bare Breasts by Bowser & Blue


User avatar
Lord.Ashes
Dragon
Posts: 350
Joined: Wed Jul 03, 2013 5:58 am

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Lord.Ashes »

wolph42 wrote:You're allowed now to use the term OP :wink:
Thanks for the "initiation"... :wink: But there could be other newbies around.
"We often compare ourselves to the U.S. and often they come out the best,
but they only have the right to bare arms, while we have the right to bare breasts"
The Right To Bare Breasts by Bowser & Blue

Volomon
Cave Troll
Posts: 56
Joined: Fri Jul 02, 2010 4:43 am
Contact:

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Volomon »

This is going to be a stupid question, so don't beat me to hard.

I automatically assume this has to be on everyone's Maptools in order for it to work, right?

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by wolph42 »

Volomon wrote:This is going to be a stupid question, so don't beat me to hard.

I automatically assume this has to be on everyone's Maptools in order for it to work, right?
Thats not a stupid question at all, but yes if you want to remotely play some sound then The other mt version must understand what you're asking.

User avatar
Lord.Ashes
Dragon
Posts: 350
Joined: Wed Jul 03, 2013 5:58 am

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Lord.Ashes »

wolph42 wrote:
Volomon wrote:This is going to be a stupid question, so don't beat me to hard.

I automatically assume this has to be on everyone's Maptools in order for it to work, right?
Thats not a stupid question at all, but yes if you want to remotely play some sound then The other mt version must understand what you're asking.
I will somewhat correct this statement but basically it is true. The way the sound functions (that I added) work is by using the regular chat messages and inserting special characters that the clients recognize as a audio instruction. So in order for the client to actually play the sound, the client must be the 1.3b89s version (i.e. the modified version). However, if you manage to use a unmodified version (i.e. 1.3b89) with a modified version (i.e. 1.3b89s), which is not normally possible because there is a check that requires the MT version of the server and clients to be the same, the unmodified client would still get the chat message (also known as the audio cue) but it wouldn't recognize it as a special command so no audio would be played (i.e. it would just display it in the chat screen). This would be a similar effect as using the modified version with earPlugs turned on (i.e. you get a chat message indicating that a player requested audio but no audio is played). Obviously the unmodified client would not be able to send any audio requests (at least not using macro commands) since the macro commands would not be present in an unmodified version.

So unless you are going to use my patch to modify your own copy of MapTool and still call it version 1.3b89 then it is unlikely you will be able to mix unmodified and modified versions of MT and thus the initial answer of "yes, all clients must use the modified version to play sounds" is true.
"We often compare ourselves to the U.S. and often they come out the best,
but they only have the right to bare arms, while we have the right to bare breasts"
The Right To Bare Breasts by Bowser & Blue

User avatar
Lord.Ashes
Dragon
Posts: 350
Joined: Wed Jul 03, 2013 5:58 am

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Lord.Ashes »

This is actually a good point...I should look into modifying the version check on the server/client connection to look at the base version (e.g. 1.3.b89) ignoring any suffix on the end. This would allow a version, such a my sound version, to be distinguished from the core version but still be compatible with a core server. After all there is no real reason to now allow a non modified MT to be used with my sound modified one...it won't play the sounds but it is still otherwise compatible.
"We often compare ourselves to the U.S. and often they come out the best,
but they only have the right to bare arms, while we have the right to bare breasts"
The Right To Bare Breasts by Bowser & Blue

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: *COMPLETED* MapTool b89 with Streaming Sound Functionali

Post by Azhrei »

PLEASE don't do that!

If your sound version interoperates without an error with an unmodified MT, then when some people get sound and others don't it will be reported here as a bug. It is very important that people understand that your patches are not supported by us or we'll be flooded with support requests!

Anyone who has downloaded your custom build (probably the GM) can easily send the link to their players.

Post Reply

Return to “User Creations”