Hey Folks! Doing some more work on the sleep system today, as I'm realizing some of the limitations it implies for crew work/shifts.
One of the big problems I ran into was that my circadian rhythm setup was wrong, and it was causing a new rhythm to begin each time the crew finished a ~1.5 hour sleep cycle. Basically, they'd never wake up. Furthermore, I couldn't really think of a way to interrupt their sleep if I wanted them to wake before fully rested. E.g. in an emergency or via alarm clock. Finally, it was based on my original, limited, interaction system which required the bed to "talk back" to the crew every so often to proceed.
So there were a couple of problems to overcome. (Which also apply to other long tasks like work.) And the complex cyclical/circadian sleep, in particular, was really giving me grief.
So I took a step back and tried a more simple approach. Just an activity that deducts tiredness for each hour slept. And while I'm in there, I've been meaning to test out a "ticker" approach to the way conditions increment over time. Historically, I could add a condition that expires after some time, and that could re-add itself when done, allowing me to do heartbeat-style effects. But it's really clunky. And a bit expensive when you get more and more of these on each item/crew, each updating in parallel.
The "ticker" is just that: a timer that counts down, and when it reaches zero, I apply its effects to a crew/item. It resets, and begins counting down again. Something like my "start sleeping" interaction can apply one of these to the crew, and that ticker deducts tiredness (and any other stats) over time while applied. Then, upon waking, that ticker is removed.
One of the benefits of this approach is that I can basically put all these tickers into a list sorted by whichever one expires soonest. I just count down the one at the head of the list until it's done, apply its effects, reset it's timer, and insert it back into the list in chronological order. And if the next item in the list also expired, I handle that and move it back, etc. Until the head of the list still has time left.
The benefit of this approach is that I just have a float value ticking down over time, and only have to bother checking/applying things when it hits zero. As opposed to tracking duration on each condition in a huge dictionary, as I did before. Basically, only one timer needs updating per crew/item if I do it this way, vs. many per.
If this works out, I'll probably migrate a lot of the other ticker conditions to this system. But first, let's see if it helps make sleeping work.
For now, though, it's time to take a break. (And, by the looks of it, shovel the driveway.). Hope everyone has a good weekend!