April 1997
- From out of the shadows... Dan Mazeau
- Introduction Shawn Halpenny
- Introduction Nathan Yospe
- Introduction Chris Gray
- Introduction coder@ibm.net
- Introduction S001GMU@nova.wright.edu
- Introduction Jeff Kesselman
- Introduction Chris Gray
- Introduction Mik Clarke
- Introduction Caliban Tiresias Darklock
- Introduction Mik Clarke
- Introduction Caliban Tiresias Darklock
- Introduction J C Lawrence
- Introduction Elia Morling
- Event-driven? Michael Hohensee
- Event-driven? Nathan Yospe
- Event-driven? coder@ibm.net
- Event-driven? Jon A. Lambert
- Event-driven? Adam Wiggins
- Event-driven? Shawn Halpenny
- Event-driven? Chris Gray
[Michael H:]
:Precisely how does an event-driven mud work? I understand the idea, but
:I don't see how it could be run efficiently, and be coded neatly...
:
:Can somebody enlighten me?
Nathan's explanation was quite detailed, so I'll give a simpler arm-waving
one. I have a list of events that need to be scheduled in the future. The
list is sorted by increasing date/time (I use an internal seconds count).
Each element also contains a pointer to the MUD code to run, and a pointer
to the PC/NPC on who's behalf it is to be run. Whenever the first, or a
new earliest, event is added, the server starts or modifies a timer for
that time interval. The server then goes back to doing whatever it was
doing before (typically, it continues executing the MUD code that just
scheduled the event). When the server goes idle (does its main 'select'
call), that call can be woken up by the timer signal. The server also
occasionally checks the time when it is busy, to see if it is getting a
long way behind. If so, it can stop processing incoming requests and do
some timed events for a while.
To process a timed event, it just sets the current identity to that in
the request, deletes the request (important!), and then calls the MUD
code of the request. It loops through the earliest events until it comes
to one that isn't due to run yet (re-checking the current time occasionally,
since doing all of this does consume time), or until it decides it has
done enough catching up for now and should go back to input requests.
So, to have an NPC that does things occasionally, the MUD code looks
something like this:
/* the routine which Frog executes on each "step": */
define tp_frog proc frogStep()void:
int direction;
if not ClientsActive() then
After(60.0, frogStep);
else
direction := Random(12);
if TryToMove(direction) then
MachineMove(direction);
fi;
After(IntToFixed(10 + Random(10)), frogStep);
fi;
corp;
(This is from an example file on NPC's that is part of my docs.) The key
here is the 'After' calls. They schedule an event for the given time
(in seconds) after the current time. Note that the MUD code they are
scheduling is the same code that is currently executing - this is quite
common on my system.
--
Chris Gray cg@ami-cg.GraySage.Edmonton.AB.CA - Event-driven? coder@ibm.net
- (subject missing) Dan Mazeau
- A late introduction Jon A. Lambert
- Re-Introduction S001GMU@nova.wright.edu
- New guy Walter Goodwin
- New guy coder@ibm.net
- Socket Stuff Shawn Halpenny
- database stuff Chris Gray
- So in an event-driven server, how do you ... Michael Hohensee
- So in an event-driven server, how do you ... Nathan Yospe
- So in an event-driven server, how do you ... S001GMU@nova.wright.edu
- So in an event-driven server, how do you ... Chris Gray
- So in an event-driven server, how do you ... clawrenc@xsvr1.cup.hp.com
- So in an event-driven server, how do you ... clawrenc@cup.hp.com
- Off on the languages tangent! Chris Gray
- Yet Another Introduction Reed D. Copsey, Jr.
- Yet Another Introduction Nathan Yospe
- Yet Another Introduction clawrenc@cup.hp.com
- Yet Another Introduction clawrenc@cup.hp.com
- Yet Another Introduction Adam Wiggins
- Yet Another Introduction Dmitri Kondratiev
- self-intro: Cynbe Cynbe ru Taren
- Unique id's Chris Gray
- Unique id's clawrenc@cup.hp.com
- Unique id's Jon A. Lambert
- Unique id's coder@ibm.net
- Unique id's Jon A. Lambert
- Unique id's coder@ibm.net
- Unique id's Jeff Kesselman
- Unique id's clawrenc@cup.hp.com
- Unique id's Jon A. Lambert
- Dupes are my fault (again) coder@ibm.net
- six degrees of submission ... er, compilation. Cynbe ru Taren
- six degrees of submission ... er, compilation. Jeff Kesselman
- Java as a mudserver language Cynbe ru Taren
- Java as a mudserver language Jeff Kesselman
- Execution Chris Gray
- Using system time for ObjectIDs clawrenc@cup.hp.com
- short absence Chris Gray
- short absence coder@ibm.net
- Hello! Ross Nicoll
- Ho hum (clarifiyign AI terms) Jeff Kesselman
- Ho hum Ling
- Fw: Just a bit of musing Travis Casey
- Risk Assessment -- was (Ho hum) Jon A. Lambert
- Who is Steward and what can he do for me? Jon A. Lambert
- Who is Steward and what can he do for me? clawrenc@cup.hp.com
- Who is Steward and what can he do for me? Chris Gray
- project management (or coding, kings, and other things) Jon A. Lambert
- Threads and Sockets (Was Ho hum) S001GMU@nova.wright.edu
- Threads and Sockets (Was Ho hum) Jeff Kesselman
- Threads and Sockets (Was Ho hum) S001GMU@nova.wright.edu
- Threads and Sockets (Was Ho hum) clawrenc@cup.hp.com
- Threads and Sockets (Was Ho hum) Chris Gray
- Strings & Memory Usage Greg Munt
- Strings & Memory Usage clawrenc@cup.hp.com
- Strings & Memory Usage Jeff Kesselman
- Strings & Memory Usage Shawn Halpenny
- Strings & Memory Usage ashen
- Strings & Memory Usage Chris Gray
- Steward coder@ibm.net
- r.g.m.* - worthwhile thread Nathan Yospe
- r.g.m.* - worthwhile thread clawrenc@cup.hp.com
- r.g.m.* - worthwhile thread Jeff Kesselman
- r.g.m.* - worthwhile thread Chris Gray
- (fwd) A Mud Protocol (MUD Markup Language) coder@ibm.net
- Ho hum (Sockets) Ling
- Steward and other painful friends coder@ibm.net
- A Combat System (please critique!) S001GMU@nova.wright.edu
- Your Message To mud-dev Jon A. Lambert
- I'm back Chris Gray
- Changes to the list coder@ibm.net
- Oops coder@ibm.net
- Verb binding Chris Gray
- Verb binding clawrenc@cup.hp.com
- Verb binding ashen
- Verb binding Chris Gray
- Verb binding Adam Wiggins
- Verb binding clawrenc@cup.hp.com
- Verb binding S001GMU@nova.wright.edu
- Verb binding Shawn Halpenny
- Verb binding Chris Gray
- Verb binding clawrenc@cup.hp.com
- Verb binding Chris Gray
- Why have a combat state? Jeff Kesselman
- Why have a combat state? clawrenc@cup.hp.com
- Introduction Jamie Norrish
- Introduction S001GMU@nova.wright.edu
- Introduction clawrenc@cup.hp.com
- Introduction Jeff Kesselman
- Introduction clawrenc@cup.hp.com
- Introduction Chris Gray
- Introduction Travis Casey
- Introduction Jeff Kesselman
- Introduction scherecwich@angelfire.com
- Introduction Jon A. Lambert
- Introduction Chris Gray
- (fwd) Issues from the digests and Wout's list Raz
- (fwd) Issues from the digests and Wout's list Chris Gray
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Raz
- (fwd) Issues from the digests and Wout's list Chris Gray
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Chris Gray
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Oliver Jowett
- (fwd) Issues from the digests and Wout's list Chris Gray
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Raz
- (fwd) Issues from the digests and Wout's list Miroslav Silovic
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Adam Wiggins
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Miroslav Silovic
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list Raz
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- (fwd) Issues from the digests and Wout's list clawrenc@cup.hp.com
- Me Raz
- Sendmail changes coder@ibm.net
- Reposts Adam Wiggins
- Semaphores, Mutices, fd_sets Greg Munt
- Semaphores, Mutices, fd_sets Jeff Kesselman
- Semaphores, Mutices, fd_sets clawrenc@cup.hp.com
- MUD Design Digest V1 #55 coder@ibm.net
- Me Raz
- Magnetic Scrolls' magical parser Greg Munt
- Magnetic Scrolls' magical parser clawrenc@cup.hp.com
- Magnetic Scrolls' magical parser Adam Wiggins
- Magnetic Scrolls' magical parser Nathan Yospe
- Magnetic Scrolls' magical parser Chris Gray
- Magnetic Scrolls' magical parser Ling
- Magnetic Scrolls' magical parser Chris Gray
- Magnetic Scrolls' magical parser Shawn Halpenny
- Reposts Jeff Kesselman
- Email change Alex Oren
- SUBSCRIBE Alex Oren
- (fwd) Death in Muds -(also Birth, Imprisonment, Aging, and skill development) coder@ibm.net
- fd_set limitations Greg Munt
- parsing Chris Gray