time triggers

[Avenger]

Some clarification is needed. The time parameter is given in full hours.

The actual time hours appear to be rounded (2:30 = 3).

So TimeLT(3) won't be true at 2:30!

[devSin]

I didn't catch your note here before PPG. My assumption has always been that time corresponds to the bits in the schedule field (for scheduled objects; actors, animations, and ambient sounds). Which means an hour runs from n:30 to (n+1):29, but I've never bothered to really look at this in-game.

 

So, it's not really rounding, but that 3 PM is specified as the hour-long range between 2:30 and 3:29 PM (OK, so maybe it is rounding). Or something. Somebody should work out whether the calculation is done from game seconds or not (much easier than trying to guess if this particular game minute is 3:00 or 3:01).

[Avenger]

It sounds realistic that the schedule and the time triggers are working the same way.

[devSin]

But why would they do the schedules that way? Maybe time in Canada is offset by 30 minutes from the rest of the world or something?

 

To me, 0:00 to 0:59 would have been the logical choice over 0:30 to 1:29?

 

I think you can just use the bits to eyeball times (if you have TimeLT(12), you want bits less than 12 (0-11)), but I can't be certain without actually having tested it.

[SimDing0]

To me, 0:00 to 0:59 would have been the logical choice over 0:30 to 1:29?

If I'm understanding TimeGT/LT correctly, a 0:00 to 0:59 scale would mean that TimeGT(0) started being true only at 1:00, while TimeLT(0) began at 11:59 and below? This isn't a good spread--it makes more sense to place the divider equally on either side, at the half-hour mark.

As for schedules, the same principle applies really. If I place an actor at 12:00, I'd rather he be active around 12:00, not between 12 and 1.

[devSin]

Since the schedules only support 1 hour increments, that makes a lot of sense. I guess the unfriendly triggers are just a consequence of the more natural scheduling.

[devSin]

Below is a copy of my PPG post. I suspect that TimeLT(24) would work fine, but I don't think you could do TimeGT(-1) for midnight; I doubt the trigger wraps around, only the time, so TimeGT(23) wouldn't ever be true.

 

I had a chance to check this out last night. Time is related to the 24 hour schedule used by scheduled objects as thus:

bit 0  - 0030 to 0129 - Time(1)  | TimeLT(2)  | TimeGT(0)
bit 1  - 0130 to 0229 - Time(2)  | TimeLT(3)  | TimeGT(1)
bit 2  - 0230 to 0329 - Time(3)  | TimeLT(4)  | TimeGT(2)
bit 3  - 0330 to 0429 - Time(4)  | TimeLT(5)  | TimeGT(3)
bit 4  - 0430 to 0529 - Time(5)  | TimeLT(6)  | TimeGT(4)
bit 5  - 0530 to 0629 - Time(6)  | TimeLT(7)  | TimeGT(5)  // DAWN_START
bit 6  - 0630 to 0729 - Time(7)  | TimeLT(8)  | TimeGT(6)  // DAWN_END
bit 7  - 0730 to 0829 - Time(8)  | TimeLT(9)  | TimeGT(7)
bit 8  - 0830 to 0929 - Time(9)  | TimeLT(10) | TimeGT(8)
bit 9  - 0930 to 1029 - Time(10) | TimeLT(11) | TimeGT(9)
bit 10 - 1030 to 1129 - Time(11) | TimeLT(12) | TimeGT(10)
bit 11 - 1130 to 1229 - Time(12) | TimeLT(13) | TimeGT(11) // NOON
bit 12 - 1230 to 1329 - Time(13) | TimeLT(14) | TimeGT(12)
bit 13 - 1330 to 1429 - Time(14) | TimeLT(15) | TimeGT(13)
bit 14 - 1430 to 1529 - Time(15) | TimeLT(16) | TimeGT(14)
bit 15 - 1530 to 1629 - Time(16) | TimeLT(17) | TimeGT(15)
bit 16 - 1630 to 1729 - Time(17) | TimeLT(18) | TimeGT(16)
bit 17 - 1730 to 1829 - Time(18) | TimeLT(19) | TimeGT(17)
bit 18 - 1830 to 1929 - Time(19) | TimeLT(20) | TimeGT(18)
bit 19 - 1930 to 2029 - Time(20) | TimeLT(21) | TimeGT(19)
bit 20 - 2030 to 2129 - Time(21) | TimeLT(22) | TimeGT(20) // DUSK_START
bit 21 - 2130 to 2229 - Time(22) | TimeLT(23) | TimeGT(21) // DUSK_END
bit 22 - 2230 to 2329 - Time(23) | TimeLT(-)  | TimeGT(22)
bit 23 - 2330 to 0029 - Time(0)  | TimeLT(1)  | TimeGT(-)  // MIDNIGHT

Have fun!