Yes, color would definitely just work with subwindows. I'd be inclined to just add clear to the zmp package if we add it, so it's (obviously) useful even when not using subwindows.

For panes, Vassi and I are really just talking about a "split-window" kind of display. Those are in addition to having minipanes in a sidebar for displaying more specific information. In such a client, the server cannot guarantee anything about the size of the window, but there's no reason that a NAWS-replacement couldn't let the client tell the server what the actual size of a window is. A map window might prefer a 5x5 display, but if the client forces the window to 10x5, the server might be able to deal with it just fine.

Some MUDs draw relatively large maps on screen, especially for "overworld travel." I've seen them as big as 80x12. Some of those MUDs make use of cursor positioning to only update the player avatar when moving around or the like. These MUDs expect a client to deal with the basic ANSI codes for movement, and I imagine ZMP-capable clients will usually support them just fine. Is it unreasonable to expect subwindows to have the same capabilities as the "main" window?

My eventual goal is to be able to get a client that looks something like Simutronics' stormfront: http://www.play.net/gs4/play/stormfront-...

David, can you give a summary of how the clickable stuff in MUCHclient works?

My thoughts on that were to add a separate "click action / context menu" package (similar to what MXP can do) and just use that in conjunction with a subwindow. No need for a specialized subwindow behavior. Is there a reason that can't be reasonably implemented in MUSHclient?

I'm unsure how good of an idea it is to design packages solely on the features and limitations of a single client (especially if can be updated to remove said limitations), just as I'm unsure how good of an idea it is to design packages that we don't have a fully working test client to try the package out with. I think at some point someone is going to make a client that actually uses subwindows (maybe in an x-subwindow package to start), see how it all works with a MUD, and if we're happy with it, call it stable and move it into an official subwindow package.

Why reinvent the wheel? slackhalla.org:4321 has a pretty decent vt100 interface and it works fine with zMud, tintin, and telnet. Most mudclients don't support VT100, but all terminal emulators do, and the protocol and implementations are out there.

If you're talking about full subwindows, I guess it's not unreasonable. I was hoping for something simpler that wouldn't require a full cursor control implementation.

Let's look at some use cases. For chat, you really don't need cursor control. (Right? I can't think of any plausible reasons, but that doesn't mean there aren't any…) For a constantly updating map, you can either use cursor control to be smart about updating, or just draw the whole thing every time. But the use case isn't your primary information display in this case: a side pane of 80 characters is a pretty big side pane. Your window would have to be fairly large to accommodate 80 characters of side pane and 80ish for normal output. The use case is more likely to display a smaller map that actually needs quasi-real-time updates.

Another use case is status display. Move the prompt information (hp, mana, etc.) to a side bar. This is again fairly small, and yes, you could redraw it using cursor control.

My problem is that your solution requires a lot of smarts on the client end. For me, moving chats to another window is really almost auxiliary (even though it would be very nice). I'm interested in things that are all but impossible without a side display: the tactical map is probably the best example of this that I have.

Of course, this can all be considered from a different point of view: I would also be happy if the server said: "here is your new HP value" and the client did whatever it wanted to with that (which could mean rendering it onto the input bar as a prompt, rendering it into a side bar, rendering it into a fancy graphical slider, …).

Maybe it's worth thinking about what exactly the point of this side window business is. I get the impression that we are expecting rather different things out of it.


I have to admit that I don't see how your proposal of a simple side bar gets this, because that client has all kinds of panes. In fact it looks a lot more like the miniwindow stuff I've been talking about than what you and Vassi have been talking about, as far as I can tell.


It works with a callback mechanism. You define a rectangle, and then give callback functions for mouse over, down, up.
I'm guessing that you could implement a popup type thing fairly easily, yes.


Agreed, however, MUSHclient happens to be a good test client for this kind of stuff because it already has the ability to create these "mini-windows". Yes, they have their limitations, but it's a good place to start.


How do you write a fully working test client without knowing what the package specs are? :smile:

It might not be a "side" pane – most MUDs I've seen with ASCII maps take up the upper-half of the regular window. So if you have a standard 80x24 display, you end up with 80x8 - 80x12 on the top-half of the screen being the map and the regular text being underneath that. A subwindow would just make coding those way easier (no fancy cursor control or scroll regions), but not necessary mean that the MUD should redesign itself to constraint the map to a tiny side pane. Especially not if the map is your primary navigation means.

(I don't myself use ASCII maps. So I'm going purely off of what I've seen from other MUDs. I'd much rather see a graphical map like the automapper feature several clients have.)



Yeah. I would MUCH rather have a separate status bar package for that. So true graphical clients can draw them as pretty bars/liquid-filled-glass-balls/color-changing-boxes/whatever.



Yeah, that's the problem. Getting a package that does what we all want and isn't limited to just one specific use case and requiring an entire almost-the-same package for other uses. :)

