This walkthrough shows how to get MUSHclient going under Windows 7 (similar remarks probably apply to Vista too).
The normal installer puts writable files (like world file and log file directories) into a place it shouldn't, namely the Program Files directory, which is now protected. Until the installer is updated you can follow this post to get MUSHclient going anyway.
I put the download into my Users folder, but wherever it got downloaded, you should see it like this:
Double-click the "MUSHclient_4.43" folder to open it, you will see a single directory, like this:
Copy that folder somewhere - I put it on my desktop, like this:
Double-click to open and you will see the MUSHclient program, support folders, and other useful files:
(Optional)
You can make a shortcut in your Start menu, by simply dragging the MUSHclient icon (the yellow icon that looks like Aladdin's lamp) directly onto your Start menu button (bottom left-hand corner of the Windows window). Then when you click on the start menu, there it is:
Now you can start MUSHclient, either from the Start menu if you made a shortcut as I just described, or by double-clicking the MUSHclient icon in the folder you just copied.
It should now start up, and amongst other things, display a message about help not being available. This is because the help file was designed for earlier versions of Windows:
(Optional)
You can install the WinHelp.exe program by following the link shown, and choose to get it for Windows 7:
After a bit of mucking around validating your copy of Windows, you can download WinHelp:
Once that is downloaded, install it, and then the help function will work normally.
All working!
It should now work, like this:
You may find if you go to save a world file it will try to put it into My Documents. This is OK, but you can navigate back to the "worlds" subfolders of the MUSHclient folder. That might be more convenient.
If you've made the shortcut in your start menu, right click on it, and change the Start In directory to C:\Users\<My acct>\Documents
Once you've started Mushclient, I highly recommend pressing CTRL+ALT+G.
On the Worlds tab, Click the Default Worlds Directory button and change the path to something in C:\Users\<My Account>\Documents.
On the Logging tab, Click the Default Log File Directory button and change the path to something in C:\Users\<My Account>\Documents.
On the Plugins tab, Click the Plugins Directory button and change the path to something in C:\Users\<My Account>\Documents. I'd recommend copying the default plugins folder (...\MushClient\Worlds\Plugins) to your Documents directory as well.
Windows 7 will hide the files from you anytime an app tries to write to "C:\Program Files\" or "C:\Documents and Settings" and put them under C:\Users\<My Acct>\AppData\Local\VirtualStore\...
On the Worlds tab, Click the Default Worlds Directory button and change the path to something in C:\Users\<My Account>\Documents.
On the Logging tab, Click the Default Log File Directory button and change the path to something in C:\Users\<My Account>\Documents.
On the Plugins tab, Click the Plugins Directory button and change the path to something in C:\Users\<My Account>\Documents. I'd recommend copying the default plugins folder (...\MushClient\Worlds\Plugins) to your Documents directory as well.
This screen shot illustrates the idea for the world files:
I made a "MUSHclient" folder inside the Documents folder, and inside that I created "logs", "worlds", and "plugins". Then it was a case of using the Global Preferences to make those the default directories for logging, worlds, and plugins (you need to go to three different tabs to do that).
BTW, very confusingly, Windows shows the Documents folder as "My Documents" in the folder picker window, but shows it as "Documents" when you make your choice. Why do they do that? I mean, why isn't "Downloads" shown as "My Downloads"?
BTW, very confusingly, Windows shows the Documents folder as "My Documents" in the folder picker window, but shows it as "Documents" when you make your choice. Why do they do that? I mean, why isn't "Downloads" shown as "My Downloads"?
Inside explorer, if you right click on the "My Documents" folder in explorer (the Documents folder is hidden) you'll notice you have an extra tab, "Location" that refers back to the documents directory. There's a shell special extension set up for these folders. (Incidentally, XP needed the attributes on the directory to be Read-only, hidden, and system for shell extensions to work... this doesn't seem to be the case anymore)
If you open up a cmd prompt, and do a "dir /a" in your profile directory. You'll see that Win 7 makes a bunch of junctions for the old XP paths. If you check "cacls Documents" and 'cacls "My Documents"' you'll see that the permissions on My Documents are rather funky and that everyone has Deny read access. This is just more hokey stuff MS did to move the folder to one without an annoying space in the name, and not break every old app.
And "My Downloads" doesn't exist because it was never there in XP, so there's no need to preserve backwards compatibility.
Perhaps. All I am saying is, it is confusing. If I use the file picker and choose a directory called, say, "uploads", I don't expect to find I have put my documents in "downloads".
This is similar to the comments in another thread, where you could put log files in C:\Program Files\MUSHclient\logs and then open that directory and not find them.
I suggest that in this case, the file picker should refuse to let you choose, for the purposes of making an output file, one where it has no intention of putting it.
My basic trust in getting what I think I am getting is being eroded.
You think you're confused? At least you have a better than basic programming knowledge. Most of us know simply to 'point and click'. :)
Anyway, before I rant, I have been thinking of upgrading XP to Win7 so I thank you for taking the time to show us how to at least get MushClient working. I'm understanding the point about no longer being able to write to files in Program Files and even though that will be a big adjustment for me I guess I can live with it.
I am a little confused and have a question about what you did higher up in the process. After you downloaded the file and double-clicked it (Win7 has a built in zip/unzip now? does it do tar too?) why did you put the MushClient folder on your desktop and decide to run it from there? I guess it works and it's not really wrong but shouldn't it be in Program Files where it usually is? Are you saying not to put it there even though you've explained how to change the writable files required? Could you even leave it where you downloaded it? I'm asking because I prefer a clean desktop and would rather not clutter it with something I'm never going to access like an entire folder.
And I agree with you on the "Downloads" vs. "My Downloads" point. Call it one thing, keep it simple.
Nick Gammon said: I suggest that in this case, the file picker should refuse to let you choose, for the purposes of making an output file, one where it has no intention of putting it.
Definately makes sense. Hey, maybe Windows 943 can be your idea!
I am a little confused and have a question about what you did higher up in the process. After you downloaded the file and double-clicked it (Win7 has a built in zip/unzip now? does it do tar too?) why did you put the MushClient folder on your desktop and decide to run it from there? I guess it works and it's not really wrong but shouldn't it be in Program Files where it usually is?
It has a built-in unzipper (I think XP does too). So, you can just open a .zip file without installing WinZip. However a quick test shows that .tgz and .tar files are not recognised (however WinZip recognizes those).
As for the location, you really have a couple of options:
Keep everything together in the traditional way. In that case, you need to put the MUSHclient folder somewhere writable, which excludes Program Files. I used the Desktop, but you could also put it somewhere in My Documents (or Documents as it seems to be called now).
Split things up into non-writable and writable parts. In that case, you could put the main install into Program Files (I think the standard installer would do that anyway), and then move the "worlds", "logs", and "plugins" folders into your Documents folder.
If you put everything into one place, eg. the Desktop, or your Documents folder, then you don't really need to change the "Start In" location of MUSHclient (as Willfa suggested) because that is writable anyway. The Start In location needs to be writable because it writes the global preferences file there (and also saves your world positions into a file called MUSHclient.ini).
The "Compressed Folders" shell extension first appeared in Win2k. It handles zips and cabs.
7-zip is free, open source software that handles 7 types of compression.
Supported formats:
* Packing / unpacking: 7z, ZIP, GZIP, BZIP2 and TAR
* Unpacking only: ARJ, CAB, CHM, CPIO, DEB, DMG, HFS, ISO, LZH, LZMA, MSI, NSIS, RAR, RPM, UDF, WIM, XAR and Z.
The first thing I installed on my shiny new Windows 7 was MUSHclient. I have never used C:\Program Files\MUSHclient for storing my data, however, so I completely circumvented the whole UAC thing without even realizing it.
All I really needed was to change the target working directory for my shortcut to the directory on my flash drive where I keep all my files. I changed my global preference for the world files directory a non-Program Files directory (not even the same as my new working directory), and everything's been working great.
If anyone would like, I can create a NSIS-based installer for MUSHclient that will install it in, let's say, "C:\Games" which will also bypass all of these steps. Honestly, that's where I install all games anyway, so I had never realized it was an issue.
On a side note, Nick, how hard would it be to change the source so that it stores all user-based files in <account>\Documents\Games? That would also make it much much easier to use on multi-user computers (such as mine).
If you can do this, please, PLEASE don't hard-code the location of that folder. I have my Documents folder stored on a separate drive from my Windows install, specifically because that way if my Windows drive dies, I lose absolutely nothing. Windows knows where it is, though, and sets environment variables accordingly.
I love how various versions of windows often had trouble figuring out where *they* where, never mind anything else, yet every recent version requires that we place more and more trust in it knowing where other things are, via symbolic links from places they are not... Seriously, this is a pain in the backside. And, yeah, I agree with the whole "put stuff in 'games'" thing. You know how many fracking games have stuff like "override" folders, where you place mods? A bloody huge mess of them. Win Vista and 7 torpedo modding like that completely, if you are stupid enough to put them in Program Files, since you **must** have access to the program directories to install the bloody mods. What a damn mess, and all as some lame ass "security" solution that probably doesn't succeed in making the machine truly more secure.
Well, some newer games (Torchlight comes to mind) put their Mod folder in your documents, and sites where you download mods make it quite clear where that is. Makes life a lot easier all the way around. I'm not sure what I'd have done with Fallout 3, though, if I'd installed it in my Program Files directory.
If anyone would like, I can create a NSIS-based installer for MUSHclient that will install it in, let's say, "C:\Games" which will also bypass all of these steps. Honestly, that's where I install all games anyway, so I had never realized it was an issue.
On a side note, Nick, how hard would it be to change the source so that it stores all user-based files in <account>\Documents\Games? That would also make it much much easier to use on multi-user computers (such as mine).
If you can do this, please, PLEASE don't hard-code the location of that folder. I have my Documents folder stored on a separate drive from my Windows install, specifically because that way if my Windows drive dies, I lose absolutely nothing. Windows knows where it is, though, and sets environment variables accordingly.
I need to look at NSIS anyway to try to update the way installation works, so I'll take a look at that now.
As for the source, most locations are already stored as variables, like:
Plugins
World files
Logs
It shouldn't be too much trouble to make that work.
As for hard-coding, don't worry. On some of my PCs I don't use standard folders either.
I don't know if this is something I did wrong, but is there a reason my windows7 mushclient copy won't remember its previous location/dimensions, whereas my vista copy will?
It stores its screen locations in a file MUSHclient.ini in the same directory as MUSHclient.exe.
If this is not writable, which it probably won't be under Windows 7, it can't save the screen locations.
I suggest you move the whole MUSHclient install directory to somewhere writable, such as your Documents folder, and run from there (you may need to change the shortcut that starts it up, or make another one pointing to the right place).
I did that and it didn't work, BUT... I realized for some reason when you do the dragging stretch with the pulsing blue circles that makes it expand the opposite side, it won't save it. I moved everything back to the programs x86 folder, and didn't stretch the window to the VERY edge of the screen and it saves it... go go gadget 7?
Any updates on the NSIS installer, Nick? If you'd like, I can post the code that I use. Doesn't use the MC icon, but it wouldn't be hard to change that. Mostly it just compresses everything in the source directory, storing relative pathnames, then when you install it, it puts everything into the folder you choose (default for my installer is C:\Games\MUSHclient). Then it creates a Start Menu folder named "MUSHclient" and puts shortcuts to the executable and the uninstaller in there.
I know I am coming into this late, since it has been months, but I just tried installing Mushclient on two different Windows 7 systems and got different results. Funny thing was, I never looked at this until now so I never did the standalone part and wondering how I got the mixed results.
The mixed results I gotten, using the standard installer, in both cases, they came up as normal (Including the Help window error, which I didn't care about much). But the mixed results came with the default plugins...
On one computer, the plugins didn't complain about class not registered, but on another system:
loading scripting engine
Plugin: gonienie_pro (called from world: barsawia)
Error -2147221164 occurred when loading scripting engine:
Class not registered
(This is copied from another post, as I don't have the computer with me at the moment but this is the similar error.)
This was with the hyperlink and Newactivity plugin giving me the error. So kinda of confused as to what the problem is.
It's working on one PC but not the other because one has a script engine installed that the other does not. I am guessing Python, but it could be Perl or something.
In the case that works, either you installed it for MUSHclient, or some other software (game, utility) installed it for you.
If you edit the plugin "gonienie_pro" (you will need to work out the exact file name, maybe gonienie_pro.xml) with Notepad you will see near the top the script language, like this:
Well, in this case, it isn't that plugin, Nick, but the two default plugins that come with Mushclient, that being Hyperlink and NewActivity. The only real difference between the two computers, besides OS builds (Home Premium vs Ultimate), the laptop with Home Premium has UAC set to 2nd from the bottom and the Ultimate has UAC set to 'none'.
Unfortunately, I don't have the computer next to me at the moment, and that was the closest to the error message I got when I did a search to determine what was going on.
Well, Hyperlink and NewActivity both use VBscript (the copies I have do anyway). I would check inside your copies to see if they do or if you have a version that uses another language.
So either VBscript isn't installed (or some sort of UAC stops it being usable) or your plugins use a different language.
I don't know enough about Windows 7 to comment - when I tested it under Vmware my Mac ran like a dog (unlike every other operating system that runs under it) so I don't use it much.
I will see if it is UAC... The only other thing I can think of is whether or not it is due to having Curse Client (www.curse.com) with its One-Click installer put in some MDAC/Scripting support in.
Edit - Not UAC related... So trying to get VBScript installed, although Win 7 comes with 5.8 VBScript.
From this thread, there is a mention of computers with McAfee installed. The Win 7 Ultimate computer was a clean, no preload install. The Laptop is a default Dell Preload install with McAfee on it. I will have to check on my computer when I get back and see if this is the issue. Something to consider for not just Win 7, but for other computers.
Last Edit -
Ran the McAfee uninstaller and now it is working properly... *stabs McAfee for poorly designed uninstall procedure*
Thought it was related to Windows 7, but FYI, the current installer will work without an issue from what I saw. Citing Version 4.43 and up.
Sorry to resurrect an old topic, Nick, but I noticed that your installer is still installing into Program Files. I'm attaching the code for my NSIS installer, it doesn't ask what folder to install to but it installs into C:\Games so there's no pesky permission issues.
; Script generated with the Venis Install Wizard
; Define your application name
!define APPNAME "MUSHclient"
!define APPNAMEANDVERSION "MUSHclient 4.66"
; Main Install settings
Name "${APPNAMEANDVERSION}"
InstallDir "C:\Games\MUSHclient"
InstallDirRegKey HKLM "Software\${APPNAME}" ""
OutFile "Installers\${APPNAMEANDVERSION}.exe"
; Use compression
SetCompressor /SOLID lzma
; Modern interface settings
!include "MUI.nsh"
!define MUI_ABORTWARNING
!define MUI_ICON "${NSISDIR}\Contrib\Graphics\Icons\modern-install-colorful.ico"
!define MUI_UNICON "${NSISDIR}\Contrib\Graphics\Icons\modern-uninstall-colorful.ico"
!insertmacro MUI_PAGE_WELCOME
!insertmacro MUI_PAGE_LICENSE "..\MUSHclient\license.txt"
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_PAGE_FINISH
!insertmacro MUI_UNPAGE_CONFIRM
!insertmacro MUI_UNPAGE_INSTFILES
; Set languages (first is default language)
!insertmacro MUI_LANGUAGE "English"
!insertmacro MUI_RESERVEFILE_LANGDLL
Section "MUSHclient" Section1
; Set Section properties
SetShellVarContext all
SetOverwrite on
; Set Section Files and Shortcuts
SetOutPath "$INSTDIR\"
File /r "..\MUSHclient\*.*"
CreateDirectory "$SMPROGRAMS\MUSHclient"
CreateShortCut "$SMPROGRAMS\MUSHclient\MUSHclient.lnk" "$INSTDIR\MUSHclient.exe"
CreateShortCut "$SMPROGRAMS\MUSHclient\ReadMe.lnk" "$INSTDIR\readme.txt"
CreateShortCut "$SMPROGRAMS\MUSHclient\Uninstall.lnk" "$INSTDIR\uninstall.exe"
SectionEnd
Section -FinishSection
WriteRegStr HKLM "Software\${APPNAME}" "" "$INSTDIR"
WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "DisplayName" "${APPNAME}"
WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "UninstallString" "$INSTDIR\uninstall.exe"
WriteUninstaller "$INSTDIR\uninstall.exe"
SectionEnd
;Uninstall section
Section Uninstall
; Set Section properties
SetShellVarContext all
;Remove from registry...
DeleteRegKey HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}"
DeleteRegKey HKLM "SOFTWARE\${APPNAME}"
; Remove directories
RMDir /r "$SMPROGRAMS\MUSHclient"
RMDir /r "$INSTDIR\"
SectionEnd
; eof
Also, have you ever decided about putting world/script/plugins into My Documents? If I knew more about coding, I'd offer to change it, but it's way over my head.
Sorry to resurrect an old topic, Nick, but I noticed that your installer is still installing into Program Files. I'm attaching the code for my NSIS installer, it doesn't ask what folder to install to but it installs into C:\Games so there's no pesky permission issues.
You can't really do that, on some systems the C: drive doesn't exist (eg. with multiple partitions) or if it does exist you can't write to it.
However I take your point that the installer needs updating.
In my experience, Windows is *ALWAYS* installed on drive C:, unless it's a really messed-up system, and the root has always been writeable. But, since you brought up that point, here's slightly altered code to allow directory selection:
!insertmacro MUI_PAGE_WELCOME
!insertmacro MUI_PAGE_LICENSE "..\MUSHclient\license.txt"
!insertmacro MUI_PAGE_DIRECTORY <~~~ insert this line here
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_PAGE_FINISH
That should install everything exactly the way yours does, just not into Program Files with all the issues Vista and Win7 have with that.
YmerejO42 said: In my experience, Windows is *ALWAYS* installed on drive C:, unless it's a really messed-up system, and the root has always been writeable.
I've had one of those really messed-up systems. It's hard to believe there isn't a way to "get" the drive that Windows is installed on: the installers I'd used worked fine.
In my experience, Windows is *ALWAYS* installed on drive C:, unless it's a really messed-up system, and the root has always been writeable.
Well if you install to the not-first partition, it won't be C. For example, if you install Vista *and* Windows XP, or Windows *and* Ubuntu.
I have a PC with C: being a non-writeable partition (because it looks unformatted) which actually has Ubuntu or something like that on it. And in this case Windows is on J:
I have started incorporating your suggestions into an improved installer, but don't you think that just putting stuff into C:\Games (or whatever drive) is itself a bit arbitrary? On my copy of XP for example, there is no C:\Games folder.
It is, but it has the advantage of not mixing games (which don't always play nice with the UAC in Vista and Win7) with other programs. Mods and such are much easier to install, as for example Fallout 3 which requires them to be inside a subfolder of the game itself.
Also, as another example, in order to save changes to worldfiles in MUSHclient, you have to run it in elevated mode, which just gets annoying. If it's in another folder, though, they save perfectly well. Unless you're going to institute my suggestion about storing them somewhere in the My Documents folder. Then, as long as all files it may need to write are in that folder, there should be no issues.
Plus, if you look at the root of your drive, you know right away where your games are, since they have their own folder. Makes it easier to find them for mods/backups/whatever.
Twisol said: I've had one of those really messed-up systems. It's hard to believe there isn't a way to "get" the drive that Windows is installed on: the installers I'd used worked fine.
Just noticed this one, figured I'd answer it. For the most part installers use system variables, for instance %PROGRAMFILES%, which redirects to (windows drive):\Program Files. So the person writing the installer doesn't need to know what drive you have Windows on, the installer detects it itself.
Nick Gammon said: I have a PC with C: being a non-writeable partition (because it looks unformatted) which actually has Ubuntu or something like that on it. And in this case Windows is on J:
Weird, because when I've installed Windows/Linux in a dual-boot setup, Windows always calls whatever partition it's installed on C:, even if it's the second/third/whatever partition. It just ignores the rest as though they don't exist.
Nick Gammon said: I have a PC with C: being a non-writeable partition (because it looks unformatted) which actually has Ubuntu or something like that on it. And in this case Windows is on J:
Weird, because when I've installed Windows/Linux in a dual-boot setup, Windows always calls whatever partition it's installed on C:, even if it's the second/third/whatever partition. It just ignores the rest as though they don't exist.
Windows always calls the boot partition C:. That's the primary partition with a bootsector pointing to a contained NTLDR and NTOSKRNL. Under XP or earlier there's the Boot.ini that may specify an ARC path to a different partition for the other windows Files, with Vista or newer there's a configuration DB.
On Newer systems, this DB is actually on the EFI Partition - the ~100 meg partition that appears first on the disk. Since EFI (Extended Firmware Interface) is replacing BIOS (Basic Input/Output System)
p.s. %SystemDrive% gives you the boot drive. %HomeDrive% can be set by your Net Admin so that you save to a server and not locally.
WillFa said: p.s. %SystemDrive% gives you the boot drive. %HomeDrive% can be set by your Net Admin so that you save to a server and not locally.
Hopefully, people using MUSHclient will be either playing on a standalone computer, at home, or if they do have a network, they'll know not to install it on a server drive.
The current installer allows you to choose a destination directory (which you could easily make to be C:\games\).
Also it remembers what you previously installed into for next time. So, for a one-time change of the installation location, effectively the existing installer will do what you suggest.
However the latest version does include the updated look-and-feel of the installer.
Well, all I ask is that you keep putting up a .zip download, please, so I can continue using my installer. That way, I don't have to remember to change the install location to a place where Vista or Win7 won't continually prompt me for Administrator rights for me to save worldfiles, or aliases, or most other things that I do in the normal course of MUDding.
Plus, remember, if MUSHclient is started in a non-elevated state, Win7 at least won't allow it to elevate "on the fly" to write into the Program Files folder, I believe. So you'd have to elevate it on every run, which would make some people paranoid that you'd hidden some malicious code in the program, and was using that to force them to allow it to run. Not saying that you have, pointing out that some people are paranoid enough to think that way.
Again, as I said on another occasion, if you could modify the source so that the default directory for datafiles is something like <user>\My Documents\My Games\MUSHclient, that would also avoid all of the issues with the User Account Rights. If I knew programming well enough, I'd offer to patch it myself, but I don't, unfortunately.
Also, any luck with getting the help file updated? I tried, but I never had any luck with getting it converted.
Well I seem to be getting different results to you. First I made a non-administrator account on Windows 7, then grabbed the latest installer (4.67) and ran that. It asked for an administrator password to run the installer, which is fair-enough I think. Under your plan of installing to C:\games you would expect to have to give permission for that.
After that it asked an install directory so I said C:\games (so it ended up in C:\games\MUSHclient). That worked fine, then I started the program, connected, saved the world file and exited.
I then re-ran MUSHclient - didn't have to enter an admin password. I saved the world file again, no admin password.
So I'm not sure what is really being achieved by your turning my .zip file into another installer.
YmerejO42 said:
Also, any luck with getting the help file updated? I tried, but I never had any luck with getting it converted.
No, but downloading the Windows-supplied help program makes the existing help file run OK (as described on page 1 of this thread).
Quote: So I'm not sure what is really being achieved by your turning my .zip file into another installer.
I just prefer to have the default installation be in a folder other than Program Files. That way, if I have to reformat my computer (happens more often than you might think), I don't have to remind myself to change the installation folder when I'm installing MUSHclient.
Quote: No, but downloading the Windows-supplied help program makes the existing help file run OK (as described on page 1 of this thread).
And yeah, the Microsoft-supplied help file reader does read the old format, but 1) it's something extra for end-users to have to install, and 2) it doesn't do any good if you're playing and hit F1 for help. In that case, it tries to launch it with the native help program, which won't read the old format, even if you have the older one installed and associated with the older help files.
In fact (having just tried it), for some reason Win7 refuses to associate older .hlp files with the program, you have to edit the registry in order to do so. But it still won't launch from within MUSHclient, so context-sensitive help is nonexistent.
In fact (having just tried it), for some reason Win7 refuses to associate older .hlp files with the program, you have to edit the registry in order to do so. But it still won't launch from within MUSHclient, so context-sensitive help is nonexistent.
Yeah it works fine. I just tried on what is basically a Vanilla Windows 7 environment. I only bought and installed it to prove MUSHclient starts up OK. No registry editing or anything like that.
I just started MUSHclient, and the Ctrl+Shift+Alt+L stuff works. And as you can see from the screenshot, hitting the "Functions" button when editing a script works. And the context-sensitive help works (the "show me what this does" cursor). And F1 works in the usual way.
Maybe you didn't install the legacy help stuff in the recommended way?
OK, once I got Windows Validation to admit that my copy is legit (Microsoft hates me), I got the Win7 64-bit version, and now it works perfectly. Turns out that the one I had was for Vista 32-bit, and wasn't installing properly or something.
Still think it would be nice to update the helpfiles, but at least now it works. Thanks for the verification on that.
On the matter of moving the world/plugin/logs folders - What do you have to have to compile MUSHclient? I have Visual Studio 2008 Express, would that work? If not, then what would I need to get? Maybe I can help contribute by rewriting part of the code to move those into the My Documents like I've suggested, then it shouldn't matter where MUSHclient is installed. I know, you can change them manually, but I'm not sure the changes would save if you weren't running in elevated mode to start with. If it defaults to a writeable folder, then there's no issue there. Plus it would make it easier to use on multi-user systems, like mine.
Same technique of installing onto Windows 7 will work on Win8 and I thank you for mentioning it as I was getting pretty ticked off at my logs being empty, my characters being unrunable etc.
Hello, I had an unusual glitch with my desktop copy of MushClient v. 4.84, and I'd managed to narrow it down to one type of trigger, and the script (using VBScript) that it calls ( my 'pose-clipper' script)
My laptop runs Windows 7 Home Premium x64, without any issues. My desktop was also running Win 7 Home Premium x64, but it was kicking back an error upon startup:
(* well, it was until I disabled all the related triggers... something about access to "OnGagTrigger" the call for the script in my glitch'd trigger *)
It was still kicking this back the following error despite my not having anything that really could trigger it (it was triggering on a name that is not set in the trigger list, and nothing else on the line is set either...)
Trigger function "OnGagTrigger" cannot execute - scripting disabled/parse error.
I narrowed it down to that type of triggers, and the script, by disabling the triggers as a while at first, then the 'pose-clipper' ones manually - a tedious process)
I finally tried the solutiuon that worked... copy the installed MushClient directory from my laptop to my desktop (it goes into C:/Program Files (x86)/MushClient in both systems, and hey presto, the 'glitch' vanished.
So, my question becomes, was anything changed recently in the 4.84 install compared to the originally distributed one? If so, its got a glitch... I'm just glad I could salvage from my laptop...
Then again, maybe something in my desktop was preventing something from running correctly (or at least ~installing~ correctly) as the brute-force copy/paste worked. A manual look-compare saw identical files/sizes/dates... so If you changed sommat, please, swap it back?
WhiteWolf McBride
faithful MushClient user (yea, I prefer my formatting... its a Client for Mushes, right?)
help me please!!! Windows 8, starting error -> Can't open global preferences
database at:
C:/рабочий стол/днс/mushclient/
mushclient_prefs.sqlite (Error was: "unable to open
database file")
Check you have write-access
to that file. what to do???
MUSHclient wants to update files in its own folder. Windows UAC doesn't allow that in certain places like %ProgramFiles% or %SystemRoot%. If you want MUSHclient to run properly, you have to either not put it in a UAC protected location or run MUSHclient as Administrator.
Now I don't know what the security settings on C:\рабочий стол\ are, but try moving the MUSHclient folder to a location controlled by your user such as your user documents folder.
Also try restarting the computer. Windows could just be locking the file temporarily.
