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 Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #210 on Sat 20 Feb 2010 08:04 PM (UTC)
Message
David Haley said:

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.


No, agreed. However WoW with its 10+ million users must be doing something fundamentally right with its overall user-interface.

David Haley said:

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.


Agreed again, and indeed Aardwolf did just that for objects.

David Haley said:

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.


My reference point here was what you currently see when you look around a room. A one-line description of things. Then I noticed that Smaug coloured some of them, so added enough extra information to colour them too.

I don't know that, for the purpose of a quick "glance around the room" you want to send down weight, cost, all possible flags, etc. when you have no plans to use that data.

What *might* be useful is a "can interact with" flag. Eg. in WoW things you can interact with make the mouse pointer turn into a gear shape as you move over it. So for example, fountains can be drunk from, objects can be picked up, food can be eaten, corpses can be looted. That could certainly be useful. This is heading towards what you do with MXP and its popup menus of interaction.

David Haley said:

This is part of what I was getting at with the complexity of ontologizing this stuff.


Ah, religion again. :P

David Haley said:

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.


What I was thinking of as a next iteration is to do this:


  • Allow free-form types to be sent which in themselves have no specific meaning
  • As part of the "hint" message state a relationship between types and the colours to display them (eg. "water" = "blue").


As for flags, I think a type is unique to the object (it is water or it is food, etc.) however other flags like ("can wear it", "can move it", "can sell it") are more like a set.

Again, I think this extra detail might be better implemented as part of something you do when you "look", "examine" or "consider" the object.

Actually in my next iteration I think I'll try to make things more efficient, thus solving these extra issues you raise (like supplying more detail) but sending even *less* data every time you walk into a room. The word "cache" springs to mind here.
- Nick Gammon

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

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.


(And with reference to the CSS idea) ....

There are two parts here. The *default* user interface, which you get with no effort, would have limited customization. Such as, specifying that certain types of bars are displayed in green, and certain types of objects in brown.

Once you start saying "I want to display my group in a completely different way" then this is where custom plugin-writers appear out of the woodwork (as they have done in their thousands for WoW) and take the raw data and re-present it.

And indeed some of those plugins (addons they call them) are themselves highly customizable.

I think, to get this general concept off the ground initially, I would not like to go too far down the path of style sheets etc., because that is just delaying a workable end result.

However if you can argue that any design aspect *absolutely prohibits* adding such functionality in the future then that design aspect would need modification.

I should add that one of the features of the Lua interface is that you can always add stuff, and indeed I am doing just that. For example, first I send down the mob's name. Later I add "level=5", but the original plugin still works, it just ignores the extra data.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #212 on Sat 20 Feb 2010 08:15 PM (UTC)

Amended on Sat 20 Feb 2010 08:17 PM (UTC) by Twisol

Message
In regards to "caching", I'd prefer that the server just send GUIDs for the items, mobs, etc. and provide an API to query for more data against those GUIDs, just like WoW does. Then, you can choose whether or not to re-query next time, but all the MUD ever -has- to do is send GUIDs to mark that those entities are present.

EDIT: Also, just to note, I'd like to make sure that whatever comes out of this will be feasible to incorporate into other clients too eventually. The CSS thing would give any client a good standard to target, mapping the details to internal client-specific functionality. I think it would make it easier... but you're right, that's something to consider later on.
'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 #213 on Sat 20 Feb 2010 08:16 PM (UTC)
Message
David Haley said:

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'".


Initially I was sending the "clr" field with each piece of data, then moved it into a hint. When being sent once it may as well be spelt in full. The first idea was just to save the number of bytes being sent.

I take your point about colours, but I was trying to make a system where the default plugin would at least show health and mana in different colours, even if they weren't called health and mana per se. And indeed maybe the CSS idea isn't so silly once you decide to send the colours once and not attach them to every message.

Already the plugin has some colours I picked out of the air for things like borders, shadows, background etc. It would be minimal work to let the server specify that once off, when you connect. And authors of other plugins could use them if they want, or ignore them.
- Nick Gammon

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

In regards to "caching", I'd prefer that the server just send GUIDs for the items, mobs, etc. and provide an API to query for more data against those GUIDs, just like WoW does. Then, you can choose whether or not to re-query next time, but all the MUD ever -has- to do is send GUIDs to mark that those entities are present.


Which is *exactly* what I had in mind. ;)
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #215 on Sat 20 Feb 2010 08:25 PM (UTC)
Message
David Haley said:

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.


Yes but then they get reused unfortunately. An address 0x123456 could be a naga one minute and a carrion crawler the next.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #216 on Sat 20 Feb 2010 08:27 PM (UTC)
Message
Quote:
No, agreed. However WoW with its 10+ million users must be doing something fundamentally right with its overall user-interface.

Doing something right with its overall interface isn't the same thing though as making game design choices like not grouping with NPCs. So while emulating interface might not be a bad idea, emulating game design is another question -- and besides you will never be able to convince all MUD devs out there to only do what WoW does. ;)

Quote:
I don't know that, for the purpose of a quick "glance around the room" you want to send down weight, cost, all possible flags, etc. when you have no plans to use that data.

It's not so much to send stuff you don't plan to use, but rather to not lock yourself into not being able to send more stuff.

Quote:
Actually in my next iteration I think I'll try to make things more efficient, thus solving these extra issues you raise (like supplying more detail) but sending even *less* data every time you walk into a room. The word "cache" springs to mind here.

