[DGD] RE:time() and suspending call_outs

[Steven Brooker]

>And finally, the original reason I wrote this mail:
When I was looking at
>the kernel lib, the impression I got from the
call_out functions in the
>auto object, was that when the kernel suspended
call_outs, it didn't pause
>them, but rather delayed them until just after the
call_outs were released.
>Is this correct? I'm kind of worried that this could
end up getting players
>killed on a hack-n-slash mud. Imagine that there's a
huge pause for 30
>seconds while the mud does something CPU intensive,
then suddenly all the
>combat occurs at once and you're dead without a
chance to flee.

Only the last action would go off for each player and
mob.  An example of what would happen is:
Mob begins to attack a player - this sets up a 5
second callout.
At the same time, an NPC enters an area. He sets up a
60 second callout to randomly move again.
Immortal decideds to recompile the entire mud. 
Callouts delayed until the recompile is complete 30
seconds later.
When the recompile is complete, the mob attacks, and
then sets up a 5 second callout for the next attack.
It's still another 30 seconds until the NPC random
walks.

You don't want the mud to try and play catch-up (it
takes more effort to code it to anyway).

>I just thought of one more question... for an object
daemon, since I don't
>want the source code of every single object stored in
memory at once, am I
>forced to store the source code in real objects
rather than LWOs referenced
>by the object daemon?

What's wrong with saving them to file somewhere?  My
objectd copies the code into ./current after compiles.
   You just need to make sure people can't compile the
contents of these backup folders.


	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd