Gammon Forum : MUDs : General : Suggested protocol for server to client "out of band" messages

Register forum user name Search FAQ

Gammon Forum

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

David Haley USA (3,881 posts)

Date

Reply #225 on Sat 20 Feb 2010 09:39 PM (UTC)

Message

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

Heh... welcome to the club! :-)

Quote:
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++.

If you're actively rewriting chunks of the SmaugFUSS code, it might be nice to coordinate with the folks at smaugmuds.org. It would be nice for everybody if it had a good telnet handler; that's something that has been on the table for a while. A conversion to C++ with a general cleanup has also been planned; it's no accident that it compiles cleanly under g++. (Actually I did a good chunk of that work, esp. when it comes to string constness.)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #226 on Sat 20 Feb 2010 09:48 PM (UTC)

Message

After looking at the code a bit more .... <sigh>.

To even do something simple like make the unprocessed text a string type rather than a fixed buffer (which will one day overflow), we need to "new" the DESCRIPTOR_DATA rather than malloc it. Then it has to be deleted.

Do you recall David, since you are the C++ expert and I'm not, if I "new" DESCRIPTOR_DATA does the default constructor for everything inside it get called? In particular, do ints, longs and so on get set to zero? And what about pointers? Do they become NULL automatically? I seem to recall not, but if they do it saves a few assignments. The existing code does a calloc which guarantees everything becomes zero but that will just crash string types.

- Nick Gammon

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

Posted by David Haley USA (3,881 posts) bio

Date Reply #227 on Sun 21 Feb 2010 01:09 AM (UTC)

Message

When you create any data structure with 'new', it calls all implicit member constructors (unless you have initialization lists). The thing is that for primitive data type constructors to be called, you need to call them explicitly. See for example:


$ cat test.cpp

#include <iostream>
using namespace std;

class C
{
    public:
        C() : i() { /* empty */ };
        int i; int j;
};

int main()
{
    C c;
    cout << c.i << endl;
    cout << c.j << endl;
    return 0;
}


$ g++ test.cpp
$ ./a.out     
0
32767
$

Note that i is initialized but j is not, because we called i's constructor explicitly.

By the way, I'm not sure that a std::string is really the most appropriate data structure for a network data buffer, but I guess that's another topic.

What exactly are you doing here? A few people (myself included) have started partial conversions to C++ where you have objects that are new'ed rather than calloc'ed. The internals really are a mess, and yes the "start from scratch" impulse gets very high the more you read it.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #228 on Sun 21 Feb 2010 02:41 AM (UTC)

Message

David Haley said:

What exactly are you doing here?

I'm trying to make the server reliably accept incoming telnet subnegotiations. Also tidy it up so that it doesn't rely upon things like IAC and WILL happening to be in the same packet.

I believe I am getting there. The function read_from_buffer has had a total rewrite. It should now handle all telnet negotiations including IAC SB x <blah> IAC SE including imbedded IAC IAC. It will also handle that in the middle of text from the player.