I _am_ about adding smarts to the client. That's part of what ZMP is all about – being able to let intelligent client-side features communicate cleanly with the MUD server. That's not to say you can't use ZMP differently (it's meant to be flexible), but what you're trying to do and what I want to do are a bit different. Which goes back to why I think the community should in cases define their own packages and why I didn't just make a bunch myself – my needs are not everyone else's needs.



Many of those would be specialized widgets, not a generic subwindow concept. I was just giving an example to let you know where I'm coming from in general (versus the highly-generic reusable window stuff that MUCHclient currently relies on). Getting to the point of a client like that is going to require far, far more than just subwindows.



That's fairly sophisticated, honestly. More than I was expecting by far. It sounds like you're trying to make generic text-widgets for the kind of stuff I would have just made specific graphical widgets.

I really don't have much useful feedback for that kind of behavior. Why don't you try to add a ZMP package specifically for those kinds of windows to MUSHclient and hash out the details, and we can post the spec on the zmp site.

if it's tied to the specific behavior MUSHclient offers, it can be a subpackage in the mushclient package. Wouldn't preclude other MUD clients from using it, of course.



The same way you develop a library: you make unstable releases in which you clearly state that the API may totally change, and don't make a stable release of the client or server using that library (or make sure the library is optional and marked as BETA) until the library is "1.0."

Just replace "library API" with "ZMP commands" and there you go. :)

Well, the way I'm figuring it, the MUD wants to redesign itself to draw a tactical map. I've been trying to emphasize that it's a tactical map because it's not supposed to be some big overland map: it's supposed to show your immediate combat situation. Think a grid-based room where you have x/y coordinates that matter to combat.


Clients are not endlessly flexible programs. I just don't see how it makes sense for MUD developers to go around doing stuff that might or might not work in any given client. Sure, I make some package that makes sense for my MUD. I go to the trouble of getting client X to support it. But client Y doesn't want to, or can't short of a massive rewrite. ZMP has not accomplished any real goal here other than some way to communicate raw data.

I'm getting the impression that ZMP is just a raw data communication protocol, but wants to be a standardized way of communicating semantically rich data.

If everybody is going off writing their own "semantics packages", the protocol hasn't done anything at all in unifying them. OK, I can parse out your commands, but I can't do anything with them.


If your only goal in the exercise is to shunt chat traffic to a separate window, then yes, it's more complicated. But this map I'm talking about is extremely simple: x by y characters, clear it, draw new characters representing the current situation. No clicking at all. Hotspots are icing on the cake in some sense.


I was getting at the problem that we obviously don't even know what we want in the first place, never mind having a fixed-in-stone API.

——

To repeat something I said earlier, I'm very concerned that this is requiring clients to be far smarter than is reasonable to expect. If you start with the goal that a new client needs to be written, that's a different story. But I'm not seeing how this is going to work with existing clients that might have to completely rewrite their internals to support some of it – that's just not going to happen.

