[MUD-Dev] Re: clients anyone?...

[Adam J. Thornton]

On Tue, Aug 11, 1998 at 11:50:09PM +0200, Hans-Henrik Staerfeldt wrote:
> If you want complex scripting, it would be a good idea to extend the
> protocol to handle pre-processed data. In reality, your in-game model
> of the world is translated into nasty ambigous text for reading of humans,
> or even worse - graphics. Unless you want to do some very nasty AI attempt
> at understaning the messages (graphics!) intended for the player you 
> should extend your good flexible protocol with an AI stream mode that 
> allows for nicely formatted events to be parsed to the remote NPC.
> Player> Buffy pick up the hammer.
> AI> Pickup((Player 52364),(Object 23647)).

Ah, but what happens here (and with any action that changes the game state
in a way visible outside a player object) is that the new room state is
propagated to all the players in the room/all the players in the line of
sight (depending on how fancy I get).  So, Buffy picks up the hammer
(whether by typing GET HAMMER, or clicking on the hammer picture while
standing within a certain radius of its location, assuming buffy has
sufficient carrying capacity left, etc., etc.).

All the players within view (including the AI "player") get something along
the lines of UPDATE:PARENT(HAMMER)=BUFFY.

So the AI gets the changes to the world state more or less automatically.
On the other hand, let's assume the AI is named Buffy, and what we want is
"Buffy, pick up the hammer"; then we can use a system kind of like Inform's
creature library to decide if a) Buffy takes orders in the first place, and
if so, then we can parse the text input; "PICK UP" is a verb equivalent to
"TAKE" and "GET" and so on, and then we see whether "HAMMER" is anything in
scope.  And if so, then Buffy a) moves to it, and b) tries to pick it up.
But I think we want to put the parser in the Buffy client, not in the
server.

An unrelated problem, but a very annoying one.  I'm new to Linux threads
programming.  I'm using RH5.1.  When I call pthread_create() I get the new
thread, but also a SIGUSR1.  If I don't SIG_IGN it, the program exits (this
is default behavior for SIGUSR1).  But if I *do* ignore it, then the
process never returns from the thread creation.  Did I miss something
really obvious here?

What's going on?  My guess is that the newly created thread is calling back
the main thread with a SIGUSR1 to tell it to go on with its life.  But
whatever the signal handler is that was supposed to be installed so it
could do that wasn't.

Interestingly, the tcpserv02g in Stevens _Unix Network Programming_ ch. 23
does the exact same thing (in the threads subdir of the tgz from the book).
So it's not just me.  I'm trying to do something very similar, by the way:
I block on accept() (well, really an error-checking wrapper to accept(),
but same difference), and then I create a new thread to deal with the fd I
get from it after someone connects, and, if the program actually resumed
after spitting out the thread, it would head back to the top of the loop
the accept() is in and block there again, but it never gets to the
statement beyond the pthread_create.

Any Linux thread gurus out there who can tell me what's going on here?
Also, are there any free thread-aware debuggers under Linux?  Gdb doesn't
seem to be thread-aware.

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman