GMCP Data open to non-plugins

From what I can tell the only things that have been addressed for GMCP-type data is a plugin that broadcasts the data and is only available to other plugins.

Has any strides been made to push GMCP data to the main Lua environment or made so that I can run a function from inside my main Lua script that will pickup those broadcasts?

It would be nice to see GMCP/ATCP data capture and storage built into the client since it is catching on or the ability for the main environment (non-plugin) to be able to receive broadcasts and/or easily pass tables.

The main issue is that plugins are more privileged than the main world. That is, plugins have more hooks available (OnPluginSubnegotiation being the key one here). It's also hard to reliably pass the data from a plugin to the world, as CallPlugin can't call into the world's script space.

What you posted is exactly what I've found out. I've tried to hook a specialty plugin back into the main environment but its troubled and requires things I really hate doing. Not to mention its messy and doesn't seem to be reliable.

That's why I'd like to see something done on the client side to deal with GMCP or ATCP if GMCP isn't available on a particular mud.

Why can't broadcast and other plugin functionalities be setup in the main environment? Is the a limitation of the framework or just how it was designed and could be easily changed?

The design evolved over the years, and plugins were done in a more modular way. I suppose it could be done, anything is possible after all, but why do you really need it? Plugins are much more useful if you have multiple worlds (eg. multiple characters even, on the same MUD) because you can share them and not have to make a minor fix to every world if you find a bug.

There are ways of communicating with the main script space easily enough. For example with GMCP if you change rooms the GMCP/ATCP plugin could just do something like (in the plugin):



Then in the main world you make an alias that matches:



That way you find if you have changed rooms, and what the new room is. Ditto for other messages.

That's true but Achaea is sending a great deal of information through GMCP every prompt, look, inventory, etc. I dislike serializing and then recreating the tables (and tables within tables) of information every single time.

That would be multiple aliases executed per prompt (and if in combat I can see 1-5 prompts+ during raids). I've never tested if MUSH can handle that but I think it's a bit excessive.

I hate using plugins only because when I convert things to plugin format I end up having to change so much. I've been thinking about pushing my entire system to a plugin but it just NEVER works out right in regards to variables and even some functions I think I had issues with in the past.

When I converted a large amount of triggers for something called a wholist to plugin it took forever for me to make it work right in plugin form.

That shouldn't happen. Can you describe in detail what problems you had?

It was many versions ago when I first started using MUSH (multiple years ago) and I just have stayed away from it since then.

Why not assign whatever you want to have in the main Lua environment to a variable in the plugin and then call GetPluginVariable() from the script file or trigger etc? Unless I'm just a noob and that function can only be used in a plugin :P

The issue is how to notify the main script environment that there's new data to get.

You can call GetPluginVariable from anywhere.

The plugin that detects the GMCP stuff could do a world.Execute, and use that to notify aliases in the main script that there is new data.

This might be a stupid question, but if I used the telnet plugin callbacks in a plugin that doesn't send it's information from OnPluginTelnetSubnegotiation outside the plugin it's in, do i even need to use PPI. Can i just assign it to a local variable in the plugin and have it completely self contained?

Personally, I'm also in favor of having the functionality of OnPluginTelnetRequest and OnPluginTelnetSubnegotiation as a client function in the main script space, so that they could be called in my script file or make them a premade hard-coded trigger that's available each time you create a new world file. MUSHclient already handles MCCP MXP and Pueblo in a behind the scenes manner. Why not ATCP and GMCP the same way?

It seems kinda stupid when I spend more time trying to figure out how to make a new idea work than actually playing the game that it's for when I want certain information to come from GMCP instead of from triggers or defining the variables manually myself.

Couldn't it be as simple as this?

health, maxhealth, mana, maxmana, endurance, maxendurance, willpower, maxwillpower, levelpercent = GetGMCPInfo ("Char.Vitals")

or

ash, bayberry, bellwort, bloodroot, cohosh, echinacea, elm, ginseng, goldenseal, hawthorn, kelp, kola, lobelia, moss, myrrh, pear, sileris, skullcap, valerian = GetGMCPInfo ("IRE.Rift")

and have a little check box for whether you want MUSHclient to tell the server to send GMCP data or not.

My system is just for my personal use, so why should i need to make a plugin to do all that?

Lets spend more time gaming and less time messing with code, seriously..

One more thing. Twisol, in the GMCP plugin you made codes.IAC_DO_GMCP is initialized but I don't see it actually used anywhere in the plugin. Is it there and i missed it, or is that index unnecessary?

You can, and there's nothing inherently wrong with that. The reason we have reusable protocol plugins is so that you don't have to handle the protocol-level details. Also, there can be issues with multiple plugins attempting to negotiate with the server, so it's better to have a single plugin do the talking.

The GMCP plugin I posted is a self-contained module that makes its data accessible to other plugins. It needs PPI or some other mechanism to do that. For example, the ATCP plugin I originally inherited used BroadcastPlugin() and the OnPluginBroadcast hook to notify plugins about new data, but it wasn't especially flexible. And neither approach can reliably call back to the world script-space.


From a design perspective, it's better to make things modular. Certainly the interfaces we have now aren't the greatest, but MUSHclient is over 15 years old at this point. It's pretty hard to tell what you're going to need 15 years down the road.

From a practical perspective, the codebase is now old and crufty, and it's a testament to Nick's skill that the client is one of the best I've used. It might not be worthwhile to add another protocol in a part of the code that hasn't been touched in a long time.

That said, I'm in favor of giving the world space more of the plugin-only callbacks. I also wish we could use CallPlugin to call into the world, since that's the only reason I remember why you can't use PPI from the world to talk to the GMCP plugin.



Not really. Imagine if you just want the valerian? And how does the computer know what order to return the numerous (potentially optional) fields in? It'd be better to return a table and let you pick what fields you want, like the GMCP plugin does now.


That's a remnant from before OnPluginTelnetRequest, when we had to hijack OnPluginPacketReceived and send our own IAC DO GMCP request. It's not necessary, no.

With a fairly simple GMCP plugin running in the background getting information as the MUD sends it, it should be pretty trivial to make an interface function in the main world script space that gets what you want (by doing a GetPluginVariable call) in much the way you describe it.

Thank you, Twisol. It is indeed hard to predict when you are starting to develop a client (primarily for your own use initially) what might be required in 15 years, and indeed to know about the existence of languages, such as Lua, which hadn't been written at the time.

My primary goal these days is, as far as possible, to preserve backwards compatibility in preference to adding some "cool new feature". I've been through too many computer or operating system upgrades, where things I have spent good money on, or a lot of time on, now just don't work.

The day will probably come (IPV6?) when the client staggers to its grave. And with the benefit of hindsight, someone will write a much better one. And that is as it should be, we should all learn from the experiences of others.

I hope IPv6 adoption isn't the thing that does it, because that's...like...already happening.

I don't really see MUDs doing that for a while. And in any event IRE and the other hosts would likely give the MUD developers ample warning before such a drastic change.

And on the scripting side of things. I think my problem is that I don't fully understand Lua syntax..the more complex interactions, I mean.

I guess I could print the results of a chunk if I can't visualize what it's result would be, such as when using string.gsub for example. Although the relevant sections of the Lua 5.1 reference manual helps some, I don't feel confident using it myself.

Can you give an example snippet of some code you have questions about? (A new topic might be best though.)

I'm posting from my phone lol I'll start a new thread from my laptop when I have the code in front of me.

I looked into IPV6 a while back. It seems I have to spend $1000 to get a version of the compiler that supports it. You might imagine that I don't have a strong incentive to do that, for software that is freeware.

However I think that IPV4 support will be around for a while. Considering that modern routers use NAT to expand IP address ranges, I imagine you will find that routers in future will take IPV6 addresses "in the wild" and convert them into IPV4 addresses for home use.

So Nick, if we were to donate enough money, slowly but surely, to buy that shiny new compiler would we see a MUSHclient version 2? And just for the record where do you get such a compiler? :)

(2007) http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=8132


http://www.microsoft.com/visualstudio/en-us

Which version of visual studio is that?

Visual Studio 2010, the most recent.

Don't assume it's a piece of cake to migrate MUSHclient, though. I have VS2008, and there were a number of issues that VC6 allows but VS2008 complains about. In the long run, it might be better to start fresh than to migrate a storied codebase that's heavily dependent on its current environment.

([EDIT]: Extremely belated, and probably unnecessary, fix: I use VS2005, not VS2008.)

Okay so only the 2010 version of visual studio can compile IPv6?

Also which would you need for your purposes, Nick, professional, premium, ultimate?

I would only need the minimal version that supports MFC.

However I wouldn't get too excited right now. I haven't had any reports about people not being able to use IPV6 on MUSHclient. As I said, in all likelihood routers will have fallback positions in them to interface IPV4 programs for quite a while yet.

Still a new client like the one you described in 2007 would be welcomed. I have access to visual studio, don't remember which version though and I've been wanting to learn C++. I'll help anyway I can.. Twisol?

I'm curious; what in particular would you want to see in a new client, that MUSHclient doesn't already have? I'm working on my own browser-based client (albeit extremely slowly due to other commitments), so I'm interested in hearing what people want out of their MUDding experience.

Although you didn't ask me, I'd still like to answer:

1. Customisable input boxes - so for example, you could create a login screen where people click on the 'name' box and enter their name, then the 'password' box and enter their password (with a private mode whereby characters are displayed as stars or dots). Or an OLC where you fill in various fields by clicking on the appropriate input box.

2. A fixed-width Unicode font offered as the default, which can be checked through CHARSET without also needing to activate the UTF-8 checkbox.

3. Additional MXP features, such as <FONT> and <IMAGE>.

4. Some sort of script auto-installer, to make the entry barrier for newbies as low as possible.

5. Support for drawing animated GIF files, not just PNG and BMP.

6. A simplified interface that isn't as scary for newbies, with a toggle to switch to the more configurable "advanced" mode. It makes me sad when players refuse to use MUSHclient because they think it's too complex.

7. Support for character mode.

Isn't this possible in MUSHclient?

No, although it's been discussed: http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=11320

Definitely something I want too. I think most things like this will be produced by plugins and widgets, but the client should support their existence.


I'm not aware of any fixed-width fonts that support a large array of Unicode characters, but if you know of any I'd be glad to investigate!


I do plan on supporting character mode at some point. Are you aware of any MUDs that utilize character mode right now? It would be helpful for testing against whenever I get around to it.


With the introduction of luasocket, it's almost possible. I think, but am not sure, that you'd need LuaFileSystem in order to do it properly, and likely luazip and/or gzio to unpackage downloaded bundles.

I use Fixedsys Excelsior: http://www.fixedsysexcelsior.com

The only problem is its bold characters are a bit wider than the normal characters, and the bright ASCII colours use the bold character set. However you can work around it in MUSHclient by sticking exclusively to xterm 256 colors.


Not off the top of my head, although I believe some may use it for Windows Telnet, or in combination with VT100 codes to create in-game editors.

However in a MUSHclient context, it would be quite nice if you could allow people to navigate a 3D GUI using the keyboard - in theory you could even remove the input box entirely, or perhaps just allow people to open it for chatting. Hotkeys already work for some of the keys, but not all of them.