Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Suggestions ➜ MCP Support
MCP Support

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

Posted by Gedrean   USA  (12 posts)  Bio
Date Wed 30 Jul 2003 03:49 PM (UTC)
Message
Given that MXP and Pueblo were the formats selected for support for an out-band message system, I don't think I'll get very far with this but I'd like to try.

I'd like to see MCP support in MUSHclient. The MCP protocol spec can be found at:
http://www.moo.mud.org/mcp/

However, since I probably won't get anywhere with just requesting I'd like to ask a favor. If Nick would let me have a shot at BUILDING the MCP support, I would greatly appreciate it. I'd think that then plugins could be written for MUSHclient for each MCP package. This keeps the overall size of MUSHclient at a minimal but allows the greatest expansion. If a particular MUSH has a particular package, use a simple script language to write the implementation for it. It could even be tied to the MXP, for example if someone writes an MCP package to tell the user to play one of a specific set of sounds, the MCP package could tell the MCP system to tell the MXP system to play the sound.

The simpleedit package is obviously one of the most important, the idea being to open a window to edit things sent back and forth from the server, ie messageboard messages and code and mail.

It's worth a try. Nick, you said your system runs on MFC?
I'm not special! I just code my brains out for you!
Top
Posted by Meerclar   USA  (733 posts)  Bio
Date Reply #1 on Wed 30 Jul 2003 08:01 PM (UTC)
Message
Actually, there is already a plugin that is bundled with versions 3.32 (I think) and beyond that supports MCP. Granted, it only allows for a single sound to play at once but it seems to handle 99% of all sound samples. If it's not part of your MC version, it's available here on the plugins page.
Meerclar - Lord of Cats
Coder, Builder, and Tormenter of Mortals
Stormbringer: Rebirth
storm-bringer.org:4500
www.storm-bringer.org
Top
Posted by Orange   United Kingdom  (25 posts)  Bio
Date Reply #2 on Wed 30 Jul 2003 08:22 PM (UTC)
Message
MCP != MSP.

See <http://www.moo.mud.org/mcp/>
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #3 on Wed 30 Jul 2003 10:11 PM (UTC)
Message
Hmm.. Ok.. This is just another way to talk to the client, in this case if you where a wizard and wanted to edit a room, then the server could do something like:

1. Tell the client to open a notepad window.
2. Copy the text sent in the packet into this window.

Then after you edited it you could 'in theory' have the client send a packet back to the mud that contained the changes and saved them.

The only issue I have with this is that it is only a wrapper, i.e. it provides a way to contain such commands to tell the client to do something, but each command has to be interpretted by the client to the best of its ability. If the client doesn't have a clue, for instance, how to play back a music sequence that used the mud developers own method to encode it, you are basically out of luck. Same with anything else you used it for. It simply wouldn't be practical to try to add some sort of support method for every goofy command set that evey mud might use.

This is the equivalent of coding an implementation of XML, but assuming that its someone elses job to provide support for basic HTML, CSS, PHP, ASP, Java, Buttons, Sound, Text boxes, etc. In other words you couldn't even show ordinary txt unless the 'client' knew how to handle the messages 'and' how to do it the way 'that specific mud' expected.

Now having covered the bad news... lol The good news is that mushclient is probably the best equipped client to deal with this. For simple stuff like showing text one needs only to have the plugin look for the messages to do things the client already can. Assuming that the specification correctly places each bit of this info in its own seperate packet, you can even capture the raw command, before it ever reaches triggers or other mushclient internals. However, since there is not specific standard in MCP for how to do any of these things, so each plugin would need to be 'catered' to the specific mud you played on.

This means that you can't just make 'one' plugin to support this and have every mud use that plugin. For practical reasons any commands over and above those 'specifically' provided in the spec, you would need a MyMud_MCP.xml, ThereMud_MCP.xml, ThoseOthersMud_MCP.xml, etc. One specific to the features and methods used by each mud that uses MCP. In this respect MXP is far less flexible, but also 100 times more stable and certain to work. The fact that you can make such a plugin for each world is the only thing that doesn't make the idea completely insane imho.

This also doesn't mean you won't need some sort of special COM apps for each special feature as well, since mushclient scripting can't 'run in the background' to handle complicated stuff that is not already built into the client. Downloads for example would just lag mushclient if down in such a plugin, but will completely hang it until completion. It may be worth trying to do, but since even some of the built in stuff like the edit thing in MCP for opening a window are not likely even entirely supportable in mushclient's current version. Other stuff 'may' be possible depending on what it is, like playing a sound, but as I said, such things are bound to require a case by case design, not one simple and straight forward plugin.

Its worth a try, just to see how useful it really is, but I am glad it is you that will be working on it Gedrean. ;) lol
Top
Posted by Nick Gammon   Australia  (23,166 posts)  Bio   Forum Administrator
Date Reply #4 on Thu 31 Jul 2003 02:29 AM (UTC)
Message
OK, I've read all of the above and skimmed the MCP spec, and am trying to work out what the real object here is. What are we exactly trying to achieve?

One thing the spec mentions is the possibility of server-to-server or client-to-client communication. My general impression is it is a throwback to the days when you only had a single connection from your computer (eg. a dial-up connection to a bulletin board) and wanted to do more than one thing - in this case they are talking of "out of band" editors. For example, the spec says "It is expressed in 7-bit ASCII, permitting it to be carried over channels with restricted character sets." - surely this requirement is no longer necessary? To be added to MUSHclient, for instance, we are talking over the Internet which has as its primary carrier medium 8-bit characters.

It seems to me this "out of band" communication in the client is no longer required. For instance, an admin could easily set up two connections to a MUD (using MUSHclient, say) and use one for editing room descriptions, and another for chatting. Or, s/he could edit room descriptions offline and ftp them later or during a session. Or, they could telnet to the MUD server site and make changes there.

As for the peer-to-peer communication, this is offered by the chat system. The chat system has expansion in it, effectively duplicating a lot of what the MCP spec talks about (starting sessions, negotiating, out-of-band data and so on). I gave an example earlier of how players could use the chat system to effectively communicate with each other, including using user-defined message numbers, to work "out of band" of normal MUD communications.

The chat system does not let you "chat" to the server, probably because I did not expect the server to chat back, however you could conceivably add code to the server to let you make an out-of-band connection, on another port, for that purpose. MUSHclient will "chat" to anything that supports the chat protocol, so if you added the MudMaster or zChat protocol to a server, then you could "chat" to it with MUSHclient. Of course, chatting would require the messages to have a certain format, because there is no human at the server end responding to you.

One of the examples given in the MCP document - a help system - could now reasonably be implemented by a MUD simply giving a reference to its web page where help about the MUD could be found.

In fact, what I thought would be a nice idea for a future MUD server - and which I am looking at doing - would be to provide this "out of band" access by making it into a mini HTTP server. Thus, admins for example, or anyone really, could point their web browser to the HTTP port (eg. 4001) and the server would accept connections, and let them do things (eg. edit their description, change room descriptions, change settings) by the use of HTML forms. I already have a prototype of doing just that, which works fine. This gives you the advantage that you are not limiting people to using a particular client - anyone would have a web browser.

It would be easy enough to authenticate players too - as they connect the server would generate a random string, which can be used to connect to it (the same server) via its HTTP port. That string would expire when the player disconnected, so any player connecting and supplying that string (in the GET line, or in a cookie) could be reasonably supposed to be the correct player.

If I am missing the point let me know, but I think this alternate idea is more flexible, and easier to use. ;)
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #5 on Thu 31 Jul 2003 03:59 AM (UTC)
Message
Yeah Nick, I don't get it either. It sounds like a mud version of SHTTP. I.e. Providing a secure mean to send the client stuff that 'it' can't do anything with unless it already supports that feature and knows what it is being told to do. I can't imagine there being muds out there that actually still use 7-bit text in their communications, nor can I see any reason why an existing protocal like MXP can't support the same things through special entities. I don't really see the point, but like I said, if some muds actually use this silly design, then mushclient can be very easilly adapted to do it through a plugin for that mud. But since all it really does is provide a sort of secure container class for other commands, it would need to be specific to 'that' mud, since other might choose to use completely different commands.
Top
Posted by Gedrean   USA  (12 posts)  Bio
Date Reply #6 on Wed 06 Aug 2003 04:44 PM (UTC)
Message
Okay, maybe I wasn't too clear as to WHAT exactly MCP could be used for.

MXP and Pueblo are, for the most part, recognised by symbols getting sent back and forth. These are usually blipped out by the MUCK if the client doesn't support it. MCP is an extensible protocol which, at the beginning, negotiates between client and server as to which packages to support. Thus, Shadow, you wouldn't need extra plugins for each MUD, just extra plugins for which packages you want to support. The most common package currently available is the SimpleEdit one which I think is referenced in the spec or at LEAST in the page for it in the link given by Orange.

I understand Nick's comment that there doesn't seem to be much of a use for out-band messages anymore, However the 8-bit ASCII really doesn't add much improvement to the system. Granted, yes, you get more characters, but you don't get some of the better features.

Picture this:

You connect to your favorite MUSH, with an MCP enabled client with the SimpleEdit package. The MUSH, after sending a few MCP messages back and forth, decides that:
- You support MCP
- It supports SimpleEdit
- You support SimpleEdit
- USE SimpleEdit.

Therefore, every single time you're going to be editing text, either in your description, in board postings, in mail, in editing of room descriptions (Like in TinyMUCK with a builder bit), you get a nice little window that pops up and lets you work on it. Now, this may not seem like all that much useful, however I'd like to give you the following: Normally, when editing mail or board postings or whatever, you're not able to, say, respond to conversation around you. If the messages you send back and forth to the MUCK for the board posting is Out-Band, you can carry on your conversation, edit the posting in a separate window, etc. The same goes for sound.

Also, most online MUCKs MOOs MUSHs I've heard of do NOT permit multiple connections to the same character.

The other benefit of MCP is that if the player does not have a client that supports it, all they end up seeing is one ID string up at the top of the screen when connecting, and nothing more.

I mean I'm not saying you /have/ to implement MCP, but I'd love a chance to try at it. It seems to me that this protocol would have a LOT less overhead than the MXP & Pueblo stuff, and I think the MXP is a good system, it's an XML based formatting system as well as a way to identify certain things like what the room name is etc so you can do certain things with these areas, however that's all based on the actual code. And yes, the HTTP miniserver is also a good idea, but keep in mind that the server developers want to keep their systems rather smallsized, as MU*'s themselves tend to be very disk and memory heavy, so more stuff to work with would be a bit difficult. I do know for a fact that FurryMUCK, one of the larger MUCKs based off TinyMUCK, runs at something on the order of 800 MB in size with almost all of that entirely in Memory. Adding the HTTP server with the setup for each player as they're doing editing... WOW.

The HTTP server system, however, DOES seem like a good idea if it can be implemented correctly and with low overhead. Any ideas?

I think that MCP is a good idea and I'd really like to get a crack at trying to code out the system. If it looks like it'll be something I can't handle, no problem, I delete the code files and drop the issue. All I'd need for the code files would be... I think the language you're writing it in (I'm assuming C/C++) and maybe access to the code that starts parsing through the incoming text.

On the topic of MXP: Also, seeing an automapper system similar to zMud (Let's get some competition going here, eh, isn't that what Capitalism's all about?) would be amazing, but isn't quite necessary.
I'm not special! I just code my brains out for you!
Top
Posted by Nick Gammon   Australia  (23,166 posts)  Bio   Forum Administrator
Date Reply #7 on Wed 06 Aug 2003 08:27 PM (UTC)
Message
Quote:

Therefore, every single time you're going to be editing text, either in your description, in board postings, in mail, in editing of room descriptions (Like in TinyMUCK with a builder bit), you get a nice little window that pops up and lets you work on it.


You could use a variant of the "grab" plugin - see:

http://www.gammon.com.au/mushclient/plugins/

This particular one (designed for a MUSH) effectively gets the attribute sent to you ready for editing in the command window. However a minor change, and it could send it to a notepad window. This fits your description - you get a separate window, you can edit it whilst still doing other things, the editor is easy to use, you don't have multiple connections, it is quick, and when you are finished you just "send to MUD" (Shift+Ctrl+S). Pretty simple to use. :)

The overhead for a small inbuilt HTTP server should be pretty small. I looked at that a month back, and basically you would parse the incoming HTTP header - not too hard - and respond appropriately. It could all be done in memory if you kept the graphics to a minimum.

As for the automapper, see the other current thread on that topic. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #8 on Wed 06 Aug 2003 09:03 PM (UTC)
Message
Hmm. Ok. I think I see what you are getting at. However.. This causes another issue. You 'do' realize just how much of a pain in the backside trying to get plugins to talk to each other is?

If you use the more traditional method, then you have to fight with a calling method that only allows you this:

callplugin "ID","ScriptName","Data"

Which means that Data if it has more stuff than just a single string needs to be split and dissected into all its parts to work. You end up having to write a script into each plugin that functions as the front end to all the subs you really do want called, because you can't talk to any of them directly. Lets just put it this way, it is bound to be a lot more complicated than you give credit for.

Your main plugin would need to capture 'all' incoming lines, it would need to pass each such line to a list of plugin it knows are MCP, but unless you require that all such plugins be named like MCP_SimpleEdit, there is no way it can 'know' what plugins you may have added are actually MCP. Then it needs to deal with split lines due to possible line wrapping, it needs some way to only nuke parts of lines that contain MCP commands, which you currently can't be that specific about, or the user will see all of them, etc.

The other way to do it would be to use Python and the XML parser you can get for it and save all your 'plugins' as something found by the main plugin as .MCP files or something and autoloaded into its own internals. Something that has its own nightmare issues to get working right, not the least being how to deal with some fool using the same sub names or global variables as your own main plugin.

Not saying any of this is a bad idea, just pointing out some things to consider when deciding how you plan to make it all work. Though imho, the greatest complication is the general lack of a direct or effective means to provide your pop-up window for the editor.

I have tried some experiments with Python, but the only partially successful attempt crached Mushclient due to a resource conflict, I kind of tried to give the Python modual two 'primary' windows. This is a no-no. An application can only have one such window at a time or the OS doesn't know which one to send messages to. Since Mushclient 'is' Python's primary window, making a second one was not acceptable. However... It may be possible to have Python or even VScript, Java, etc. run a Python script that provides the window you need. There is even a trick that could let you dock it against Mushclient's main window (possibly with some tweaking, against a secondary window, but I haven't tried actually making one yet. Until we get a real edit window in Mushclient, preferably a floating one, the options for this sort of thing are bleak. :(

BTW Nick, What is the Class Name for Muschlient's main window, to make retrieving its handle easier? ;) lol
Top
Posted by Nick Gammon   Australia  (23,166 posts)  Bio   Forum Administrator
Date Reply #9 on Wed 06 Aug 2003 09:23 PM (UTC)

Amended on Wed 06 Aug 2003 09:25 PM (UTC) by Nick Gammon

Message
What I meant was, a plugin to do the offline editing, not a plugin to do MCP support. That would be nice and easy - to show the idea I have adapted the grab plugin to make an "edit" plugin, that does just that:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE muclient>
<!-- Saved on Thursday, August 7th 2003, 7:19 AM -->
<!-- MuClient version 3.42 -->

<!-- Plugin "Edit" generated by Plugin Wizard -->

<!--
The plugin generates a new password every time it is installed.
-->

<muclient>
<plugin
   name="Editor"
   author="Nick Gammon"
   id="95b8e918f472cf956d025af1"
   language="VBscript"
   purpose="Edits a MUSH attribute in the notepad"
   date_written="2003-08-07"
   requires="3.35"
   version="1.0"
   >
<description trim="y">
<![CDATA[
This lets you edit a MUSH attribute in a notepad window, and then send it back to the MUSH.

Usage
-----


edit item/attribute

  eg.  edit me/describe


The plugin will send:  @pemit/silent me=password &%2 %1=[get(%1/%2)]

It awaits a response, and then upon receipt places it into a notepad window for editing. Make your changes and press Shift+Ctrl+S.

Edit:help  <-- This help screen

]]>
</description>

</plugin>


<!--  Triggers  -->

<triggers>
  <trigger
   enabled="y"
   expand_variables="y"
   match="@password *"
   omit_from_output="y"
   name="attribute_editor"
   send_to="4"
   sequence="100"
  >
  <send>%1</send>
  </trigger>
</triggers>

<!--  Aliases  -->

<aliases>
  <alias
   match="edit */*"
   enabled="y"
   expand_variables="y"
  >
  <send>@@pemit/silent me=@password &amp;%2 %1=[get(%1/%2)]
</send>
  </alias>
</aliases>

<!--  Script  -->


<script>
<![CDATA[
Sub OnPluginInstall
  world.setvariable "password", world.getuniqueid
End Sub

]]>
</script>


<!--  Plugin help  -->

<aliases>
  <alias
   script="OnHelp"
   match="Edit:help"
   enabled="y"
  >
  </alias>
</aliases>

<script>
<![CDATA[
Sub OnHelp (sName, sLine, wildcards)
  World.Note World.GetPluginInfo (World.GetPluginID, 3)
End Sub
]]>
</script> 

</muclient>


You can type (for instance) "edit me/describe" and your description will appear in a notepad window, ready for editing and sending back.

To save an extra dialog box each time, go into the world configuration, "send" tab, and uncheck "confirm on each 'send to world' ".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #10 on Wed 06 Aug 2003 09:41 PM (UTC)
Message
We have to stop meeting like this Nick. ;) But seriously, we where both typing our replies at the same time and mine happened to land after yours due to the post time, so I wan't specifically talking about what you said.

Yes, an editor feature is workable. imho, the function of the notepad for doing that leaves a few things to be desired, not the lest of which being that unless you intentionally leave you windows smaller than maximum, it will bury your world while using it (which runs counter to the whole idea of responding to people while still being able to edit). But theoretically it is usable, just not nearly flexible enough to not drive you nuts trying to do it that way. lol

My own response was directed more at the specifics of MCP and some of the possible issues of making it work effectively and the fact that a real customizable and floating window would really be much more useful, if a tad complicated to make work right.
Top
Posted by Nick Gammon   Australia  (23,166 posts)  Bio   Forum Administrator
Date Reply #11 on Wed 06 Aug 2003 09:42 PM (UTC)
Message
    BTW Nick, What is the Class Name for Muschlient's main window, to make retrieving its handle easier? ;) lol

I'm not sure, but looking at the typelib viewer (below) it is one of 'MUSHclient', 'IMUSHclient' or 'World'.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #12 on Wed 06 Aug 2003 09:56 PM (UTC)
Message
Hmm. I can try those. There seems to be no direct way to look for a window without the class name. Even if you have an existing handle, none of the functions that Python or wxPython seem to support will return the class if you already have the handle. It is quite annoying.

When I did my experimenting I just kept feeding it numbers for the handle within the general range that Mushclient was likely in until I ran accross the right one. Once you have it you can play lots of interesting games, like resizing the window, changing the clients title bar text, etc. I am not sure what the limits to it are, but it does provide the possibility of making a small program that creates a window with icons in it or the like and actually 'docking' that with Mushclient by positioning it automatically relative to the windows dimensions. I don't consider the idea of trying to actually attach the window directly with Mushclient as a parent to be either safe or practical though, which was what I had originally considered doing through scripting. As a script it would have worked, it is the same thing IE does more or less, but since Mushclient run scripts can't respond to events, this is pointless. However, making a seperate COM program behave in a friendly way with Mushclient is quite easy, as long as some twit doesn't open multiple copies of the client, then it is a guessing game as to which one belongs to the world you need to use the program with. lol
Top
Posted by Nick Gammon   Australia  (23,166 posts)  Bio   Forum Administrator
Date Reply #13 on Wed 06 Aug 2003 10:19 PM (UTC)
Message
Ah, OK I see what you mean. The display above was for the COM object, which is nothing to do with the windows. The COM object is for the world which does not directly have a window. The world has views, and the views have windows.

A bit of a play with Spy reveals the classname of the main window is something like Afx:400000:8:10008:0:1100562 or Afx:400000:8:10008:0:a011b2 - I gather it changes for each execution.

I have added a new method to 3.43 - GetFrame - this will return the 32-bit address of the main world window (the enclosing frame). If you are keen you could work your way down from that to find the lower-level windows. Use it at your peril. ;) However I think doing that will be safer than randomly choosing numbers.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #14 on Wed 06 Aug 2003 11:23 PM (UTC)
Message
Probably safer yes. I did it that way because I was to lazy to figure out how to use the Enumerate function for windows. Well that and I was typing commands by hand looking for the window from the Python Shell application. The EnumerateWindows things uses a callback, so it starts at the first real window on the system and returns that handle to the callback, where you have to text Handle.WindowText to see if it is the right one and store the handle someplace. In any case it hunts down the entire list of windows based on execution ID and leaves it to you to find the right one.Needless to say this is impractical from the standpoint of typing in each command one at a time in the Shell. lol

Giving us the handle is definitely easier, thanks. Dangerous, but definitely easier. lol Then again, once you have the handle, windows doesn't protect you from much you might do with it anyway. ;)
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.

48,953 views.

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

Go to topic:           Search the forum

[Go to top] top

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

Home