[SUGGESTION] Organizing the music folder

[Ryemanni]

Something has to be done about the music folder. It will become a huge cluster of unorganized music just by downloading a few levelpacks.
I had a short break after downloading the new format version and starting out fresh, but now the musics are already starting to pile up again.

I would suggest to organize the music into folders by levelpack, but this will cause multiple of the same files if people reuse the same music in different packs.
Other solution would be to include the music in it's own folder within each pack, but the same reuse-problem would still happen.

Any sort of other suggestions and discussion is encouraged. I'd also like to hear more opinions on this matter. Is this actually a problem or am I just too obsessed about organization.

[Nepster]

Here is my take on the problem: Yes, the music folder will be (or even is now) a bunch of unrelated files, that isn't sorted properly. But most users will never ever look into this folder and just include whatever music files they get with the pack downloads (at least I hope so). So a bit of chaos there doesn't really matter.
Actually it's the same as with the pieces in the "special" folder: As long as there are no name clashes (and for this reason we encourage to put the designer's name in front of the piece/music), it doesn't really matter how unorganized it is.

Basically the only way to keep all folder neat and sorted is the way Lix goes: Everything has to be approved by Simon and then added to the default release. But as soon as one opens the possibility for users to include stuff without Nessy or me checking it first, there will be chaos at some point. Of course one can try to minimize it, as we did with level packs and full styles, but music is somewhat less important: No level breaks, if the (correct) music file is missing.

So before changing anything, I would like to have one question answered: What are the big advantages of having a nicely ordered music storage, that pays off the non-trivial amount of coding work needed for any such solution?

[IchoTolot]

I am with Nepster here. I think the coding work is way bigger than the advantages.

Sure, a nicely ordered folder would be neat, but even the great cluster is optional and somewhat manageable. I for myself named my pack music "Reunion_XX" for example to be better recognisable.

Maybe at some point in the future the player gains the ability to look into subfolders of the music folder for music, but I wouldn't call this a big nessasity and rather a nice-to-have feature. There are more important things for now.

[nin10doadict]

I am also with Nepster on this one. It would be nice if there were some way to organize it well, but people are going to have different naming conventions here and generally you're not digging into this folder often. Probably best to just let it be, though this does give me the idea to improve my own personal naming convention (perhaps stick nin10_ at the start of each filename that I use?)

[Ryemanni]

Valid points. Organizing music is not a priority, especially since it doesn't have any technical benefits.

I for myself named my pack music "Reunion_XX" for example to be better recognisable.

That's a pretty good idea, I could try that. It would at the very least reduce some of the stress caused by the music folder.

[kieranmillar]

If the name of the music you type into the level when making it accepted sub-folders you could at least have packs put their music in a designated subfolder, might help a bit.

Music from old packs, or packs from authors that don't care about organising it in this way would still be sprawled all over the base directory, but it might help going forward.

[Nepster]

If the name of the music you type into the level when making it accepted sub-folders you could at least have packs put their music in a designated subfolder, might help a bit.

To be honest, the way it is currently coded, this has a high change to already work. However it is absolutely not intended, so no guarantee that it works reliably, no guarantee that it will still work in future versions and don't blame me if you run into some unexpected problems if you try this.

[namida]

It's intended to allow for subfolders. Unless you're making an active decision to discontinue supporting that, it's a bug if subfolders don't work.

[Nepster]

Interesting! I wasn't aware of that. One more question, though: If I have a music file like "...\music\myfolder\dadada.ogg", does the NeoLemmix player find this if a level file specifies "dadada" as the music, or only if it specifies "myfolder\dadada"?

[namida]

The latter. Though probably not too hard to implement the former - just a recursive function using FindFirst / FindNext / FindClose - aside from the question of "what to do if more than one file (in different folder) with the same name exists?".

[namida]

After some testing, I can confirm NeoLemmix (current stable version) definitely does support this.

However, the associated tools (or at least Flexi, in relation to music.nxmi EDIT: can confirm the level editor does this too) do not, and will strip the path from any music specified (but preserve the actual filename correctly).

[namida]

^ Latest update neither removes support for this from the player, nor fixes the bug where the editor (haven't tested the pack toolkit yet) strip the path segment from music names. (Latter is obviously preferable.)

Suggestion: Actually investigating the subdirectory tree (which could go as far as nested subdirectories, at least in theory) and showing each valid music file in the dropdown list in the editor / etc is probably a lot of work. Understandable that this wouldn't be there. However, it should be very simple to at least preserve such names. This is already partially supported - if you load a level file with a music path like, let's say, "Lemmings_Plus_V/abstract1", it shows the full correct name in the music box in level properties. It just removes the "Lemmings_Plus_V/" part when actually saving the level. All that's needed is to remove the code that does that. Might have potential to cause issues with invalid names, but this is a risk the user takes when entering their own value instead of selecting from dropdown, and at any rate they should be testing this and making sure everything works correctly before releasing their pack.