Timed events reported one minute late

I’m experiencing an (admittedly minor) issue with trying to display the current time in the status bar and also print messages for timed events. What happens is that the effects of each event are reported one minute too late, so the message for an event taking place at 9:00 is printed when the status bar reads 9:01.

Here’s an example:

Clock Tower is a room.

At 9:00 AM: say "The bells ring for nine o'clock."

When play begins:
	now the time of day is 8:59 AM;
	now the right hand status line is "[time of day]";

Test me with "z / z / z".

What seems to be happening is that the “at 9:00 AM” timed event does occur at 9 AM, but after the player’s input, and is therefore reported at 9:01 AM.

I can manually adjust it to at least appear to be in sync by changing the timed event to occur at 8:59 AM, or by subtracting one minute from the reported time of day. Is there a better way to do this? For example, is there a way to modify the turn order so that timed events are reported before the player’s input?

2 Likes

This is pretty easy to do, I think – try:

The advance time rule is listed before the timed events rule in the turn sequence rulebook.

Just because something is easy to do doesn’t necessarily mean it’s a good idea, though – monkeying with Inform’s built-in time processing system gives me the heebie-jeebies, since it seems like this could lead to unexpected behavior with all sorts of other pieces of the machinery. So I’d personally just stick with the 8:59 hack, but perhaps you’re made of sterner stuff than I!

EDIT: Also, hopefully from that tweak it’s clear what’s actually happening – the issue, and fix, aren’t about how the time-advancing rules are sequenced with player action, but about the fact that by default in the post-action bookkeeping Inform does every turn, timed events happen right before time advances. Which sort of makes sense, but in this case leads to odd behavior.

5 Likes

But that dial in the Universe Maintenance Room is right there!

3 Likes

I think in this case it should be okay, actually, because the “time of day” is mostly for the author’s benefit. I don’t think anything except the timed events rule actually looks at it in the Standard Rules, which is why most of the examples in RB 4.1 replace it or hack it in various ways without worrying about the consequences.

Notably, the example Uptempo actually discusses this particular situation, and how you can fix it by rearranging the rules just like you’ve done here.

4 Likes

I spent some time looking at this last night, and moved the advance time rule up in the turn sequence rulebook, too. I didn’t suggest it because I was afraid I’d blow up somebody’s game!

Good to know it’s safe. Looking at Uptempo, it seems like there’s a lot of freedom to mess around, there.

Question, what would be a case in which the default would be more desirable (reporting after the minute ends)? I suppose that while the player experiences things as happening concurrently, things always occur in a sequence within the program. So, a clock cannot toll exactly when the clock reaches nine. They are separate events. Do I have that right?

I guess it doesn’t really matter—it’s only an illusion of time and the important thing is maintaining it credibly. I just have time on the brain!

3 Likes

It’s also easy to add a post-time-advance rulebook:

Upon the stroke of is a time based rulebook.

This is the upon the stroke of stage rule:
  follow the upon the stroke of rules for the time of day.

The upon the stroke of stage rule is listed after the advance time rule
  in the turn sequence rules.

Upon the stroke of 9 am: say "The bells ring for nine o'clock."
3 Likes