Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUDs ➜ General ➜ Suggested protocol for server to client "out of band" messages
Suggested protocol for server to client "out of band" messages

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2  3  4  5  6  7  8  9  10  11  12  13  14 15  16  17  18  19  20  21  22  23  

Posted by Xtian   (53 posts)  Bio
Date Reply #195 on Sat 20 Feb 2010 05:52 AM (UTC)
Message
Nick Gammon said:

Again I think we need to distinguish between semantics and presentation. I am not envisaging the server specifically saying "put up 5 windows".
[...]
Compare for example, the amount of information you could show on an iPhone, compared to a 21" monitor.


Point. I was thinking more on the lines of semantically grouping messages together. Call what I defined as "window=..." a "flag".

Then, having the plugin opening a mini-window for (all) things semantically messages could be acceptable, no? Think of the WoW GUI where messages have a fixed place to appear - and as I said, many users do this in MUDs (I'm thinking of some IRE libraries), so there is a real world use-case for this.

Then, improving the plugin, the next step would be to handle different message flags visually differently, no?

Warning messages and channel messages should be a generalized enough concept.
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #196 on Sat 20 Feb 2010 05:53 AM (UTC)

Amended on Sat 20 Feb 2010 05:57 AM (UTC) by Twisol

Message
Are you talking about literal messages, like warnings or chats? I don't really think those would be sent over this protocol, but if they were, it would still be up to the client on how to display them. There are a few WoW mods that do in fact direct incoming channel messages elsewhere, IIRC - it's not hardwired, and it's still a choice by the client, not the protocol.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #197 on Sat 20 Feb 2010 06:01 AM (UTC)
Message
Nick Gammon said:

Twisol said:

MXP isn't the only way to make things clickable...


Absolutely. The inventory plugin I did for Aardwolf let you click on items in the inventory (I think Twisol did something similar) but did not use MXP.


I have no knowledge of another way of doing this? But I'm guessing you are referring to a MUD-specific, client-specific technique implemented for one plugin? But that is not what we where aiming for here.

MXP lets me tell the client: If you left-click you can view this. If you right-click you can choose between taking it, examining it, etc. ... in any language. We don't want to have such information in this spec, do we? So the best way would be to let the server pimp up the information it is sending with an already established protocol the same way it is handling text in the clear.

So the question is: Are we beneath or above MXP tag parsing, ANSI, etc?
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #198 on Sat 20 Feb 2010 06:02 AM (UTC)
Message
I think we are all on the same page here, which is gratifying.

If I may suggest, this might be the "year of the MUD".

From what I have read people are getting bored with WoW (and I am not sure the competitors really cut it). They have an expansion coming out "sometime" which might be much later this year.

If you can get MMO players onto your MUD, but present things reasonably helpfully (eg. status bars, and the other sort of stuff I am demonstrating) you might have a good chance to get quite a few new players.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #199 on Sat 20 Feb 2010 06:05 AM (UTC)

Amended on Sat 20 Feb 2010 06:06 AM (UTC) by Twisol

Message
It's the most client-inspecific method of all: let the client decide how to do it. With MUSHclient, a plugin can get the message data and display a graphical representation of it in a miniwindow, with clickable hotspots if applicable. In clients that don't have graphical functionality like that, they might opt to echo a different representation of the data onto the output area, which might be clickable in a similar manner to what MXP results in.

I believe telnet subopt negotiation, of which this protocol is based on, would be beneath MXP and ANSI, because those formats are part of the text, and this protocol takes advantage of a feature of TELNET itself.


EDIT: Nick, count me in with one of the bored-of-WoW-ers. I found Achaea after quitting WoW a while back. ;)
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #200 on Sat 20 Feb 2010 06:08 AM (UTC)
Message
Twisol said:

Are you talking about literal messages, like warnings or chats? I don't really think those would be sent over this protocol, but if they were, it would still be up to the client on how to display them. There are a few WoW mods that do in fact direct incoming channel messages elsewhere, IIRC - it's not hardwired, and it's still a choice by the client, not the protocol.


I was abstracting all text, grouping it into relevant categories. (at the moment this would mean for the server to double that output over the telnet SB).
The plugin could then choose what to do with it.

Warnings and channels were a minimum case that I proposed to handle specifically. As some MUDs also send maps and it would be nice to give them a window, I proposed giving every such "message category" its own window.
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #201 on Sat 20 Feb 2010 06:14 AM (UTC)
Message
Xtian said:

Warnings and channels were a minimum case that I proposed to handle specifically. As some MUDs also send maps and it would be nice to give them a window, I proposed giving every such "message category" its own window.


Sure, why not? My point is just that it's not something the protocol itself needs to worry about, but those who define their own messages, and the clients that receive them.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #202 on Sat 20 Feb 2010 06:30 AM (UTC)
Message
Twisol said:

