Gammon Forum : MUSHclient : General : Pretty interfaces

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

General

Pretty interfaces

Pretty interfaces

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

Pages: 1 2

Posted by

Worstje Netherlands (899 posts)

Date

Mon 28 Jan 2008 09:59 PM (UTC)

Message

So, I suppose most of MUSHclients users have wanted to make those 'pretty' interfaces another popular mudclient can do. (Although, pretty is in the eye of the beholder entirely!) Many of the scripters have probably fiddled around with UDPSend() or maybe COM-objects or another method to influence a window of their own liking and have it display the things they'd like to see.

I've been thinking (okay, I admit, I've been coding away) on an application to bring this kind of functionality to the masses, while allowing MUSHclient to keep its lean and mean performance, and keep its interface clean.

It's still very much into hobby right now, and I'm kind of reluctant to post pictures of the few screenies I have so far due to expectations that may arise, lack of storage space and the simple there-is-not-much-to-see-yet.. so I'd rather ask everyone a simple question:

What would you like to see in a 'one tool fits all' kind of status program? Having it useful for beginning scripters and experts alike would be one of the main points to me.

Posted by

Onoitsu2 USA (248 posts)

Date

Reply #1 on Tue 29 Jan 2008 01:50 AM (UTC)

Message

I would like to see gauges (progress bars) that allow multiple colors, as well as clickable buttons that send commands to Mushclient. Possibly "multi-state" buttons, i.e. toggle buttons, where when pressed another object does something secondary to what it did when "this" button was not pushed down.

Basically anything that zMud does for buttons would be a GREAT addition, as Mushclient would then have a customizable GUI, even if it were an external application that accomplished the task. I know that the moving of the buttons and objects is something that has been discussed OVER AND OVER again, and has been determined to be futile, unless you use "messages" with the positions to "move" controls to, but moving controls via the mouse has been fraught with lack of information.

-Onoitsu2

Posted by

Worstje Netherlands (899 posts)

Date

Reply #2 on Tue 29 Jan 2008 10:08 AM (UTC)

Message

You'll need to define multiple colors. Do you mean something like (example of R=red, Y=yellow, G=green):

RRRRYYYYYGGGGG and an inbetween state of RRRRYYYY?
Or do you mean more that the interface should be able to be one solid color at one moment, and another solid color at another moment?

Multi-state buttons I am kind of torn on, to be honest. In something like zMud, it works because it is done in the application itself so that it has direct control to all variables and classes and such. My application would have to track its own state, (thus possibly getting more troublesome because it would get out of sync with the actual state, which would be a pain if you depended on it) and implement updates based on that. On the other hand, something like:

myVar=10
gui.SetObject("progressbar", "progress", 10)

or

myVar=True
gui.SetObject("toggle", "state", myVar)

would be just as simple as anything else, since the gui needs to be updated manually no matter what route you take.

Right now, my primary 'problem' of sorts is a lack of people who will help me out with images while I test (I doodled in Photoshop a bit so far but it's pretty ugly) and to figure out a way to make a proverbial buttonclick in my interface cause an action within MUSHclient. But I'm happily coding away so far. :)

Posted by

Onoitsu2 USA (248 posts)

Date

Reply #3 on Tue 29 Jan 2008 10:32 AM (UTC)

Amended on Tue 29 Jan 2008 10:34 AM (UTC) by Onoitsu2

Message

I meant for the progress bars to change entire color at certain settable percentages, so from Green being good, yellow being in trouble, and red being near dead, and possibly blue as the good for mana, and so on, as long as each color is settable in SOME method, as well as the change percent.

As for the button click thing, I have accomplished this in AutoIt, by having a script look at all the open worlds, and individually grab the title of each one, present them in a selectable list, and then from then on out it will send things to the input area via its handle obtained from the handle of the world itself.

It is kinda messy, works 99% of the time, occasionally you will have to close and reopen the world file and then run my program (compiled script)

I even implemented a graphical tick timer (progress bar that ticks down) and the 8 buttons themselves are settable for the actions they should send to the server (via input box submission) via UDP sends, as well as the names presented on each button, so you can have different triggers automatically update a certain button.

It is VERY limited, and un-user friendly BUT what can I say for something that's source is 14.9kb and "dirty compiled" (compiled without UPX compression, nor special icon, nor "version info") is 205kb

I can send you a copy if you'd like to look at the methods I used.

-Onoitsu2

Posted by

Worstje Netherlands (899 posts)

Date

Reply #4 on Tue 29 Jan 2008 11:35 AM (UTC)

Amended on Tue 29 Jan 2008 11:48 AM (UTC) by Worstje

Message

Nah, I'm going for clean (is that possible?) programming techniques. Right now, I'm battling to try and find a way to expose my world object to my application. I managed partially so far, but it is a pain:

1) I need to use Lua, since it is the only environment I am garantueed on having. Except that it needs luacom.dll to be installed, which is something I could live with as a part of the installing procedure. However, Lua doesn't work within the windows scripting host, so the world object isn't actually an OLEVariant, so I'm kind of unsuccesful in passing or calling anything. Psshh, Nick. How about a Lua specific function in the world object that goes world.ObtainCOMObject()? :D
2) I can use VBScript is worst comes to worst, but franky I hate that language and it would probably diminish my eagerness to work on this project to zero.
3) Python is succesful so far, although I'm kind of confused why it isn't releasing the com object when I unload my plugin (it would when I was trying in the interpreter). Then I went to look for a OnPluginUninstall but I couldn't find any - am I getting blind? :D

Anyhow, I rant and digress. Opinions and suggestions please!

Posted by

Onoitsu2 USA (248 posts)

Date

Reply #5 on Tue 29 Jan 2008 01:04 PM (UTC)

Message

I think I am going to have to look at getting the source code, and looking up some MFC things relating to COM in my ebook "Sams - MFC Programming with Visual C++ 6 Unleashed (1999)"

I stumbled across a section that had to do with exposing certain COM objects as well as making a Query interface, which would be the way to go about doing things, Query the Mushclient object for worlds, and then from there you can have the program send back the number of worlds open, and possibly the names of them, your program can present the list of the names, and then call another COM method that retrieves the COM Reference of selected world from the "array" via the "index".

Then from there EVERYTHING in COM should work just fine since your program will have the reference. As well as the nice thing about doing it in this way is that NO PLUGIN WILL BE NEEDED!!! YAY, so even the most basic of computer users can simply run a second executable whenever they want these features.

-Onoitsu2

Posted by

Worstje Netherlands (899 posts)

Date

Reply #6 on Tue 29 Jan 2008 01:34 PM (UTC)

Amended on Tue 29 Jan 2008 01:42 PM (UTC) by Worstje

Message

I've already looked up that stuff. MUSHclient does not register its objects for external use, so I can't just 'query' it. There's no CLSID anywhere on my system for a MUSHclient.World. It doesn't bother me much, since I want to make my system work based on different worlds anyhow, so a scripting interface is actually a pre. It's just a pain that MUSHclients Lua implementation does not deal in COM Objects at all, so I have nothing to pass to my own program.

Okay, explanation for the seperate worlds thing: it is already skinnable. I want to make the interface be potentially different per world, so that the interface gives a clear hint as to what character you are on. (and lack an interface when there is no interface defined for another world :))

Posted by

Isthiriel (113 posts)

Date

Reply #7 on Tue 29 Jan 2008 03:39 PM (UTC)

Message

You could use something like xml-rpc or corba or any of the other rpc apis.

Or, you could mix one of your own. Have the external app send the lua code it wants executed via UDP, have MUSHClient poll the socket via a timer and execute the code it receives via loadstring and send the result back as some kind of serialized object.

It's a kluge, and it'll be relatively slow (rtt will depend on the timer resolution) but it is simple and it works.

Posted by

Worstje Netherlands (899 posts)

Date

Reply #8 on Tue 29 Jan 2008 04:40 PM (UTC)

Message

Speed is one of the things I intend to maintain, given the fact that MUSHclient is lightning fast and keeping that impression is a Good Thing (tm). I used UDPSend() and such before, and it was too slow for my likes. COM on the other hand is fast and has a decent implementation, and can be implemented relatively easy in scripting languages. Even Lua supports it with Luacom. I jsut need to find a fix for the non-ole world-object, but I'll figure something out eventually. :)

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #9 on Tue 29 Jan 2008 10:00 PM (UTC)

Message

If there is ANY possible chance of having some sort of extra toolkit put in place that does not require COM, that would be absolutely wonderful. I know that MUSHclient is really only 'supposed' to run on Windows computers, but there are several people out there like me running it through WINE. Although COM functionality has made pretty big leaps recently, if I remember right, I did not like COM while running Windows boxes anyway. Having a wxLua interface with the normal Lua scripting would be the idea solution, although that may take enough prodding of enough people that I am not keeping my hopes up for this.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Worstje Netherlands (899 posts)