Just as we shouldn't design something exclusively to one client's limitations, I don't think it makes sense to design something assuming existing clients will be able to just fix themselves to make it work. Yes, of course, not all clients are born equal in the face of ZMP – but if ZMP is aiming to be some kind of unifying protocol, you need to at least establish common ground.

This idea of "our goals are different, let's just implement two completely different packages that clients will have to implement independently" is setting off all kinds of warning bells for me. Especially considering that the needs aren't that different.

This is actually the same argument that was used back when ANSI colour support was uncommon. MUD's that wanted to add such things worried that it would alienate users who were stuck on terminals that couldn't handle it, or that the clients of the time (tintin and tinyfugue) would be confused by it and not render it through correctly.

In the end, most MUD's either added support with a switch to turn it off per user/character, or added it and said "if it don't work, sucks to be you!"

Personally, I wouldn't worry so much about the client side of things. I assume ZMP does telopt negotiation with the server, and that the server will tell the client what all it wants to use, and then the client is free to send back "Nope, I don't know what a ZMP_flashy_bubble_widget is". If that's the case, it's up to the individual client authors to find the best way to support any particular package (or not), in what they deem is the best way to do it.

In that case, you are portraying ZMP as just a way of sending commands with arguments, and are attributing almost no semantics to it. It becomes almost meaningless to say that you "support ZMP" as a feature – supporting ZMP itself is irrelevant, it is the packages you support that matter. To me this strips ZMP of most of its usefulness as a standard.

That's not necessarily a problem, but it's not the impression I was getting of what people wanted to do with ZMP.

How are you supposed to design your game to use nice widgets if you have no idea that people will actually be able to use them? This is fundamentally different from color, mind you. Losing color doesn't mean you lose (much) actual information. Losing a tactical map can mean the difference between being able to play a game at all successfully or not.

I didn't think it was portrayed differently at any point, isn't that kind of the point of this discussion?

We've been talking about it as some kind of meaningful way of communicating windows, layouts, etc. to the client. If the answer to any complicated (read: interesting) question is "punt, let the MUDs and clients write/implement their own packages", then there isn't any standardization work going on.

Normally I have no problem telling MUD developers they're doing it wrong, but that seems a little… overbearing, even to me. If a MUD _wants_ a huge overland map, who are we to say it's wrong?



ZMP itself is just a communications protocol. The packages themselves are what define the semantics. Much like XML: standard format, but useless if you're not agreeing on a schema. ZMP is a mechanism, not a policy. The packages are the policy.

You are absolutely 100% correct in stating that there needs to be an agreed upon policy that MUDs and clients agree on. The point of ZMP is to provide the framework to build that policy over. Without ZMP (or something like it), you end up needing to develop a million different ways of communicating data. Subwindows might end up using some kind of line-based #WINDOW-COMMAND output, chat might might use <chat occ> </chat> XML-like markup, images might use some custom TELNET negotiation, etc. etc. ZMP gives you the common mechanism so all those specific packages can exist without needing a MUD or client to having a billion ways of parsing data.

ZMP is useless without the packages. No question about that. The strength of ZMP is that it is not limited to just a fixed set of specific pre-defined packages, though. It's extensible. If you – for whatever reason – want some MUD-specific package that only works with one specific client, you have that freedom. ZMP is not weakened by the possibility of oddball unique packages; it might weaken the MUDs that use them, or it may make those MUDs and their respective clients shine far brighter than all the others.

Obviously having a solid set of generic packages implemented by most clients is far more useful than having a ton of MUD-specific ones. No reason to sacrifice those just because the MUD-specific ones might exist.



Sure. Absolute perfect example use of subwindows.

My big point was that some clients may not allow arbitrarily-sized subwindows. In a client that ONLY supports "split-window" style subwindows (think a console-only client), the client may very well say that all subwindows are just vertically-split windows and so are all forced to have the same width. Not really a big deal at all – the MUD just needs to be able to be told that the window is size X by Y and the MUD can either choose to just keep drawing a 5x5 grid, use up the whole widget, whatever it wants.

A more advanced client might let the player move the windows around (e.g., slide them between a left, central, or right column), but the windows would still then be locked into the width of whichever column they're in.

I'm totally cool with a client that lets you have just arbitrarily-sized windows floating around. But that's not the only way to design a client with subwindows.

If we say that input is not supported for subwindows, then what? We need a whole separate package to add it?



I don't have a good answer. If we don't expect clients to add features, there is no point to ZMP at all. Most clients do not have MUSHclient's subwindows feature, so by your logic there, it's pointless to create a subwindow package because most clients are going to have to add a ton of code to actually support it. Where's the line drawn between expecting too much and expecting too little?

I must have been unclear. I wasn't saying that MUDs shouldn't be allowed to use big maps. I was talking about an example use case where a MUD explicitly wants a small, tactical map.


Well, ok. With this and everything else you said, what is the next step? Where is the middle ground between simple pane-based windows, and these floating windows? Is there any middle ground?

What exactly are the issues of contention between your pane windows and the thing I've been talking about? Maybe if we homed in on those we could move forward very productively.


We could use window flags like we said before, although you'd need a way to tell the server that your client doesn't allow input bars for subwindows.


Well, in practice, maybe it is. I don't really have a good answer either. It's one thing to put in small changes, like new ways of handling color that are usually easy to bolt on to a new client. A whole intelligent windowing system is a very, very complex undertaking: it's not some simple new feature that people can add quickly.

You might have said something similar to this earlier, but perhaps a reference client is needed, and then we'll just see where things go from then. In that case, either we use an existing client and bolt on the implementation (using plugins for example) or "somebody" writes a client to serve this purpose. I hardly have enough time to work on my own stuff, much less write a whole client. :thinking:

I'm not seeing the big deal here. They're the same thing.

The MUD says "create a new subwindow at 5 cols by 5 rows with id tacticalmap."

The client creates the window, but because of how it works, it stretches it out to 80 cols. In all other ways, it just works. It then sends back a ZMP window-size command to the server that basically just says "subwindow id tacticalmap has been 're'sized to 80 cols by 5 rows."

The MUD just deals with it the same way the MUD deals with the main window being resized. It just keeps drawing a 5x5 tactical map. Or it decides to start drawing an 80x5 tactical map. Maybe it centers the map. Whatever the MUD wants.

That's acceptable, yes?



Alright. So we need a subwindow negotiation command. Say, a subwindow.get-capabilities (sent from server to client) and a subwindow.has-capabilities (client back to server)?

Maybe it would be better to just have a set of commands for setting individual flags. subwindow.enable-input. Then we can just use the existing zmp.check command to check if the client supports input in subwindows. (if the client does not support it, it would not implement the subwindow.enable-input command, which the spec would state.)

Err, well, ok, then I'm confused because I thought you guys were talking about panes in opposition to what I was suggesting. I got the impression that you were saying I wanted something else, and you weren't happy with it. So I guess I was just misunderstanding?


Works for me.

Yes, I think so. It's been a crazy couple days, I'm probably talking circles around everyone (including myself) right now. I need booze.



OK. So, updated informal package specification (in a slightly nicer format):

subwindow.create (id, title, width, height) - server only

Creates a new subwindow. Each subwindow has a unique identifier, specified by the first argument. This identifier must be alphanumeric, must not be empty, and must not be equal to the string "main".

The second argument is a user-visible title for the window.

The third argument specifies the preferred width of the window in character cells, and the fourth argument specifies the preferred height in character cells. It is not guaranteed that the window will be created with these dimensions.

subwindow.close (id) - server only

Closes a previously created window.

subwindow.select (id) - server only

Selects a previously created window as the current output target. All output following the command should be directed to the specific window. The window id "main" selects the default window. If the specified window does not exist, the main window should be selected.