It's the most client-inspecific method of all: let the client decide how to do it.


I get the whole "separate presentation from the data" argument. Really.
But what we are doing here is giving every MUD out there a GUI design out-of-the-box. The way Nick is going to arrange and display his bars and mini-windows will be THE LOOK of thinks. The GUI standard, if you want.
Keep this in mind please, when you argue that we are not talking about layout and design. When the server sends data for a health-bar and it is automatically displayed in the way Nick programmed his generic plugin to do it, then the server is effectively assigning the client to present it in that way.

And that is the strength of the whole effort. (it works out-of-the-box).

Now, the question is, what use-cases are general enough and applicable enough for most MUDs out there. Those we should include in the plugin-spec.
A MUD/user will always be able to locally add to this with its own extensions/plugins, of course.

I tried to give an abstract semantic to categorised text and 2-3 use-cases I think that would be used by more than my MUD. That probably didn't come across clearly enough.

Then I said you could open a miniwindow for every text category the MUD sends. If that is too flexible in your opinion, don't throw away the whole idea. It could still be applied only to some special text categories.

Quote:

I believe telnet subopt negotiation, of which this protocol is based on, would be beneath MXP and ANSI, because those formats are part of the text, and this protocol takes advantage of a feature of TELNET itself.


Yes, as do I believe. So, back to my first question: Nick, would this work with your actual implementation? ;)
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #203 on Sat 20 Feb 2010 06:35 AM (UTC)
Message
Hmm, lots of posts since I last checked...

Quote:
Can you group with NPCs? You can't in WoW. Or at least, you can't follow them, you get a message "you can't follow that unit".

As Xtian said, grouping with NPC henchmen in games is not only possible, it actually happens. I'm not sure we should be taking WoW as the reference point for all aspects of the design. This is the danger in developing such a protocol with a relatively small audience: it's easy to omit things that other games are doing.

SMAUG doesn't really have GUIDs although it does have the pointer addresses, which would work at least as unique during the lifetime of the objects in question. But presumably, if a server wants to make use of session-unique numbers, they will be willing to cooperate enough to add these numbers.

Quote:
I'm not sure what you would do, in a simple display (eg. room contents) that would require multiple flags (eg. is water, can be carried, and can be drunk). This sounds more like the level of detail you might want if you examine something.

Well, you could color things if they're water, and sort them by whether you can pick them up or not; perhaps your presentation layer will entirely separate decorative objects from objects that can be manipulated. Etc.

Basically there's no reason for the inherent "type" to be water and for moveable to be a separate property. If 'water' is the type, what are fountains? What about type 'furniture'? Now fountains are either water or furniture?

This is part of what I was getting at with the complexity of ontologizing this stuff. I get nervous about fixing concepts too rigidly like enforcing types, and would prefer a more free-form list of properties simply because it's extraordinarily difficult for us to capture all existing uses, let alone predict future uses.

Quote:
Being able to glance at the screen, and take in the basic information about who you are with, their status, if you are fighting or not, and if so, how the battle is going, gives the whole thing a sort of fun immediacy which gets you involved in it.

Yes, I completely agree. Having information like this is very valuable and helps bridge the gap between purely textual and graphical games. This is partly why I'm eager to try to get it more right this time around than previous attempts made by other people.


Xtian said:
When the server sends data for a health-bar and it is automatically displayed in the way Nick programmed his generic plugin to do it, then the server is effectively assigning the client to present it in that way.

This is a point worth considering, although I don't see why there couldn't be several "skins" distributed out of the box to change how things are displayed. And remember that MUDs will have to speak this protocol for anything to actually happen, so they could provide their own data for the client to display.

I think it would be wonderful for MUDs to provide a stylesheet of sorts, for example. This way the MUD could choose colors, maybe even graphical elements, for some kind of coherent theme. It would also let the MUD choose if HP should be displayed as a horizontal or vertical bar, for instance, without changing the actual data being sent -- and without removing the freedom for the player to change things if they feel like it.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #204 on Sat 20 Feb 2010 06:45 AM (UTC)
Message
David Haley said:

I think it would be wonderful for MUDs to provide a stylesheet of sorts, for example. This way the MUD could choose colors, maybe even graphical elements, for some kind of coherent theme. It would also let the MUD choose if HP should be displayed as a horizontal or vertical bar, for instance, without changing the actual data being sent -- and without removing the freedom for the player to change things if they feel like it.


A form of CSS itself would actually work rather nicely for that... I like the idea.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #205 on Sat 20 Feb 2010 07:01 AM (UTC)
Message
What I like in this discussion is that we seem to have united all three perspectives to this: client, user, mudadmin.

