Zugg Software :: View topic - Redisplaying mud output with Color in tact.

Beginner Joined: 07 Jul 2008 Posts: 14 Location: Orlando

Toxic bought this thread to my attention. Here's the response I posted to him in our forums:

"You all missed the main point I made during that discussion which is that these tags are for a specific project right now. They are *NOT* intended to replace/undermine MXP. I can make a single toggle that converts all existing tags to MXP once I study MXP in more detail. I will not hold this project up while I do that and I will not "half ass" MXP without understanding it fully. Although it seems over the top, if there is a reasonable need for it (ease of scripting in different clients) I could even let you define the tags to be whatever you want. If someone wants to make them work for Pueblo or Portal or whatever other MUD clients have extensions, this may even be the best approach. In terms of MUD programming, it's a fairly trivial implementation.

The thread seemed to be leading to the impression that I have no interest in supporting MXP, that was not what I said. I said all along you may be completely right, I may look back and say "should have done this from the start", but there are plenty of ways to adjust tags as necessary without breaking things for people using the existing format. If MXP can improve the experience of playing Aardwolf for a good percentage of its users I will implement it. As with everything else, it has to be weighed and prioritized against the million other things we could do to improve the mud, but "avoiding MXP" was never the intent."

So, there was no "bashing of MXP", there was a discussion on whether now was the right time to jump into MXP fully, it wasn't. The next part of the discussion was in that case it is better to avoid anything that looks like MXP tags so we moved away from <>. I may regret that decision when I do get to MXP later on, but I sure don't feel a need to apologize for making it or discussing MXP somewhere other than here.

Edit: Zugg's last question was posted at the same time as this. Not a custom client per se, a custom version of Mushclient. Actually, there's nothing particularly "custom" about it in terms of special mushclient code for Aardwolf, just a single download with plugins pre-installed.

Adept Joined: 04 Feb 2005 Posts: 246

The intent of my post was to try to not to start any MXP-flame wars here (since I know little about how good or bad it is), but to mention that there has been some derogatory comments without much in the way of support on TMS, which is where MUD admins tend to congregate (along with TMC). It's probably better to carry on the conversation over there, given that this is a protocol not tied to any one client, and more related to support in codebases than in clients, but that's just my opinion. It seems to me it is sorely in need of some marketing support.

If you want to see the threads on TMS, you have to search to "Zugg" in their forums (for some reason, doing one on "MXP" doesn't turn up anything).

Posted: Fri Jul 11, 2008 1:27 am

Aylorian: I'd just like to reiterate that it wasn't you (or anyone else in particular) I was talking about a couple of posts ago, and as far as I know, neither was Zhiroc. I'm not sure where that impression came from, but it certainly wasn't intentional, and I apologise again.

It's nice to hear that you've designed the system with a future look at MXP in mind. One of the first things I talked about was my hope that you'd've done this in such a way that a future change to MXP would be easy, so's not to make more work later. On the face of it, your arguments about not wanting to delay this (extremely useful) feature while you learn about MXP are certainly sound.

It's always good to know that MXP has its foot in the door, too ;)

Zhiroc: Mmm, simultaneous posts. Some direct links to those topics would be awesome - if you don't want to post them for whatever reason (can't imagine why you wouldn't, but you haven't, so there might be some reason) then a PM would be ace.

Posted: Fri Jul 11, 2008 1:43 am

He's modifying a version of mush with custom plugins, and alot of z/c coders are developing equivalent plugins for z/cmud, all to eventually be hosted on aard site I believe. Though the window stuff coming from mush seems alot nicer than cMud ones, still a few bugs I need to post regarding floating windows etc... I'm sure fiendish has a few others too.

Good to hear that stuff for telnet triggers, pretty sure Lasher is watching this thread anyways, but I think that will be of interest to him too. At the moment i know the aard mush has telnet negotiations to enable/disable certain tags in game.

As for my previous post, meh, someone had to defend the guy, like you said, he's got alot of stuff going on right now, and everyone was complaining that they weren't getting what they wanted straight away :)

Oh, and I took the stuff to do with TMS / TMC to be aimed at the admin there, not the users, my mistake there.

Beginner Joined: 07 Jul 2008 Posts: 14 Location: Orlando

Ok, now we're all straight (this is Lasher btw), I was pleasantly surprised this afternoon to learn that Cmud can receive arbitrary IAC,SB ... IAC,SE sequences. It just adds even more value to what we're doing.

The issue of knowing when a player is active and able to actually receive commands has always been a pain for any script writer, so we're using a set of telnet negotiation sequences that will toggle various config options at the socket level independent of player state. This ensures plugins can always initialize themselves appropriately even if the player is at MOTD, in an editor, etc.

The same applies in reverse, when player state changes, a telnet sequence is sent notifying the client (ie, you are now afk or in the description editor - don't bother trying to run your spellup script). Obviously this can all be done with triggers, but this way is just much more efficient and being able to have plugins trigger on a specific state really makes it work. It also means if we change the MUD output, it doesn't suddenly break a bunch of scripts.

Not sure if its ok to post links or not so feel free to remove if appropriate, I'm not here to self promote, but more details on what we're doing and why is at http://www.aardwolf.com/blog/2008/07/10/telnet-negotiation-control-mud-client-interaction (excuse the long URL, that's wordpress).

As you can see, this whole tags thing came out of a quick need to make some plugins work.

I missed the mapper comment on first read. If the plan is still to design an open mapping protocol that can be implemented by any mud and any MUD client I'll be on board and do whatever I can. The last post I saw on it (which could very well be me just being out of date) was to request features for an enhanced zmud mapper.

Beginner Joined: 07 Jul 2008 Posts: 14 Location: Orlando

Posted: Fri Jul 11, 2008 3:01 am

Lasher, thanks for posting directly to this. I was getting concerned with all of this second and third-hand info that was being posted.

I can understand now why you made the choice that you did for the short term in order to give MXP a more detailed look in the future. Given zMUD/CMUD/MUSHClient/other-client support for MXP, I'm pretty confident that you'll eventually "see the light" on this and use MXP. Especially if you are already doing telnet option negotiation for other stuff. Doing the MXP telnet option negotiation is usually the hardest parts for most MUDs. Doing the secure line tag and converting < and > characters is pretty trivial. But it's good to know that you are coding it in a way that would make it easy to switch in the future.

Keep in mind that doing anything involving other custom telnet options is ok for CMUD, but leaves zMUD users SoL. At least MXP would include zMUD users. And while I'd like zMUD users to switch to CMUD, that's not going to happen for a while. But who knows...maybe the improvements to Aardwolf that might require CMUD will encourage some zMUD users to switch.

Btw, given our long relationship, I'd also hope that you'd contact me if you needed anything in a "custom" MUD client too. While I know that MUSHClient is open source now and free, I'd like to stay in the loop too.

I hadn't been worrying much about the timescale on the new mapping protocol because I knew you were pretty busy with the V3 stuff. Even though the graphical map stuff in still a few months away, I'm getting closer to it. At least I started working on the mapper code *finally* this week.

Finally, we need to be careful what we wish for. I'm not sure we really want most of those discussions on TMS and TMC to move here. I've pretty much stopped posting on TMC completely because anything that I post turns into a flame-war. There are just too many "everything *must* be free" fanatics on those boards. I'm afraid that we'd have to start moderating these forums a lot more if that stuff migrated over here. I'm as frustrated as anyone by trolls on various other sites posting negative stuff about zMUD/CMUD that isn't true half the time, but I'm never going to be able to stop that. While I always appreciate any help with trying to get threads like that to mention specifics and not just vague problems with some old beta version, I just don't have the time and/or desire to keep track of those threads myself.

Posted: Fri Jul 11, 2008 3:03 am

Posted: Fri Jul 11, 2008 3:14 am

Heh, that was the most annoying one, i think fiendish found one about not being able to set width on right-docked windows, but i'll get him to post it.

Beginner Joined: 07 Jul 2008 Posts: 14 Location: Orlando

Adept Joined: 27 May 2008 Posts: 299

OK, so, sorry for starting such an 'issue' but I am glad everyone came around to civil discussion.

Zugg: Although I have found a way around using PSUB by using the reparse condition trigger Fang advised me of, I would like to know if you were able to reproduce the same issues I had with PSUB and the aformentioned XML I posted.

I also think that Lasher made the correct choice to remove the origional tags using <> and change them to {} at least for now as to not interfere with MXP stuff. As much as I want MXP in Aardwolf, I wouldn't want something that was only half understood and therefore half supported. Good things come in time.

Posted: Fri Jul 11, 2008 5:18 am

I'll test then PSUB stuff on Aardwolf tomorrow and see if I can reproduce it.

Adept Joined: 08 Jan 2001 Posts: 255 Location: Australia

Posted: Fri Jul 11, 2008 4:48 pm

Nick, that is an excellent summary of an important issue. I agree that even though CMUD does a better job at detecting MXP-like "tags", zMUD definitely had several bugs regarding that problem. In most cases, if the tag is "unknown" (like your Depths of Despair example), then zMUD and CMUD are going to leave it alone unless the line is tagged as a secure MXP line. So even though MXP is "on" by default, the MUD still has to enable it via the secure line code to use custom tags like this. CMUD also leaves alone any tag that doesn't have a corresponding closing tag on the same line (again, unless in secure mode). But yes, unfortunately, that didn't work in all cases in zMUD, which is very unfortunate since I never thought it would drive design decisions like this.

However, the tricky position that I'm in now is supporting the {rname} tags. Aardwolf is a very popular MUD. And like supporting ATCP for the IRE MUDs, if the {rname} syntax is going to be used for any length of time on Aardwolf, then I'm going to want to support that and whatever additional telnet negotiation is being done.

In fact, all of this had me thinking while I was in the shower this morning...maybe MXP *needs* a way to more easily tag an entire line with a custom tag. I'll take a look at how this ends up working on Aardwolf and think about how I might want to handle it in the future. But we could easily be on the verge of a defacto MXP extension where {tag} at the beginning of a line marks the entire line as if it was enclosed in <tag>data</tag>.

Adept Joined: 08 Jan 2001 Posts: 255 Location: Australia

I wonder if direct support is needed? It would be different if the tag was (say) {b} ... {/b} for bold text, as you expect the client to directly do something with the text.

What I have done with the {stats} tag when writing a plugin is simply make a trigger on {stats}* (that is, the whole line), and then in Lua extract the fields like this:

Adept Joined: 27 May 2008 Posts: 299

Um, so did the PSUB issue happen to you as well Zugg?

Adept Joined: 08 Jan 2001 Posts: 255 Location: Australia

Re-reading your post, Zugg, maybe I misunderstood that your concern was more about room names, which might impinge on the auto-mapper?

As a work-around is it possible for the client to detect the {rname} line, and then effectively change it to a <rname> ... </rname> line locally, but force itself to re-interpret that line, and therefore trigger the mapper?

Adept Joined: 27 May 2008 Posts: 299

Wizard Joined: 14 Oct 2000 Posts: 1368

Posted: Fri Jul 11, 2008 10:31 pm

Sorry, didn't mean to get confusing.

Of course it's trivial to set up a trigger for {rname} in zMUD/CMUD. And then call #TAG to send it to the mapper. That's not really what I meant. I was just thinking of a way for making it easier for newbies. Doing it at the lower MXP level in CMUD would be faster that creating a trigger that then had to use #SUB to get rid of the tag on the line.

And yes, the {tag} syntax is just "syntactic sugar". But it's still a nice shorthand for tagging a line. But nevermind.

Edited: Toxic, I haven't gotten to the PSUB test yet today. It might have to wait till Monday.

Posted: Sat Jul 12, 2008 8:27 am

OK, maybe I'm just tired and shouldn't be posting this late, but I just kept thinking about this today.

MXP already has "line tags". It's the ESC[nnnz code. There are some predefined nnn values for room name, description, etc. But in all of the years that MXP has been around, I don't know of a single MUD that uses these line tags. Why? Because they are a pain. They don't have names. After all, just like Aardwolf discovered, it's a lot easier and more supportable to output {rname} at the beginning of the line then to remember that the proper MXP line tag is ESC[20z.

So maybe using {tag} at the beginning of a line *is* a natural way of doing "named" line tags, instead of the obscure "numbered" line tags that are already in MXP. Maybe this should be part of the MXP 1.1 spec?

It would actually be *very* easy for me to support these "named tags" internally in CMUD and treat them the same way I treat "numbered" tags. If you go into the CMUD MXP Preferences, you'll see an area for MXP line tags where you can actually do a bunch of cool stuff with them. You can automatically "capture" them to a different window, change their color, gag them, etc. The original idea was that the MUD would tag their chat "channels" with these tags. But with obscure numbers instead of names, the idea never took off.

I'm going to spend some time next week taking a closer look at the tags that Aardwolf is using and their telnet protocol negotiation stuff. At first glance it looks trivial to implement in CMUD packages.

Btw, looking at the setup of playing Aardwolf in Mushclient was kind of amusing because it looks like the setup I already use in CMUD. I already have the ascii map filtered to a different window, and various other chat windows, all docked in a nice layout. In fact, it was a lot of trouble to get the ascii map captured to it's own window and if I had know that I simply needed to email Lasher and ask him to add new tags to the MUD, I probably would have done that months ago! :)

Anyway, now that Aardwolf has all of these tags, it's going to make my life a lot easier as a player. But it also makes me thing "How can we do this better?". I completely understand that Aardwolf needed to work with a *free* MUD client since they can't ask their players to all buy CMUD. But maybe CMUD could make this easier for both Aardwolf and other MUDs.

The issue is that for any given MUD, there are several packages (plugins) for CMUD that make playing that particular MUD a lot nicer and easier. I have my own packages for Aardwolf. Larkin has packages for IRE MUDs. Just look in the Package Library in CMUD...there are lots of packages for lots of MUDs.

But that's still too hard for a newbie. A new player doesn't know how to get into the Package Library and find the package that they need for the MUD that they want to play. Somehow this needs to be made easier. If a player downloads CMUD and runs it and double-clicks on the pre-defined Aardwolf (or other MUD) icon, then somehow CMUD should have a list of packages to load for that MUD.

When the mapper configuration info is added to the package library, CMUD could even install the correct mapper configuration, and maybe even download some maps of the starting areas.

As always, the devil is in the details: How do we decide which packages are to be preinstalled for a given MUD by default? Which packages are good enough and stable enough for general use? Who decides?

If we can answer these questions, then we can have exactly what Lasher wanted for Aardwolf within CMUD...the player double-clicks on the Aardwolf icon and gets a nice layout of multiple windows, with the map in one window, stats in another, gauges automatically set up for hp, mana, etc, and whatever starting triggers, aliases and macros are needed. Once the player learns the MUD and the client, then they are free to customize it, remove some of the default packages, etc.

But this would work for *any* MUD, not just Aardwolf. I'd probably officially support the MUDs that had the icons in the startup screen, but in theory, you could pick any MUD from the MUD list and CMUD could install the proper packages for that MUD from the package library.

That sure would be a huge step forward from where we are today. It would make it a lot easier for MUD to set up custom client interfaces for their players. And it would make it a lot easier for new players to get started with a MUD.

This probably isn't the right thread for this discussion, so maybe this late-night rambling should be split into it's own thread. But I'd love to hear suggestions on how to manage this. I certainly can't be in charge of "picking" the packages. There is no way I can play all of the MUDs out there and certify the packages for them. *Maybe* I could ensure that the packages for the ten predefined icons remain working across CMUD upgrades, but I couldn't test the packages for *all* the MUDs. So we need a system for organizing this. I'm open to ideas.

My final thought for the night is: If any other MUD admin/owner/coder is thinking about cool stuff they want to do on the client side, please contact me. While I understand the reason Lasher contacted MushClient because it is free, I'd like to remind everyone that *I* do this full-time for a living. As far as I know, I'm the only one who works on MUD clients as a full-time job 24/7. I'd like to believe that I'm pretty responsive with my updates these days (ignoring the couple of years that I was distracted with zApp). I really want to help drive the MUD community forward and have dedicated my life to doing this. While I'm just one person and there is a limited amount of time in a day, I'd still like to add all sorts of cool stuff to make MUDs easier to play and more fun.

zMUD and CMUD have been driven by suggestions from MUD players for years. Maybe it's time to start getting more suggestions from MUD admins/owners/coders. After all, there are a lot of people in this community who want it to succeed too.

(ok, time for bed now)

Wizard Joined: 14 Oct 2000 Posts: 1368

Adept Joined: 04 Feb 2005 Posts: 246

Posted: Sat Jul 12, 2008 5:00 pm

I think making the Developer's forum open is something to consider. I might also change the name since the "zMUD" Development Forum is no longer really appropriate. We'll probably discuss stuff beyond MXP, so maybe just the "MUD Developers Forum" or something like that. Or, if everything in the future is seen as an extension to MXP, then the "MXP Developers Forum" would be fine too.

The original purpose for the restricted access was to prevent novice zMUD users from posting support questions there. Getting access to the forum is pretty easy, and the method is explained on the main Forum page that you get when you click on the Forums link. I can maybe make it automatic like the old zMUD Beta Forum access just so we don't have to wait to approve the messages.

I'm not sure about advertising it on the other sites though. The flame-wars on those sites have driven me away. And I don't really want those types on this forum. This is a *moderated* forum, and we've never had to really control that much in the past. These days the Gurus mostly just flag spambots that get through our filters. If we started getting annoying people that we truely had to moderate/delete/ban then we could have some real trouble on our hands. I really don't like moderating, but I'm not going to let our forums turn into TMC either.

Posted: Sat Jul 12, 2008 5:54 pm

I really don't mind having to be heavy-handed with the lock button. I've been a moderator on forums before that needed it. And I'd hope that it wouldn't take too long of that for people to stop doing it, too. It's not like we have a slow response time ;)

And if you want to make it an open forum, we can just move zMUD/CMUD support requests and remove MUD-specific ones. It's not as if it's a hassle to do. A note somewhere in there to that effect would probably help, too.