adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] changes, problems & solutions


From: Kai Sterker
Subject: [Adonthell-devel] changes, problems & solutions
Date: Sat, 15 Jun 2002 22:21:25 +0200

Still working on the schedules :). First of all, I changed the event
base class. Now we can use events to execute event scripts, but also to
run callback functions defined in any other python script. This could
even be extended to allow C++ callbacks, should we ever need them.

Using callbacks as an event's action allows us to use events in schedule
scripts (and possibly others too). For example, a script could register
a time event to quit itself after a certain period. That means less work
for the different manager scripts using that schedule. But of course
this is not limited to time_events. A "guard" schedule might for example
'listen' for a certain map event (e.g. someone entering the guarded
area) and react accordingly.

As events are much more efficient than constantly polling the time or
state of a mapsquare, that seemed to be a useful addition.


However, there are still some problems remaining. If such a callback
function would set another schedule, this would execute the new
schedule's constructor before running the destructor of the old one. But
as the destructor might save some variables back to the character while
the constructor reads some variables of the character, the new schedule
might miss the most recent values.

In fact, this is a general problem of schedules that switch to another
schedule without making use of the manager script. The only safe way to
quit a schedule is by calling 'schedule::set_running (false)' which will
cause the manager script to run during the next update. However, it
would be very useful if we could set new schedules from within the old
one. 

A solution would be to have a prepare_ or queue_schedule method that
will override the manager script. If a schedule wants another script to
run, it would queue it and quit itself with above method. The next
update would spot the stopped schedule, but instead of running the
manager script, it would use the queued script as new schedule. That'll
cause none of the problems described.

I'll look into that tomorrow. What remains then is state saving/loading
and the schedule stuff is done :).

Kai



reply via email to

[Prev in Thread] Current Thread [Next in Thread]