The owner of a stream radio can change the volume with the C menu while other people cannot change it.
Other players should be able to change the volume for the stream radio in the C menu because some models do not have screens attached to them, and the owner of the radio can disable input which doesn't allow people to change the volume.
Some people may not like the music that is being played, and cannot lower the volume or stop the song from playing and they want to hear other radios, which the above makes it so they are unable to change the volume.
I suggest making it so people can change the volume via the C menu because the stream radio already has a menu for it.
(Image below shows a stream radio without a screen and the C menu for that radio)
In one of the latest updates of GMod (IGModAudioChannel:GetTagsID3) was added along with other functions. This allows to get meta information such as title or artists of a song. I will see what I can do with it.
PermaProps uses non-standard methods for storing and restorting entities on a map between sessions. At the moment this addon only supports the official duplication API for storing entity data so it works with every duplication/persisting addon that uses the duplication API. PermaProps is, because of its non-standard implementation, not supported yet.
When connecting to a Stream Radio entity with a "virtual" wirelink1, the IsConnectedWirelink function does not recognize that wirelink, because it only checks if the "physical" input has been wired to something.
When trying to set / trigger an input change of (for example) the Stream URL (does apply to any other input as well), it will not actually change the internal value due to the hard-coded check if that specific input has been wired.
1. Inconsistency: the majority of other wireable entities do not ignore "virtual" wirelinks and their input changes, even if the corresponding "phyiscal" wire input has not been actually wired.
2. Confusion: it is not visible or known to someone working with the entity, that inputs will be "scrapped" if the corresponding wire input is not "physically" hooked up to something.
Footnotes
A "virtual" wirelink is a wirelink that is created / assigned purely from within a script execution background (e.g. Expression 2, Starfall, ...)
For example (Expression 2): Wirelink = entity():isWeldedTo():wirelink() - returns the wirelink of that entity the chip is welded to, without actually ever wiring the input of that entity โฉ
Something that could be useful for VR users would be on-screen buttons to toggle track loop and playlist looping. This could even be one button with more than one mode using icons to indicate which mode it's in.
The idea is to create a special directory somewhere in the server/game directory that Stream Radio is allowed to stream audio from.
Usually I use Discord file links to stream some of the files I play in-game, however Discord has since changed their file link system to remove permanent links. I could theoretically make an unlisted addon that puts music files in-game, but something that would be nice is if I could just upload audio files to a special directory on the GMod server that Stream Radio is allowed to stream from. Only the server host would be allowed to use this feature since it requires access to the file system.
It's hard to find file services these days that allow you to use direct file links.
Of course, this raises the question of how do we denote that a URL is for a server file...? Maybe it could just start with SERVER:// or something like that...
Would be cool if there was a Wire playlist URL array input to allow us to input an entire playlist into a radio entity through Wiremod.
In the most recent updates I changed the structure and handing of playlist data in the radio entity to separate it from the GUI elements, so non-display radios can use and store and playlist data too. This is needed to implement the playlist input.
There are some issues with this I would have to solve first:
All online URLs inputted via the playlist input must be filtered on disabled custom URLs to prevent abuse/bypass. I am not sure how to implement this in a way the user would understand this blocking behavior yet. This might need issue #9 to be finished first.
Each playlist entry also needs a name. Could be solved with Wire input #1, Wire input #2, ..., Wire input #N, but this looks kinda lazy and maybe confusing to the user too.
Im not sure how to replicate this issue unfortunately. However i have the stack trace.
Players are getting this error pretty rarely but i thought, might as well report it.
Heck, I just discovered that there's an audio cache... I have some cached DAT files from 2018, and interestingly, Audacity allows me to just drag the DAT files right into it to view them.
Yes, indeed. Files are downloaded in the background via HTTP() to make the loadup faster the next time the radio plays an online file. It reduces traffic and is a good Anti-DDoS/Anti-Spam too.
It only works with files with a length (e.g. not radio streams). Only files less then 1.5h long are cached. The cache is capped at 16 GB total size and 1024 files. Each file is limited to 256 MB. Small files (HTTP requests) are even cached in memory (max 16x16 MB) as an additional de-duplication of requests. Small files (<64 KB) that could just be an HTML error page or something are never cached. Caching is only attempted when the radio does not error on playback, which means only valid sound content ends up there.
You can clear the file cache any time by deleting the cache folder or by using "cl_streamradio_cacheclear" ingame. The dat files can be any sound file and are saved as dat because of engine restrictions.
I noticed that the radio causes a frame drop of about between 200 to 500 ms on my computer when it is spawned.
It his is caused by the GUI system initializing its caches and elements. I will see if I can fix that by using Lua coroutines, but I can not do any promises.
When the convar sv_streamradio_allow_customurls set to 0 the radio does not accept any URL that has been manually inputted (wiremod, toolgun, dupe) into the radio. This is for security reasons.
Even when the URL is actually existing inside a playlist it would not play if it was not picked from the playlist view in the GUI. The goal of this change is that the URL no longer blocked in this case. So the playlist files are the server's whitelist so to speak.
It is however unclear if I will be able to implement this in the near feature.
I ran into a perculiar bug today when I went to touch Stream Radio... When I first open an audio file, the UI loads in in a buggy state. At first nothing appears wrong when you look at the interface and tooltips and button rollover effects work normally and display correct tooltips, however when you attempt to actually interract with them, it seems as though the buttons are not where they should be.
At first load of the stream player UI, the button order is as follows: Pause, Stop, Decrease Volume, Increase Volume, Timeline, Back.
However, if you exit the player and then open the file again, the interface loads with this layout: Pause, Stop, Previous Track, Next Track, Decrease Volume, Increase Volume, Loop Mode,, Timeline, Back. This is the order in which interactions trigger even if the previous button order is displayed.
Stream.Radio.Ui.Bug-1.mp4
For additional context: This bug was encountered whilst playing on a dedicated server that had just been restarted (also meaning all addons were freshly updated).