21 Jun, 2009, David Haley wrote in the 21st comment:
Votes: 0
Quote
- Should these be two separate packages to make detecting support easier, or is relying on individual command detection enough?

Well, we never did really decide how to detect support in the first place, right? As I recall, we didn't come to a conclusion on whether or not commands were optional, if people had to support them, how to report support of additional commands, etc.

Quote
- Should commands within clickable text regions just be disallowed entirely for simplicitly's sake?
- If the prior is "yes," then should the command just include the clickable text as an argument and rid us of the end-* commands?

I'm tempted to say that we should disallow other commands because that will really make a lot of things simpler. We can always change it later… assuming we agree on some kind of package/command versioning mechanism. :wink:

Quote
- Can we get rid of the action version by just stating that a menu with a single item with an empty user-visible text portion should just send the action immediately upon clicking wtih no menu display?

Sure, seems reasonable enough.

Quote
- Do menues or clickable text actions need an associated id to help protect against stale action links, or should the MUD just deal with that itself by what information it puts into the action text?

I vote for the MUD dealing with it itself. After all, nothing prevents a player from typing in commands that might have been relevant an hour ago, and the MUD still has to deal with it. If you have to start associating IDs with menus and actions, that places some amount of burden on the server for gain in only relatively few situations.



Overall I like this. It's worth noting that this can be implemented in MUSHclient already, assuming a ZMP layer. It's very similar to MXP's hyperlinks.
30 Jun, 2009, elanthis wrote in the 22nd comment:
Votes: 0
Hmm, OK.

Les seems to be busy with other stuff (haven't seen any svn commits to gnome-mud in a while, anyway), so unless MUSHclient is ready to slap in ZMP, I may need to get back to work on a client…

Someone brought up AnyTerm which I might swipe the HTML/JS portion from to get the Cloud9 HTML MUD client back on track. I've been delaying on that since I keep waiting for browsers to be able to do bi-directional JavaScript-usable network connections on their own, but I officially give up waiting on that since it probably won't happen for another 5 years. Simple Python daemon can do everything I need.
02 Jul, 2009, David Haley wrote in the 23rd comment:
Votes: 0
MUSHclient can implement ZMP as a plugin fairly straightforwardly, you'd just have to do it. I've been meaning to but haven't had a pressing reason yet as I don't have ZMP enabled in my server, currently. It has Lua as a scripting language so you'd have a sane framework to work in.

Somebody already wrote a plugin for ATCP or something like that, which I gather is Iron Realm's ZMP-alike.
15 Dec, 2009, Les wrote in the 24th comment:
Votes: 0
elanthis said:
Hmm, OK.

Les seems to be busy with other stuff (haven't seen any svn commits to gnome-mud in a while, anyway), so unless MUSHclient is ready to slap in ZMP, I may need to get back to work on a client…


I had a baby which has been keeping me in a perma-frazzled state for months now. Finally at point where I have some balance between work/gnome/family and am back to developing the client. If you've started work on your own client I'd still like to collaborate re: zmp.
20.0/24