Backslasher
Joined 6 years ago
Joined 6 years ago
https://news.ycombinator.com/item?id=49432857
Thought about doing it as a Linux screensaver, but I didn't have the patience to actually wait for the idle time, and that way I can share it with my non-Linux-using family.
I saw Bryan's CSS version (https://www.bryanbraun.com/after-dark-css/all/flying-toaster...), and tried reproducing it with manually-extracted sprites (windows virtualbox -> ffmpeg -> gimp) about 2 years ago, resulting in https://backslasher.github.io/flying-toasters-legacy/
They both didn't scratch my itch fully, and I had some Fable credits available so I decided to put it to good use.
This reproduction is fully based on the sprites, music, sfx, engine logic of the original screensaver. It has the "gags" (toasters doing something silly), baby mode (which I'm not a fan of, but to each their own), and karaoke.
Claude Fable did a lot of good work, including some basic validation (spinning up a headless Chromium and grabbing console output and screenshots), but I was still needed in the loop. It was really big on magic-number-ing, patching, and "assuming" things and most of my comments that weren't bug reports were pushbacks on it inventing stuff rather than going deeper.
As per usual when doing old-things-disassembly, I marveled at how much rich logic this tiny binary has, e.g. the "gags" that involve multiple toasters (airshow squadron split-off) initialize regular toasters, grab them for the gag, then release them into individual units when done. On the other hand, they didn't have weighted random, and I kept wondering why 10 entries in the flight-act table were identical (loop-de-loop) until I realized it's the same act, and they wanted it 10x more likely to be picked.
New code is AGPL (https://github.com/BackSlasher/flying-toasters-reverse-engin...). Extracted art, behavior, audio remain the property of whoever holds After Dark's IP, and are held for archival purposes (see NOTICE).
If you have questions or other AD screensavers you miss, let me know!
I recognize these from different dev teams where it was agreed that a "how much AI" policy is needed, but the actual policy was very hard to settle on.
Firstly, issue #153175 refers to the "time of day" sensor, which is not what you're using - you're using the "time" trigger. The TOD code does a bunch of timezone acrobatics that can be fixed, but I don't think it'll affect your problem.
Secondly, I built a tiny regression test on dev (on top of 333a3421) to reproduce your problem, and it didn't repro. I created a "trigger: time, at: 06:00:00, Europe/Paris", attached it before the DST transitions, and checked when it fires before, during, after the DST actual. The trigger fires perfectly on 06:00 walltime, and adjusts utc to match.
Thirdly, the HASS UI has a small bug where it shows "Paris/+1" even if it's currently DST. It's a UI bug only, but it can lead to someone thinking that the entire HASS core doesn't respect DST.
Silly tech support questions - are you on latest? Did you try playing around with {{now()}} in developer templates? Maybe open a new issue?
I hope there won't be a reelection as it won't get that much of a momentum.
One can use this to get the bloc breakdown (Hebrew): https://www.kan.org.il/lobby/skarim/