All output-generating commands should operate on the currently selected window.

subwindow.set-input (id, bool) - server only

Either enables or disables a dedicated input box for the selected window. This has no effect for the "main" window. The second parameter should be either "false" (disable input) or "true" (enable input).

If a client does not support dedicated input lines for windows, it should not implement this command. Servers can use zmp.check to see if subwindow.set-input is supported by the client.

subwindow.size (id, width, height) - client only

Replaces the TELNET NAWS subrequest. Allows the client to notify the server of the width and height of a window in character cells. This works for the "main" window as well.

Clients SHOULD send a subwindow.size command directly after a subwindow is first created (especially if the window was not created with the same size as requested), and whenever a user resizes a subwindow.

subwindow.input (id, line) - client only

If a subwindow has input enabled, this allows the client to send a line of input to the server for a specific subwindow. Also works for "main", in which case it is equivalent to the zmp.input command or simply sending a line of text. If the specified subwindow id does not exist, the server should ignore the input.

subwindow.flamewar (id) - server or client

Makes elanthis send incomprehensible gobblegook that confuses everyone.

Some comments:

"It is not guaranteed that the window will be created with these dimensions. "
–>
"Note that the client might create the window with other dimensions. See subwindow.size."

"If the specified window does not exist, the main window should be selected. "
I thought we said we wouldn't do this? Or was it that the client can't "close" windows, and instead only hides them?


No subwindow.clear option? (Or did we move that to another package somewhere?)

—

Oh, and I like the flamewar command. But there should be a parameter that specifies who elanthis flames. :tongue:

That the only wording change to recommend? That was just meant to be an informal draft, but might as well start formalizing it I guess.



Yeah, that was about the closing thing, and I think we agreed that hiding a window is identical to closing it, except better. That should probably be cleared stated in spec.



