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
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Mon Jul 14, 2008 9:23 am   

Certifying CMUD Packages for a Specific MUD
 
I'm really spinning off another topic discussion that Zugg started here.

Zugg wrote:
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.


I think ultimately the MUD admin coders should be the ones that certify which packages should be included by default with the MUD.

I've been working on a few for the MUDs I frequent and while I think they are good people interface preferences vary, as well as the quality of work that can be received.

We could take several approaches one of which being having an MXP 1.1 tag that specifies the default package(s) and their versions to be downloaded at start up?

Another alternative is to give MUD owners special access to library to mark the ones they certify. Of course this causes difficulty in certifying who the owner is.

Yet another would be to allow MUDs to do this only when they do a customized version of CMUD, a la the zApp form functionality due later. (That may not be such a good idea, but we'll see)

MUD admins/coders will have to be the ones to approve it ultimately for it to be official, and that may require them 1) being aware of the features and available packages, 2) having evaluated them and 3) take whatever steps are necessary to indicate the preferences.

Whatever the mechanism we will need to be able to specify multiple packages. I'm developing several packages for a MUD that I think will be quite useful. They are designed to work together but can stand on their own as well. I could roll them all into one big package but that would defeat some of the modularity in the design. So a way to indicate package dependencies, i.e. one that builds on another (eg a package that builds off of Viji's toolkit), or specify a group that should be used together for maximum effect.

It's late for me too so maybe I should go to bed as well but this should serve a thought starter.
_________________
Asati di tempari!
Reply with quote
Fang Xianfu
GURU


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

PostPosted: Mon Jul 14, 2008 9:40 am   
 
I don't think there should be too many packages pre-installed for any particular MUD. The only identifying feature of a MUD is its domain name (since sessions can be called whatever you like), so you'd have to track by them. It would be far from a perfect system.

And installing things by default that the user might not want is a bad idea. That's the whole idea of the package library. I think all this extra functionality wouldn't be needed if the library were better-advertised. Since this system would presumably build off the library anyway, why not just use that? That way users can decide for themselves what they want - whose stat-bar package they want to use, say.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Mon Jul 14, 2008 10:24 am   Re: Certifying CMUD Packages for a Specific MUD
 
Tech wrote:

Of course this causes difficulty in certifying who the owner is.

A php script can make a telnet connection to a MUD server. So the owner could enter a verification string in the login message.

E.g:
1. Register for account on Zuggsoft website.
2. Tell it you want to register mud X. You get a verification code.
3. You enter verification code in the MUD logon message.
4. You push verify button on the Zuggsoft website. The website connect to the MUD and check the login message. If the verification codes match, the registration is set as valid.
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Mon Jul 14, 2008 10:46 am   
 
Fang Xianfu wrote:
I don't think there should be too many packages pre-installed for any particular MUD. The only identifying feature of a MUD is its domain name (since sessions can be called whatever you like), so you'd have to track by them. It would be far from a perfect system.

Some MUDs might be accessible on many domain names mapping to the same IP. One IP/domain might have many different MUDs running on different ports. I have read about this issue before. It could be possible to use a standard way of differentiating MUDs. Scripts are differentiated by their guid, perhaps it should be possible to assign a guid to a MUD? It could be part of e.g the login screen somehow and collected by MUD list spiders as well as when connecting to the game.

Quote:

That's the whole idea of the package library. I think all this extra functionality wouldn't be needed if the library were better-advertised.

In my opinion the library works poorly. At least for me. It updates slow, it put its window in the center during update on top of all other windows so you can't even read websites during update as it block the view. It is complicated to find what you look for. Of course the library idea is very nice but I think there's room for improvements.

You want a better connection between the MUD list and the library. When you click to view the library you want to see what is available on the MUDs you are currently connected to. It is unlikely you really bother about someMud2 that you do not play. It should show updates available. Take a look at Firefox3 how it handles addons.
Reply with quote
Fang Xianfu
GURU


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

PostPosted: Mon Jul 14, 2008 12:06 pm   
 
Please, please give your library feedback in detail - in a separate thread so Zugg'll notice it and so this thread doesn't get side-tracked. There's been very little library feedback so far, so every little helps.

The trouble with guid for MUDs is then working out which guid goes with the MUD the user is connecting to. Users don't have to use the mudlist, they can just enter IPs and ports.

