RPTools.net

This is high on mine as well. The idea would be to have sounds files as part of the resource library. The GM would then be able to launch these in a player or have the launched on a client via macro trigger.

RPTroll wrote:This is high on mine as well. The idea would be to have sounds files as part of the resource library. The GM would then be able to launch these in a player or have the launched on a client via macro trigger.

I have sort of a framework in beta but it's been a while. Real life is really getting in the way this summer from making good on getting any meaningful work done on all the half done code and merging my personal build with 1.4.x. Ugg.

I was also using JavaFX and a couple of other libraries, so was sort of waiting on how that pans out with Java 1.8, as I was initially having issue getting the proper runtimes packaged for the build.


However, what I did/do have is a new window/panel/tree/explorer (like Map Explorer panel) that holds "Playlists". Double clicking (right click-add) on an MP3/Wav file in the asset window (which I also added .mp3/wav as showing up in the asset windows) would add said audio file to the playlist. From the playlist window you had standard play/pause/ff/rw controls and it would play to all connected clients (using standard MT asset transmission protocols). The asset window also displayed the Album art for the mp3 or a standard icon if missing.

Along with that there was also a couple of macro's to start/stop/play audio files (to local or remote clients). It all basically worked but I still have lots of bugs to squash (playing multiple files at once had issues, reliably stopping said audio, adding ability for client to "mute" pushed audio, etc). Also a bug where audio files showed up in other asset windows where they shouldn't, like textures when painting... Also still had to work on saving set playlist data to the campaign file...


I only post, in case someone else wanted to take the mantle, I'd share what I have so they wouldn't have to start at nothing, or use it for ideas. It touches a LOT of classes where it comes to assets but most of the audio playing/playlists, etc are in their own classes.

In anycase, it was a neat POC that getting audio in MT wasn't impossibly hard. But to be honest, I always "think" adding audio to my games is cool but the novelty usually wears off, and the number of times where it really is needed, playing the audio outside of MT has been easier.

I likely won't use audio until the triggerables come into being. I really want to add sound effects as folks roam around the map.

As a Mac user, I would really appreciate if the built-in Java version that comes with Maptool would change to 8 instead of the old version (Java 6). I still have no idea how to redirect Maptool to Java 8 that is installed in my Applications folder.

nirkedar wrote:As a Mac user, I would really appreciate if the built-in Java version that comes with Maptool would change to 8 instead of the old version (Java 6). I still have no idea how to redirect Maptool to Java 8 that is installed in my Applications folder.

The Oracle-approved approach for applications is to include a Java implementation that the application is known to work with.

This obviously has some downsides, like increasing the size of the downloads (probably negligible for most people nowadays) and not being able to take advantage of any plugins the user may have installed in their system's default implementation (such as native sound drivers).

The upsides are just as big, and sometimes bigger from the typical user's point of view: guaranteed compatibility, guaranteed configuration, and reduction of external dependencies.

Having said all that, it should be possible for the user to specify that they at least want to try a different JVM, so I agree with you. There's just no Oracle-approved approach for doing this in a platform-neutral, application-neutral way. Which means every application would have it's own tweaks required to do this and they're all going to be different.

In the case of MapTool, the Java-based launcher (is it even part of the 1.4 distro?) allows the specification of a pathname to the Java command, thus allowing a different JVM to be used. Last time I looked (a few months ago) the launcher was included in the download, but it wasn't configured to be the default starting point for the application. Someone more familiar with how 1.4 is packaged might know better.

Azhrei wrote:

nirkedar wrote:As a Mac user, ....

The Oracle-approved approach for applications is to include a Java implementation that the application is known to work with.
...

Hmm. Using 3.b91 on Mac here as well, and 1.4 simply won't start, telling me it can't start the JRE: So the q is: what do I do? Require all my players to install Java 8? (I want to keep using .b91 in parallel until I'm sure 1.4 is the way to go...) What's the trick?

I cant directly help you, but can you try running my test version found at maptool.nerps.net?

It's packaged with its own JRE v1.8, and you sound like a good test candidate Hopefully we can package 1.4.x this way to alleviate such issues...

I may be go back and package b91 this way if I get time...

So Jamz, are you saying 1.4 doesn't currently include the Java runtime?

Must be my mistake then. I thought I saw a maven config somewhere that had the JRE included. Maybe that was 'for future use'...

Correct, the 1.4.0.0 build still packaged MT up like usual, in a zip, with libs. The Launcher is still there but I think we need to integrate more tightly, like Mote, for the same reasons.

The JRE gradle commands were probably just 'targets' for compile. There isn't a direct Gradle command to package JRE's that I know of.

JamzTheMan wrote:I cant directly help you, but can you try running my test version found at maptool.nerps.net?

It's packaged with its own JRE v1.8, and you sound like a good test candidate Hopefully we can package 1.4.x this way to alleviate such issues...

I may be go back and package b91 this way if I get time...

Hi Jamz,

just d'led and ran your fork, started like a charm (and that on my brand new El Capitan'ed Hackintosh), so your package works for Macsess. Need this technique for the offical 1.4.0.0 version... which of course is what I'd like to do. Is there a way to get the official version going?

Thanks guys - good work!

Thanks, that's good news.

I'll look into it but the current issue is that I have to bake the XMM and XSS JVM parameters which isn't perfect.

My group of 5 played for several hours recently on 1.4.0 and had zero hiccups. Seems really stable.

Only "bug" I encountered was that my resource library images change whenever I am looking through textures when choosing a drawing texture. Can document more thoroughly if this isn't something that's already known.

cubeblue wrote:My group of 5 played for several hours recently on 1.4.0 and had zero hiccups. Seems really stable.

Only "bug" I encountered was that my resource library images change whenever I am looking through textures when choosing a drawing texture. Can document more thoroughly if this isn't something that's already known.

What do you mean by change?

I have the resource library window docked to the right of my screen. Say, for example, I have my token images folder selected, so the bottom part of the resource library window shows tokens. When I go into the draw tool, select a color and then flip over to the textures tab, I see my textures, but also, the tokens in my resource library are now replaced by the same textures. When I choose a texture, the resource library continues to show my textures instead of tokens. If I then select some other folder in the resource library, I'll see whatever is in that folder.

Similarly, say I have my state images folder selected in resource library, showing image icons for various states I have there. If I double click a token and change it's token image, as soon as the window comes up showing me my token images, the resource library images change to show my token images also.

It's kind of like anytime there's a window showing that I can see images in, the resource library gets the same list of images. Maybe something is targeting both image views or something.

I see what you mean. Thanks for the explanation. Yeah, that's a bug.