Member Discussions

I wanted to do some stuff along the lines of adding casting times to spells and the such, so is there any way to make a function wait a certain amount of time before continuing?

WAIT_STATE(ch) only blocks the character in game from inputting any commands for a while.

I'm using a godwars derivative, but I'm not sure that matters so much as I imagine this is more of a C coding question.

In case you still have no idea what I'm talking about, I'd like to be able to do something like:

stc("You begin casting a spell.",ch)
PAUSE(5)
stc("A fireball erupts from your hands.",ch)

It would begin casting, and five seconds later it would finish casting.

TYIA

Event Que

Kyndig

You'd need some sort of threading/coroutine model to do that, which is usually more trouble than it's worth. You're pretty much going to have to split it up into separate functions (or one big function with a bunch of if/elses) and use an event queue like Kyndig suggested.

Anything interruptable (including using events) will have things you to watch out for. For example, you should handle the case where the caster gets killed before he/she completes the spell, or even logs out if that's possible. I often try to do this in a generic way, so that the event handler will cancel any "search room" events or "pick lock" events if you leave the room.

The event que might not be the best solution. A simpler aproach that is more directed to your focus would be:

Tavish' Timed Casting Snippet

Kyndig

Hmm.. sounds like a job for the hamster and TITS.

If you had a queue of commands for each player, you could send the player the message, "You start casting..." when the command at the front of the queue is a cast command and set some variable for a wait time. Then when you next check the player's input queue, if enough time has not passed, skip them, otherwise remove the cast command from the queue and send them the message, "You finish chanting a shoot a fireball." and set the wait time variable back to zero.

I don't know how this compares to TITS, or if it would even work with your codebase, but it seems like the simplest approach.
*This does assume that you're not going to let the user do anything else while chanting a spell, like scale cliffs, search their inventory, chat with people, etc.

I think Diku actually does it right (almost) and most event systems do it wrong. But to clarify why that is would be a rather lengthy post.

Unfortunately the more serious discussions on this event system and others has scrolled off the TMC boards into the bit bucket. So I'll just point you to the more humorous release announcement...
http://www.mudconnect.com/discuss/discuss.cgi?mode=MSG&area=coders&message=22930#22930

I find the whole notion of scheduling events to have some serious flaws.

The boards have been slow and I'm bored. Care to elaborate and coax this discussion back out again?

The boards have been slow and I'm bored. Care to elaborate and coax this discussion back out again?

Sure why not? I managed to resurrect some of my posts and piece them together into a halfway coherent form...If this sounds a bit disconnected and repetitive, well that's why I included the separators.

--------------

My personal pet theory of events I call TITS or Tyche's Immediate Temporal System. It's not exactly mine as it happens to be the same event theory proposed by the 5 amigos of Object-Oriented design (Rumbaugh, Blaha, Premerlani, Eddy and Lorensen). But since the 5 amigos are pretty boring I'll just describe the parts that I think are important and relevant.

--------------

Under TITS, an event is something that is occurring immediately, or will occur presently within the restrictive notions of temporality embedded in the software/hardware of our primitive machines.

Nevertheless, an event isn't something which will occur at a distant point in the future. Nor is an event something that MAY or MAY NOT occur. In other words, events simply cannot be scheduled to occur! And in practice an event is guaranteed to complete. One that cannot complete indicates a flaw in our design or an error in our implementation.

Here are the two fundamental laws of TITS:

An event is issued at the point of a state change.

An event is guaranteed to complete.

Consider the consequences of the TITS-less implementation above. If something should occurred before the scheduled event like an earthquake, flood, or a hole is ripped in the space time continuum that redirects or otherwise voids the destination, then there is no way the event can occur, be completed and will be invalidated. One must handle that. Or consider the consequences of your present TITS-less system. Either way you will be faced with unsatisfactory results unless you embrace and grasp TITS.

Thus State should always maintained where it should be... in the object itself, NOT in the event which happens when you schedule it.

-------------

What's that mean for queues? Is a queue really necessary? Well the 5 amigos insist that in a pure concurrent system objects will communicate directly with each other so a queue is unnecessary. This is fine but most of us use languages that aren't concurrent. And no I don't mean thread support because there's no practical way you can build a mud where each object is a concurrent machine in itself. So my notion of an event queue is one filled with events that have occurred.

-------------

There are many problems with scheduling events to occur in the future. One of the serious problems is non-existent objects causing fatal errors, or objects in the wrong state.

There are many others involving causality and logic errors, a few examples:

Inevitable Death scenario:
Bob eats a poisoned apple.
A death event is scheduled to occur in 10 minutes.
Bob takes an antidote to the poison.
Bob dies in ten minutes.

Elves and the Sword maker scenario:
Bob is crafting a sword
A sword completed event is scheduled to occur in 2 hours
Bob goes to the local pub gets drunk and returns to smithy in time to receive the completed sword

Non-interruptus scenario:
Bob begins casting a fireball
A fireball spell event is scheduled to occurred in 2 minutes
Sam knocks Bob unconscious
Bob completes the casting of the spell and a fireball is produced

All of these problems have different solutions depending on how you want the
scenario to play out, most involve carefully removing the non-event from the
queue or writing additional to carefully check the validity of the assumed
state.

Event removal may also introduces new problems...

Item Eaters and the Sword maker scenario:
Bob is crafting a sword
A sword completed event is scheduled to occur in 2 hours
Someone knocks on the shop door and Bob goes to answer it.
The sword completed event is removed from the queue.
Bob returns to an empty work bench and has to start all over again.

---------------

The event systems of Erwin and Kyndig are not really dynamic event-driven programming in the traditional sense (i.e. signals, GUI programming, object messaging). They are really job/task scheduling or transactional systems. It certainly quite difficult to test and build a system or even generate meaningful event-state diagrams to test your system when you don't know the state! Scheduling events to occur in the future implies that these aren't really single discrete events as they actually have a duration, and are actually pairs of events with some unspecified/undefined state that exists in between. It's that empty space in between that's the source of having to write complex code and the errors above. If you do go multi-threaded you'll only compound the problem.

I could describe them alternatively in terms of a transaction model. It's a queue of potential events (or non-events)... transactions rather than events. Pushing one on the queue is the start of a transaction, popping one off the queue and executing it successfully is the commit or completion of a transaction. Canceling one or one failing during execution is a rollback. They invite all the causality concerns and problems that accompany transactional programming.

In theoretical terms, an event has no duration, though in practical terms this is not so as the cost of sending a message to a receiver plus the receiver processing the message is not zero. An event is initiated by a state change and may or may not effect a state change in the receiver. An event is a one way message, though in a non-concurrent procedural language this means a dispatcher must send the message and wait upon it's return. Events never return a value. A reply to an event is a new event.

-------------------

So here is one way to implement the casting effect in TITS as this event is based on time.

First all living objects are registered with the timer (a hamster wheel in my case)

Change the state of the character to casting. Why? It allows the character to interrupt
what they are doing voluntarily. To react to something else occurring in the environment. A casting state might permit certain commands that don't interrupt casting YMSCAHWV (Your magic system can and hopefully will vary)

Set casting timer ON THE character. This should be familiar to Diku users as Diku uses a wait timer. I said Diku almost has it right. Surely a character can and ought to have multiple states and timers.

Save the spell being cast on the character. (transition state of the timer).

Every time a timer event occurs the character object decrements the casting timer, as well as other timers it may have.

When the timer runs down the transition state (cast of spell) is executed.

This is much simpler and straight forward than a scheduling system. There is no error handling or special case code.

How about the case where Bob casts a Fireball at Fred? Do they both receive an event, Fred as target and Bob as caster?

How about the case where Bob casts a Fireball at Fred? Do they both receive an event, Fred as target and Bob as caster?

I have no idea because this is where YMSCAHWV kicks in. I can tell you how the Diku spell system might work under this event system because we both know exactly what spell system we are discussing.

`cast fireball fred` command event sent to Bob, executes...

Damage event sent to Fred (state change in Fred)

Wait event sent to Bob (state change in Bob - wait state timer activated)

Output message event sent to Fred.

Output message event sent to Bob

Timer events sent to Bob (decrements wait state timer until state change to 'normal')

The Diku magic system is split into two meta events, the instantaneous spell event which changes the states of Bob and Fred, followed by the affect wears off event which puts Bob back into a 'normal' state from a 'wait' state. (If we were talking about `sleep` then the kind of events sent to Fred would resemble those sent to Bob i.e. a sleep state and sleep timer would be set on Fred)

The OP wants to move the affects wear off state before the spell event. But it's no longer an affect of the spell, casting time is a precursor event to the spell event. So using the minimal assumptions, changing the spell system into something very different in game terms but not changing the interface at all.... then we'd save both the target and the spell onto the character and when the cast timer reaches zero we check the existence of Fred and then...

Damage event sent to Fred (state change in Fred)

Output message event sent to Fred.

Output message event sent to Bob

I think the tactical implications are obvious. Bob has the problem of losing his target Fred while he's casting the fireball spell. Also Bob can't interrupt his casting. But all that is more about the utility and design of this accidentally new magic system, instantaneous vs. prepared spells, rather than the event system.

It's a change in the Diku theory of magic so the OP has a lot more to think about than just 'I want spell casting time'.