Gammon Forum : MUSHclient : General : My Vista woes

Entire forum ➜ MUSHclient ➜ General ➜ My Vista woes - any suggestions?

My Vista woes - any suggestions?

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by

Nick Gammon Australia (23,120 posts) Bio Forum Administrator

Date

Sat 25 Jul 2009 10:13 PM (UTC)

Amended on Sat 25 Jul 2009 10:24 PM (UTC) by Nick Gammon

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Coderunner USA (27 posts) Bio

Date

Reply #1 on Sat 25 Jul 2009 10:19 PM (UTC)

Message

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.

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #2 on Sat 25 Jul 2009 11:49 PM (UTC)

Amended on Sat 25 Jul 2009 11:57 PM (UTC) by Twisol

Message

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.

Quote:

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

I admit, I laughed. :D

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Top

Posted by

WillFa USA (525 posts) Bio

Date

Reply #3 on Sun 26 Jul 2009 01:07 AM (UTC)

Amended on Sun 26 Jul 2009 01:20 AM (UTC) by WillFa

Message

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?

Top

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #4 on Sun 26 Jul 2009 02:38 AM (UTC)

Message

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.

Top

Posted by

WillFa USA (525 posts) Bio

Date

Reply #5 on Sun 26 Jul 2009 03:01 AM (UTC)

Message

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.

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #6 on Sun 26 Jul 2009 04:10 AM (UTC)

Amended on Sun 26 Jul 2009 04:29 AM (UTC) by Twisol

Message

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.

Quote:

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.

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.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Top

Posted by

Fadedparadox USA (91 posts) Bio

Date

Reply #7 on Sun 26 Jul 2009 04:21 AM (UTC)

Message

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.

Top

Posted by

Lasher USA (22 posts) Bio

Date

Reply #8 on Fri 18 Sep 2009 03:17 AM (UTC)

Message

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.

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

26,552 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top