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

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  MXP Frames Tag?
MXP Frames Tag?

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

Posted by Tiopon   USA  (71 posts)  [Biography] bio
Date Fri 01 Dec 2006 04:26 PM (UTC)
Message
I know (from scanning the forums) that the MXP Frames tag isn't supported by MUSHclient. Is this something that might eventually be added, especially now that zMud is wandering off the scene to be replaced with their new client. I've registered both MUSHclient and zMud, but heavily prefer MUSHclient because of its speed and general system, it would just be nice to be able to actually get mud-controlled additionally loaded windows in it as well. As I'm the one working on the coding now, if there's a workaround that can do this in a way that actually complies to some sort of standards, I'll implement that instead, but the whole MXP thing is sort of new to me. Thanks.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #1 on Fri 01 Dec 2006 05:44 PM (UTC)
Message
Well. I haven't "yet" tried it, but in theory there is nothing preventing the use of the wxLua library being used to create true windows, with Mushclient as the master, and scripting all the needed stuff to make them work any way you want. The only big issue is that currently such a window might create serious lag if its own code isn't threaded correctly (i.e. coprocessed or what ever it was called). Something like a icon bar would be fairly trivial, something like a scrolling text window... I am not so sure about. But, the fact is no one has tried it. Everyone has instead relied on more complicated, less client specific, external application to handle all of it, which, while it works, isn't as flexible, since each application has to be designed to a specific task, not re-scripted to what ever you want to use it for.

The only real alternative would be quite silly. Design your own application that just provides a basic window framework, such as Mushclient doesn't provide directly itself, then tack on Lua, wxLua, wxWidgets, LuaCOM and what ever else is needed, to give the user a way to "design" what they want in it. But, that is doing the same bloody thing that you should be able to do with Mushclient already, for want of anyone testing to see if it will work in the first place.

In theory, the way to create a window for wxLua is:

frame = wx.frame(World.GetFrame, wx.wxID_ANY, "wxLua")

Its redesigning the rest to work with Mushclient that is an issue. As an example:

http://wxlua.sourceforge.net/wxLua/samples/editor.wx.lua

is a sample file for an editor in Lua that uses wxLua. With modifications it is probably possible to make it work "with" Mushclient as a mail editor or what ever, but... the key factor is making sure that "wx.wxNULL" is replaced with "World.GetFrame", since the first tells it that you are running a stand alone application with a "top level" window. If you try to create a top level window inside a script running in another top level, such as Mushclient's own frame, it will, at best, crash both the script and client. Otherwise, the only major issues are to add some extra toolbar items, menus, or whatever, so that you can "send" the contents to through Mushclient, or if using this as a text window, you might strip out all the menus, status bars, etc., adjust it to use a color supporting text field type and add code to let you send stuff to it from Mushclient instead.

The basic framework for a simple window should be fairly trivial. Been too busy with other stuff recently to fiddle with it though, and the biggest issue, due to the way these people developed wxWidgets and wxLua, is just getting all the damn .dlls you need in the right places for everything to work right. Straight installs rely on the old DOS autoexec.bat at startup to set "PATH". If that isn't set, manually, the libraries don't know where to find each other. This is why Lua5.dll must be in the Mushclient folder to work, though placing it in Windows/System would probably solve the problem too. With wxLua and wxWidgets, you are looking at them scattered through 2-3 different places, with no registry entry to find them, and no copies any place like Windows/System, where the OS can find them for you... Very annoying. Though, I think wxPython was even worse... lol
[Go to top] top
Posted by Tiopon   USA  (71 posts)  [Biography] bio
Date Reply #2 on Fri 01 Dec 2006 06:11 PM (UTC)
Message
The issue with this is that with the zMud MXP system, the mud itself is in control of the window. What I'm trying to do mostly is to make this work:
http://www.rafermand.com/fear/tiles/

While the whole actual images piece would just be a bonus, what it's basically doing is loading its wilderness map into a separate window, with or without additional client-side images. My goal is to not have messy client-side hacks to make it work, and to just have it working from the server. I've seen similar systems (as I'm sure most others have) with custom clients or addins... but I'd prefer to reduce mess/bloat/random junk if possible, hence the question about a) future MUSHclient supporting of this, or b) a server-side way to make this work with MUSHclient and other clients that might support MXP but not the <frames> tag. Thanks for the idea though.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #3 on Fri 01 Dec 2006 06:45 PM (UTC)
Message
Quote:
My goal is to not have messy client-side hacks to make it work, and to just have it working from the server.
This is something of an odd statement, because no matter how the server communicates to the client that it should create extra windows, the client needs to implement this. The server doesn't create and destroy the windows, it just tells the client when it should create/destroy the windows.

Quote:
The only big issue is that currently such a window might create serious lag if its own code isn't threaded correctly
I'm not sure of this. The basic idea is that you should minimize the computation involved in your GUI thread. If you do CPU-intensive computation, you should do it in a different thread, because as long as the GUI thread is busy the GUI won't be updated.
But keep in mind that if all you're doing with these separate windows is displaying their contents, then you're not doing much CPU intensive stuff beyond what you have to do anyhow. So I'm not sure if this is a big issue, if, again, all you're doing is displaying the contents of the window (or clicking on it and whatever other normal things you'd be doing).
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Tiopon   USA  (71 posts)  [Biography] bio
Date Reply #4 on Fri 01 Dec 2006 07:12 PM (UTC)
Message
What I meant wasn't that I wasn't trying to have the client be able to handle it. Obviously if the client can't handle what the server is telling it to do, the server's extra code is pretty useless. What I'm trying to do though is make that an unmodified, out of the box version of MUSHclient will be able to handle this somehow, without just having a helpfile that I point people towards and saying: copy-paste this into your scripting section. The issue with that is that then I start to get into the regions where I spend more time trying to come up with client-type hacks than just saying, this is the way the standards are, you can experience it or not depending on your client, but I suggest you stop using GMud (about half my players still like GMud, and I have a straight telnet holdout too) and start using a client with MXP and MCCP. If I make it difficult for them, I'll probably be the only person who would ever experience the advantages, and my goal is to make things easy on the player side at least. Sorry if I'm rambling, I've got the flu and it's scrambling my thinking a bit.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #5 on Fri 01 Dec 2006 07:22 PM (UTC)
Message
Oh, right. Well, from a functional point of view, if there exists a MUSHclient plugin that implements the "standard" (see footnote [1]) correctly, then other than the inconvenience of having to stick it in, it's really the same thing. I think I remember Nick giving various reasons why it's not all that easy to implement the frame standard, but he's best placed to explain that.

Footnote [1]: the MXP standards are somewhat fuzzy. Zugg has unfortunately taken liberties in places where it was convenient for him to do so (especially in the handling of escaped vs. unescaped < > symbols), making it somewhat unclear what the "correct" behavior is. Nick defines correct behavior as that which follows the standard (which seems to be the correct thing, IMO) whereas a fair number of users consider "correct" to be whatever zMUD does. (Usually, these people are the ones who are transitioning from zMUD to MUSHclient.)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Tiopon   USA  (71 posts)  [Biography] bio
Date Reply #6 on Fri 01 Dec 2006 07:29 PM (UTC)
Message
True... I was just hoping to be able to do this by a 'standard' (using the non zMud defined) server-side way. And by this, I don't mean that the client is irrelevant, but that it supports more than just zMud. If that means scrapping the 'frames' tag and doing something else, great. Just so it's simple enough so I can actually convince some of my players that it's worth the effort. :)
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #7 on Fri 01 Dec 2006 07:34 PM (UTC)
Message
I don't understand the issue. If you want to pick a 'standard', you can go ahead and use MXP frames, it's just that very few clients actually implement it. If MUSHclient were to have a plugin that implements the standard, then you have one more client that implements the standard, never mind that it's through a plugin.

If you want to design a completely new standard that uses additional client-side windows, no client will support it out of the box.

I think your best bet is to either use MXP frames -- knowing how much that will limit your client audience -- or find another way of implementing your idea.

Trust me, I am also very frustrated by the problem of wanting to display more and richer information than the normal text medium can display. I find myself wanting to do things that would only make sense in a [i]slightly[/i] augmented text client. I don't want to go to a graphical client; that's overkill and undesirable for other reasons. But anyhow, trust me, I share the frustration. :-)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Tiopon   USA  (71 posts)  [Biography] bio
Date Reply #8 on Fri 01 Dec 2006 07:41 PM (UTC)
Message
Heh. I was hoping for a workaround, either a different MXP tag that will do something similar, or a way to show the same information inline without using the external window. I suppose that might work... I'll need to look into that... hmm... Anyways, I'm not trying to recreate the wheel, if possible, I'm just trying to find out what wheels are already out there, hopefully with as many standard connectors as possible. :) If that makes any sense... my analogies are somewhat wonky atm.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #9 on Fri 01 Dec 2006 07:53 PM (UTC)
Message
Unfortunately I think there aren't any universally adopted standards for controlling extra windows. There is one option, which is to use the telnet protocol's cursor placement to "draw" a fake window at the top of the screen, but some clients -- most notably MUSHclient -- do not implement the telnet cursor movement commands. IIRC, the Forgotten Kingdoms MUD uses this to draw a little 'map' thingie at the top of the screen.

MXP frames are a "standard" in the sense that there's a document explaining how they are supposed to work, but very, very few clients actually implement the standard.

I'm not aware of any other way to get "windows" that can be supported universally, without using a client that specifically supports them. It's unfortunate but it's the way it is.

I think, yes, that the best way is to perhaps display the maps inline, whenever the player requests one. Or, give a link so that the player can open the map in another window. With transparency being added in MUSHclient's next version, that should be a quite viable solution, for MUSHclient at least.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #10 on Sat 02 Dec 2006 05:13 AM (UTC)
Message
Quote:

What I'm trying to do though is make that an unmodified, out of the box version of MUSHclient will be able to handle this somehow, without just having a helpfile that I point people towards and saying: copy-paste this into your scripting section.


Before I get into the meat of the issue here, which is somehow making frames work, the whole idea of MUSHclient plugins is that you simply say "install the plugin" and that should be it (effectively, just browsing for a file), which doesn't involve cutting, pasting, and a whole heap of complicated stuff.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #11 on Sat 02 Dec 2006 05:16 AM (UTC)
Message
Something that might help, is this:

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

This is an independent program, that can display an extra window of information (you could have more than one for extra windows), or the general idea could be used to implement an extra set of frames.

I'm not absolutely sure without looking at the code is what happens to the MXP frames tag. I suspect it can be picked up by the MXP callbacks (in a plugin).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #12 on Sat 02 Dec 2006 05:31 PM (UTC)
Message
In the end, I think figuring out "if" and "how" to impliment something like a wxlua based plugin is the best solution. It takes away two issues, 1) Mushclient doesn't have to impliment "any" of the windows/buttons/etc. to make it work and 2) its a lot easier to make a new copy of a plugin, rename it and change the code to handle different information than to impliment an "external" application to do it. Since plugins already recieve all the callbacks and it has direct access to world commands, its comparitively trivial. The only real issue is that, as of now, we only have lua5.dll and maybe luacom??, and that is it with the client. To support my idea you need the dlls for wxwidgets and wxlua installed as well. Neither currently come "with" the client and since the client itself doesn't impliment any of the basic interfaces needed...

That is the problem in a nutshell. Either the client has to provide the means to produce those sorts of windows, you need a library that does, *or* you have to design a custom application to handle it. The only means to make such a thing "universal" though, which I can think of, would be to impliment a program to act as a proxy and do the windows. I.e., instead of connecting like:

Mushclient --> mymud.org:5000

you connect like:

Mushclient --> localhost:5000 --> mymud.org:5000

Where the localhost address is "listened" to by a program whose only job is to watch for <frame> tags. If found, it strips out the MXP for them, impliments the effect, then passes the remains on to the client. If nothing is seen, it just passes the information directly to the client. It should work, but it just adds yet another layer of complications to the whole thing.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #13 on Sat 02 Dec 2006 05:50 PM (UTC)
Message
Note: I have looked into the wxlua a bit more and... for some screwball reason, instead of making it a library you add in "through" the script, it has to be bound to the application that impliments the binding for Lua as well. I.e., its unusable unless Nick adds it as a permanent extention to the client, unless I am reading something wrong...
[Go to top] top
Posted by Tiopon   USA  (71 posts)  [Biography] bio
Date Reply #14 on Mon 04 Dec 2006 03:12 PM (UTC)
Message
Yeah... I expect that because of the way things work, there's going to be no real way to do this without cutting out the normal MXP frames bit completely, as the suggestion that Nick mentioned would work, but it's completely client-side, and wouldn't really work well (as I understand it) being run on the server side, what with everyone having firewalls and private IPs and the like...

So that leaves the next question... is there a good way, on the server side, to detect what the client is giving as its terminal type? Mushclient uses 'mushclient' by default, and zMud must do something similar on its end. If I can detect this, I can use it to have the server decide whether to run the <frames> code, with its capability for using client-side images, or using the integrated code, with MXP maps but no other fun coolness.
[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.

37,566 views.

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

Go to topic:           Search the forum

[Go to top] top

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.

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

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

[Best viewed with any browser - 2K]    [Hosted at HostDash]