portable MUSHclient.

This is probably about the most insane thing I'm asking for yet, so please bear with me on this. I reecntly crashed at a friend's house for a few nights, and I forgot to put MUSHclient back on my USB drive after wiping it. When I went to go install it onto the USB drive, I wound up changing my friend's registry. I cleaned it up, but I'd rather not have to. Is there any way that you could make a portable version of MUSHclient? Either something like what's at http://portableapps.com/ or just make a -portable command argument for the installer to make it not poke the registry. Granted, anything portable like that should impossible to actually register, but the splash screen shows up when I just copy over my MUSHclient directory anyway.

I have created yet another program in Autoit for use with MUSHclient. I call it MUSHclient Live, in the same aspect of FireFox Live. Ok Setup and usage instructions ...

1. Place In MUSHclient Installation Location
2. Run ONCE on HOST PC (The Source PC for the MUSHclient files) to Extract the Settings.
3. Place ENTIRE MUSHclient Installation Folder onto desired storage medium (If CD is used, then it will not keep previous settings already on the portable system, NOR update the extracted settings with any altered ones)
4. Run MUSHclient Via the MUSHclient_Live.exe, and Enjoy.

Breakdown of program's operations:
1. If MUSHclient.exe does not exist in same location, quit with error
2. If Mushclient.reg does not exist in same location, then try to extract from registry, if not exist, quit with error
3. If another copy of MUSHclient_Live is running, then quit with notification (ONLY 1 COPY Can Properly Function)
4. If MUSHclient Settings Exist in Registry Already, Extract to backup_mushclient.reg, remove ALL MUSHclient Settings (Prevents Conflicts, and Unneeded Updates to Settings).
5. Insert settings from Mushclient.reg (Created with First Run)
6. Updates the folder locations to absolute paths that are located on the storage medium, or wherever Program run from. (I.E. logs = Location\logs\, worlds = Location\worlds\, plugins = Location\worlds\plugins\)
7. Runs MUSHclient, and waits till you quit.
8. Re-Extract Settings from registry (to keep any changes), remove ALL MUSHclient Settings in Registry (Again to Prevent Conflicts), if mushclient_backup.reg exists then Insert back into Registry, then remove mushclient_backup.reg

URL: www.torasin.com/~venificius/MUSHclient_Live.exe

I hope that MANY find this useful :)

Laterzzz,
Onoitsu2

I just copy my C:\Program Files\MUSHclient directory to a USB drive and run it off of there. The few seconds of waiting is fine by me. And with a little modification, I can get it to automatically load plugins with no problem. I'm mostly concerned for when I bring the wrong flash drive or forget to bring one at all. I'd rather not muck around with my friends' registries.

The MUSHclient live option sounds similar to the PortableApps programs. I just suggested PortableApps because I can just toss them onto my Treo and run off of my phone.

Ya MUSHclient Live is just like Firefox Live, I have "dissected" the Fire Fox Live, and all that does is copy the proper registry settings from the profile folder, and then run the Normal Firefox Executable. Pretty near the same as mine, only mine uses .reg files to back up the settings, so that ANY moderate to advanced user (one comfortable with mucking around with the registry) can understand the "profile" file itself.

The only problem I can foresee is if you use a plugin that is located anywhere other than the default plugin location, OR a folder located in that same location, due to the way the location will be stored in the world file. This could cause an error message, stating that it cannot find the specified plugin, yada yada yada, and then all you will have to do is re-add the plugin to the world file, and all will be well again.

Laterzzz,
Onoitsu2

Actually, with all the swapping in and out of registry files, do you need any sort of admin access in order to use this live version you have? I'm not terribly used to Windows, since I've been running various flavours of linux for several years now. I'm not sure how affecting the registry works anymore. Also, any idea how this works on Vista with its overly hyped up security features?

Actually you SHOULD NOT need anything more than a REGULAR user account, meaning a NON Guest account, as this is using the HKEY_CURRENT_USER location in the registry, which is perfectly allowed typically, exceptions being CERTAIN Microsoft, and other settings within, but this SHOULD work without Admin privs.

As for Vista, I don't think ANYTHING will actually WORK on it ... lol, but that is just my opinion of ANY BRAND spanking new OS from MS, it needs to have at least 1 MAJOR patch in order for it to function PROPERLY, even XP needed that, heck even Windows 98 as well...

Laterzzz,
Onoitsu2

Wow, major caps there. :-)


Although it is nice to have third-party solutions, I would be happier with a built-in solution. There are several reasons why I might want the settings to be stored in the active directory, without needing another application. The first and foremost is that it makes migrating settings easier; you just need MUSHclient, nothing else.

Also, I get twitchy about running third-party executable files without seeing the source, especially when the registry and so forth is involved. It's nothing about you Onoitsu2; I feel the same about pretty much every executable I see for download off the Internet. :-) Generally for me to run something I need to have reason to believe I have basically no choice but to run the executable. (Or have some reason to believe that the source is trust-worthy.)

well ANYONE requesting the source, I would be happy to send it to them, but it was coded in AutoIt, so you will need that to compile it.

If you want the source, drop me an e-mail using the forum e-mail option, or at onoitsu2@yahoo.com, and i will e-mail it to you :)

I ALSO understand that a "first-party" solution would be nice, but I like making things that solve problems, without having to disturb the authors of the software. Take for instance, I am currently creating a program using AutoIt, that adds a pane to the MUSHclient toolbar, that expands and contracts via a button or hotkey, that recieves UDP messages from mushclient, on port 4444, so that you can set the buttons in the pane to do things on the fly, or set a few aliases to alter them based upon different situations. The Button text and what they send to the world file is customizable, as well as a tick timer (Aardwolf Only Currently, fixed 30 second), that is a label that counts down, as well as a progress bar, that is shown when pane expanded, that graphically ticks down. Am planning on adding more soon, but taking a break so brain does not implode :)

Laterzzz,
Onoitsu2

I'd like to "bump" this discussion, and also add my own wrinkle to the list...

My reason for requesting "portability" comes from the fact that I play on 3 different computers, with 3 different OS. Currently, I have MUSHclient installed on each of the computers, 2 Windows and 1 Linux/Wine. I don't like having settings in the Windows registry, but I can live with it.

My problem is (I suspect) simpler: I do not know in advance the drive letter for the .mcl, script and log files. Even on the same computer, the letter will change from day to day depending on the sequence I use to insert USB drive.

Current solution:
1) Insert USB drive, run MC, open world
2) Suffer through error messages.
3) Edit paths. Save world. Quit.
4) Restart MC, reopen world. (Log file now gets created.)

I would love a solution that avoided steps 2-4.

P.S. The biggest headache is getting the log file to open, as I log every session to a logfile directory, with a unique name.

P.P.S. Directory structure is...
USB:\World1
......World1.mcl
......World1.lua
......\Logs
.............Logfile_1
.............Logfile_2

I for one have never had an issue with drive letters, and this is going from approx 60 possible computers in the College Computer Lab, and 2 at home.

I have all plugins located in 'worlds\plugins\' or in a folder located within that location that is named appropriately to the server.

My 'Mushclient Portable' executable will alter the path that the registry looks in each run, and prevents these issues.

It ALSO removes all trace of the Mushclient settings in the registry. And if a previous Mushclient installation on the computer existed, then it will backup those settings, and use the ones stored with the portable installation, then once it is closed will restore the existing installation's settings.

As for logs, my program also alters the location of the logs folder, as long as it is located in a 'logs' folder within the Mushclient folder.

As for usage in linux and wine, well that I have not tested, BUT should work just fine, if Mushclient works as well.

-Onoitsu2

Thanks for the reply. The problem I have with Linux (and this may be my ignorance showing) is that the path name to the script and log files becomes totally different from the Windows system. This results from the way Linux treats my USB drive -- it mounts the drive as a subfolder in the MEDIA folder. Wine (and the application directory for MUSHclient) is sitting way over in another path.

Perhaps a linux guru could tell me how to automount the USB drive "in" the directory structure where MUSHclient expects to see the .mcl file. I've not yet figured it out.

I looked at Mush Portable before I wrote my first post, and decided it probably would not do the trick for me because of the above issue. I may go back and look at it again.

In any event, it would be nice if this functionality were present in the standard product. Basically, I'd like everything to be relative to the .mcl file I execute. That is the one common denominator, as far as I can see.

You can find out this from GetInfo:

http://www.gammon.com.au/scripts/doc.php?function=GetInfo

In particular:



Given the startup directory, you should be able to script a log file open, or even by simply using a special code on the automated log file startup (see logging help):



Now by using something like %E\logs\<somename> you could make the log files open under wherever it is that MUSHclient is installed this time.

Or if you script the open in your script file, tack the path onto whatever GetInfo (68) returns.

If your problem is the list of worlds that open at startup (and this surely isn't an essential feature) then you could edit the Registry entry to change the absolute pathname (eg. "C:\Program Files\MUSHclient\worlds\something") to be a relative pathname, (eg. "worlds\something").

I thought I would bump this up again and add my own suggestions. I like
the idea of a portable MushClient. Taking the idea
of the % substitutions in the logging configuration, could the same thing
be done for anything that requires a path (e.g. script file)? for example:
%F\%N\%N.lua
I think that this would be useful for anywhere where we can put a path (e.g. the sound
edit box in the trigger dialog). In my oppinion this
would make it easier to distribute things such as preconfingured worlds,
(the sound packs for the blind for example). I could use a plugin,
but there's no easy way to modify them once created, so for example
if there was a trigger that you wanted removed, it would be far easier to just keep
everything in the world.

Can I just ask why you say plugins are hard to modify? They are just text files, and I would have thought that for blind users, a text file would be easier to manipulate than GUI-type dialog boxes.

For example, to remove a trigger, you look through the file for <trigger> ... </trigger> and delete those lines and the ones between them.

In certain situations, modifying a text file is easier. If I want to remove a trigger that matches if someone pokes me
in the ribs, with the gui dialog I can just press
control-shift-8 alt-f pokes enter, focus is still
on the list so if it's not the correct trigger just press alt-n, and alt-r y to remove it. Enter closes the dialog,
and the trigger is gone. The same goes for modifying one. If the shortcuts are there, or the dialog is
accessible and doesn't take much effort to navigate around, it's often faster to use
the dialog than to remember that I would need to add
omit_from_output="y" or send_to="12".

If the dialog isn't accessible or the interface is just confusing and
difficult to work with and a text file is available, then I would just edit the text file.

I can't think of any dialogs that I've ever had problems with in MUSHClient. Everything uses standard
controls, so just works.

Nick-

Just wanted to say, I absolutely LOVE MUSHclient, but I'd like to request a portable version, also. Onoitsu2 had the right idea, the way you do things now, but there are 2 problems:

1) His solution won't work with Windows Vista.
2) With or without his solution, the paths to worlds and plugins (I assume scripts also) are hard-coded once MUSHclient is installed on a computer.

I found an alternative to his solution, it's a utility specifically for programs like MUSHclient that store data in the Registry, it works great for extracting the information, saving it, inserting it on another computer, even cleaning up after itself... But where the paths are hard-coded, you have to install it somewhere on their computer then remember to delete it afterward.

Would there be some way, in the source, to make the codes relative to where the MUSHclient executable is? I downloaded the newest version available (4.37, with source) but I'm not that experienced of a programmer to find where I could change those functions.

Even better (but probably even more complicated) would be to change the source so that it stores all data in an external file, probably XML would be good for this, but I'm not sure how hard it would be. If you would be willing, I would be happy to try and learn enough programming to change the Global Prefs to do that.

I'm subscribing to this post, so I'll receive notification of any answers, hope to hear from you soon.

~Jeremy

I certainly acknowledge that the way the Registry is used is sub-optimal to say the least, and have part-coded ways around that. I think the stumbling block for me was where to store the global prefs file (eg. the XML file), without using the Registry.

An obvious place is "where the MUSHclient executable is" however in some ways that has problems. For a start, technically the program directory shouldn't be writable (although I know I store things like the world file directories as subdirectories under it), and secondly, with multiple users on one PC, how would you specify multiple global preferences? At present, using the Registry, each logged-in user gets their own global preferences.

Yes, but they end up using the same world files and such, so I have to be careful writing triggers, since my gf also plays Aardwolf with me, and her equipment is different, so my triggers won't work for her... Could you set it up so that it checks the install directory, then checks the user's profile folder? I know that Microsoft now has most of its games store data in <userdocuments>\My Games. Would it be possible to do that? Say, My Games\MUSHclient, recreate the directory structure for plugins/worlds/scripts and everything there. Since you use NSIS for the installer it wouldn't be too hard.

You could even store the Global Preferences that way, or even in each user's Application Data folder, so that each user would still have their own preferences. Maybe include a command-line switch (--portable or something similar) that will cause it store everything in the MUSHclient folder, if that switch isn't there then it uses the profile folder by default.

I really appreciate the quick response, and I hate to think of all the potential work this would be, but as I said, I'll be willing to help with anything I can. I'm pretty good with writing install scripts with NSIS if that would be any good.

Weren't you thinking of incorporating SQLite anyway?
The registry is just another database, after all. :)

From looking at my registry, I don't believe you ever store anything under HKLM. The HKCU\Gammon Software Solutions\{exename} key could become a SQLite database in the exe's directory. (or under Application Data if you suddenly cared about getting a Windows Logo cert.)

The table schema could be nearly identical to the registry layout, with one additional column for UserName to still give the multi-user support.

The code changes could even be minimal with just overloading GetProfile(Int|String) and WriteProfile(Int|String) to two functions that do the SELECT or INSERT/UPDATE queries. (After linking to the SQLite dll and incorporating a DBOpen call into the initial startup)

I can't be bummed reading the rest of this thread, but would a single check for a file called 'portable' in the MUSHclient directory not suffice to see whether or not it is portable? If it is portable, you store stuff in the MUSHclient directory, otherwise you use Application Data?

All that remains then is migrating the Registry data to some other configfile in the appropriate path like the SQLite database someone mentioned.

Nick, Worstje and I are saying SQLite... It's two against one again! ;)

Not to join the, still small, mob and gang up on you Nick, but I am in the same boat with Worstje and WillFa.

I have two main computers, home desktop and work desktop, plus two laptops laptops I use when out of town on jobs. It gets tiresome to remember to bring any changes I make to global preferences or world files with me on my personal memory stick and copy them over every time I change computers. God forbid I forget to bring a file and have to remember how I had a trigger/script set up :P

Figured I would just throw in my vote for a portable version of your awesome ( brown nosing time ) MUD client.

I agree in principle with all this.

An SQLite database is an interesting idea - I suppose the major key would be the logged-in user name (like in the Registry), and then you would access the other stuff.

I think we have two issues here:
The first issue is a portable MUSHClient that doesn't
use the registry. A truly portable application, at least
from what I've read on the subject, needs to keep everything in its program folder, a state
which we mostly have now (except for the few preferences stored
in the registry and some hard-coding of paths in the world files - see my recent
post on the suggestions board on a possible solution to this).
As it stands right now, we can set the script files path to a relative path which will work the first time the world is loaded when the current directory is set to the
location of the world file. If something changes the directory (loading another world, adding a
plugin), reloading the script file will no longer work.
I think that a simple .ini file would work in this situation, and the
variables that controlled the world files/plugins/... directories could be set relative to the program folder.

The second issue is that of an installed client on a multi-user system. We can put
the preferences in application data, but that folder is hidden so it wouldn't be a good
place to put worlds or plugins unless there was a way of accessing your local
MUSHClient directory from inside the client for those users
who aren't technical enough to figure out how to access it.
I think mIRC does it this way in recent versions.

This goes back to my whole thing about using a folder in each person's My Documents... Everyone knows where they are, they're easy to access, and it would work with environment variables that Microsoft provides.

And easy path would be

<USERPROFILE>\Documents\My Games\Gammon Software\MUSHclient

With the world, plugins, and whatever other folders are needed, could even have them in completely separate folders unlike they are now. (where it's world\plugins, could be two separate folders under the MUSHclient folder).

Also, Nick, have you thought about updating the helpfile to a different format? I use Vista, and the new help system won't load the old format. I have the winhlp32.exe installed and associated with the older help files, but it still doesn't work from within MUSHclient. I have to browse to the folder and open it manually whenever I need to access it. Nothing major, just an annoyance for those of us who try to stay cutting edge. =)

Again, I'll be glad to help with anything I'm able to, I'm not an experienced programmer but I do what I can.

Yes, I will look at a more up-to-date path structure, the problem probably being existing plugins expect stuff where the old directory structure is.

As for the help file, a certain laziness overtook me there, and the fact that I thought that the help worked under Vista if you got that old help application. The help stuff is in fact in a database (and I have released the source for the program that processes it) so conceptually turning it into another format is certainly possible.

Already that same program outputs the RTF file which becomes input to the help file generator, and also separate HTML files.

I tried downloading the application that you'd written to process the help file, but it wouldn't compile with Visual C++ 9.0. Is it C++ or regular C?

I also downloaded some other programs to try to decompile the .hlp file and make it into a .chm help file, but they kept encountering errors and wouldn't compile properly. Is there any chance of getting the HTML files as a download? If so, I could probably compile a .chm file and email it to you or something.

One thing - I disabled the BigWorld window on Aard, since I didn't really use the World map, but it kept popping up anyway. I ended up having to edit the main window plugin to remove all references to the BigWorld window before it would stop showing up. Is that deliberate behavior or a bug?

The individual help files (a bit out of date) are here:

http://www.gammon.com.au/files/mushclient/mushclient_help_4.15.zip

The documentation itself is at:

http://www.gammon.com.au/files/mushclient/src/documentation.sql.bz2

You can always import that into an SQL database (I used mySQL) and then write code to generate whatever you want.



It is C++ but version 6 of MS Visual Studio, and needs MFC to compile and run.

Is this MUSHclient Live program still available somewhere? Or something similar? The old website appears to be gone.

I don't have a copy, however recent versions of MUSHclient keep their global settings in a SQLite database (as suggested earlier up the thread) and thus you don't need to fiddle with the registry any more.

You should be able to put an installed copy of MUSHclient on a USB stick, and when it opens it looks for the preferences in a SQLite database in the same location as MUSHclient.exe, and thus that should work for you.

Ah, okay, hadn't noticed that change. The one thing I still don't see... how to do relative paths for the directories?

What directories do you have in mind?

See this lengthy thread:

http://www.gammon.com.au/forum/?id=7776

If you specify the plugins directory (say) as a relative path, then MUSHclient changes the ./ part of the pathname to be relative to the directory MUSHclient started up in.

How do I go about that? I was going to try just typing a relative path in to see if it worked, but I can't seem to find a way to type a path in at all. It just comes up with a box asking me to browse for the folder.

You would need to use the sqlite3 program offline (ie. while the client is not running) to change the global preferences database. For example:



You can get that program from:

http://www.sqlite.org/download.html

Look for "Precompiled Binaries For Windows" -> "A command-line program for accessing and modifying SQLite version 3.* databases.".

At present that is: http://www.sqlite.org/sqlite3-3.6.14.bin.gz

And I'm supposed to do that every time? It seems kind of... overinvolved, just to change a directory. I really dislike the idea of having to be messing with SQL stuff. That's why I was hoping here for a program that could handle it.

No, you do it once. You haven't answered my question about which directory you need to have a relative path to. Perhaps I am answering the wrong question.

I have created a page explaining how to create a portable aardwolf mushclient.

http://code.google.com/p/bastmush/wiki/PortableMushclient

The part that you really want to pay attention to is the editing of the mushclient_prefs.sqlite database.

Bast/Eric