02 Oct, 2008, Mabus wrote in the 1st comment:
Votes: 0
Has anyone here done any work on getting a MUD server to detect MUSHClient, and set it correctly for MXP?

I am having a problem with CoffeeMUD codebase MXP and MUSHClient. I have asked at the CoffeeMUD Yahoo Group, but no answers there as yet. I believe Bo followed the MXP protocols, and I know that CoffeeMUD MXP works with ZMUD and a couple other MXP clients. Answers there so far place blame squarely on the client, but if this is so I would still like to modify my code so that players could get use of MXP with the client automatically (rather then go through any hoops).

I also know there are other games that have no problem with MUSHClient's MXP, so I figured it would be good to ask here before I went to the Gammon site and asked.

Mainly:
1) How can I detect that MUSHClient is the client?
2) How can I then have the server send the proper commands, or modify the MXP, so that MUSHClient can automatically use the MXP?

Any help appreciated.
02 Oct, 2008, David Haley wrote in the 2nd comment:
Votes: 0
There is no MUSHclient-specific detection of MXP. Contrary to other clients – and in fact many servers as well – MUSHclient implements telnet negotiation rather strictly according to the standard. So if somebody isn't doing something exactly correctly, MUSHclient will ignore it.

So, you don't do anything w.r.t. MUSHclient itself: you just send the appropriate negotiation requests asking if it can do MXP, and it will respond saying it can, and then I believe you acknowledge it and turn it on, and that's that. I've been using automatic MXP in MUSHclient for years. If need be I can look up the process in the networking code.
02 Oct, 2008, Mabus wrote in the 3rd comment:
Votes: 0
DavidHaley said:
There is no MUSHclient-specific detection of MXP. Contrary to other clients – and in fact many servers as well – MUSHclient implements telnet negotiation rather strictly according to the standard. So if somebody isn't doing something exactly correctly, MUSHclient will ignore it.

So, you don't do anything w.r.t. MUSHclient itself: you just send the appropriate negotiation requests asking if it can do MXP, and it will respond saying it can, and then I believe you acknowledge it and turn it on, and that's that. I've been using automatic MXP in MUSHclient for years. If need be I can look up the process in the networking code.

I would appreciate you looking it up. I will have to translate it over to Java, but should be able to knock it out.
02 Oct, 2008, David Haley wrote in the 4th comment:
Votes: 0
OK, I will in a few hours. If I forget to by the end of the day please ping me, things are a little busy at work…
02 Oct, 2008, Mabus wrote in the 5th comment:
Votes: 0
Been looking this over at the Gammon site. If that looks correct to you it could save both of us some effort.

Grepping my code now for various portions, and going to check what needs added.
02 Oct, 2008, David Haley wrote in the 6th comment:
Votes: 0
Oh! I'd totally forgotten about that. I knew I had gotten it from Nick but forgot that he had it on a website.

Note the sequence: (1) can you do it, (2) yes I can, (3) ok now start doing it. Most people think that (1) and (2) are sufficient, IIRC, and that is why MUSHclient doesn't actually turn it on.
02 Oct, 2008, Mabus wrote in the 7th comment:
Votes: 0
DavidHaley said:
Oh! I'd totally forgotten about that. I knew I had gotten it from Nick but forgot that he had it on a website.

Note the sequence: (1) can you do it, (2) yes I can, (3) ok now start doing it. Most people think that (1) and (2) are sufficient, IIRC, and that is why MUSHclient doesn't actually turn it on.

I am going to be that is it (#3). Perhaps the other telnet clients (that support MXP) expect MXP, and so do not need to be told to turn it on.

Thank you much for the help.
02 Oct, 2008, Vassi wrote in the 8th comment:
Votes: 0
DavidHaley said:
Oh! I'd totally forgotten about that. I knew I had gotten it from Nick but forgot that he had it on a website.

Note the sequence: (1) can you do it, (2) yes I can, (3) ok now start doing it. Most people think that (1) and (2) are sufficient, IIRC, and that is why MUSHclient doesn't actually turn it on.


I'll second this, I had the same problem just yesterday actually. You can tell MUSHClient to enable MXP when it's queried (I.E. you sent it DO MXP or WILL MXP) but in order to get it to turn it on from default you have to do IAC SB MXP IAC SE after the option is turned on.

To detect MUSH specifically you'll have to implement the TerminalClient option, to which MUSHClient responds to as mushclient (unless it's changed from the default by the user for some reason)

Still, adding the subnegotiation shouldn't affect other clients even if they don't require it, I don't think.


V
02 Oct, 2008, David Haley wrote in the 9th comment:
Votes: 0
Vassi said:
Still, adding the subnegotiation shouldn't affect other clients even if they don't require it, I don't think.

Unless of course they're braindead and can't handle the negotiation. :wink: But I agree: handling it via telnet negotiation really is the cleanest solution. It's what negotiation is there for in the first place…
03 Oct, 2008, Mabus wrote in the 10th comment:
Votes: 0
Got CoffeeMUD to turn on MXP in MUSHClient now.

//mabus, forcing telnet MXP on, from here
if(clientTelnetMode(Session.TELNET_MXP))
turnMXPon(true);
//mabus, forcing telnet MXP on, to here

//and

//mabus, forcing telnet MXP on, from here
private void turnMXPon(boolean turnOn)
{
char[] command={(char)TELNET_IAC,(char)TELNET_SB,(char)TELNET_MXP,(char)TELNET_IAC,(char)TELNET_SE};
out.write(command);
out.flush();
}
//mabus, forcing telnet MXP on, to here

Rather simple, but it works.

Now it is tossing the image tags at me as urls. Seeing as how MUSHClient does not support images I need to figure a way to test for MUSHClient, and disallow image tags.

The fun never ends!
03 Oct, 2008, Mabus wrote in the 11th comment:
Votes: 0
Vassi said:
To detect MUSH specifically you'll have to implement the TerminalClient option, to which MUSHClient responds to as mushclient (unless it's changed from the default by the user for some reason)

Looks like Bo already has a TerminalClient implementation to check for ZMUD.
if((terminalType.equalsIgnoreCase("ZMUD"))

And the loading takes place in the player toggle of MXP:
if(mob.session().clientTelnetMode(Session.TELNET_MXP))
{
mob.setBitmap(CMath.setb(mob.getBitmap(),MOB.ATT_MXP));
StringBuffer mxpText=Resources.getFileResource("text/mxp.txt",true);
if(mxpText!=null)
mob.session().rawPrintln("\033
if(mob.session().clientTelnetMode(Session.TELNET_MXP))
{
mob.setBitmap(CMath.setb(mob.getBitmap(),MOB.ATT_MXP));
StringBuffer mxpText=Resources.getFileResource("text/mxp.txt",true);
if(mxpText!=null)
mob.session().rawPrintln("\033[6z\n\r"+mxpText.toString()+"\n\r");
mob.tell("MXP codes enabled.\n\r");
}[/code]

So it looks like I just need to make an alternate mush.txt, remove the image tags, and modify the StringBuffer based on whether it is MUSHClient.

Life can be easy, sometimes.
03 Oct, 2008, Vassi wrote in the 12th comment:
Votes: 0
Mabus said:
Vassi said:
To detect MUSH specifically you'll have to implement the TerminalClient option, to which MUSHClient responds to as mushclient (unless it's changed from the default by the user for some reason)

Looks like Bo already has a TerminalClient implementation to check for ZMUD.
if((terminalType.equalsIgnoreCase("ZMUD"))

And the loading takes place in the player toggle of MXP:
if(mob.session().clientTelnetMode(Session.TELNET_MXP))
{
mob.setBitmap(CMath.setb(mob.getBitmap(),MOB.ATT_MXP));
StringBuffer mxpText=Resources.getFileResource("text/mxp.txt",true);
if(mxpText!=null)
mob.session().rawPrintln("\033
if(mob.session().clientTelnetMode(Session.TELNET_MXP))
{
mob.setBitmap(CMath.setb(mob.getBitmap(),MOB.ATT_MXP));
StringBuffer mxpText=Resources.getFileResource("text/mxp.txt",true);
if(mxpText!=null)
mob.session().rawPrintln("\033[6z\n\r"+mxpText.toString()+"\n\r");
mob.tell("MXP codes enabled.\n\r");
}[/code]

So it looks like I just need to make an alternate mush.txt, remove the image tags, and modify the StringBuffer based on whether it is MUSHClient.

Life can be easy, sometimes.[/quote]

I knew Java was close to .NET, I've even used Java books to learn concepts (like data structures) and applied them in .NET, but it never occurred to me that I could probably work with CoffeeMUD much easier than one of the C\C++ codebases. =\

It seems to be fairly popular, too, I have a slightly unrelated curiosity question. Is it as "hoggish" (I use the term playfully) to run as a C# console app? By which I mean, in the 10s of megabytes on even a simple console app.


V
03 Oct, 2008, Mabus wrote in the 13th comment:
Votes: 0
Vassi said:
It seems to be fairly popular, too, I have a slightly unrelated curiosity question. Is it as "hoggish" (I use the term playfully) to run as a C# console app? By which I mean, in the 10s of megabytes on even a simple console app.

It's a resource hog, yes.

I just love the ease of working in the code, and the inheritance.

It can be fun, and surprising. Like one time I coded a python "constriction" skill that would bind and stop the target from breathing (and the lack of breathing would damage per round, which is automatic and handled elsewhere) and asked for a play tester to help me. A higher level necromancer (who had been transformed to a lich) shows up, gets attacked, is bound, but is taking no damage at all. I almost started to look at my code, but I stopped and smiled, realizing that the Lich Race extends the Skeleton Race which extends the Undead Race, and Undead do not breath (hence, no damage). One simple example of some highly complex things that can be created.
03 Oct, 2008, Vassi wrote in the 14th comment:
Votes: 0
Mabus said:
Vassi said:
It seems to be fairly popular, too, I have a slightly unrelated curiosity question. Is it as "hoggish" (I use the term playfully) to run as a C# console app? By which I mean, in the 10s of megabytes on even a simple console app.

It's a resource hog, yes.

I just love the ease of working in the code, and the inheritance.

It can be fun, and surprising. Like one time I coded a python "constriction" skill that would bind and stop the target from breathing (and the lack of breathing would damage per round, which is automatic and handled elsewhere) and asked for a play tester to help me. A higher level necromancer (who had been transformed to a lich) shows up, gets attacked, is bound, but is taking no damage at all. I almost started to look at my code, but I stopped and smiled, realizing that the Lich Race extends the Skeleton Race which extends the Undead Race, and Undead do not breath (hence, no damage). One simple example of some highly complex things that can be created.


I'll have to take a closer look. I'm still deciding if I want to go with a completely templated engine or if I want to allow for hard-coding things based off of an interface (Which sounds like what CoffeeMUD is doing).

On the one hand, templated objects still allow for flexibility and require you to only know the OLC to be productive (good for complete novices) and on the other you sacrifice 'complete' flexibility.

In any case, I didn't mean to de-rail the thread. (Even though it seems to be resolved!)


V
03 Oct, 2008, Mabus wrote in the 15th comment:
Votes: 0
Vassi said:
I'll have to take a closer look. I'm still deciding if I want to go with a completely templated engine or if I want to allow for hard-coding things based off of an interface (Which sounds like what CoffeeMUD is doing).

Most people just use the templates. I like to hardcode things. It does give our builders a lot of freedom, and allows me to create what it does not have.

Vassi said:
In any case, I didn't mean to de-rail the thread. (Even though it seems to be resolved!)


I still need to either disable images altogether (which is what I am pondering) or check for MUSHClient and disallow images. I really, really dislike the MUSHClient "link instead of image".
03 Oct, 2008, David Haley wrote in the 16th comment:
Votes: 0
Most of the resource hogging comes from having to load the JVM (or the .net runtime). In Java's case – don't know about .net – memory usage from that point onward isn't all that bad.
03 Oct, 2008, Vassi wrote in the 17th comment:
Votes: 0
DavidHaley said:
Most of the resource hogging comes from having to load the JVM (or the .net runtime). In Java's case – don't know about .net – memory usage from that point onward isn't all that bad.


Aye, that's why I used the term playfully. It's the biggest reason most people cite for not giving Java\.NET a try - which I can understand, as hosting plans with a lot of memory are not as cheap. Still, I managed to do decently well on MudMagic when they installed Mono for maybe a quarter of what the cheaper VPS' cost.

I use a VPS now, but I can afford it and some of the cost is subsidized by letting a couple of people host on it.
03 Oct, 2008, Fizban wrote in the 18th comment:
Votes: 0
Quote
Still, I managed to do decently well on MudMagic when they installed Mono for maybe a quarter of what the cheaper VPS' cost.


Mudmagic charged a good bit more than $5 a month. Their absolute cheapest plan is $8, and you can easily get a VPS for $20 a month.
03 Oct, 2008, Vassi wrote in the 19th comment:
Votes: 0
Fizban said:
Quote
Still, I managed to do decently well on MudMagic when they installed Mono for maybe a quarter of what the cheaper VPS' cost.


Mudmagic charged a good bit more than $5 a month. Their absolute cheapest plan is $8, and you can easily get a VPS for $20 a month.


Not a windows VPS. If you can, by-god tell me =X The benefit of having MudMagic do it is that they installed everything for me and I never had to learn the whole Linux environment. I suppose a 20 dollar VPS is good if you know your way around and can do your own installs of stuff, etc, but really the majority of people who know what they're doing are using whatever they've been using for the last decade (or half a decade or however long) and your adventurers tend to be your complete newbies.
03 Oct, 2008, Zeno wrote in the 20th comment:
Votes: 0
It almost seems pointless to buy a Windows VPS to host a MUD.
0.0/21