Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Peekofwar: Wiremod input for playlist URLs. #18

Open
Grocel opened this issue Sep 24, 2023 · 4 comments
Open

Peekofwar: Wiremod input for playlist URLs. #18

Grocel opened this issue Sep 24, 2023 · 4 comments
Assignees

Comments

@Grocel
Copy link
Owner

Grocel commented Sep 24, 2023

@Peekofwar on Workshop:

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:

  1. 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 Add stream url whitelisting based on installed playlists #9 to be finished first.
  2. 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.
@Grocel Grocel self-assigned this Sep 24, 2023
@Peekofwar
Copy link

Peekofwar commented Sep 25, 2023

Oh yeah, that's right. Playlists have names associated with the file... Theoretically you could have a table that uses arrays where the table is the playlist, and the arrays each contain two values, but this could potentially be a little confusing...

# Expression 2 example code
@outputs Playlist:table

Playlist = table()
Playlist:pushArray(array("Guard Down", "music/entropyzero/guard_down.mp3"))
Playlist:pushArray(array("Kill Bound", "music/entropyzero/kill_bound.mp3"))
Playlist:pushArray(array("No One Rides for Free", "music/entropyzero/no_one_rides_for_free.mp3"))
Playlist:pushArray(array("Penultimatum", "music/entropyzero/penultimatum.mp3"))
Playlist:pushArray(array("We Need Backup", "music/entropyzero/we_need_backup.mp3"))

Just a thought.

Alternatively you could just have an array that resembles how the playlist files are made with each array entry being a name entry followed by an address...

# Expression 2 example code      - Note: I'm not sure if "pushString" is a valid array method.
@outputs Playlist_2:array

Playlist_2 = array()
Playlist_2:pushString("Guard Down")
Playlist_2:pushString("music/entropyzero/guard_down.mp3")
Playlist_2:pushString("Kill Bound")
Playlist_2:pushString("music/entropyzero/kill_bound.mp3")
Playlist_2:pushString("No One Rides for Free")
Playlist_2:pushString("music/entropyzero/no_one_rides_for_free.mp3")
Playlist_2:pushString("Penultimatum")
Playlist_2:pushString("music/entropyzero/penultimatum.mp3")
Playlist_2:pushString("We Need Backup")
Playlist_2:pushString("music/entropyzero/we_need_backup.mp3")

Personally, I'd prefer the table of arrays.

@Grocel
Copy link
Owner Author

Grocel commented Sep 25, 2023

I'm not sure. The stuff needs to be kinda idiot proof and both seem not to be that well understandable to users. I like the first option more, but it is also less transparent. To be idiot proof it would need to support other formats as well, as like:

  • URLs only as a string array
  • URLs with names like your first option.
  • Mixed

This seems kinda messy to implement. Wire inputs also don't have a way to tell users about the wrong format, so what should it do when the input is bad? Just ignore it? What happens on empty URLs and/or empty names? On case of the 2nd option, what would happen if the one name is skipped? How would you determinate if a line was a name or a path/URL without having to guess it?

There is one idea I could work with: I will change the playlist output to have your first option as it's format, remove the name/URL separation on the playlist output. The new input will only support that format as well. So it works as output like input and users can see how it works. Invalid types or data would be skipped/ignored. Backwards compatibility for old dupes is not a thing I care about, it dies as soon as it gets in the way of development.

@Peekofwar
Copy link

Peekofwar commented Sep 25, 2023

Some additional thoughts:

You could theoretically have two different playlist input options where the first is a Table with arrays, and theoretically you could check if either the second string is empty or doesn't exist and assume the first in the array is the address...

Playlist = table()
Playlist:pushArray(array("music/entropyzero/guard_down.mp3")) # <-- Second string doesn't exist; assume first is the address and default track name, or alternatively treat it as a 404 "file not found"
Playlist:pushArray(array("Kill Bound", "")) # <-- 404 "file not found"
Playlist:pushArray(array("", "music/entropyzero/no_one_rides_for_free.mp3")) # <-- Either shows an empty track name or defaults to the file name or path

... and secondly, you could have an alternate array input that only accepts file addresses and doesn't support providing track names. Track names in this case could just default to the filename or file path.

Playlist_2 = array()
Playlist_2:pushString("music/entropyzero/guard_down.mp3")
Playlist_2:pushString("music/entropyzero/kill_bound.mp3")
Playlist_2:pushString("Penultimatum") ## <-- This will appear as a 404 "file not found" error or be skipped over.

Having two different input options could theoretically be confusing to users though... And what if the user hooks up both? In the case that a user connects valid input to both, perhaps the one that supports track names takes priority over the basic playlist array input.

How would you determinate if a line was a name or a path/URL without having to guess it?

I guess in most cases file addresses typically have a file extension at the end. However, it is possible for track names to contain punctuation which could potentially get detected as a file extension. If I'm not mistaken, Stream Radio also supports streams, which I'm not familiar with the address format of.

Wire inputs also don't have a way to tell users about the wrong format, so what should it do when the input is bad? Just ignore it?

Theoretically the Stream Radio could show an error message that indicates the Wire input is malformed.

@Grocel
Copy link
Owner Author

Grocel commented Sep 25, 2023

I would prefer to not add complex bloat. It will be one input and one output for the playlist. I am not going to add unreliable/inaccurate name/address string detection. Maybe you see now, why it was not added yet.

Coding a separate error screen for this is pain, so I would rather skip this and just make it skip/ignore malformed parts instead. Arrays with length <= 1 will assume URL at index [1], otherwise it is [1] for name and [2] for URL. (subject to change)
Empty URLs will be skipped, empty names will be replaced by a default.
I will write up proper docs to make it more accessible to new users.

Btw, address format is HTTP URLs or local file paths as told so in the stream URL description in the toolgun menu.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants