[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  portable MUSHclient.
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
portable MUSHclient.

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Pages: 1  2 3  

Posted by YmerejO42   USA  (25 posts)  [Biography] bio
Date Reply #15 on Thu 11 Dec 2008 09:08 AM (UTC)  [ quote  ]
Message
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
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Reply #16 on Thu 11 Dec 2008 06:59 PM (UTC)  [ quote  ]
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by YmerejO42   USA  (25 posts)  [Biography] bio
Date Reply #17 on Thu 11 Dec 2008 08:31 PM (UTC)  [ quote  ]
Message
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.
[Go to top] top
Posted by WillFa   USA  (517 posts)  [Biography] bio
Date Reply #18 on Thu 11 Dec 2008 09:03 PM (UTC)  [ quote  ]

Amended on Thu 11 Dec 2008 09:06 PM (UTC) by WillFa

Message
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)


[Go to top] top
Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #19 on Fri 12 Dec 2008 03:23 AM (UTC)  [ quote  ]
Message
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.
[Go to top] top
Posted by WillFa   USA  (517 posts)  [Biography] bio
Date Reply #20 on Fri 12 Dec 2008 04:45 AM (UTC)  [ quote  ]
Message
Nick, Worstje and I are saying SQLite... It's two against one again! ;)
[Go to top] top
Posted by Zhamel   USA  (67 posts)  [Biography] bio
Date Reply #21 on Fri 12 Dec 2008 12:16 PM (UTC)  [ quote  ]
Message
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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Reply #22 on Fri 12 Dec 2008 08:55 PM (UTC)  [ quote  ]
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Tspivey   Canada  (50 posts)  [Biography] bio
Date Reply #23 on Sat 13 Dec 2008 09:33 AM (UTC)  [ quote  ]
Message
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.
[Go to top] top
Posted by YmerejO42   USA  (25 posts)  [Biography] bio
Date Reply #24 on Sat 13 Dec 2008 05:45 PM (UTC)  [ quote  ]
Message
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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Reply #25 on Sat 13 Dec 2008 07:24 PM (UTC)  [ quote  ]
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by YmerejO42   USA  (25 posts)  [Biography] bio
Date Reply #26 on Sat 13 Dec 2008 09:39 PM (UTC)  [ quote  ]
Message
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?
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Reply #27 on Sun 14 Dec 2008 12:53 AM (UTC)  [ quote  ]
Message
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.

Quote:

Is it C++ or regular C?


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

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Whitchek   (4 posts)  [Biography] bio
Date Reply #28 on Mon 04 May 2009 04:44 PM (UTC)  [ quote  ]
Message
Is this MUSHclient Live program still available somewhere? Or something similar? The old website appears to be gone.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Reply #29 on Tue 05 May 2009 08:47 PM (UTC)  [ quote  ]
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] 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.

11,804 views.

This is page 2, subject is 3 pages long:  [Previous page]  1  2 3  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]