Date

Reply #10 on Tue 29 Jan 2008 10:58 PM (UTC)

Message

Well, the reason I want/need to use COM has is actually divided into several reasons...

1) There are no worries about the application being running or whatever. It takes care of the starting of my application and closing it down once MUSH closes - it's fully transparent. Not using it involves a shitload of mutex openings, closings and re-checkings which are considerably slower. I tried this method before.
2) It allows my application to directly interact with MUSHclient - just pass the world object to it and it will make clickable buttons with a special command to send a reality.
3) It is more efficient data-transferage wise. I wrote a tool to display little maps that came straight from the telnet code once, but the throughput to get a mere 10 lines out to my destination applications made me plain sad. (Yes, the bottleneck was UDPSend since I had no problems updating that window semi-real time through manual inputting.) And since I intend to use the same control (maybe update it a bit tho) that speed is still important.
4) I haven't got any hands-on experience with COM and for me it is a good learning opportunity.

Now, of course, I could switch the stuff I have to wxPython or wxLua, but that's another new framework for me to learn. And frankly, I don't want to learn yet another framework which is bound to a single interpreter instance at a time. Hell, I'm even looking for a certain amount of flexibility that I don't think wxWhatever could give me.

I am aware there are other methods of RPC that are worth taking a look at, but I have to be a bit of a realist: COM does what I need it to do, it is a worthwhile learning experience for myself and it is a well-established form of communication. It's been around for over 10 years - I think it is time that Linux finally catches up on it if they insist to keep emulating windows programs (especially now that MS is giving out more data about the innards documentation). I have a few boxes with Linux myself btw, and while I don't use them as desktop replacements I do like what they have to offer. :)

Of course, if you have something that allows my application to talk to MUSH without a lot of extra fuss and without tons of slowdown, I'm willing to consider it. I'm using Delphi to develop my program.

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #11 on Wed 30 Jan 2008 02:40 AM (UTC)

Message

First off, I would like to make a polite, good natured jab at talking about emulation, since Wine really is not an emulator. It even says so in the name: Wine Is Not an Emulator. It is just an implementation of the Windows API for Linux, which is why it is so much faster than emulation. Granted, the Wine people are insane enough to try and have compatibility with EVERY version of Windows for some obscure reason...

And yes, I do agree that COM needs to be supported, which is why I am glad about the leaps and bounds that Wine has made in this area recently. However, I mentioned that I was not expecting you to give up on using COM. I just never had any luck personally in getting anything with COM working well, and I severely dislike MS' use of "COM" and "NET" naming, since it makes searching for any information a pain in the neck. But it has been a while since I have tried anything with COM, so I am willing to test compatibility.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #12 on Wed 30 Jan 2008 04:12 AM (UTC)

Message

Quote:

MUSHclient does not register its objects for external use ...

It should do, and in any case comes with a mushclient.tlb file which is its type library.

- Nick Gammon

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

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #13 on Wed 30 Jan 2008 04:18 AM (UTC)

Message

Quote:

I used UDPSend() and such before, and it was too slow for my likes.

I don't know why that is. Sending a UDP packet to localhost should be lightning fast.

You know what would be fun? Use UDP to send data to another PC on the local network, and have a HUGE screenful of status information (put 2 screens side by side). Space wouldn't be a limitation then, and you could have big buttons and status bars.

The custom status bar window http://www.gammon.com.au/forum/?id=4951 could almost be used for that purpose. In any case the source is available if you want to play with it.

- Nick Gammon

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

Posted by

Onoitsu2 USA (248 posts)

Date

Reply #14 on Wed 30 Jan 2008 09:38 AM (UTC)

Message

Mushclient DOES in fact register itself, cause I was working on a VB app a while back, that tried to instance a NEW Mushclient object, it worked only half-way, as it would think of it as an embedded one, only it would not allow you to load settings from an existing world, nor name it or anything that kinda makes it useful. In fact I could not even toggle scripting on in said world.

If someone were to add a query method, and then a retrieve method, things COULD be done without having to use a plugin, nor LuaCOM, nor VB for the plugin.

I am still reading up on it, and I might be able to throw together some snippets of code that might assist in the cause.

-Onoitsu2

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.

51,825 views.

This is page 1, subject is 2 pages long: 1 2

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

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )