Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion Goto page Previous  1, 2, 3  Next
Toxic Posted: Wed Jul 09, 2008 3:05 am
Redisplaying mud output with Color in tact.
Aylorian
Beginner


Joined: 07 Jul 2008
Posts: 14
Location: Orlando

PostPosted: Fri Jul 11, 2008 1:07 am   
 
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.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Fri Jul 11, 2008 1:24 am   
 
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).
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
alluran
Adept


Joined: 14 Sep 2005
Posts: 223
Location: Sydney, Australia

PostPosted: 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.
_________________
The Drake Forestseer
Reply with quote
Aylorian
Beginner


Joined: 07 Jul 2008
Posts: 14
Location: Orlando

PostPosted: Fri Jul 11, 2008 2:27 am   
 
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.
Reply with quote
Aylorian
Beginner


Joined: 07 Jul 2008
Posts: 14
Location: Orlando

PostPosted: Fri Jul 11, 2008 2:32 am   
 
Fang Xianfu wrote:
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.


No my bad on this one, I missed the part about MXP bashers on another forum so assumed you meant me. It's all good.

Fang Xianfu wrote:
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 ;)


Absolutely, it was a quick discussion on our test port as a cmud user was trying out the tags. The quick version was "Can we move ahead with this without breaking MXP or our ability to implement it later?", the quick answer was "Yes".

Everything beyond that is just internet communities being internet communities, particularly when subjects cross over multiple forums :)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Jul 11, 2008 3:03 am   
 
Quote:
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

Please do post new threads with any bug reports like this. I just fixed an issue that I found myself regarding floating windows not remembering their size, but since I've been in the middle of the MXP code lately, this is a good time to get any bugs fixed.

You could also give some more specific details on what you mean by "window stuff from mush seems alot nicer".
Reply with quote
alluran
Adept


Joined: 14 Sep 2005
Posts: 223
Location: Sydney, Australia

PostPosted: 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.
_________________
The Drake Forestseer
Reply with quote
Aylorian
Beginner


Joined: 07 Jul 2008
Posts: 14
Location: Orlando

PostPosted: Fri Jul 11, 2008 3:24 am   
 
Zugg wrote:
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.


The only thing I would have needed to ask for in order for CMUD users to be able to take full advantage of what we're doing is the telnet code. It already does, so we're good.

Zugg wrote:
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 hear that. When TMS started to moderate the forums and try to keep it civil, they pretty much died overnight. They're picking up again now but the posts with the highest volume are still those that start to lean towards flame wars. Threads about how to try to expose muds to a wider audience die after a few days, go figure. We're our own worst enemy.
Reply with quote
Toxic
Adept


Joined: 27 May 2008
Posts: 299

PostPosted: Fri Jul 11, 2008 4:03 am   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Jul 11, 2008 5:18 am   
 
I'll test then PSUB stuff on Aardwolf tomorrow and see if I can reproduce it.
Reply with quote
Nick Gammon
Adept


Joined: 08 Jan 2001
Posts: 255
Location: Australia

PostPosted: Fri Jul 11, 2008 6:16 am   
 
Zugg wrote:
And on Nick's argument, it's just as easy for any MUD client to strip the <rname> MXP tags as it is to strip the {rname} at the beginning of a line.


This was the point we were uncertain about, during the fairly lengthy discussion we had on the Aardwolf test port. As you know, I am a supporter of MXP, having spent probably a couple of months of my life adding it to MUSHclient, and I believe that Zugg and I are fairly happy about having a broad base of client support for a protocol, rather than restricting it to one client.

Our concern was, and I believe it was a legitimate concern, that if we were not careful, adding some sort of half-baked MXP-like commands to Aardwolf, may in fact break it for some users of CMud or ZMud. There was no such concern for MUSHclient, because as the MUD did not negotiate MXP (ie. did not turn it on), MUSHclient would treat things like <rname> ... </rname> as just any other sort of MUD output. A trigger could match on it, exactly the same as {rname} or *rname* or whatever you chose.

However, as has been explained to me in the past, numerous times, zMUD (and CMud too for all I know) has MXP parsing permanently turned on (thus players can put their text in bold by using <b> even on a non-MXP MUD). This raised the issue, and it was mentioned by some of the zMUD-script writers on the MUD, that we need to be careful with using what look like MXP tags, because they might cause zMUD to interpret them in a way that was not intended, or to perhaps have the whole line treated in a different way than was intended.

Concerns were raised that some newbie players, who did not know or care what MXP was, may or may not have turned on MXP support, or MXP extended support, or whatever the exact options in zMUD and CMud are.

In the end we thought it was best to stay away from anything that might confuse zMUD, or cMUD (possibly depending on client-side options) and run with something that was, quite clearly, nothing to do with MXP.

