3.50 Path Bug(?)

First of all, does version 3.50 say "3.49" in the about box, or did I do something really stupid? And secondly, the paths are not working :( I tried to enter "\Program files\etc\whatever" as the path to the include file, and MUclient could not load it and gave me errors.

in a dos box has no problem displaying the contents of the world file. After that, I added an entity "path" to the world file to point to "C:\Program Files\Mushclient" and it worked, but on saving MUclient substituted the entity in the paths. Also, does it save the following directives as it found them?
auto_log_file_name
script_editor
script_filename

Well, maybe not script_editor, but one would like logging to be correct... The problem now is to get MUclient to load files with relative paths, can I do that?

OK, luckily MUclient will work if the file is in the worlds\ directory and it is specified as <include name="include.xml" />. I still can't get relative paths to work for the logs though... If I specify the filename only for logging, with no path, it defaults to the shortcut's path, and doesn't mess with the saved filename, which I guess could work... The script file cannot be found, so I guess that MUclient looks for it in the shortcut directory, but it does not change the saved pathname, so I think saving is OK, and the only thing left to do is fix relative paths.

OK, first things first.

As requested, with standard include files (not plugins) it will save exactly the name you used.

Your problem with "\Program Files\MUSHclient\worlds\Poromenos.MCL" I reproduced, but it was because I ran MUSHclient from a different disk (eg. G:) from where the file was (eg. D:) and thus the path did indeed not exist.

You need to change your MUSHclient shortcut to at least start in the disk (and preferably directory) where you want your relative paths to be from.

As for relative paths, MUSHclient had two tests to inhibit adding in the MUSHclient directory to your include file name:

1. It did not have a ":" in it (eg. c:)
   
2. It did not start with "\" (ie. was not an absolute path).

I have added a third test in version 3.51:

• It did not start with "..\" (ie. is not a relative path - upwards).
  
• It did not start with ".\" (ie. is not a relative path - downwards).

• auto_log_file_name should be unchanged
  
• script_editor should be unchanged
  
• script_filename should be unchanged

Yes, that's true, thanks for the correction. I didn't think to check the shortcut because i thought it uses the path it's installed in. With what you said, it should work fine as it is.