I do agree that the library could do with some improvement, and agree that those features would be awesome (updates to installed packages). Trouble is that now we've gone full-circle - there's no way for the library to know which MUD you're playing, so it can't just list packages for that MUD. That's what the search box is for. But the updates thing is a good idea.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Jul 14, 2008 5:51 pm   
 
The current MUD list uses the MUD Title as the key value, so this Title is always unique. With the combination of the MUD Title and the host, I'm not too worried about figuring out which MUD you are on. I don't really have any problem with restricting this "auto load packages" feature to just the MUDs in the MUD list. If you are entering a hostname/port directly and it doesn't match something in the MUD list, then you probably don't want CMUD to automatically load any packages for you (or you know enough to load them yourself).

What needs to be done for this to work is to tie the MUD Name field in the Package Library into the list of Titles from the MUD Connector database. Right now you can enter *any* text into the MUD Name field in the package library that you want. The package library doesn't currently validate that field. But it should. Once the package library and MUD list are brought together, then I can match hostname, IP address, etc.

As for loading packages that the user doesn't want, that's pretty easily handled. CMUD could just display a popup list of the packages about to be loaded the first time the player connects to the session. Something like "CMUD has found the following packages available for your MUD. Click OK to load the default packages". So I'm not worried about that. The whole point is to make it more automatic so that the new player doesn't need to know about the package library. They just want to play the MUD, not mess around searching for packages.

Rorso, you can already display packages for a particular MUD, or just show your Installed packages to see what updates are available. Just use the filters on the left side of the package library. Also, the updates should not be slow. At least they are very fast for me here. Maybe it's a network connection issue? But as Fang mentioned, create a separate post for discussion about improvements to the Package Library.

Back to the main part of this topic: I'm not sure putting the MUD admin in charge is really the right thing to do either. The MUD owners usually have their hands full already with a lot of other work. And they often don't know a lot about CMUD. It's usually some advanced *player* that has the useful CMUD scripts for a MUD.

I can just imagine this kind of conversation:

Player: "Hi, you don't know me, but I'm one of your MUD players. I have this cool CMUD script that I want to make into the default that everyone gets when they play your MUD. But Zuggsoft told me that only the MUD owner/admin can approve this script. So, can you approve this script for me?"

Admin: "I don't use CMUD. I have no idea how to approve your script. Besides, I don't know you, so how do I know that you haven't hidden some sort of backdoor trap into your code?"

Player: "No really, you can trust me!"

If the MUD admin/owner was in charge, then nothing will ever happen. I can't make it part of MXP, because most MUDs don't support MXP, and I don't want MXP to be a requirement just to get default script packages.

The Gurus might be able to help, but they are volunteers and are also overloaded a lot of times. Also, they really only know about their specific MUDs that they play and couldn't really help approve packages for other MUDs that they don't use. I have that same problem, so it's hard for me to approve anything too.

Maybe CMUD just needs to display a list of *all* plugins available for a MUD when you first connect to it. If people would actually *use* the rating feature in the existing package library to rate the packages that they like, then you'd be able to see which packages were being used by other people. Maybe I could add a field for "approved" or "tested" that could be used to distinguish those packages that have been somehow approved by the MUD. But maybe just displaying the list would at least tell the player that these packages are available.

Right now it's just too hard for the new player. As Rorso mentioned, clicking the Library button shows *all* packages by default. And even if it automatically filtered based upon the current MUD connection, by then it's usually too late to load those packages. Especially if the packages perform any MXP or telnet option negotiation. The packages really need to be loaded *before* you connect to the MUD.

If you want to display the packages before you connect to a MUD, you currently have to Edit Session, go to the File/Packages tab, and click the Edit button (the pencil) which is not well-labeled. This is too obscure. Even if the interface in the File/Packages tab was improved, it's still buried.
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Mon Jul 14, 2008 7:16 pm   
 
Zugg, I see your point on the admin being the one to approve the default package, but it should be them or one of the coders of the MUD that do so. I do like the idea of offering the top-rated packages for your MUD when you first connect, but then the issue of package compatibility comes up again.

It will likely difficult for a new play (that these features are aimed at) to distinguish which packages work well together. If they both try to do the same thing, or conflicting things then you can easily end up with a convoluted session. This would give the default packages idea, and potentially CMUD itself a bad reputation.

Perhaps it should occur when a user is setting up the MUD for the first time through the MUD list. Then give them them the option of downloading the top rated package for that MUD (one only). Automatically download any additional dependent (i.e. required packages) and give the option to also get the recommended ones for the selected package.

For this to really took off though, I think the MUD staff (at some level) have to buy in to it, and certify packages they recommend. They could then do like Lasher is doing and request that a certain feature set is built. The MUD staff doesn't have to be the one's writing the code, but at some point they have to evaluate it.

As for not putting into the MXP spec, I'm not sure I agree with that. It's quite possible (sic very likely) I don't understand what's involved, but I'd like to think they could add code to negotiate the packages with out implementing full MXP support. If that's alot, then maybe it could be a telnet negotiation option. Assuming the the level of effort in either case is small, I'm inclined to think that a MUD that won't do this probably won't put forth the effort identify, evaluate, and approve preferred packages for their MUD. Note this is all speculation, as I have no experience being a part of MUD staff.

I do agree that the package library should validate the MUD names from the MUD list, that way why don't have packages scattered because of typos or contractions in the MUD names.
_________________
Asati di tempari!
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Jul 14, 2008 7:33 pm   
 
Tech: Look at how many MUDs still use the old code bases that send LF CR instead of CR LF! If a MUD can't even conform to the simple Telnet protocol standard, how can you expect them to implement the telnet option negotiation.

I'd *love* to only support those MUDs who use *standards*. But then I'd just lose customers because "CMUD doesn't support OldMudXYZ". It's a no-win situation. Until MXP gets more widely accepted, I really don't want to make that a requirement. Not even the "top-ten" MUDs that have icons in CMUD all support MXP. Geez, not even IRE MUDs support MXP and they actually have a development team who could easily do it.

Anyway, I do agree with you on the problems with package compatibility. And it would probably be pretty common to have multiple packages from different authors on the same MUD that mostly do the same thing. We've somehow got to make it easier for people to test and rate the packages so that we can build up some sort of way to determine which packages are the best. The feature is there, but nobody is using it. Few people are using the Comment system either. I don't know if it's broken or if people just aren't using the package library yet. It's sort of a chicken/egg problem.

I still think it would be useful to display a list of available packages when you first create a new MUD session. But maybe they can all be un-selected by default, so just clicking OK would not load anything. But if there was a message like "To see this list again, click the Library button in the main toolbar" to remind the new player that these packages are available if they want to add them in the future.

I have some other ideas, but they are more package library specific, so I'll go post in that thread instead.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Mon Jul 14, 2008 8:19 pm   
 
My thoughts, make the Package Library available from the Session window. Put it right there on the left pane in its own little divider. If someone click on it it brings up the full library. This lets them browse the library to see what muds people are writing and publishing packages for.

Make mud naming a required field to uploiad to the library, and validate it. This is an important piece of your interface. Seperate out packages that are general use (like my Toolbox) into a smaller panel MUD naming should control the main sorting, and to bad for the user that wants to sort on something else first.

Next when a session is loaded, and the user clicks on the Library button ask them if they want to filter based on thier current MUD. General use packages would still display in the addition panel, but those that are specific to a MUD would be filtered.

Finally when a new session is created, or one of the preloaded icons is used (which should actually create a new session anyways), definitely ask, "Do you want to check the Package Library for useful packages?" Even if the user answers no, they now have an idea what the library button is for. Currently I don't think it really gets used because most people don't know what it is for.

An added bonus would to be to ask that question 1 time when an imported zMud session is first used.
Sorry, Zugg and Fang. I put all my thoughts on the PL in here.

I really think the certify thing is a no starter. Zugg is right that users have to use the rating and comments systems. The only packages I can certify as useful for any given MUD are those that I write, and a new user doesn't know me from some forum id that was banned for spamming. The only author name that should have total trust would be Zugg, and I am absolutely certain that some people wouldn't realize Zugg as a package author means the owner of Zuggsoft and author of CMud.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Fang Xianfu
GURU


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

PostPosted: Mon Jul 14, 2008 9:11 pm   
 
I still think that downloading packages by default is a bad idea - which is handy, really, since getting them onto the approved list is pretty much an unsolvable problem. But if you think it's possible to have the library display packages for the current MUD, then it'll be easy for users to decide what they want. Just make sure it says "Currently showing packages for YourMud" or something somewhere, so people know it's filtered. Otherwise they'll be annoyed that they can't find more general scripts.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Jul 14, 2008 11:16 pm   
 
Moving my comments over to the other thread about improvements to the package library.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
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