So I found out you can do a thing. I don't think it's intended, but
technically it could be used as a feature. I'm not endorsing this technique, but I think it's best to go public about this discovery, and let the community and namida decide what, if any, response should be made to prevent it, rather than relying on obscurity to make sure people don't do it. Of course, if you know relative file paths, it's pretty trivial, but on the other hand you might simply not have thought to try this, because, well,
you probably shouldn't actually do this.
Maybe this should have gone in the Bugs and Suggestions subforum instead, but I wasn't comfortable calling it a bug and also wasn't comfortable calling it a suggestion either. I guess I'm intending a discussion here? Still, mods: I won't be upset if you decide it should be moved there.
This is almost certainly bad practice and you probably shouldn't do it.A recent post by WillLem led me to believe he'd encountered an issue with a
music pack masking the default music and got me thinking about the way music filenames are handled and how name collisions can occur because of it. I wanted to think about ways the engine could help prevent these collisions (beyond just hoping pack authors adopt their own unique subfolders or naming conventions), and this made me think about whether we could allow level packs to store their music in their own fully self-contained music folders inside the pack, instead of part of a separate directory. I wrote up a huge post about it (along with some other methods of alleviating some of the issues) and then second-guessed if it was worth posting, but I then thought about this:
What if it's
already possible for level packs to have their own music folders stored with the pack and not in the music folder?
It turns out, it is! Suppose your pack is located in levels\My_Pack and you want to put the music in My_Pack\Music (as opposed to a My_Pack subfolder in the main music folder). We're already allowed to have our music in a subfolder of the main Music folder, and this is the feature we can abuse to accomplish this nonstandard music location.
The music selection box lets us type the filename in. This is useful because otherwise subfolders wouldn't work, and subfolders are useful since they mean we can store the music for a particular pack or author together to try to reduce the chance of name collisions. It would also be a pain to find the file you want if your music folder is filled with the music from several level packs, so typing it in lets us find it faster. Plus, even if we weren't allowed to type it in, we could just fill in the relevant information in a text editor. There is also nothing that stops us from nesting these subdirectories, which is still useful for something like Music\Author_Name\Pack_Name\[songs go here]. If we are in a command prompt and a certain subdirectory of some arbitrary directory, and we want out of that subdirectory, all we need to do is type
cd ..
Now we have everything we need to put the music wherever we want: to put the music for the pack in levels\My_Pack\Music, all we need to do is type the following into the music selection box:
..\levels\My_Pack\Music\[song]
I'm not sure if this
should be allowed, but the engine won't stop you.
It'd be pretty stupid to step outside the NeoLemmix base directory because from that point on who knows what the directory and filesystem might possibly look like, but it is allowed by the engine. Absolute paths, however, are not (which is a sensible design choice since there's absolutely no reason to use an absolute path since it likely won't work on anyone but the original creator's machine, unless by coincidence someone else uses the exact same folder structure).
I'd say that \..\ in the relative path probably shouldn't be allowed, but perhaps packs should be allowed their own internal music folder since this does have some utility for avoiding name collisions by keeping the pack entirely self-contained - though if we decide to go that route, we'd definitely want to discuss the exact rules for it, since it would probably be a useful feature to allow a structure that allows multiple packs by the same author to share music.