Force current directory to be the exe location for world loading

If you have a world in your Load at Start list with a relative path, say “./worlds/Aardwolf.mcl” that contains within it more relative paths, and you launch MUSHclient from the command line from a different location,

example:

MUSHclient/MUSHclient.exe

instead of

cd MUSHclient
MUSHclient.exe

An error dialog pops up saying that the (relative path) world file contains an invalid path.

If you then go to File->Open Worlds in Startup List, a different error dialog pops up saying that the (absolute path) world file contains an invalid path.

It’s weird that the errors are not the same (that one shows the relative path and one shows the absolute path), but I think it would be superior for all cases if, when loading world files, relative paths were always interpreted from the executable location and not from wherever the user happens to be in their file system.

Hmm. Well, it would be better behavior, but lets be honest, having it treat the executable location as the default is non-standard on Windows. There is a reason why almost 100% of all application use either a branch of "application data", or "documents" as a save location - because it guarantees that data that can/needs to change is always written some place that doesn't have write restrictions on it, and gives a standard location for all data, so you can, in theory, always find it.

This is even why its often suggested you don't install Mushclient, in all cases, in the normal program locations - because it never has conformed to this behavior, and doesn't apply sensible rules.

That said.. Yeah, it would be better if there was a clear, built in, rule for this, instead of the program "guessing".

That's actually false for most things. Consider how MUSHclient never fails to find its Lua DLL. I promise that it's not because it stores the DLL in application data or documents.


That's a nonsequitur. My suggestion has nothing to do with write restrictions.

I'm talking exclusively about how relative paths are written and interpreted. If you want to use absolute paths to documents, feel free, but relative paths must be both recorded and interpreted relative to a concrete reference or else they are guaranteed to break. Having that concrete reference be arbitrarily outside of MUSHclient's space is just bad.

Let's say I am using the command line (shell) prompt in Linux, and my current directory is /home/nick and in that file is an image I want to edit, such as cat.png.

I might type:



Now I expect my "current directory" to stay the same, and not change to /usr/bin/ because if it did, it wouldn't find my cat image.

Possibly relevant: https://www.gammon.com.au/forum/?id=9741

Also some discussion here: https://www.gammon.com.au/forum/?id=7776

This is not the same because gimp doesn't have its own portable internal storage directories like MUSHclient does. If you tell your command line /usr/bin/gimp cat.png, your computer gives gimp /your/current/path/cat.png. Gimp is not actually using a relative path for your file. It doesn't need to.

MUSHclient on the other hand is structured to be portable and has internal standard directories for the user's sounds, plugins, lua imports, etc. But the only way to make MUSHclient actually portable (and in my case redistributable) is to use relative paths, and using relative paths breaks on this issue.

MUSHclient reading a world file in the standard world files folder that says that sounds are in the standard sounds file folder* shouldn't break when the user runs MUSHclient/MUSHclient.exe instead of MUSHclient.exe

* - Just an example. I don't actually know which path it's complaining about because the error message doesn't say.

MUSHclient already successfully finds the world file. I'm asking for the same behavior to extend to inside the world file as well.

I don't want to resurrect that thread itself by commenting on it, so I'll put a brief response here:


Nobody does this. And I don't even mean because nobody is putting MUSHclient into Program Files anymore, though that's also part of why. The real reason that nobody does this is because the concept of a start directory is both extremely obscure and also very fragile and arbitrarily restrictive and breaks in circumstances like the one I outlined above.

What people in that scenario actually do now is just make their own independent MUSHclient folders, because they can do that now, so that they never have to fight over plugin or lua import name conflicts or desired client versions.

And if a person wants their logs to be somewhere outside of the MUSHclient folder, they have the ability to do so already without using relative paths that should definitely point inside the MUSHclient folder, because Windows has always had path variables for both user and current directories which they are free to use.