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 Twisol   USA  (2,257 posts)  Bio
Date Reply #180 on Sat 20 Feb 2010 04:13 AM (UTC)
Message
I dipped my toes into WoW scripting a while back, and I agree that the system they have is definitely a great setup!

As for having multiple flags, send a table: {"water", "movable"} for example.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #181 on Sat 20 Feb 2010 04:19 AM (UTC)
Message
Twisol said:

*shake* Your transactions are all single, like "inroom" and "move" and "group". The example I gave, "subwindow.open", is a message (open) within a namespace (subwindow).


The distinction between transactions and message eludes me a bit.

In fact, I think this is heading towards what I think is wrong with MXP, that it tries to describe in too much detail the presentation of the data (eg. allowing you to specify bold, underline and colour, inline with your data).

IMHO the important thing is to supply semantic information (eg. there is a mob here which is level 20 and it is aggressive). The client can then, if it wants to, put the mob's name in red, and ring a bell. Where that name goes, and if it appears on the screen at all, is a client issue, not something the server should concern itself with.

I agree that if we get to the stage of client-to-server messages (which I haven't yet) then the client may send something like "get meat from bag; eat meat", and preferably using GUIDs, so it would be "get item 38534 from bag 32193498; eat item 38534".

When you say "it isn't a message" I am trying to get a system where the server keeps the client up-to-date with the overall situation - like telling the client what is in the room with it. That isn't a message as such, it is information. I suppose it depends on how you define the word "message".

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #182 on Sat 20 Feb 2010 04:22 AM (UTC)
Message
Twisol said:

As for having multiple flags, send a table: {"water", "movable"} for example.


How would you sort such items? If you want water together for instance? I think you are grouping unlike things here, like "tall" and "red-head".

You conceivably could have another table of dispositions (eg. typ="water"; moveable=true) but maybe this level of detail is something you would get from a client-to-server query as I described before.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #183 on Sat 20 Feb 2010 04:37 AM (UTC)
Message
Nick Gammon said:

Twisol said:

*shake* Your transactions are all single, like "inroom" and "move" and "group". The example I gave, "subwindow.open", is a message (open) within a namespace (subwindow).


The distinction between transactions and message eludes me a bit.

In fact, I think this is heading towards what I think is wrong with MXP, that it tries to describe in too much detail the presentation of the data (eg. allowing you to specify bold, underline and colour, inline with your data).

IMHO the important thing is to supply semantic information (eg. there is a mob here which is level 20 and it is aggressive). The client can then, if it wants to, put the mob's name in red, and ring a bell. Where that name goes, and if it appears on the screen at all, is a client issue, not something the server should concern itself with.

I agree that if we get to the stage of client-to-server messages (which I haven't yet) then the client may send something like "get meat from bag; eat meat", and preferably using GUIDs, so it would be "get item 38534 from bag 32193498; eat item 38534".

When you say "it isn't a message" I am trying to get a system where the server keeps the client up-to-date with the overall situation - like telling the client what is in the room with it. That isn't a message as such, it is information. I suppose it depends on how you define the word "message".


Eh, no. I'm using "transaction" and "message" interchangeably based on your original usage of "transaction". In technical terms, a message is uniquely defined by its name and the namespace(s) it's located under. It's precisely the same concept as C++ namespaces: it allows you to (a) group similar messages together under a namespace, and (b) use the same message name under other namespaces.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #184 on Sat 20 Feb 2010 04:39 AM (UTC)
Message
Nick Gammon said:

Twisol said:

As for having multiple flags, send a table: {"water", "movable"} for example.


How would you sort such items? If you want water together for instance? I think you are grouping unlike things here, like "tall" and "red-head".

You conceivably could have another table of dispositions (eg. typ="water"; moveable=true) but maybe this level of detail is something you would get from a client-to-server query as I described before.

I don't know. It was a quick response to a problem that was mentioned, about supplying multiple flags. The two flags given were just the two previously mentioned.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #185 on Sat 20 Feb 2010 05:10 AM (UTC)
Message
Twisol said:

Eh, no. I'm using "transaction" and "message" interchangeably based on your original usage of "transaction".


I appear to have misused the English language here.

I understand transaction to mean "something that has to be done" (eg. a banking transaction). (And looking at Wikipedia to refresh my memory, you might add "something that has to be done as a complete unit, or not at all).

I really meant that the messages passing from server to client are nothing more than notifications of some changed state, not something the client has to act on in any particular way (it may choose to display the information but it has no obligation to do so).

These are more like Windows messages, that is, a notification that some event has happened (eg. in the case of an operating system, that a key has been pressed). In my case I was notifying the client that something has changed at the server end (eg. someone left the room).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #186 on Sat 20 Feb 2010 05:17 AM (UTC)
Message
*nod* Right, that is the kind of message I've had in mind as well.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #187 on Sat 20 Feb 2010 05:24 AM (UTC)
Message
Fantastic how this is evolving.

I'll try to get a few details in:

- NPC groups: in our MUD we can group with NPCs, so I'd appreciate it if it were possible

- percent bars: An alternative to the stats that MUDs that hide some absolute numbers could use. Just send the percent value the player has achieved instead of the max value. (or send the percent value AND the current absolute value. albeit only for mouse-over)

- bar colour change: Make it possible for the MUD to change the bar colour. Example: When the HP falls beneath 10 points the MUD sends a colour change suggestion to "red"

- global warning: some messages from the MUD are important and should not be missed: You died, your buff collapsed, a reboot notice, ... We could implement such a message, that lets the client background/borders light up, make the taskbar blink ... something like this. See next item for a "msg" type.

- dedicated custom windows: I know many of my users like to extract and put channel messages in seperate windows from the normal textflow. We could abstract this by sending messages that are tagged to windows the plugin creates: msg { text= ...; window= "channels" }. Other possible fields are: warning= true (see above), clr (colour hint - or simply keep the ANSI colour).
This could also be used to extract the map to a different window, for those MUDs who have ASCII-art maps.

- is it possible to keep the MXP parsing active for contents of some of these? It would be great if inroom, msg (see above), exits were/stayed click-able.

I'm looking forward to implementing this.
xtian
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #188 on Sat 20 Feb 2010 05:29 AM (UTC)

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

Message
(EDIT: Nick, if I'm stepping on your toes or just plain wrong, please prod me. >_>)

Xtian said:
Fantastic how this is evolving.

I'll try to get a few details in:

- NPC groups: in our MUD we can group with NPCs, so I'd appreciate it if it were possible

- percent bars: An alternative to the stats that MUDs that hide some absolute numbers could use. Just send the percent value the player has achieved instead of the max value. (or send the percent value AND the current absolute value. albeit only for mouse-over)

- bar colour change: Make it possible for the MUD to change the bar colour. Example: When the HP falls beneath 10 points the MUD sends a colour change suggestion to "red"

- global warning: some messages from the MUD are important and should not be missed: You died, your buff collapsed, a reboot notice, ... We could implement such a message, that lets the client background/borders light up, make the taskbar blink ... something like this. See next item for a "msg" type.

The MUD can define whatever of its own messages it wants, this protocol simply defines how exactly to encode the messages and data. It's not really our job to place restrictions or limitations on specific messages.

Xtian said:
- dedicated custom windows: I know many of my users like to extract and put channel messages in seperate windows from the normal textflow. We could abstract this by sending messages that are tagged to windows the plugin creates: msg { text= ...; window= "channels" }. Other possible fields are: warning= true (see above), clr (colour hint - or simply keep the ANSI colour).
This could also be used to extract the map to a different window, for those MUDs who have ASCII-art maps.

This is more of a presentational effect. You could have a package that's explicitly intended to be used for custom windows, or the client itself could let a user handle messages and create windows themselves. It's not really something inherent to the protocol itself (or it shouldn't be), but it is handy however it's done.

Xtian said:
- is it possible to keep the MXP parsing active for contents of some of these? It would be great if inroom, msg (see above), exits were/stayed click-able.

The contents of this protocol are invisible, so MXP makes absolutely no sense within it. The client would display messages in a format that is sensible to it, which may or may not include links; it's up to the client.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #189 on Sat 20 Feb 2010 05:30 AM (UTC)
Message
Xtian said:

- percent bars: An alternative to the stats that MUDs that hide some absolute numbers could use. Just send the percent value the player has achieved instead of the max value. (or send the percent value AND the current absolute value. albeit only for mouse-over)


Certainly, this I have allowed for. You can either specify current and maximum, or a percentage. The difference is that if you hover over the bar, and the current and maximum are known, it will tell you (eg. 20 / 80 (25%) ). However if only a percentage is supplied then that is all it shows.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #190 on Sat 20 Feb 2010 05:42 AM (UTC)
Message
Xtian said:

- global warning: some messages from the MUD are important and should not be missed: You died, your buff collapsed, a reboot notice, ... We could implement such a message, that lets the client background/borders light up, make the taskbar blink ... something like this. See next item for a "msg" type.


Again I think we need to distinguish between semantics and presentation. I am not envisaging the server specifically saying "put up 5 windows". However I agree that something like "MUD going down in 5 minutes" could conceivably be put into an "important warning" message type.

I think things like buffs disappearing are the sort of things that plugin writers could work on. For example, a "buff manager" plugin (there are similar things in WoW). I don't think the server should micro-manage what the client presents. Compare for example, the amount of information you could show on an iPhone, compared to a 21" monitor.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #191 on Sat 20 Feb 2010 05:42 AM (UTC)
Message
Twisol said:

Xtian said:
- is it possible to keep the MXP parsing active for contents of some of these? It would be great if inroom, msg (see above), exits were/stayed click-able.

The contents of this protocol are invisible, so MXP makes absolutely no sense within it. The client would display messages in a format that is sensible to it, which may or may not include links; it's up to the client.


It makes sense as with the example I provided. It is rather a technical issue, along the lines of
- do we keep or strip ANSI codes?
- what encoding do we use?
- what do we do with IAC?

Remember: Mixing MXP Tags and ANSI codes proved to be a problem for example for all clients. It is a very real implementation issue and we should get it hammered down early.

As I said: It would be cute to have click-able room inventories. And since the "technology" is already there client and server-wise this seems reasonable to me.
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #192 on Sat 20 Feb 2010 05:45 AM (UTC)
Message
Xtian said:

It makes sense as with the example I provided. It is rather a technical issue, along the lines of
- do we keep or strip ANSI codes?
- what encoding do we use?
- what do we do with IAC?

Remember: Mixing MXP Tags and ANSI codes proved to be a problem for example for all clients. It is a very real implementation issue and we should get it hammered down early.

As I said: It would be cute to have click-able room inventories. And since the "technology" is already there client and server-wise this seems reasonable to me.

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

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #193 on Sat 20 Feb 2010 05:47 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #194 on Sat 20 Feb 2010 05:51 AM (UTC)
Message
Xtian said:

Remember: Mixing MXP Tags and ANSI codes proved to be a problem for example for all clients. It is a very real implementation issue and we should get it hammered down early.


I think that was an example of the MXP protocol not specifying whether it was above or below the ANSI protocol.

In any case, I don't envisage any clash between these protocols. As far as I am concerned the telnet protocols are invisible to MXP, which may or may not be there alongside it.

Also, as I have been trying to say, I don't envisage you would say things like "show this in green".

You make an interesting point about showing your health in red as it gets low, but this is the sort of thing a custom plugin could do (eg. if health is less than 10% show it in red). I think trying to micromanage the presentation at the server end is a mistake.
- 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 13, 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