Did we come to a consensus on that? We talked briefly about having a separate terminal package that replaces the basic ANSI features, don't think we agreed on whether that is necessary or not. I think both you and Vassi agreed that you wanted to axe ANSI entirely (which still seems silly to me, because your clients are still going to support it, and your servers will still need to send them for non-ZMP clients, but what the people want, the people will get). If a ZMP solution is desired but there isn't enough functionality to justify an entire terminal package (because we don't do cursor control or anythinig), should clear perhaps be in the core zmp package (it seems pretty universal, not dependent on subwindows).

I think if we want to replace ANSI, a terminal package probably is the best bet. Some MUDs really do want cursor control. The terminal package could clearly note that all commands in the package are optional and that a server should check if the specific command it wants exists, because even clear is hard to do in a pure HTML terminal widget (my CSS skills are not the bestest, but I couldn't figure out how to make it work), and cursor control in most custom terminal widgets is also pretty hard. I could see a clear screen, clear line, cursor position, and I'm sure I'm forgetting something… maybe a "graphics mode" command for the VT100 drawing characters, http://vt100.net/docs/vt100-ug/table3-9.... .

Oh, man, that brings up memories of grade school and making goofy little QBASIC RPGs that rendered in the "extended ASCII" graphics set: http://www.jimprice.com/ascii-dos.gif . Yeah, those were the days. (of suck)

Maybe leave off the graphics one and just recommend people to use UTF8 and the Unicode drawing characters? http://sti.pooq.com/Tech/UnicodeLineDraw...

I wonder how many MUD servers or clients know to enable BINARY mode and negotiate encoding? (I'm sure anything written by Tyche does, because he's anal about that stuff. Everyone else I'm quite unsure about.)

Could add a terminal.size commands for replacing NAWS for non-subwindows, too.

subwindow.size would need to stay since it has to specify a subwindow id. Just like subwindow.input has to exist even though there's a zmp.input, due to the need to specify subwindow id. I don't want the core package dependent on or using features in other packages, but I don't think a client should have to implement the whole subwindow package just to get a couple commands useful even without subwindows. le sigh.

But then I feel icky having both core package versions and subwindow versions. I don't really see a clear way around that, though, so I may just have to deal with it.

</rambling>



Oh, good idea. Defaults to 'everyone' because I'm a jerk.

Clear should probably belong to another 'output control' package. I would definitely like to replace ASCII for color and style definition, zmp.color is just not enough I don't think, we should be able to define an entire style which includes formatting.

If we go and do that then a bit of the rest would definitely be nice. I honestly don't know much about unicode other than that it uses more than one byte to render characters, and that UTF8 and ASCII are compatible up to byte 255 (obviously). .NET has plenty of unicode support, and I'm a quick study, so I'm not too worried about being able to implement it once I start looking into it.

I'm not too concerned with package dependency, especially not if we're defining a suggested core set. For instance, packages are already kind of dependent on zmp.check (it's a stretch to say so, I know). I feel, if nothing else, that output commands would be core where subwindow would be extra, so if you have subwindow you'd have core, which would include all the sugar of output.

Its late for me so I apologize if I'm talking in circles, but i'm still a bit torn on the VT100 and ASCII stuff. Again I know nothing about VT100, so I'm not sure how difficult that is or is not to implement, but it does feel weird to essentially replicate functionality that already exists - that is unless we can do it more elegantly with ZMP. I would rely on you guys to make that call, as the only thing I have used is ASCII codes. I really like the way ZMP makes it more straight forward to pick out what 'state' your output should be in, parsing text as it comes in is tedious. In the interest of full disclosure, part of my annoyance with the parsing is the way WPF's rich text control works. Adding text to it is a strange combination of HTML and XML and you have to make a couple of assumptions when you're doing text, assumptions which are annoying to go back on when you run into codes in the text. ZMP allows me to be completely secure in my assumptions.

Would it be fair to expect that in particular ZMP, MXP, MCP and Pueblo cannot all be active at the same time?
That only one may be active and it ought to be the last one successfully negotiated?
Of course the way ZMP is structured in packages, and as it exists in core, isn't necessarily incompatible with any of them.
What about MSP, MSP2, MCCP2, other Telnet options?
It would seem for example MSP isn't incompatible with ZMP, if the zmp.sound package can't be negotiated.
I thought these might be rare cases, but with Mushclient being open source and all, it certainly becomes possible to have all the aforementioned protocols implemented in a single client.
Is there any value to an authentication/session key core package negotiation in ZMP, like MCP does?

MUSHclient miniwindows don't have any kind of ANSI support; you'd have to do it all yourself as the plugin author. (Or, Nick would have to provide some mechanism to handle it easily – whatever.) The point is that all I want is simple clearing, not full ANSI control. So I don't need to complicate my life with the whole shebang. Do you have use cases for full terminal control?

(It's worth mentioning that MUSHclient doesn't support any kind of cursor positioning commands, and never has.)


Just to be clear: I don't really care either way, I just want to be able to clear the screen. I have no objections to playing with terminal control, I just don't need it. But having it is probably a good idea.


Well, they do slightly different things, and you can't get all the birds with one stone, so, yeah…

Actually, the standard client–>server input command can still be useful, and the server can probably treat it identically to the main window client–>server input.


I think the last bit says it best, IMO at least. Embedded codes are nice and all, but separating output from state setting (i.e., "turn on color 'red'", or, "turn on color used for friendly tells") means it is veryveryvery easy to parse; in fact there's basically no parsing at all.


I guess so, although it would more be a question of "why would the MUD do that?" rather than "must the MUD not do it?".


I'm not familiar with what MCP does. But being able to auto-send user/password/whatever on request is a nifty feature of MXP that I think ZMP should have.

I gave one a few posts back, slackhalla.org:4321, Shattered Kingdoms, Altered Reality, and Roguelikes come to mind as well.

Clearing an entire display is done with \e2J, needless to say that mushclient sucks in the VT100 department.