What about compressing all this using zlib or something like that? Stuff can be cached client-side, and also zlib compression will do a good job of removing repeated information.

Quote:
I take your point about colours, but I was trying to make a system where the default plugin would at least show health and mana in different colours, even if they weren't called health and mana per se.

I'm not sure how you can enforce this without the server attaching at least some semantic data along the lines of "this represents health" and "this represents mana", unless you decide that all of these things should be displayed in bars of different colors.

What I like about the CSS-like approach is that it enforces some level of consistency of tag names. It makes you think about messages as chunks of meaningful data, that will go through some coherent formatting process. I also don't think it would terribly hard to get at least some basic CSS-like information set up, and yes it would even save some data too. (But I don't view that as a huge concern, especially if stuff is being compressed. It's a nice side bonus.)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #217 on Sat 20 Feb 2010 08:31 PM (UTC)
Message
Nick Gammon said:

Initially I was sending the "clr" field with each piece of data, then moved it into a hint. When being sent once it may as well be spelt in full. The first idea was just to save the number of bytes being sent.


Presuming every nearly every MUD has switched to MCCP compression this actually wouldn't be that big an issue. Our experience is that the compression has a _huge_ effect - obviously especially on repeating text.
Just a note.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #218 on Sat 20 Feb 2010 08:34 PM (UTC)
Message
Quote:
Yes but then they get reused unfortunately. An address 0x123456 could be a naga one minute and a carrion crawler the next.

This is true, but, well, again if a server really wanted to use this functionality they would presumably add support for it (just like they'd have to support a lot of other stuff). So I guess that I don't see it as a big deal, really.
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 #219 on Sat 20 Feb 2010 08:36 PM (UTC)
Message
Copying my edit into a new post, because I think I edited it in at a very unlucky moment:

Also, just to note, I'd like to make sure that whatever comes out of this will be feasible to incorporate into other clients too eventually. The CSS thing would give any client a good standard to target, mapping the details to internal client-specific functionality. I think it would make it easier... but you're right, that's something to consider later on.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #220 on Sat 20 Feb 2010 08:39 PM (UTC)
Message
Twisol said:
Also, just to note, I'd like to make sure that whatever comes out of this will be feasible to incorporate into other clients too eventually. The CSS thing would give any client a good standard to target, mapping the details to internal client-specific functionality. I think it would make it easier... but you're right, that's something to consider later on.

I agree, and this is what I was driving toward with my comment:
"What I like about the CSS-like approach is that it enforces some level of consistency of tag names. It makes you think about messages as chunks of meaningful data, that will go through some coherent formatting process"
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 #221 on Sat 20 Feb 2010 08:56 PM (UTC)
Message
Xtian said:

Presuming every nearly every MUD has switched to MCCP compression this actually wouldn't be that big an issue. Our experience is that the compression has a _huge_ effect - obviously especially on repeating text.
Just a note.


I totally agree, and in my tests, have MCCP active. The compressed data is around 5% of the uncompressed data (that is, it is saving 95% of it).

However the server still has to assemble the data, and then get it compressed.

It is surely going to be faster (and ultimately use less bandwidth) to send something like "room=34545" than:


room=34535;desc=[[
Chamber of Trials for Warriors
Here you will experience your first full combat against MOBILES, also known
as MOBS. Mobile is the name used for monsters and the like in the game.
All exits, except down, lead to a CAGE mob. Some of these cage mobs may be
aggressive and will attack you upon entering their room. As you kill them,
you will gain experience, as well as academy equipment and gold. Once you
have defeated a mob, type GET ALL CORPSE to loot the coins and equipment.
You may also type CONFIG +AUTOLOOT or CONFIG +AUTOGOLD. Autoloot will take
everything from the corpse when you kill it. Autogold will take only the
gold from the corpse. When you loot a corpse of equipment, the items are
transferred to your inventory. You may suffer injury during the battle, so
return here and type REST or SLEEP. This will speed your healing process.
When you are finished healing, type WAKE or STAND to continue.
]];


Plus once a room desc is cached, and you have a map up of some sort, you could mouse-over rooms shown on the map and their lengthy description could be pulled out of the cache.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #222 on Sat 20 Feb 2010 09:19 PM (UTC)
Message
Ah, the pain, the pain.

A quick look at the low-level read for SmaugFUSS makes one thing spring to mind: "total rewrite".

In order to process *incoming* telnet negotiation the thing needs to be redone. For one thing, it uses zero-terminated strings, for another it looks for \n and \r in the buffer. None of this will work for data which might be an IAC SB sequence (which might have imbedded 0x00 bytes for one thing, unless we define them away).

Later on it checks that a line is not more than 254 bytes, and then it checks for things like IAC SB ... but only if they are in the same buffer.

I think the whole thing needs to be turned into a state machine. Oh well, there go a few hours.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #223 on Sat 20 Feb 2010 09:19 PM (UTC)
Message
BTW, Nick: As soon as you've got some sort of more or less stable format I'd be interested of trying out implementing the server-side on my test machine. Should give us some more insights practicability-wise, before you freeze for the first public release. (but give me a few day for that)
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #224 on Sat 20 Feb 2010 09:29 PM (UTC)
Message
OK but it won't be stable for a while now because of the caching. :)

Do you use C++? I am switching from C to C++ because I want things like map and string classes. I note that SmaugFUSS compiles without errors under C++.
- 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 15, 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