There you go, I've learned something - I didn't see it in the URL RFC.
Printable View
At a guess, emphasis on the guess, the third / may actually be part of the path....
file:///C:/Users/damned/Desktop/rbm/web1/warlock.jpg
Yeah, that makes sense - I've never really thought about it until now :)
Cheers
Yup, damned is correct. 3 slashes have to follow the "file" header and using 2 slashes within a browser address bar returns an error and won't play the local music file. So here's the interesting bit that i don't know what to think, when I enter:
in the address bar of firefox or chrome the music begins to play immediately from within the browser. I had assumed this was some browser-ish feature but am not sure.Code:file:///home/skj310/Music/DnD/gun-shot3.ogg
In linux it's possible to play music from the commandline without needing to open an application, for example:
orCode:skj310@hostname ~ $ play /home/skj310/Music/DnD/gun-shot3.ogg
File Size: 15.7k Bit Rate: 112k
Encoding: Vorbis Info: Processed by SoX
Channels: 2 @ 16-bit
Samplerate: 44000Hz
Replaygain: off
Duration: 00:00:01.11
In:100% 00:00:01.11 [00:00:00.00] Out:49.0k [ | ] Hd:0.0 Clip:0
Done.
So no need to open VLC to play the file!Code:skj310@hostname ~ $ gst-launch-1.0 playbin uri=file:///home/skj310/Music/DnD/gun-shot3.ogg
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
Got EOS from element "playbin0".
Execution ended after 0:00:00.675375801
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
Notice that in the 2nd commandline option, it requires me to enter the path using the "file:///" header as discussed above. At this point i'm gonna run FG in a windows VM and see if i can work out what happens when playing local files. Then perhaps i can workout what seems to be mising from linux.
My concern in all this was that perhaps there was something blatantly obvious regarding the URL syntax related to DOE:Sound or FG; but based on your replies, I am now thinking that perhaps this is not something tied to the code y'all are familiar with and I'll need to dig deeper into understanding the differences in OS ... i'll report back whatever i might find. Thanks.
Well, the DOE: Sound and DOE: OLE basically use the same "hack" of the underlying FG system that allows a website to be opened up from within FG - you know, the "Read User Manual" and other links on the FG Launch Screen.
The "hack" has to do with how FG treats these links when Exporting and Importing to/from a Module, not how the link is processed by the FG-engine, so a plain URL/URI should work, and up to now has. We tested our URL-strings and suggest others test theirs by putting in the URL-string into their browser: if it works in the browser, it works in the DOEs - up to now.
Mind you, all that's been done on a Wintel box - we've never done it before now on a *nix box (using Wine, I assume), so I'd be really interested to see if it works in your VM (a Windows VM, I assume).
Interesting ... my findings are as follows:
Yes it works in the VM as you mentioned. When placing a path like "Z:/Documents/DnDMusic/gun-shot1.ogg" to the address bar of firefox/chrome/IE it translates to "file:///Z:/Documents/DnDMusic/gun-shot1.ogg".
Ok that's all fine ... but what happens? I noticed 2 distinct things:
- Well it looks like html5 will translate "file:///Z:/Documents/DnDMusic/gun-shot1.ogg" and automatically play the file from within the browser.
- Whereas using DOE:OLE and DOE:Sound will take either URL "Z:/Documents/DnDMusic/gun-shot1.ogg" or "file:///Z:/Documents/DnDMusic/gun-shot3.ogg", then open the default music player (on my VM the default has been set to VLC), and play the file successfully.
Whereas on linux it is step 2 above that acts differently and where I get lost (hmmm, I wonder if this would be a similar issue on MAC)! Why? Cause I'm not sure what happens when the link is exported from the module. Is there anyway that I can turn up the debug level on FG?
Otherwise, you are also correct in your assumption of using wine in linux, therefore i'll run FG with the winedbg turned on and see if i can see anything there as well. As before i'll keep you posted on what i find.
When a Soundlink is imported from a module (or even played from a module) the DOEs strip a suffix (in the form "@module_name") from the URL which the FG-engine places there on Export - if it exists. This is one of the reasons that I created the Soundlink and OLElink classes/templates in the first place (from the link class parent), because of the FG-inherent Export/Import issue.
Short answer is this should have no effect on the issue you are having - provided you are actually using Soundlinks / OLELinks ie the link icons are purple and green, respectively.
I don't know of a way to turn up the debug level in FG.
BTW have you tried the URL without the "file:///" part?
Regarding debug level in FG, yeah I expected that, so I'll see what I can do using wine debug (a royal pain to deal with ... mostly cause I've not have much success in the past).
Otherwise regarding, yes I have and the results are the same.Quote:
have you tried the URL without the "file:///" part?
Regarding running in Linux OS: Fantasy Grounds doesn't know what to do with the "file://" protocol when opening the "url" windowclass within Linux.
Try typing this in the chat line: /openwindow url file:// In Linux, nothing will happen. In Windows this will open File Explorer. Now, this may depend completely on how you're running FG within Linux, but essentially Fantasy Grounds doesn't know what to do with the file:// protocol. At least, this is the case in my "PlayOnLinux" installation of FG.
Having said this, you can send commands directly to the "Windows" subsystem you're using within linux. For example: /openwindow url notepad will open the Window notepad application on my installation. If I use the path to a text file, notepad is associated with the .txt file extension, then it will open that text file in notepad: /openwindow url /home/martin/test.txt
What this tells us is that we can send commands to the Windows subsystem which FG is running within by just including the command/filename after the url windowclass name in the /openwindow command. *But* for this to work, the file we call must be associated with a Windows application available within our Windows subsystem. So, a media player needs to be installed within the Windows subsystem being used and then the file extensions must be associated with that file.
You can usually test this by going to the FG Images window and clicking the "Folder" icon in the top left. This should open a Windows file explorer ("Wine Explorer" in my case). Navigate to one of your music files and try to open it - you'll probably get "There is no Windows program configured to open this type of file" until you have a "Windows" application setup to handle these.
One thing to try in Linux is to setup a Windows command file to play each music file - a bit of a faff, but it seems to work.
@skj310 - On your Linux drive, create a text file gun-shot3.cmd
Edit this file in a text editor and have one line: winebrowser /home/skj310/Music/DnD/gun-shot3.mp3
winebrowser passes the second argument to Linux and Linux will decide the best application to play the .mp3 file.
Then you can use the full path to the gun-shot3.cmd in the /openwindow url command to test - and, hopefully, this will be the same path to use within DOE: Sound - i.e. the path to the .cmd file, don't include the test /openwindow url - just what comes after that.
EDIT:
Probably a better longer term solution would be to install a lightweight web server on the Linux box and put the audio files onto this. Then you could use a HTTP URL in DOE: Sound to player the audio through your browser.