Allow customization of tags/scoreboards when exporting data pack

[Spaceginner]

(i tried searching for existing feature request, but didnt find, tho was a bit lazy)

So, with how OpenNBS currently exports datapacks, it is impossible to have multiple of datapacks at once.

I would propose, when you choose unique name, it would also change scoreboard names and tags too, for example nbs_music would become nbs_music_storrytelling_one if as a unique name I would choose storrytelling_one, this will resolve conflict between mulitple datapacks.

Also, perhaps I would also recommend changing structure of the datapack a bit too.

P.S. i really love this idea of creating music with note blocks in minecraft, perhaps my next next piece is gonna be written with limits of minecraft

[Bentroen]

Hi! Thank you for opening the issue.

So, with how OpenNBS currently exports datapacks, it is impossible to have multiple of datapacks at once.

It's funny that you suggested this! As of the latest version (3.10.0), the current data pack export system works exactly like you proposed: the song name is used as an identifier that represents your song in the world. Both the scoreboard objectives and the relevant tag use the first 10 characters of the 'Song name' field to identify each song, so it is possible to have multiple playing data packs at once :)

Additionally, you can customize the namespace and path of the song within the data pack structure, so if needed you could merge multiple songs into a single data pack in case you're working on a map that will have other files alongside the songs.

Admittedly, using the song name as the identifier isn't the best solution, as it could cause conflicts if the first 10 characters of different names match. We plan to update the system to allow for more options for identification in the future, such as re-using the same scoreboard objective (if control isn't needed per individual player) or using a random ID for tags and objectives (as we used to do in the past, but changed since it was very difficult to remove extra objectives and tags after uninstalling a data pack).

P.S. i really love this idea of creating music with note blocks in minecraft, perhaps my next next piece is gonna be written with limits of minecraft

Really glad you enjoy using the program! Hope you have fun doing your next creation. Feel free to join our Discord server to share your creations and find other note-block-loving people :)

[Spaceginner]

It's funny that you suggested this! As of the latest version (3.10.0), the current data pack export system works exactly like you proposed

Apologies, I just retested, and apparantly first time, as a unique name I chose music (the total path, for example, was storytelling:master/dialogue_a/music), and when I looked in the datapack, I saw nbs_music and it just felt and looked like there wasn't any generalization.

Admittedly, using the song name as the identifier isn't the best solution, as it could cause conflicts if the first 10 characters of different names match.

Why exactly 10 characters? (It is definetly not a minecraft limitation, at least of 1.19.3).

Admittedly, using the song name as the identifier isn't the best solution, as it could cause conflicts if the first 10 characters of different names match.

I would see using <namespace>.<unique name> or nbs.<namespace>.<unique name> (eg nbs.storrytelling.dialogue_a) or allowing in, lets say, "Advanced Options" manually set tag and scoreboard's name

We plan to update the system to allow for more options for identification in the future, such as re-using the same scoreboard objective (if control isn't needed per individual player) or using a random ID for tags and objectives

Why do you exactly need identification (So the music can hear nearby players?)? Honestly, I wasn't expecting tags and scoreboads be involved in such datapack at all.

I think I can now close issue, as it was already implemented, or maybe just rename it, so it would fit new discussion?

[Bentroen]

Why exactly 10 characters? (It is definetly not a minecraft limitation, at least of 1.19.3).

Objective names were limited to 16 characters up to 1.18 (more specifically 21w37a), and we use nbs_<identifier>_t as an objective name, which sums up to exactly 16 characters.

Why do you exactly need identification (So the music can hear nearby players?)? Honestly, I wasn't expecting tags and scoreboads be involved in such datapack at all.

The scoreboard objectives are used to keep track of each player's current seek position/"progress" while listening to the song. When I said "if control isn't needed per individual player" I meant that a single objective could be shared among all songs, and a fake player used as each song's identifier. This, however, would mean that all players would hear the same part of the song at any given time. Since it's common/expected for different players to be hearing different parts of the song (or not hearing it at all), we chose to have individual objectives per song instead of this option. The only approach that wouldn't involve at least a single objective (AFAIK) is to use /schedule to set the next tick to be played after initializing the song.

Tags wouldn't be needed as well, but we do need some sort of identification in order to offer the user some control over which players should hear the song (otherwise the data pack would be useless). Put more simply, it's a tradeoff between flexibility vs. "polluting" the world with extra data.

Perhaps this could all be customizable, but most of the time, users would only be interested in exporting a simple data pack with some basic control features out of the box. Since the data pack export feature will be rewritten as part of our move to Qt (see #4), I'll leave this issue open so we can consider different customization options when the time comes. :)