To achieve handling any-length buffers (as previously discussed, we don't want to limit IAC subnegotiations to some arbitrary length), I changed from fixed-length buffers to std::string.

Unfortunately, to make the simple change of adding std::string into the DESCRIPTOR_DATA structure I had to spend about 2 hours finding all the places it was referred to. I suppose it was a bit obsessive, but I wanted to get rid of the linked list previously used and change the list of descriptors into a std::list.

Now the places that used to walk the list with a custom list walker now all look like this:


  for (std::list<DESCRIPTOR_DATA * >::iterator iter = descriptor_list.begin(); 
        iter != descriptor_list.end(); 
        iter++)
     {
      d = *iter;  
      
     // operate on d here ...

     }

I also plan on using std::map for the GUID storage, so I can quickly locate a pointer given a GUID or vice-versa.

- Nick Gammon

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

Posted by

David Haley USA (3,881 posts)

Date

Reply #229 on Sun 21 Feb 2010 04:08 AM (UTC)

Message

Nick Gammon said:
I also plan on using std::map for the GUID storage, so I can quickly locate a pointer given a GUID or vice-versa.

What about using your ID system?

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #230 on Sun 21 Feb 2010 05:58 AM (UTC)

Message

Ah yes, well I had to dig around to find that. And there is this problem:

Nick Gammon said:

... this is all automatic, provided you derive the class from the appropriate auto-map pointer class ...

So far I have avoided converting *all* of Smaug to using classes (and thus new and delete), because the pain I went through with descriptors would then apply to objects etc.

So as a short-term measure I have a simple map of GUID to pointer, where the GUID is incremented each time, so even if the pointer is reused the GUID will be different. At the plugin end it shouldn't matter too much, and in fact I am sending a string, so another MUD could use GUIDs with dots and things in them.

It still relies upon deleting the entry from the map when the pointer is freed, but I don't think that happens in too many places (well I hope not).

- Nick Gammon

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

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #231 on Sun 21 Feb 2010 06:03 AM (UTC)

Message

Anyway, if you want a laugh, I was testing querying a GUID, and getting a response back, but the response was one character short, for reasons that weren't obvious.

Finally I tracked it down ... the packet ended with something like:


obj_info={guid="454";{dsc="A fountain stands here";}}

Looks OK, doesn't it?

It arrived at the client end like this:


obj_info={guid="454";{dsc="A fountain stands here";}

It turns out that calling "send_to_char" goes through colour conversion, and the sequence "}}" becomes "}".

- Nick Gammon

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

Posted by

Xtian (53 posts)

Date

Reply #232 on Sun 21 Feb 2010 09:01 AM (UTC)

Message

offtopic:

Nick Gammon said:

Do you use C++?

We are an LP-MUD (LDMUD to be exact: www.ldmud.eu), we write in LPC, which is based on C with some object oriented aspects. The server, called driver (see link), is like a java runtime engine, which handles connections and interpreting LPC code at runtime. We discern the driver from the mudlib per se - which is the custom world.
All objects, rooms, even the player object and the telnet engine are written in LPC.

Advantages:
- we can make changes at runtime
- a host of inexperienced programmers can do programming (well, when I say a host ... )
- LPC is a good language for beginners. no pointers like java ==> no way to crash the driver by accident.

Interestingly enough, I think the whole German MUD landscape is using ldmud, now.

Posted by

David Haley USA (3,881 posts)

Date

Reply #233 on Sun 21 Feb 2010 11:27 AM (UTC)

Message

Quote:
no pointers like java ==> no way to crash the driver by accident.

Java has pointers, but no pointer arithmetic. You can still cause problems by trying to use a null pointer. I would be somewhat surprised if it were absolutely impossible to refer to null references in LPC as well, unless of course you don't have any references at all (which I would find somewhat surprising).

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #234 on Mon 22 Feb 2010 04:58 AM (UTC)

Message

A quick progress report on the proof-of-concept changes I am making ...

Most of today was spent getting the caching of items going, firstly by assigning GUIDs to objects and characters (I am presuming room vnums will do as a GUID in Smaug at least).

Then some major rehashing of the plugins to accept minimal data (ie. the GUID), check their cache, and then request the missing information. This is going reasonably well. I wanted to make sure a single player couldn't bog the server down with thousands of requests for GUIDs, so the cache requests are queued up and serviced at the rate of 10 at a time from the main update loop. The side-effect of this is that there is a delay generally of 0.25 seconds for the information to arrive. Of course, this is only if it isn't cached already.

By assigning GUIDs to mobs we can distinguish between mobs (individually) and players. So the problem of following a mob should go away.

My next project is to make the window clickable so if you see a list of mobs you can just RH click on one of them to attack it, and maybe click on an object on the ground to pick it up.

A few problems have arisen, for example, corpses decay (in Smaug at least) by the server rewriting their internal description. So it might be the same object (and thus the same GUID) but it changes from "the corpse of the naga lies here" to "the corpse of the naga is buzzing with flies" etc.

A similar problem arises with looking at the contents of the room. If you trigger a new download of information when the room contents changes, that doesn't take into account their *disposition* changing. For example, a mob standing there might change to "the naga is fighting you".

All these things mean the design is changing around a bit as I go, and it is probably simpler to get a working version going and then discuss the design, rather than trying to design it all in advance and then finding that it doesn't work for some fundamental reason.

- Nick Gammon

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

Posted by

Xtian (53 posts)

Date

Reply #235 on Tue 23 Feb 2010 08:03 PM (UTC)

Message

Nick Gammon said:

My next project is to make the window clickable so if you see a list of mobs you can just RH click on one of them to attack it, and maybe click on an object on the ground to pick it up.

This would cause problems for me: Firstly: The attack command you will send, will not be the same in every language. My German MUD might not understand it. Secondly: I have established that left-click will look at an object, right-click will open a pop-up menu (with MXP).
I asked if MXP would be compatible because of issues like that - in my opinion that should fall into the servers decision space and the generic plugins should only offer the flexibility for the server to express what it wishes to represent.

Posted by

Twisol USA (2,257 posts)

Date

Reply #236 on Tue 23 Feb 2010 08:08 PM (UTC)

Amended on Tue 23 Feb 2010 08:09 PM (UTC) by Twisol

Message

Xtian said:

Nick Gammon said:

My next project is to make the window clickable so if you see a list of mobs you can just RH click on one of them to attack it, and maybe click on an object on the ground to pick it up.

This would cause problems for me: Firstly: The attack command you will send, will not be the same in every language. My German MUD might not understand it. Secondly: I have established that left-click will look at an object, right-click will open a pop-up menu (with MXP).
I asked if MXP would be compatible because of issues like that - in my opinion that should fall into the servers decision space and the generic plugins should only offer the flexibility for the server to express what it wishes to represent.

Clearly, the action command will be customizable, since this is, after all, a server-to-client protocol. Any plugin can get the appropriate fields from a server-sent message and modulate their behavior accordingly. Forgive me if I sound tetchy.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #237 on Tue 23 Feb 2010 09:49 PM (UTC)

Message

Xtian said:

This would cause problems for me: Firstly: The attack command you will send, will not be the same in every language. My German MUD might not understand it.

Well it would hardly be a very flexible system if "kill" was hard-coded into it would it?

I have already indicated I am supporting UTF-8 character encoding, so that you could use it for Chinese, Japanese, German, Greek, Russian etc. MUDs. So obviously some provision needs to be made to support sending commands in the language of the MUD.

Xtian said:

Secondly: I have established that left-click will look at an object, right-click will open a pop-up menu (with MXP).
I asked if MXP would be compatible because of issues like that - in my opinion that should fall into the servers decision space and the generic plugins should only offer the flexibility for the server to express what it wishes to represent.

I have no intention of parsing MXP per se. This is a system for exchanging data between client and server, whilst MXP is more of a mark-up language for textual output.

Having said that, certainly some sort of "show this menu if you click" protocol could be implemented. Although I am not sure that having to click, have a menu pop up, then scroll down to "attack" is useful in a combat situation.

Already, different object types need different actions, eg. water (drink), food (eat), enemy npc (kill), shopkeeper (trade), corpse (loot) etc.

One simple approach would be to let the server do all this. For example, if you LH or RH click on an item in the room list it simply sends:


lhclick <545847>
rhclick <445844432>

Then the server can say, "hey, s/he RH clicked on some food, s/he must want to eat it".

Alternatively, the server could send down a list of types of objects (eg. food, drink, light, wand) and a list of actions that apply for LH click and RH click, per object type. Then at least you could mouse-over for a hint (eg. "RH click to eat this").

I am still working on the proof-of-concept stage, and experimenting with that is raising interesting issues, like the above.

- Nick Gammon

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

Posted by

Twisol USA (2,257 posts)

Date

Reply #238 on Tue 23 Feb 2010 10:07 PM (UTC)

Message

Nick Gammon said:
Alternatively, the server could send down a list of types of objects (eg. food, drink, light, wand) and a list of actions that apply for LH click and RH click, per object type. Then at least you could mouse-over for a hint (eg. "RH click to eat this").

I like this approach in particular. If you have an API for requesting various sets of data given a GUID (like what we keep referring to WoW about), you could request the most common actions for that type of item, and use that to build a menu list.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #239 on Wed 24 Feb 2010 05:37 AM (UTC)

Amended on Wed 24 Feb 2010 05:41 AM (UTC) by Nick Gammon

Message

Here is a tantalizing glimpse of another project I am working on, in conjunction with the extra messages:

This image shows:

An automatically-generated map of Darkhaven
The filled-in square is where I am
The dashed lines indicate I know there is an exit, but don't know where it leads just yet (in other words, I need to explore there)
The stubby lines indicate there is an exit, but it doesn't lead to the square on the map near it (in other words, the map is not necessarily logical)
Depending on where you are the map reconfigures to show the rooms leading from you (in other words, the rooms that are drawn, and the ones that are not, depend on your location)
If you mouse-over a room it tells you its name

I am planning to have it so if you RH-click on a square it computes the fastest route to it, and takes you there. It will also colour squares differently to show shops, trainers etc.

- Nick Gammon

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

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.

622,868 views.

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

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

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )