Event system

[RudolfoWood]

I don't know whether I should ask this question in coding section or in design. Because it has more impact on coding, I'll ask it here:

Are there plans to use an event schedule system instead of actual "forward time, check for events" system? I actually found a bug caused by actual implementation:
at 16:23 I ordered to remove weapon from my aircraft, it states work needs 2 hours. At 18:00 work was finished, expected time ws 18:23. This happens if you choose a slow time progress and hourly update of installation time occurs. This updates installation time to 0 (as only hours are counted) and finishes process too early.

With an event schedule system, a new event could have been added at 18:23, no other checks for updated installation time would be needed and game time stop could have been done exactly at this time.

I know that for such an event system there would be much work to do, but it could enable us to handle some events easier (and more exactly).
From my years of study I remember that such event systems are used in huge simulations, because this way is the easiest to handle many different events. For UFO:AI basically CL_CampaignRun could advance time to a) next time interval (based on actual time progress setting) or b) first event that occurs in this time interval.

[Amtep]

The problem I've run into with events systems is that you then have to write extra code to keep track of which events are pending. For example, if an aircraft is sold then you need to cancel the "finish installing armor" event. This is a common source of bugs in event systems.

 It also becomes hard to keep track of partial progress, or to interrupt progress during situations like a base attack or lack of storage, or to make speed of progress depend on the number of people working on it. A lot of this can be handled by having frequent "make progress" events instead of one "finished" event, and still keeping a countdown-timer that just gets updated via the event system. That allows for example hourly updates as long as there are many hours left, and per-minute updates during the last hour, in order to get per-minute accuracy without having a lot of calculations every minute.

[RudolfoWood]

Thx for your reply.
These were only my first thoughts and I want some feedback from main developers.

Your advice on pending events is good - I actually thought about having e.g. production structure containing a pointer to event (to remove it if no longer needed). Such pointers have to be maintained almost on every pending structure, so this would me much (error-prone) work.
What do other developers think about it?

[Duke]

From my experience, 'check timers at interval x' vs. 'timer queue' is a very complex design decision involving
- # of different event types
- spread of event duration
- dependencies between events (like AMtep lined out).
You can end up with different systems for different intervals.

The example you gave (installing armor) could easily be resolved by checking *certain* events on a minutely basis in CL_CampaignRun (at the price of a little more cpu-usage).

While playing UFO:AI, I never ran into a situation where those 23 minutes were *crucial* to the gameplay.
So do you have another example where a timer queue would really help ?

[RudolfoWood]

I don't know whether a timer queue would be really helpful in the end.

I know that these 23 minutes are not crucial, but I think it would be best to be as exactly as possible.
I thought that all these hourly checks (update production progress, check for ufo) could be made more exactly with an event queue. I think that I read something about game stoping after ufo had been detected, but because of timeframe being very big the ufo left the radar zone.
I think I even remember that with these hourly checks some timestamps 24:32 or so are displayed, because messages are added before day-change is processed.

[Duke]

I don't know whether a timer queue would be really helpful in the end.

First let's make sure we're talking about the same thing.

In *my* wording, an event is something that comes from *outside* the code, like a user's mouseclick, from the OS or at least from a different thread of the same application (afaik UFO:AI is single-threaded btw).

Installing a new weapon on an aircraft is a *timed process*. We start it, it has a duration, and we can calculate the ending time of that process. So we start a 'timer' and need some code to more or less frequently check if the timer has expired. We could do that in a decentralized way OR put all the timers into a 'timer queue' (which eases checking for expiration, but introduces other problems).

So how is the 'event system' you have in mind different from that ?

[RudolfoWood]

a queue for user events (e.g. mouseclicks) already exists - I'm not speaking of anything that improved/changes this one.

I am speaking of improving the *timed process* system. Actually almost all checks are done on a hourly basis - which is not exactly enough in my opinion. I thought a 'timer queue' could be helpful, but learned that I did not think far enough to think about pending events.

[Duke]

Ok, now we are talking about the same thing

A queue can be very efficient as far as checking for expiration is concerned. Inserting new timers costs more cpu because the queue is sorted, and cancelling a timer can be a pita. It all depends on the total # of timers, the # of different timer types, the spread of timer duration, the accuracy required and so on. There are various designs for every combination.

However, *before* discussing the most efficient way of timer implementation for UFO:AI, imho we should simply ask one of the devs around here whether timer checking accuracy is really a cpu-problem. Maybe we could have certain timers checked minutely without hurting performance ?

[Mattn]

just a little note (haven't had the time to follow the whole discussion yet) - see Schedule_* functions

[Duke]

@Mattn:
The Schedule_ stuff seems to be only used with battlescape. The above discussion is about geoscape timers.
The code might be reusable, though.

@Rudolfo:
When getting latest svn, I found several occurrences of your name in the log. So I assume you're much more familiar with the code than I am. Hope I didn't tell you too many things you already knew. If I did: Sorry for that

I dug in the code a bit yesterday, and it's a little worse than I thought. It's not just about a missing minutely check in CL_CampaignRun(), it's also that slot->installationTime is given in *full* hours. That is, 2 hours means '2'. Switching that to 120 minutes is not a biggy, but installationTime is also persistent !
So changing the format would break savegame compatibility.