08 Aug, 2010, Zula110100100 wrote in the 1st comment:
Votes: 0
Surely there is a way to make the skill wait the time and THEN say the result,


WAIT_STATE(ch, 36);
send_to_char("yeah\n\r", ch);


prints the word yeah before the wait is over, any ideas?
08 Aug, 2010, Kline wrote in the 2nd comment:
Votes: 0
You'd need to implement an actual queuing or event system. The "wait state" mechanic just introduces an artificial lag/delay to processing the next command from the player; it doesn't actually pause anything at all.
08 Aug, 2010, Runter wrote in the 3rd comment:
Votes: 0
I don't think you really want to completely block output like that.


There's little value in delaying merely messages on a timer. You'd be better off delaying a function call which could include output.
08 Aug, 2010, Davion wrote in the 4th comment:
Votes: 0
This snippet includes a timed printf.

[link=file]497[/link]
08 Aug, 2010, David Haley wrote in the 5th comment:
Votes: 0
Look up 'search' in SMAUG, it implements delayed command results. (I think the way it works it rather terrible, but that's another question…)
08 Aug, 2010, Zula110100100 wrote in the 6th comment:
Votes: 0
The use I am talking about is for a forage command, Right now it says you don't find anything immediately and then waits, would be more realistic if it waited, then said you didn't find anything is all…I guess most muds just drops the realism there?

implementing an event system just for that seems like overkill
08 Aug, 2010, quixadhal wrote in the 7th comment:
Votes: 0
It's not overkill, because DikuMUD is designed to resolve all actions on each execution round. Without and event system to queue actions into future loop iterations, there is simply no way do do what you want to do.

Look at the code. All actions are done to completion, and all messages are printed to the output buffers of the victims. At the top of the next loop, output to players is actually sent, input from them is read and acted upon, and then autonomous systems are run.
08 Aug, 2010, David Haley wrote in the 8th comment:
Votes: 0
You want delays, but you don't want a system that implements delays because it's overkill?

Well, you don't need a full event system just to implement foraging, however if you go down that path you will find yourself in the SMAUG boat and very rapidly regret your decision and wish you had taken the more general approach.
08 Aug, 2010, Runter wrote in the 9th comment:
Votes: 0
You'll find more places its useful once its in. Its easy to let convenience drive design and that's precisely why many stock muds don't come with some event systems.
08 Aug, 2010, Kjwah wrote in the 10th comment:
Votes: 0
There's a port of the SocketMUD event system here. Though, I think it's based on an older version but either way, it's not a bad idea. As you get comfortable using it, you'll slowly be able to replace most of your *_update crap with events.

[link=file]2539[/link]
0.0/10