[Adonthell-devel] Re: Bugs, bugs, bugs ...

[Kai Sterker]

On Tue, 13 Aug 2002 18:18:52 +0200 Kai Sterker wrote:

> Well, first of all I'll get rid of those circular references.

Hm, that isn't as easy as it seemed. No matter where an event is stored,
as long as it points to the method of a python class, this class can't
be deleted. So trick seems to be deleting the events before deleting the
schedules.

Here the event_list could help. If each mapcharacter has it's own
event_list, the schedule (which knows it's mapcharacter) can store
events in the character's event_list. When the character is deleted, it
could first free all events, and then the schedule. In that case, no
event would point to the schedule and the schedule can be completely
freed.

But there is a problem. The time_events that are used by the schedules
are 'once-only' events. That is, they are executed once, and can then be
deleted. After all, they are meant to be executed at a certain point in
time, and that point exists only once. Now if we'd keep those
time_events in an event_list, they'd keep getting more and more as the
schedule constantly generates new time_events. Therefore, once an event
is no longer needed, it has to be removed from it's event_list. For that
to work, the event needs to know the event_list it is kept in.

So all in all the event stuff is pretty tricky:

1. Create event
2. Add event to event_list
   This will
   * register the event with the event_handler
   * add a pointer to the event_list to the event
3. When the event is raised and reaches repeat-count 0
   * it will be removed from the event_list
   * it will be deleted
4. Deleting the event will finally remove it from the event_handler, 
   if neccessary 

OTOH, events that repeat forever, or have not used up their repeat-count
yet, will remain in the event_list and get deleted when the event_list
is deleted. Again, that will also remove them from the event_handler.


With that we can ensure several things (as long as all events are kept
in an event_list or another): 
1. All events will be freed once the event_list gets freed. 
2. If all events are freed, none can remain registered with the
   event_handler. 
3. All events that reach repeat-count 0 will be permanently removed 
   from the game. (Since they are saved via the event_list. Events
   that reach repeat-count 0 are removed from their event_list.)


I know that this would make the event-system quite complicated, but I
can't really think of another way. Everything else would be at least
less generic. But the event-system is written to be as generic as
possible.

And the cool thing is: if we make event_handler::register_event
protected and only allow event_list::add_event to call it, we can easily
ensure that _all_ events that are registered with the handler also end
up in an event_list. Which means that all the automatic unregistering
and deleting will apply for them. That way, the event system can't be
messed up by sloppy use. (At least as long as nobody tries to free an
event twice!)

Well, the more I think about it, the more I like the idea. I'll go ahead
and test it, and see what happens. With a bit of luck, it might actually
fix some of my problems :)

Kai, who feels really sorry that you have to read all this mess :P