Later on, when Lasher has read the MXP spec, and taken time to fully implement it, the whole issue could be revisited, and careful testing could take place with all the clients that might need to interpret it.

Just to give an example of what might go wrong if you don't fully implement it properly, imagine for a moment a room whose name happened to contain the string </rname>. Now I know you might say that is unlikely, and it probably is. It might however contain something like <The Depths of Despair>. My point is, that once you start using < and > signs to indicate mark-up tags, the server should then convert non-markup instances of them into (ampersand)lt; and (ampersand)gt; - just to make sure that no matter what is in a room name, an exit name, or a mob name, it will be rendered properly.

So if you are going to do the job properly, then clearly you can't just convert <The Depths of Despair> into (ampersand)lt;The Depths of Despair(ampersand)gt; if the client isn't going to convert it back for displaying. So this takes us to MXP telnet negotiation.

My point is that you can't just use MXP-like tags when you feel like it, and hope for the best, if you want to get a good end result.

Thus I believe the decision to use things like {rname} can be supported, at least as an interim measure, until MXP implementation has been fully explored.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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>.
Reply with quote
Nick Gammon
Adept


Joined: 08 Jan 2001
Posts: 255
Location: Australia

PostPosted: Fri Jul 11, 2008 9:54 pm   
 
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:

Code:

 local data = {}
   
  for item in string.gmatch(wildcards [1], "[^,]+") do
     table.insert (data, item)
  end


Effectively this gives us a table of 23 items from the stats line, which can then be made available to other scripts (eg. by putting into variables, or an array).

Naturally, the matching line is then omitted from output.

This method is quick and effective, and also allows for expansion, so if the MUD adds fields 24, 25 etc. then the code (or the trigger) doesn't need any change, except perhaps to do something useful with the additional items.

So really, I am using the stats line without needing direct MXP support, so I imagined you could do the same.

I thought it was sensible to put the extraction of the {stats} data into a separate plugin, so it is only done once. I gather cMud/zMud has a similar mechanism for plugins as well? Not technically the same, but with the same sort of capabilities?

This also gives the benefit that the telnet negotiation (IAC SB 102 1 1 IAC SE) can be placed in a single place (the plugin).
Reply with quote
Toxic
Adept


Joined: 27 May 2008
Posts: 299

PostPosted: Fri Jul 11, 2008 9:57 pm   
 
Um, so did the PSUB issue happen to you as well Zugg?
Reply with quote
Nick Gammon
Adept


Joined: 08 Jan 2001
Posts: 255
Location: Australia

PostPosted: Fri Jul 11, 2008 9:58 pm   
 
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?
Reply with quote
Toxic
Adept


Joined: 27 May 2008
Posts: 299

PostPosted: Fri Jul 11, 2008 10:15 pm   
 
Nick Gammon wrote:
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?


Not on such a level that it would be interpretted as MXP. Unless of course Zugg coded something. Changing it to <rname> ... </rname> would be easy, and you could reparse the line using a regular conditional trigger, but like I said that would of course be already past the level that CMUD would interpret the tags as MXP.
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Fri Jul 11, 2008 10:17 pm   
 
Zugg wrote:

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.

Adding support for {rname} could discourage MUDs from actually following the MXP standard. If MUD servers have problems to follow the specification there is an issue somewhere, because compared to what you have to do on the client side to actually parse MXP the implementation on the server should be very simple.

Quote:

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>.

Do you really gain that much from the {tag} syntax? It's syntactic sugar and moves away from the xml-style. It also seem pretty confusing.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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)
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Sat Jul 12, 2008 9:20 am   
 
Zugg wrote:


So we need a system for organizing this. I'm open to ideas.

You could allow the MUD admin to verify their MUD, and then be able to manage it. You could do auto verification by having a php script connect to the MUD and then scan for a string in the startup message.

Another way is to let the gurus handle it. Make a trust network and allow gurus assign users to maintain settings for different MUDs.

Adding a "hazard" icon to each package users could alert a set of moderators about inappropriate packages in the library.

Quote:

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.

What I don't understand is why people do not use the developer forum for these things. I have seen people complain about e.g MXP on other forums. Yet they don't go to the dev forum to explain their views. In my opinion MUDs really need standards and open protocols. What annoys me the most is that I have become so inactive myself so maybe I shouldn't complain about others Sad.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Sat Jul 12, 2008 4:04 pm   
 
Rorso wrote:
What I don't understand is why people do not use the developer forum for these things.

You mean, the zMUD Developers forum that takes special access?

Perhaps creating an MXP-specific (open) forum, and then advertising it on the MUD admin web sites (TMS, TMC, and perhaps the others) would get the ball rolling.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net