My Vista woes - any suggestions?

I was trying to set up MUSHclient to run under Vista for my daughter, so she could try playing a MUD or two.

Now, it *did* install and run, so I suppose you could say it worked as advertised.

But, when I tried to do fancier things, like download and install plugins, that was when Vista and I got into a bit of a brawl.

For a start, I can't download a plugin and save into the worlds -> plugins folder as that is write-protected (apparently) unless you are doing an installation. So, I saved the plugins into My Documents. Then the plugin wouldn't work because there was not "state" directory under My Documents. So, that had to be created. Ah, if only that was easy. In older versions of Windows there was a File menu, and you selected New Folder. Vista seems to have made things "easier" by doing away with old-fashioned things like menus, so it took about ten minutes to even create a subdirectory.

Then I needed to save the world file, and again, it couldn't be saved in the usual place - the "worlds" folder under where MUSHclient was installed.

"This is @$#%!&" - I thought to myself. If the developer can't get it to work easily, how can I expect anyone else to?

Obviously, a restructure is needed. Probably this could largely be achieved in the installer, by making it put things in different places.

Perhaps all you power-Vista users can suggest an appropriate setup?

I suspect the installation needs to be broken into two main parts - those that need to be written to (eg. world files, plugin state files), and those that change rarely or never.

So, how about this ...

Things that don't change

These would go into \Program Files\MUSHclient:

• MUSHclient.exe
• lua5.1.dll
• The help file and contents
• The readme.txt file and other stuff that is usually there

The following subdirectories would be created under \Program Files\MUSHclient (as usual):

• lua
• docs
• names
• locale
• fonts

Things that change

The remaining directories would be moved to \Users\<yourname>\Documents\MUSHclient:

• worlds (which includes plugins and plugins\state)
• logs
• scripts
• sounds

Also the directory \Users\<yourname>\Documents\MUSHclient would be made the working directory for the shortcut to MUSHclient. This means that the preferences database, and the toolbar .ini file would go into that directory too (since this is writeable).

Some scripts might not work if they assume the old directory structure, but many directories are available from GetInfo, so if a script uses the appropriate GetInfo item, they should find their directory properly.

eg.

• GetInfo (57) - world files directory
• GetInfo (58) - log files directory
• GetInfo (59) - script files directory
• GetInfo (68) - startup directory
• GetInfo (74) - sound files directory
• GetInfo (82) - preferences database location

Any helpful comments, or suggestions about things I have overlooked? Thanks.

Hello,
This sounds like an awesome idea. As it is, to write worlds to the worlds dir, logs to the logs dir, etc, You have to give users full control over the main MUSHclient directory, which probably isn't the best way to make it work.
I hope this gets implemented soon.

On creating subdirectories, you just right-click in Explorer and select New Folder. To make the File/Edit/View/etc menus appear, hit Alt.

As for write-protection, yes, Windows is a bit stupid about that and Program Files. I think I got lucky because I installed to a thumb drive, so there's none of that horrid business. (You can try removing the read-only attribute by right-clicking the folder and de-selecting the read-only box, but Windows seems to like to set it automatically)

On moving the commonly-modified folders out, that seems like a fine idea, as long as the user can put them where they want. That directory line you showed, for example, won't work on my thumb drive. Nor will it work on pre-Vista Windows I suspect, because those directories were named differently ("My Documents", etc). If there's a way to get the current user's documents directory through the Win32 API, that's probably one way to solve the problem, though like I said, users still need to be able to choose.



I admit, I laughed. :D

Technically, if you were going for Windows Logo certification; the State directory should be under C:\Users\<username>\AppData\Local, or under XP C:\Documents and Settings\<username>\Local Settings\Application Data
(CSIDL_LOCAL_APPDATA)

The Prefs db should be under C:\ProgramData under Vista and C:\Documents and Settings\All Users\Application Data for XP.
(CSIDL_COMMON_APPDATA)


The API to look up the folder path is documented at http://msdn.microsoft.com/en-us/library/bb762180(VS.85).aspx
with the CSIDLs documented at http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx

So, basically, The API will take care of the specific paths on the OS for you. WINE should emulate this API call as well for 'nix compatibility.

Also, the only thing I've ever seen in the scripts directory are the example scripts. Do these really need to move? Most plugin authors I've seen only deal with the World and Plugin directories. Since the scripts directory isn't even in package.path or package.cpath, can that scripts directory just be put under \docs?

I have never used the builtin world or plugin directories.

Simple reason: I feel they are cluttered with examples I will never use, and finding my own scripts in there would be really annoying. Second (and perhaps even more important reason) the stuff is in way too awkward a place in my opinion. Program Files, under world and then beneath plugins. It had always made more sense for me to have the world and plugin directories side by side.

Either way, I'm fully in favor of some changes to make the file structure make more sense. :)

I just hope that things won't end up in a linux style placement - when I delete MUSHclient and stuff gets left behind, I really don't want to go search through different hidden directories to find out where they were put. Needing to type "Documents & Settings\User\" and then going through Application Data and Local Settings is annoying enough already, since I've never been able to figure out why apps pick one over the other.

Application Data is for the Global install. (i.e. prefs db, plugins)
Local Settings is for the Per User install. (i.e. state dir)
My Documents is for user data (i.e. MCL files)


Windows Installer will clean up the App data and local settings directories, but not user data.

I doubt that you want to put plugins in where the Windows Installer will "clean up", unless I missed something here. It seems like the prefs DB and plugins would go in the user data group.

EDIT: Unless you mean when it's uninstalled, in which case that was very un-obvious. I still think plugins would go into the user data, but the prefs DB is fine where you suggested.




I have to agree with Worstje here, it is very cluttered in there. I don't mind the subdirectory-of-worlds bit so much, but it does make sense to move it out.

Odd. I got it installed and running fine for my fiancee, since zMUD (her client of choice before this point) flatly refused to work with Vista. She hasn't had any problems so far.

Even more odd, I run Zmud and Mush just fine on Vista Ultimate 64-bit.

In terms of compatibility with older programs I've had much more trouble with 64 bit ultimate than other versions of Vista -- but those two run fine.