Using JCS instead of scripts for custom boss music

[RSGDB]

Basically making it so that instead of having to choose between Boss1/Boss2 you could browse for a music file similarly to how you pick level music.

Would that be possible? Part of me feels it would already be implemented if it was, but I figured I'd shoot my shot just in case.
Otherwise maybe make it a MLLE-exclusive feature if it can't be done in JCS? It would still create an automatic script similarly to palette/tileset changes but it would still be nice as a QoL feature.

[Violet CLM]

I think the problem is that it's so simple to write

void onFunction0(jjPLAYER@ player) {
player.activateBoss();
jjMusicLoad("mycooltrack.xm", temporary:true);
}

that there's no point in making it an event parameter.

[RSGDB]

Sure, but an event parameter could (potentially) do away with the need for an AS script, which in an otherwise completely vanilla level would prevent stuff like saving the game or adding secret levels.

Not to mention the aforementioned code snippet does not play nice when the desired track is the same as the level track. Right now in order to make it so the level keeps its regular music during the boss you have to use text IDs and slightly more coding.

Again I'm aware that none of this is particularly difficult once you know what you're supposed to do, but it would be nice to have something a little more convenient, event parameter or otherwise, especially for beginners.

[Seren]

I can't help but feel that this is a moderately niche use case in the current ecosystem since, for it to be meaningful, it requires that the level be unscripted, have a boss (necessarily vanilla due to the previous requirement), and want that boss to have non-vanilla music. Now we're not strictly opposed to adding fairly niche features that save some scripting, but:

Event parameters are strictly numeric. Whole numbers are the only format JCS supports. MLLE adds some QoL visual improvements by adding checkboxes, selection from lists, etc., but it's all integers behind the scenes. Furthermore, the total of all parameters for one event is limited to 20 bits of space by the J2L file format, so even if you hypothetically wanted to fill one with text, you'd be able to fit up to 2 ASCII characters before running out of room. There is no way to store a filename in event parameters and definitely not using JCS.

There is precedent for JJ2+ storing text information in J2L files for events to reference and it's level exits. Multiple filenames for next levels can be stored in level text strings to properly support levels having exits leading to different levels. This was added before scripting and would likely not make the cut nowadays. I suspect many JCS veterans don't even remember how to use this feature and would instinctively default to the more intuitive jjNxt these days. I think this already defeats the whole point of the feature being beginner-friendly since you essentially can't avoid consulting the readme to use it. But it gets worse!

Unlike next levels, music files have the inconvenient trait that when playing online, they must be transferred from the server to the clients when the level loads or when they join. This might sound like a non-issue because if your level has a boss, it's probably designed for single player, but we aim to support online cooperative mode to the best of our capacity. Many single player levels are playable in cooperative mode as they are and we'd prefer to avoid adding a general use built-in feature that straight up breaks this compatibility. In AngelScript we provide easy means of sending files like this via "#pragma require" and "#pragma offer". Now if we allowed music filenames to be specified in text strings, we would need some mechanism to indicate in advance that they are indeed filenames meant to be sent to clients, e.g. by making the text string start with something unmistakable for anything else, such as "!file". Level designers would have to know and adhere to this mechanism and JJ2+ would need to start scanning level text strings for potential files to send to clients. I feel like the complexity of this system both on the part of implementation and usage greatly outweighs the benefits. At that point, if you're an inexperienced level designer, just copy the script.

Not to mention the aforementioned code snippet does not play nice when the desired track is the same as the level track. Right now in order to make it so the level keeps its regular music during the boss you have to use text IDs and slightly more coding.

It's actually slightly less coding - just don't include the whole "jjMusicLoad" line since activateBoss does not change the music. That said, this is a potentially separate use case that does not require specifying a filename or involve file exchange and thereby does not run into most of the aforementioned issues, so I think JJ2+ could feasibly add a parameter to the Activate Boss event that makes it not change the music, if there's demand.

[RSGDB]

Thank you for the detailed response.
For the record I am very much in the niche you described, but your explanation for why this feature isn't really viable does make a lot of sense, so I don't see a point in pressing the issue further,


It's actually slightly less coding - just don't include the whole "jjMusicLoad" line since activateBoss does not change the music. That said, this is a potentially separate use case that does not require specifying a filename or involve file exchange and thereby does not run into most of the aforementioned issues, so I think JJ2+ could feasibly add a parameter to the Activate Boss event that makes it not change the music, if there's demand.

I wouldn't mind such a feature, though admittedly it would be niche even for me as at the moment I only have one level that would benefit from it.
Thanks again.

[Violet CLM]

Sure, but an event parameter could (potentially) do away with the need for an AS script, which in an otherwise completely vanilla level would prevent stuff like saving the game or adding secret levels.
I will acknowledge that this is an issue, though. We'll fix it someday. It's just hard work.