As a MUD administrator my dilemma is this: I have a great game. I want people to see it and use it. But unfortunately, because of the nature of the thing, I don't have any access to the client program. The telnet client an my server a separate entities. I am not in control of how the user experiences my game and this greatly limits me. (in most games the way it is visually experienced plays a big part, thats why we buy big 3D graphic cards).
It also is a burden for the players, because they have to be advanced users before they can learn to adapt their client/GUI - with script and plugins, etc. If I had control over that, I would do it for them - at least for the inexperienced users - so that they had a better interface to my game.

... which would be more fun for them and give the game an overall better first impression.

Now, with this protocol, the real use for me is exactly to amend that situation.
To simply have another way to hide data in telnet subnegotiations is not new. The interesting thing is that, for the first time, I have more or less direct access to the GUI. Or at least I can have a GUI at all. And I can tell it what to do!

Still, nobody wants to give me full control over the GUI, I just get to give hints. But since my hints will be adequately displayed (i.e. health in a health bar) I am happy.

BTW: I see the mushclient<->aardwolf plugin collaboration as a first generation to this, making this generic plugin thing the second generation: mushclient<->everybody

xtian
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #206 on Sat 20 Feb 2010 07:15 AM (UTC)
Message
David Haley said:

I think it would be wonderful for MUDs to provide a stylesheet of sorts, for example. This way the MUD could choose colors, maybe even graphical elements, for some kind of coherent theme.


I'm a bit afraid this would over-complicate things for the moment. Mainly, it would increase Nicks and the mudadmins workload, making it less probable that the protocol would see the day of light or be widely adapted.

What I plan (see my other posts about incorporing MXP) is to send ANSI colour tags along with the protocol (*) information (server to client). That way the server decides which colour theme to use.

But the server may also make it possible for the player to change the server colour theme.

(*): ANSI colour for text elements like roomin. Of course for the graphical gauges we will have a "clr" hint in the datagram.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #207 on Sat 20 Feb 2010 07:02 PM (UTC)
Message
Xtian said:
I'm a bit afraid this would over-complicate things for the moment. Mainly, it would increase Nicks and the mudadmins workload, making it less probable that the protocol would see the day of light or be widely adapted.

Hmm, not really, at least not on the server end. There will have to be some kind of default behavior anyhow (such as, oh, the one Nick has now...), so MUDs without stylesheets will simply get that default behavior. As for the client end, yes, it will mean more work, but no that much more so. And libraries like Twisol's miniwidget framework will (hopefully) make it that much easier to manipulate GUI elements.

Quote:
(*): ANSI colour for text elements like roomin. Of course for the graphical gauges we will have a "clr" hint in the datagram.

I'm not sure how this is meant to be easier than controlling the same using a CSS of sorts. In fact, you'll have to add color, background color, gradient color range, border color, oh and border thickness, but wait also border style, and then you've got text color on the background color, ......

I'm really quite opposed to the data encoding its own color, even if it's just a "hint". (Besides, the "hint" situation is either very limited, or will need to support "hints" for the entire presentation layer.) I'm not sure what is gained by encoding a 'clr' (why can't we use the full word?) hint in the message as opposed to a preamble that says something like: "all 'HP' elements of the 'prompt' message should be colored in 'red'".

That said I have no real opposition to ANSI colors being sent for things like room titles although it should be kept in mind that if the text is being rendered onto something other than the main window, this will also create more work because the client will have to add another place for parsing and switch text rendering colors partway through as it draws onto the miniwindow.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #208 on Sat 20 Feb 2010 07:04 PM (UTC)
Message
By the way...

Xtian said:
If I had control over that, I would do it for them - at least for the inexperienced users - so that they had a better interface to my game.

... which would be more fun for them and give the game an overall better first impression.

Now, with this protocol, the real use for me is exactly to amend that situation.

I don't think you're really prevented from doing this already; you have full control over MUSHclient's miniwindowing system and can package an entire setup for your players to download, similar to what Aardwolf has done. The advantage of this protocol as I see it -- over and beyond a one-MUD-one-client integration -- is that many MUDs can use it and get a better experience out of the box.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #209 on Sat 20 Feb 2010 07:50 PM (UTC)
Message
Xtian said:

Then I said you could open a miniwindow for every text category the MUD sends. If that is too flexible in your opinion, don't throw away the whole idea. It could still be applied only to some special text categories.

Yes, as do I believe. So, back to my first question: Nick, would this work with your actual implementation? ;)


Certainly I think that abstracting chat messages to another "message type" is possible and desirable. The channel name or type could be part of the message. Then the client may display all channels together, separate them, or simply discard some (eg. trade chat, or newbie chat). Of course, for efficiency you probably want to stop the server sending chat messages the client won't display.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

928,612 views.

This is page 14, subject is 23 pages long:  [Previous page]  1  2  3  4  5  6  7  8  9  10  11  12  13  14 15  16  17  18  19  20  21  22  23  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home