(Link to video)
Submission Text Full Submission Page Publication Page
Kwirk is a puzzle game (called Puzzle Boy in Japan) which involves pushing blocks which fill in holes in the ground allowing you to reach the exit. It has 30 progressively more challenging levels which are played in the "Going Up" Mode.
Emulator / replay file Duration Time saved (overall) 📦 saved by Bird's-eye Viewextra UI lag Compared to
BizHawk 2.9.1 (Gambatte, GBA)15:13.627504 📦13.644952 s
BizHawk 2.9.1 (Gambatte) 15:15.888488 📦13.644929 s
BizHawk 2.9.1 (GBHawk) 15:15.910 (54705 frames) 📦13.645 s (815 frames)
BizHawk 2.3.3 - 2.5.2 15:16.010 (54711 frames)30.003 s (1792 frames)📦13.511 s (807 frames) 0.017 s (1 frame) Nitrodon, ZenicReverie, Alyosha v2[1]
BizHawk 2.2.2 - 2.3.2 15:08.710 (54275 frames)31.777 s (1898 frames)📦13.662 s (816 frames) 0.033 s (2 frames) Nitrodon, ZenicReverie, Alyosha
VBA-rr 15:03.520 (53965 frames)47.064 s (2811 frames)📦13.377 s (799 frames) 0.033 s (2 frames) Nitrodon
25 out of the 30 levels in this TAS are solved optimally using DDD (delayed duplicate detection), a project created by CyberShadow and contributed to by me, which does a breadth-first brute force search through the space of all possible solutions, finding one of the shortest possible duration. (The project is modular, and Kwirk is its flagship problem-module.) Source code: DDD, DDD-Kwirk
Of these 25 levels, fully optimized solutions to 7 of them have never been published until now. Two of these I've freshly computed; the other five were solved 10-13 years ago. I've further shortened the run by using the more 2D "Bird's-eye View" instead of the default 3D-ish "Diagonal View"[2] (counterintuitively, since this takes 1 more frame at first).
One of the freshly optimized levels is 3-6, which for the last 216 days has been monopolizing 32 GB or more of my computer's 64 GB of RAM, most of its CPU, the exclusive use of a 200+ TB RAID volume, and much of my time making sure it continued to run correctly and had enough disk space to finish.
An additional amazing fact came to light post-submission. The number of frames it takes to push a block into a hole is 36 in Diagonal View, but only 28 in Bird's-eye View. This means using the latter results in far more tremendous time saving than I had previously thought; 0.402 - 0.670 s is saved just by having less lag between levels in this view, but the quicker push-fill animation adds another 12.992 s (776 frames) of savings (dependent on which level solutions are used).
Note that although the UI input in the screens between levels is fully optimized, the new solution for Level 2-8 introduced 2 frames of extra lag in the pressing of "Start" for Level 2-9; this is covered in the "extra UI lag" column above, which specifies how much slower this submission is than the previous records due to between-level UI lag.
[1] This replay file is 56504 frames long, but its last (empty) frame can be removed without breaking it, making it 56503 frames (15:46.013) for the purposes of this comparison.
[2] Diagonal View versions of the replay files may be downloaded from the "📦" column of the table.
The "Improvement" columns in the following table compare against the previous record, if the same solution had been done in Diagonal View. The "saved by Bird's-eye View" column shows how many frames are saved by using that view mode instead of Diagonal View. As such, you need to calculate the sum of the two columns to get the total number of frames saved. The addends in the "Steps" column represent the number of "switch" actions (which Kwirk itself doesn't count as steps).
LevelDuration (frames)Improvementsaved by Bird's-eye ViewSteps ImprovementOptimality
1-1 220 23 optimal
1-2 176 19 optimal
1-3 207 22 optimal
1-4 231 8 23 optimal
1-5 292 8 29 optimal
1-6 453 8 34+3 optimal
1-7 466 47 optimal
1-8 442 48 optimal
1-9 254 26 optimal
1-10 472 47 optimal
2-1 396 41 optimal
2-2 1884 18 32 195 2 optimal
2-3 983 32 98 optimal
2-4 2409 56 241 optimal
2-5 1036 8 106 optimal
2-6 1011 16 105 optimal
2-7 2230 6 16 232 optimal
2-8 2535 16 88 249 2 optimal
2-9 1414 16 118+7 unknown
2-10 310 2 33 optimal
3-1 945 18 8 100 2 optimal
3-2 1788 24 180 optimal
3-3 1196 16 125 optimal
3-4 3251 80 321 unknown
3-5 461 47 optimal
3-6 2518 463 64 249 51 optimal
3-7 3049 425 56 309 44 optimal
3-8 2858 8 217+24 unknown
3-9 3898 18 96 389 2 unknown
3-10 4170 18 136 412 2 unknown
The following tables are presented in reverse chronological order. Since Kwirk itself does not count "switch character" operations in its Step counts, the "Steps" columns below include an additional addend specifying the number of "switch" steps where nonzero.

This TAS, in Bird's-eye View, combining the best of the below

LevelDuration (frames)saved by Bird's-eye ViewSteps Optimality
1-1 220 23 optimal
1-2 176 19 optimal
1-3 207 22 optimal
1-4 231 8 23 optimal
1-5 292 8 29 optimal
1-6 453 8 34+3 optimal
1-7 466 47 optimal
1-8 442 48 optimal
1-9 254 26 optimal
1-10 472 47 optimal
2-1 396 41 optimal
2-2 1884 32 195 optimal
2-3 983 32 98 optimal
2-4 2409 56 241 optimal
2-5 1036 8 106 optimal
2-6 1011 16 105 optimal
2-7 2230 16 232 optimal
2-8 2535 88 249 optimal
2-9 1414 16 118+7 unknown
2-10 310 33 optimal
3-1 945 8 100 optimal
3-2 1788 24 180 optimal
3-3 1196 16 125 optimal
3-4 3251 80 321 unknown
3-5 461 47 optimal
3-6 2518 64 249 optimal
3-7 3049 56 309 optimal
3-8 2858 8 217+24 unknown
3-9 3898 96 389 unknown
3-10 4170 136 412 unknown

Alyosha (2024-02-24), in Bird's-eye View

LevelDuration (frames)StepsOptimality
3-9 3898 389 unknown
3-10 4170 412 unknown

Sand (2024-02-22)

LevelDuration (frames)StepsOptimality
2-9 1430 118+7 unknown

DDD (2023-07-19 to 2024-02-26), Deadcode

LevelDuration (frames)StepsOptimality
2-8 2623 249
3-6 2582 249

Alyosha (2020-01-13)

LevelDuration (frames)StepsOptimality
2-7 2252 232 inoptimal duration
3-4 3331 321 unknown
3-7 3530 353 inoptimal
3-9 4012 391 inoptimal

ZenicReverie & Alyosha (2018-04-27 to 2018-06-29)

LevelDuration (frames)StepsOptimality
2-1 396 41 optimal (already DDD-solved)
2-2 1934 197 inoptimal
2-3 1015 98 optimal (already DDD-solved)
2-4 2465 241 optimal (already DDD-solved)
2-6 1027 105 optimal (already DDD-solved)
2-7 2289 236 inoptimal duration
2-9 1432 118+7 inoptimal duration; optimality of steps unknown
3-2 1812 180 optimal (already DDD-solved)
3-4 3338 322 inoptimal
3-7 3548 355 inoptimal
3-9 4048 395 inoptimal
3-10 4324 414 inoptimal
The entries marked "optimal (already DDD-solved)" above were reconstructed by ZenicReverie & Alyosha with only the information that was available at the time, i.e. the numbers of steps of the DDD solutions found by CyberShadow, but neither the solutions themselves nor their durations.

DDD (2010-01-13 to 2010-02-12), Deadcode

LevelDuration (frames)StepsOptimality
2-2 1916 195
2-6 1027 105
2-7 2246 232
3-7 3105 309

DDD (2009-10-20 to 2009-12-13), CyberShadow

LevelDuration (frames)StepsOptimality
2-1 396 41
2-3 1015 98
2-4 2465 241
2-10 310 33
3-1 953 100
3-2 1812 180
3-7 3244 322 inoptimal
Note that all of the levels marked "optimal" in the below table were confirmed as optimal by CyberShadow's DDD runs, despite being omitted from the table directly above.

Nitrodon (2007-01-21 to 2007-04-01)

LevelDuration (frames)StepsOptimality
1-1 220 23 optimal
1-2 176 19 optimal
1-3 207 22 optimal
1-4 239 23 optimal
1-5 300 29 optimal
1-6 461 34+3 optimal
1-7 466 47 optimal
1-8 442 48 optimal
1-9 254 26 optimal
1-10 472 47 optimal
2-1 414 43
2-2 2252 231
2-3 1049 104
2-4 2481 243
2-5 1044 106 optimal
2-6 1045 107
2-7 2315 239
2-8 2639 251
2-9 1505 130+6
2-10 312 33 inoptimal duration
3-1 971 102
3-2 1859 185
3-3 1212 125 optimal
3-4 3484 338
3-5 461 47 optimal
3-6 3045 300
3-7 3580 360
3-8 2866 217+24 unknown
3-9 4061 396
3-10 4513 434
CyberShadow started the DDD (delayed duplicate detection) project on 2009-10-19, with Kwirk as its flagship problem-module, and posted about it on the TASVideos forum. I joined the project on 2010-01-07. My computer system had an advantage for running DDD, in that I already had some fairly large RAID arrays (with a fast hardware RAID controller) to store my DSLR photos and HDV videos, and in early 2010 was able to put my 9× 750 GB drives in a RAID 0 (with 762 MB/s max transfer rate) for use exclusively by DDD, because I had moved their data onto my newer 10.5 TB RAID 5 array and hadn't yet run out of space on it (which, when that happened, would necessitate putting the older drives back into RAID 5 and returning to using their storage for its original primary purpose).
At this point, CyberShadow had already solved 20 levels with DDD. This meant there were 10 levels that hadn't been DDD-solved yet (but the solution for level 3-7 was inoptimal, so there were actually 11 levels that hadn't been optimally-solved yet; I have previously ascribed this to a bug in the validator filter, but I don't actually have any evidence for that in my records, so I'm not sure why it was inoptimal).
My contributions at this point included:
  • Implementing importing of levels from Nitrodon's TAS (a .VBM emulator replay file) into DDD's output format. At the time this allowed doing an apples-to-apples comparison of the number of frames and steps taken by his solutions, versus the optimal solutions found by DDD – but I think even then I was preparing for eventually exporting to a replay file.
  • Speeding up DDD significantly (especially for use with RAIDed hard drive storage, as opposed to an SSD)
  • Running DDD on some of the as-yet-unsolved levels:
    • Level 2-7, on 2010-01-13
    • Level 2-6, on 2010-01-14
    • Level 3-7, on 2010-02-02 (both with and without its validator filter, which prunes states in which any block is adjacent on two sides to a wall; without it, the run took 8.94 hours, and with it, it took 2.27 hours)
    • Level 2-2, on 2010-02-12 (this is the day the run finished, having taken 9 days, or 138.8 hours of DDD run time)
On 2013-04-12 I revisited the project. I was, as I recall, pretty sure that still none of the remaining unsolved levels would be solvable with my hardware at the time. I implemented exporting of the full run of all levels to a .VBM replay file. As part of this project, I made "diagonal view / bird's-eye view" an option. At first, this was mainly because I found the "bird's-eye" view (a much more 2D view than the "diagonal" view) much more pleasant and comprehensible to watch... but unexpectedly, it turned out that "bird's-eye view" also made for an overall faster run; even though it adds 1 extra frame initially to move the selection down to this option, in the between-level screens, it results in slightly less overall lag than "diagonal view". The original TAS [and the two that followed it] used "diagonal view".
Making things even more complicated, it turned out the amount of lag delay required before each level is different [and as I later learned, can potentially be affected by the details of how the previous level was solved, as shown by the fact that after I optimized level 2-8, the delay needed before the next level increased by 2 frames – this phenomenon is quite rare though]. In general, the amount of delay needed for different levels can vary by as much as 5 frames [the emulator version also affects this].
I then discussed releasing a new TAS with CyberShadow. It would use the solutions from Nitrodon's TAS in place of levels that had not yet been solved by DDD. But he was not interested in releasing a TAS that was not fully optimal. I didn't pursue the discussion further, and left the project on the back burner.
Fast forward to 2023-07-19. I had purchased a new set of hard drives, because I was running low on space (only about 10 TB free out of my 154 TB total). It had taken 5 years for me to reach this point after buying my last set of drives (80 TB in RAID 6), and I realized that this would be my last chance to try DDD again for quite a while. The new drives would make for a 160 TB array in RAID 6, but 200 TB in RAID 0. And I knew that once I started using it in RAID 6 for its primary purpose, it would be less optimal for DDD usage, not only due to the overhead of RAID 6, but due to the fastest area of the volume being filled up first. And then it would take another 10+ years before I'd need a new array.
The part of this that hurt, is that for the entire time I'd be running DDD, I would not be able to make use of these new drives in any other way, and would need to make do with the dwindling space on my existing RAID 6 volumes. I had already spent 10 days doing maximum-precision benchmarks of the new drives, and now would still not be able to use them for the primary purpose I'd bought them for, for some unknown number of weeks or even months. Not to mention that also half of my RAM would be monopolized for this entire time. But I decided this was acceptable.
So I revisited the DDD project. I was rather shocked to discover that two newer TASes had been released in the interim. I felt rather conflicted about this. On the one hand, if I had released a TAS back in 2013, nobody would've had to attempt to reconstruct the optimal solutions based on the limited information that had been posted by CyberShadow (i.e., the number of steps taken by each solution he solved with DDD) – in the case of levels 2-1, 2-3, 2-4, 2-6, and 3-2, achieved with 100% success by ZenicReverie & Alyosha. On the other hand, as part of that project, ZenicReverie & Alyosha had made great improvements in the solutions for levels 2-9, 3-4, 3-9, and 3-10 (which haven't been solved by DDD), which is awesome.
It turned out that level 2-8 only took 2 days to solve with my current hardware – much faster than I expected; it probably would have been solvable in 2010 (I don't know why I didn't). The only remaining level that looked practically solvable by DDD was level 3-6. And for all I knew, the solution run might require a full 200 TB of disk space. I decided not to try to write a validator filter to speed up the solving, because unless I could very carefully and rigorously prove that it wouldn't discard possible solutions, it wouldn't yield a guaranteed-optimal solution.
On 2023-07-21, as well as starting DDD on level 3-6, I also implemented import/export of the BizHawk .BK2 emulator replay file format. Exporting can now be done to the same emulator versions used by Nitrodon's TAS (VisualBoyAdvance-rerecording) and ZenicReverie & Alyosha's second TAS (BizHawk 2.5.2), as well as BizHawk 2.9.1. As such, the improvements can be directly compared, as apples-to-apples.
Strangely, in ZenicReverie & Alyosha's second TAS, at level 3-8, the 174th step (a "switch" after an "up", at 12:59.283 in the published video file) takes 2 frames less than it should as modeled by Kwirk-DDD. I have not attempted to replicate this quirk in the exported .BK2, as doing so would open a can of worms, probably requiring reverse-engineering Kwirk at a deep level to figure out what's really going on (with this, and the other causes of lag variation discussed above). Perhaps that will be done in the future by me or someone else, but I'm not up to doing it at this time.
After running DDD on level 3-6 for a while, it became possible to estimate how much longer it'd take to complete (in a worst-case scenario, with the existing TAS solution being no better than the optimal one). This projected that the second run would finish, at the latest, sometime in June 2024. But to my great surprise and jubilation, DDD found the exit on 2024-02-16, for a 2582 frame run. That is *much* faster than the 3045 frame run from Nitrodon's TAS! Of course, DDD still needed to do a backtrace to find the actual sequence of moves comprising this solution. (So I used that time to prepare this writeup.)
In the end, it took 161 days (130 days of DDD run time) to finish solving level 3-6 (or 216 days including the scrapped run), peaking at 163 TB of disk usage (which would have been 203 TB if I'd not had the closed node files up to frame-group 237x compressed at this point). Along the way, I made some more speed-up improvements to DDD. I estimate that with these, it would now take 115 days of DDD run time to solve level 3-6 from scratch (*without* using the now-known information of the duration of its optimal solution, which would speed up the run further due to not needing to store nodes beyond that point in game-time).
The remaining levels not solved by DDD are 2-9, 3-4, 3-8, 3-9[3], and 3-10. For these it may be impossible to do so (at least without a supercomputing cluster), due to exploding exponential complexity (and in the case of 2-9 and 3-8, there are 3 or 4 player characters, making it even worse). There may be some tricks that could enable the solving of some or all of these levels, among which may be writing validator filters for them (being careful to prove rigorously that no valid solution will contain intermediate states that would be marked as invalid). But I have decided that now would be a good time to release a TAS, even though five of its levels may not be fully optimized.
Note that Kwirk-DDD optimizes for least time (in frames), not necessarily least number of steps. It seems likely that most or all of the DDD-found solutions do also have the optimal numbers of steps, but this is not by any means guaranteed. And due to the way the backtrace is done, it's not even guaranteed that a solution rendered by DDD has the least number of steps possible with that number of frames. I'm thinking of implementing a breadth-first "parallel" backtrace (so that the solution will be guaranteed to be the best one when optimizing first for time and second for number of steps). That will require further delaying use of my new hard drives for their primary purpose, but I was prepared to have to wait until June for that anyway.
[3] Level 3-9 is the only one realistically solvable with DDD (at least without additional tricks), and after running it for 22 days (after the publishing of this submission), I estimate it would require 2-3 petabytes of storage and 10-20 years (at the speed of my current hardware) to complete.
A blow-by-blow timeline of the hazards/adventures I navigated through while running Kwirk-DDD on level 3-6:
  • 2023-07-21: Started the [initial] run.
  • 2023-07-22: My computer spontaneously rebooted. I later learned that a small bit of file corruption must have happened at this point, because my later run of DDD started on 2023-09-14 disagreed with the node counts of this resumed run from this point onward, by a tiny amount.
  • 2023-07-22: Cleaned my CPU heat sink. The dust was really caked on, making an enormous difference in its cooling efficiency (near-idle dropped from about 50°C to about 30°C, and near-100% load dropped from about 78°C to about 44°C.) This was probably in part responsible for the corruption that I later learned had occurred.
  • 2023-07-25: Power brownout (forced me to power cycle and resume from the last save point)
  • 2023-07-29: Switched from a mildly overclocked i7-4930K (12 cores) to a Xeon E5-2687W v2 (overclock not allowed, but 16 cores and more cache), to eke out the best performance I could from my 8-year-old X79 sytem with 64 GB DDR3-2400 RAM.
  • 2023-08-01: My surge suppressor turned itself off for an unknown reason. Resumed from last save point.
  • 2023-08-04: Switched DDD from "WinAPI spinlock sync" to "WinAPI sync". It turns out that spinlock sync has absolutely no advantages, and is in fact rather horrible. (It may even have been responsible in part for the corruption that I later learned had occurred.) I think one of the reasons I was using it was that it shows near-100% CPU usage, and non-spinlock sync was showing 50%-86% CPU usage in the Expanding phase, making me thinking the former was more efficient. But the latter is actually just as efficient if not more, and plays better with other processes. (See the 2024-02-18 entry below for the reason behind the low CPU usage.)
  • 2023-08-10: A hard drive dropped out of the RAID. Nothing wrong with the drive. Resumed from last save point.
  • 2023-08-15: A hard drive dropped out of the RAID. Nothing wrong with the drive. Resumed from last save point.
  • 2023-08-17: (Background: I'm still running Windows 7 because I feel that Microsoft code is no longer trustworthy from Windows 8 onward, not even Windows 10 LTSC, and because various things are necessary before I can switch to Linux). What I did not know before, is that in Windows 7, NTFS doesn't support file sizes of 16 TiB or larger. So when the "combined-25-181x.bin" file needed to exceed this size, DDD crashed. Strangely, ExFAT under Windows 7 does support larger file sizes. So I migrated the DDD files from NTFS to ExFAT. Since there is no software that can convert an NTFS partition to ExFAT, this meant using PartitionGuru v4.9.5 to resize the existing partition from 200 TB to 100 TB and create a new ExFAT partition, then copy the files over to it, and use PartitionGuru to delete the NTFS partition and resize the ExFAT partition from 100 TB to 200 TB. This whole interlude took 62 hours.
  • 2023-09-11: A hard drive dropped out of the RAID. Nothing wrong with the drive. Power cycled and resumed from last save point. CHKDSK reported that there were errors, so I let it run with the "/F" switch.
  • 2023-09-14: ExFAT does not have journalling, so it isn't as robust as NTFS at resuming after a sudden reboot, power cycle, or offlining of a filesystem that happened while file(s) were being appended. It turned out to have been a mistake having run "CHKDSK /F"; evidentally, at least in Windows 7, it's unreliable when run on an ExFAT partition. Instead of properly repairing the filesystem, it had introduced actual damage (crosslinking of files, I think), and by the time I realized, essential data had already been overwritten, and I had to start DDD from scratch. This was just as well, though, because as discussed above, there had already been slight corruption very early on.
  • 2023-09-15: Implemented preallocation in the Combining phase. This prevents a sudden crash from causing filesystem corruption during this phase (and provides a performance improvement due to vastly reducing filesystem fragmentation). This phase takes much longer than the others, meaning it's the most likely to be running at any given time, such as when a crash occurs. [A couple of later crashes did happen during the Merging phase, for which I hadn't implemented preallocation, but I just let the resulting falsely-marked-allocated blocks stay there, because I no longer trusted CHKDSK to fix them, and fsck.exfat under Linux is evidentally incapable of fixing that type of error.]
  • 2023-09-22: A hard drive dropped out of the RAID. Nothing wrong with the drive. Resumed from last save point.
  • 2023-09-27: The same hard drive dropped out of the RAID. The culprit was the SATA power 4× splitter cable leading to this drive. This normally happens to me only a small number of times per year (a bit more frequently if I'm heavily using the drives), and the (temporary) solution is to power off, remove the cable, massage all of its joints, then put it back in place. What's probably happening is micro-corrosion/oxidation at the crimped joints. The annoying thing is that I haven't been able to find any higher-end SATA power 4× splitter available for purchase. My eventual solution for this might be to modify my existing splitters, using contact cleaner on them (or maybe even soldering the crimped joints) then some sort of sealant on top of that. (Note that this problem was far worse back when I was using backplane enclosures rather than dumb enclosures and power splitters.) Resumed from last save point.
  • 2023-10-22: A different hard drive dropped out of the RAID. Power cycled and massaged the relevant SATA power splitter. Resumed from last save point.
  • 2023-10-28: Started using 7-Zip to compress the "closed-25-*.bin" files, because it was looking like I might run out of hard disk space if the optimal solution turned out to be nearly as long (in frames) as the original TAS's solution. At first I used a fast compression ratio of about 16% to catch up with the point that had already been reached, then once caught up, I multitasked the compression of each new file during non-CPU-intensive phases of DDD using a moderate-speed 11% ratio.
  • 2023-11-21: A hard drive dropped out of the RAID. Nothing wrong with the drive. Resumed from last save point.
  • 2023-11-21: The same hard drive dropped out of the RAID. Power cycled and massaged the relevant SATA power splitter. Resumed from last save point.
  • 2023-11-21: A different hard drive dropped out of the RAID. Power cycled and massaged the relevant SATA power splitter. Resumed from last save point.
  • 2023-11-22: Accidentally kicked my surge suppressor's power button (forcing me to power cycle and resume from the last save point).
  • 2023-11-27: At this point, my projections showed that I would definitely run out of hard disk space if the optimal solution turned out to be as long as the original TAS's solution. I bought 4 additional hard drives, bringing the RAID 0 up to 280 TB. (This will also make for a 240 TB RAID 6, meaning it should tide me in for 15+ instead of just 10+ years. And results in a much faster sustained transfer rate at the end of the volume.) To migrate the DDD data, I compressed the 45.1 TiB "combined-25-223x.bin" file with 7-Zip (all the "closed-25-*.bin" files had already been compressed). I had to split the "combined-25-223x.bin" file into 6 pieces because Windows (at least Windows 7) can't memory-map files sized 16 TiB or larger, and 7-Zip relies on memory-mapping (also, this allowed rebooting / power cycling without losing all of the compression progress). Then after I'd already recombined the pieces in the new 280 TB partition, I realized that since I'd used "dd" in unbuffered I/O mode to do the splitting under Windows, the last 36184 bytes hadn't been properly carried over during the splitting process. Luckily I was able to recover the data, finding that the ending of the "combined-25-223x.bin" file from the pre-migration 200 TB RAID volume hadn't been overwritten yet (it hugely helped here that the file was only very lightly fragmented, thanks to my preallocation). This whole interlude took 14.85 days – out of which the compression of "combined-25-223x.bin" with a 11.1% ratio took 7.53 days.
  • 2023-12-14: Modified DDD to not 32-bit-align the "open node" data structure, resulting in about a 11% speedup in the Merging and Combining phases. Not only is x86 very good at dealing with unaligned data, but DDD is a 64-bit program anyway, so 32-bit alignment wasn't resulting in a performance improvement in any way. Even if it had been, the net effect of the alignment was to reduce performance, due to forcing hard disk transfers to deal with 15% more data than they needed to. I then had to write a small program to convert the 46.8 TiB "combined-25-225x.bin" file into a 39.8 TiB file, which was a bit nontrivial due to the need to use unbuffered disk I/O (buffered/cached I/O is slow in Windows, especially when the disk is a RAID 0 that can do transfers at up to 2.0 GiB/s). This whole interlude took 19 hours.
  • 2023-12-19: My computer spontaneously rebooted. Resumed from last save point.
  • 2024-01-03: A hard drive dropped out of the RAID. Nothing wrong with the drive. Resumed from last save point.
  • 2024-01-10: The same hard drive dropped out of the RAID. Power cycled and massaged the relevant SATA power splitter. Resumed from last save point.
  • 2024-02-01: Power brownout during rain (forced me to power cycle and resume from the last save point)
  • 2024-02-04: Power brownout during rain (forced me to power cycle and resume from the last save point)
  • 2024-02-14: A hard drive dropped out of the RAID. Nothing wrong with the drive. Resumed from last save point.
  • 2024-02-16: Exit (solution state) found by DDD. Solution backtrace begins. I started decompressing the "closed-25-*.bin" files (and finished that before the next timeline entry below).
  • 2024-02-18: Modified DDD to dequeue nodes in chunks rather than one at a time, resulting in a huge speed-up for the Expanding phase and solution backtrace, due to vastly reducing the amount of time the multithreading code spends waiting for sync. This queue behavior was the reason only 50%-86% CPU was being used in the Expanding phase, and 30%-55% CPU in the solution backtrace. I estimate it would have shaved about 9 days from the run, had I done this improvement before 2023-09-14. Before this, the disk I/O rate during Expanding/backtrace was roughly constant, and it was the CPU usage that fluctuated; with this change, the CPU usage stays pretty constant at about 98%, while the disk I/O rate fluctuates quite a bit. (The fluctuation pattern shows a structure across each frame group that is very consistent between frame groups, as can been seen when plotted in software such as Process Explorer – almost certainly because some nodes yield more child nodes than others, and a large proportion of those children stay sorted similarly).
  • 2024-02-19: Started to "cheat" a bit in the solution backtrace, by skipping back to the frame-group during which I expect the previous step to have occurred.
  • 2024-02-20: The solution backtrace starts reaching parts where it differs quite significantly from the old TAS solution. I will no longer be as much able to help it along, but that will start to matter less and less, as it takes less time to scan each frame-group (due to each earlier one having fewer and fewer nodes).
  • 2024-02-22: Solution backtrace finished!
This is the DDD console output, edited together, dropping the parts that corresponded to computation that was discarded due to crashes, power cyclings, etc. 
Kwirk Level 25 (3-6): 15x17, 1 players
Optimized version
Compressed state is 113 bits (15 bytes data)
Using Windows API files with unbuffered disk I/O
[Thu Sep 14 19:26:00 2023] Starting search
Frame-group   0x/305x:           1 nodes,             1 total; Expanding...    0.038 s; Merging...    0.042 s,            2 nodes; Combining...     0.378 s
Frame-group   1x/305x:           1 nodes,             3 total; Expanding...    0.012 s; Merging...    0.014 s,            2 nodes; Combining...     0.151 s
Frame-group   2x/305x:           1 nodes,             5 total; Expanding...    0.016 s; Merging...    0.014 s,            2 nodes; Combining...     0.150 s
Frame-group   3x/305x:           1 nodes,             7 total; Expanding...    0.011 s; Merging...    0.014 s,            6 nodes; Combining...     0.149 s
Frame-group   4x/305x:           3 nodes,            13 total; Expanding...    0.012 s; Merging...    0.014 s,           10 nodes; Combining...     0.149 s
Frame-group   5x/305x:           1 nodes,            23 total; Expanding...    0.012 s; Merging...    0.013 s,            2 nodes; Combining...     0.148 s
Frame-group   6x/305x:           1 nodes,            23 total; Expanding...    0.012 s; Merging...    0.013 s,            5 nodes; Combining...     0.151 s
Frame-group   7x/305x:           5 nodes,            28 total; Expanding...    0.011 s; Merging...    0.014 s,           22 nodes; Combining...     0.150 s
Frame-group   8x/305x:           5 nodes,            50 total; Expanding...    0.011 s; Merging...    0.014 s,           21 nodes; Combining...     0.150 s
Frame-group   9x/305x:          11 nodes,            66 total; Expanding...    0.012 s; Merging...    0.013 s,           55 nodes; Combining...     0.151 s
Frame-group  10x/305x:          11 nodes,           118 total; Expanding...    0.011 s; Merging...    0.014 s,           71 nodes; Combining...     0.151 s
Frame-group  11x/305x:          20 nodes,           180 total; Expanding...    0.011 s; Merging...    0.014 s,          120 nodes; Combining...     0.150 s
Frame-group  12x/305x:          32 nodes,           290 total; Expanding...    0.011 s; Merging...    0.013 s,          203 nodes; Combining...     0.150 s
Frame-group  13x/305x:          46 nodes,           452 total; Expanding...    0.012 s; Merging...    0.014 s,          282 nodes; Combining...     0.151 s
Frame-group  14x/305x:          67 nodes,           714 total; Expanding...    0.011 s; Merging...    0.014 s,          403 nodes; Combining...     0.151 s
Frame-group  15x/305x:         105 nodes,          1061 total; Expanding...    0.012 s; Merging...    0.014 s,          704 nodes; Combining...     0.152 s
Frame-group  16x/305x:         164 nodes,          1604 total; Expanding...    0.011 s; Merging...    0.014 s,          985 nodes; Combining...     0.152 s
Frame-group  17x/305x:         221 nodes,          2272 total; Expanding...    0.012 s; Merging...    0.014 s,         1397 nodes; Combining...     0.151 s
Frame-group  18x/305x:         350 nodes,          3360 total; Expanding...    0.012 s; Merging...    0.014 s,         2119 nodes; Combining...     0.147 s
Frame-group  19x/305x:         469 nodes,          4659 total; Expanding...    0.012 s; Merging...    0.014 s,         2871 nodes; Combining...     0.156 s
Frame-group  20x/305x:         747 nodes,          6764 total; Expanding...    0.012 s; Merging...    0.014 s,         4481 nodes; Combining...     0.152 s
Frame-group  21x/305x:         892 nodes,          9482 total; Expanding...    0.012 s; Merging...    0.014 s,         5453 nodes; Combining...     0.152 s
Frame-group  22x/305x:        1389 nodes,         13406 total; Expanding...    0.013 s; Merging...    0.014 s,         8279 nodes; Combining...     0.152 s
Frame-group  23x/305x:        1572 nodes,         18029 total; Expanding...    0.013 s; Merging...    0.014 s,         9423 nodes; Combining...     0.153 s
Frame-group  24x/305x:        2370 nodes,         24663 total; Expanding...    0.013 s; Merging...    0.015 s,        14686 nodes; Combining...     0.151 s
Frame-group  25x/305x:        2673 nodes,         32542 total; Expanding...    0.014 s; Merging...    0.014 s,        16019 nodes; Combining...     0.153 s
Frame-group  26x/305x:        3937 nodes,         42943 total; Expanding...    0.015 s; Merging...    0.015 s,        24305 nodes; Combining...     0.150 s
Frame-group  27x/305x:        4464 nodes,         55953 total; Expanding...    0.016 s; Merging...    0.014 s,        26644 nodes; Combining...     0.154 s
Frame-group  28x/305x:        6418 nodes,         72165 total; Expanding...    0.017 s; Merging...    0.015 s,        40145 nodes; Combining...     0.155 s
Frame-group  29x/305x:        7584 nodes,         94017 total; Expanding...    0.018 s; Merging...    0.016 s,        46062 nodes; Combining...     0.156 s
Frame-group  30x/305x:       10318 nodes,        120034 total; Expanding...    0.023 s; Merging...    0.017 s,        64720 nodes; Combining...     0.160 s
Frame-group  31x/305x:       12799 nodes,        155171 total; Expanding...    0.022 s; Merging...    0.017 s,        77847 nodes; Combining...     0.157 s
Frame-group  32x/305x:       16409 nodes,        196548 total; Expanding...    0.026 s; Merging...    0.017 s,       103955 nodes; Combining...     0.160 s
Frame-group  33x/305x:       21158 nodes,        253670 total; Expanding...    0.032 s; Merging...    0.017 s,       129198 nodes; Combining...     0.164 s
Frame-group  34x/305x:       26052 nodes,        319443 total; Expanding...    0.034 s; Merging...    0.019 s,       165779 nodes; Combining...     0.166 s
Frame-group  35x/305x:       33881 nodes,        408936 total; Expanding...    0.042 s; Merging...    0.020 s,       209143 nodes; Combining...     0.190 s
Frame-group  36x/305x:       40700 nodes,        510535 total; Expanding...    0.055 s; Merging...    0.021 s,       259934 nodes; Combining...     0.185 s
Frame-group  37x/305x:       52395 nodes,        643866 total; Expanding...    0.062 s; Merging...    0.025 s,       326253 nodes; Combining...     0.181 s
Frame-group  38x/305x:       62331 nodes,        796856 total; Expanding...    0.075 s; Merging...    0.027 s,       400255 nodes; Combining...     0.229 s
Frame-group  39x/305x:       79149 nodes,        990279 total; Expanding...    0.092 s; Merging...    0.027 s,       498615 nodes; Combining...     0.201 s
Frame-group  40x/305x:       93593 nodes,       1212242 total; Expanding...    0.110 s; Merging...    0.029 s,       603624 nodes; Combining...     0.213 s
Frame-group  41x/305x:      119066 nodes,       1485808 total; Expanding...    0.139 s; Merging...    0.033 s,       755091 nodes; Combining...     0.228 s
Frame-group  42x/305x:      139139 nodes,       1812225 total; Expanding...    0.161 s; Merging...    0.037 s,       898041 nodes; Combining...     0.242 s
Frame-group  43x/305x:      177671 nodes,       2200110 total; Expanding...    0.201 s; Merging...    0.041 s,      1128446 nodes; Combining...     0.281 s
Frame-group  44x/305x:      207302 nodes,       2674612 total; Expanding...    0.237 s; Merging...    0.050 s,      1328750 nodes; Combining...     0.307 s
Frame-group  45x/305x:      263067 nodes,       3231663 total; Expanding...    0.298 s; Merging...    0.061 s,      1667198 nodes; Combining...     0.329 s
Frame-group  46x/305x:      305430 nodes,       3917723 total; Expanding...    0.343 s; Merging...    0.069 s,      1949846 nodes; Combining...     0.380 s
Frame-group  47x/305x:      380432 nodes,       4713596 total; Expanding...    0.419 s; Merging...    0.087 s,      2412951 nodes; Combining...     0.403 s
Frame-group  48x/305x:      442717 nodes,       5686306 total; Expanding...    0.494 s; Merging...    0.107 s,      2824370 nodes; Combining...     0.462 s
Frame-group  49x/305x:      539554 nodes,       6808663 total; Expanding...    0.596 s; Merging...    0.112 s,      3436014 nodes; Combining...     0.526 s
Frame-group  50x/305x:      630483 nodes,       8158228 total; Expanding...    0.718 s; Merging...    0.169 s,      4029164 nodes; Combining...     0.602 s
Frame-group  51x/305x:      758293 nodes,       9714389 total; Expanding...    0.856 s; Merging...    0.146 s,      4855487 nodes; Combining...     0.712 s
Frame-group  52x/305x:      890482 nodes,      11561049 total; Expanding...    0.938 s; Merging...    0.173 s,      5700029 nodes; Combining...     0.782 s
Frame-group  53x/305x:     1062072 nodes,      13702001 total; Expanding...    1.174 s; Merging...    0.208 s,      6812699 nodes; Combining...     0.910 s
Frame-group  54x/305x:     1253505 nodes,      16219064 total; Expanding...    1.346 s; Merging...    0.255 s,      8001794 nodes; Combining...     1.072 s
Frame-group  55x/305x:     1482530 nodes,      19149204 total; Expanding...    1.576 s; Merging...    0.293 s,      9488475 nodes; Combining...     1.274 s
Frame-group  56x/305x:     1753217 nodes,      22572681 total; Expanding...    1.869 s; Merging...    0.279 s,     11143347 nodes; Combining...     1.466 s
Frame-group  57x/305x:     2052541 nodes,      26565872 total; Expanding...    2.173 s; Merging...    0.384 s,     13097831 nodes; Combining...     1.673 s
Frame-group  58x/305x:     2426077 nodes,      31199500 total; Expanding...    2.543 s; Merging...    0.384 s,     15379221 nodes; Combining...     1.953 s
Frame-group  59x/305x:     2802757 nodes,      36620654 total; Expanding...    2.966 s; Merging...    0.515 s,     17876081 nodes; Combining...     2.226 s
Frame-group  60x/305x:     3305281 nodes,      42823609 total; Expanding...    3.531 s; Merging...    0.600 s,     20967163 nodes; Combining...     2.569 s
Frame-group  61x/305x:     3795230 nodes,      50100642 total; Expanding...    4.105 s; Merging...    0.601 s,     24273356 nodes; Combining...     2.927 s
Frame-group  62x/305x:     4458424 nodes,      58376380 total; Expanding...    4.791 s; Merging...    0.750 s,     28373382 nodes; Combining...     3.364 s
Frame-group  63x/305x:     5117836 nodes,      68063662 total; Expanding...    5.552 s; Merging...    0.802 s,     32804604 nodes; Combining...     3.880 s
Frame-group  64x/305x:     5975388 nodes,      79074810 total; Expanding...    6.529 s; Merging...    0.985 s,     38136595 nodes; Combining...     4.508 s
Frame-group  65x/305x:     6890177 nodes,      91844962 total; Expanding...    7.565 s; Merging...    1.253 s,     44169032 nodes; Combining...     5.231 s
Frame-group  66x/305x:     7975059 nodes,     106506144 total; Expanding...    8.814 s; Merging...    1.467 s,     51062348 nodes; Combining...     5.993 s
Frame-group  67x/305x:     9232886 nodes,     123286076 total; Expanding...   10.320 s; Merging...    1.640 s,     59164150 nodes; Combining...     6.833 s
Frame-group  68x/305x:    10600760 nodes,     142705581 total; Expanding...   11.873 s; Merging...    1.759 s,     68074809 nodes; Combining...     7.951 s
Frame-group  69x/305x:    12276651 nodes,     164713992 total; Expanding...   14.274 s; Merging...    2.073 s,     78695676 nodes; Combining...     9.088 s
Frame-group  70x/305x:    14037622 nodes,     190242275 total; Expanding...   16.004 s; Merging...    2.339 s,     90413598 nodes; Combining...    10.577 s
Frame-group  71x/305x:    16194714 nodes,     219046696 total; Expanding...   18.675 s; Merging...    3.884 s,    104076332 nodes; Combining...    12.107 s
Frame-group  72x/305x:    18499992 nodes,     252378503 total; Expanding...   20.410 s; Merging...    4.110 s,    119553468 nodes; Combining...    14.191 s
Frame-group  73x/305x:    21257421 nodes,     289944500 total; Expanding...   22.445 s; Merging...    4.713 s,    137070607 nodes; Combining...    15.618 s
Frame-group  74x/305x:    24287503 nodes,     333239313 total; Expanding...   24.667 s; Merging...    5.393 s,    157454981 nodes; Combining...    18.646 s
Frame-group  75x/305x:    27809044 nodes,     382087417 total; Expanding...   26.985 s; Merging...    6.107 s,    179964752 nodes; Combining...    22.038 s
Frame-group  76x/305x:    31772918 nodes,     438180636 total; Expanding...   27.232 s; Merging...    7.464 s,    206576866 nodes; Combining...    23.264 s
Frame-group  77x/305x:    36278717 nodes,     501504776 total; Expanding...   29.294 s; Merging...    8.065 s,    235522279 nodes; Combining...    26.437 s
Frame-group  78x/305x:    41403326 nodes,     573887088 total; Expanding...   34.038 s; Merging...    9.169 s,    270014808 nodes; Combining...    31.769 s
Frame-group  79x/305x:    47143574 nodes,     655676508 total; Expanding...   35.092 s; Merging...   10.633 s,    307094287 nodes; Combining...    34.434 s
Frame-group  80x/305x:    53723469 nodes,     748646012 total; Expanding...   43.368 s; Merging...   12.064 s,    351356651 nodes; Combining...    40.872 s
Frame-group  81x/305x:    60988578 nodes,     853660359 total; Expanding...   40.430 s; Merging...   14.680 s,    398570342 nodes; Combining...    43.762 s
Frame-group  82x/305x:    69351955 nodes,     972478642 total; Expanding...   50.304 s; Merging...   16.004 s,    454974415 nodes; Combining...    51.223 s
Frame-group  83x/305x:    78450180 nodes,    1106547546 total; Expanding...   52.992 s; Merging...   18.008 s,    514487218 nodes; Combining...    56.404 s
Frame-group  84x/305x:    89073759 nodes,    1257487539 total; Expanding...   65.498 s; Merging...   20.010 s,    586172981 nodes; Combining...    63.655 s
Frame-group  85x/305x:   100416860 nodes,    1427627617 total; Expanding...   64.165 s; Merging...   22.895 s,    660916982 nodes; Combining...    72.739 s
Frame-group  86x/305x:   113918588 nodes,    1618273746 total; Expanding...   70.616 s; Merging...   27.251 s,    751793572 nodes; Combining...    83.212 s
Frame-group  87x/305x:   127964751 nodes,    1833060263 total; Expanding...   80.098 s; Merging...   29.441 s,    845252134 nodes; Combining...    93.110 s
Frame-group  88x/305x:   145002540 nodes,    2072672763 total; Expanding...   87.849 s; Merging...   33.934 s,    959080181 nodes; Combining...   108.366 s
Frame-group  89x/305x:   162382643 nodes,    2342130712 total; Expanding...   94.775 s; Merging...   37.828 s,   1075847572 nodes; Combining...   118.770 s
Frame-group  90x/305x:   183493654 nodes,    2641632686 total; Expanding...  105.354 s; Merging...   43.977 s,   1216498193 nodes; Combining...   134.164 s
Frame-group  91x/305x:   205091991 nodes,    2977259312 total; Expanding...  111.700 s; Merging...   48.420 s,   1362032850 nodes; Combining...   150.447 s
Frame-group  92x/305x:   230489827 nodes,    3349584502 total; Expanding...  128.421 s; Merging...   55.275 s,   1532138660 nodes; Combining...   168.844 s
Frame-group  93x/305x:   257574550 nodes,    3764208759 total; Expanding...  146.014 s; Merging...   62.490 s,   1713568510 nodes; Combining...   191.724 s
Frame-group  94x/305x:   287255803 nodes,    4224146692 total; Expanding...  164.973 s; Merging...   71.452 s,   1915935736 nodes; Combining...   213.775 s
Frame-group  95x/305x:   321377805 nodes,    4732626170 total; Expanding...  177.880 s; Merging...   78.600 s,   2141484049 nodes; Combining...   238.094 s
Frame-group  96x/305x:   355428703 nodes,    5297032618 total; Expanding...  198.872 s; Merging...   87.516 s,   2379207913 nodes; Combining...   253.873 s
Frame-group  97x/305x:   398216840 nodes,    5916437620 total; Expanding...  214.604 s; Merging...   95.768 s,   2657780769 nodes; Combining...   289.131 s
Frame-group  98x/305x:   437065943 nodes,    6604071739 total; Expanding...  222.522 s; Merging...  104.996 s,   2936379092 nodes; Combining...   309.647 s
Frame-group  99x/305x:   489652844 nodes,    7354659330 total; Expanding...  250.334 s; Merging...  119.622 s,   3274814396 nodes; Combining...   344.043 s
Frame-group 100x/305x:   534816484 nodes,    8186078175 total; Expanding...  297.975 s; Merging...  137.604 s,   3603419152 nodes; Combining...   386.393 s
Frame-group 101x/305x:   597353085 nodes,    9090779622 total; Expanding...  332.574 s; Merging...  147.222 s,   4005994487 nodes; Combining...   431.933 s
Frame-group 102x/305x:   651285490 nodes,   10088547713 total; Expanding...  352.970 s; Merging...  163.845 s,   4396759427 nodes; Combining...   472.834 s
Frame-group 103x/305x:   722866635 nodes,   11173089430 total; Expanding...  383.581 s; Merging...  181.725 s,   4864644634 nodes; Combining...   523.215 s
Frame-group 104x/305x:   788849524 nodes,   12361232299 total; Expanding...  409.483 s; Merging...  202.066 s,   5332771120 nodes; Combining...   566.856 s
Frame-group 105x/305x:   868229118 nodes,   13653413474 total; Expanding...  448.493 s; Merging...  223.197 s,   5865502848 nodes; Combining...   632.244 s
Frame-group 106x/305x:   949533535 nodes,   15057964474 total; Expanding...  550.983 s; Merging...  248.789 s,   6426252522 nodes; Combining...   690.793 s
Frame-group 107x/305x:  1036004646 nodes,   16587222868 total; Expanding...  586.346 s; Merging...  275.321 s,   7025768951 nodes; Combining...   764.298 s
Frame-group 108x/305x:  1135146884 nodes,   18236735439 total; Expanding...  573.447 s; Merging...  297.698 s,   7692118443 nodes; Combining...   828.669 s
Frame-group 109x/305x:  1229104586 nodes,   20033900981 total; Expanding...  619.481 s; Merging...  329.746 s,   8363877041 nodes; Combining...   914.517 s
Frame-group 110x/305x:  1347046820 nodes,   21959708093 total; Expanding...  677.286 s; Merging...  358.611 s,   9143365862 nodes; Combining...   998.492 s
Frame-group 111x/305x:  1450806235 nodes,   24055879892 total; Expanding...  721.054 s; Merging...  388.813 s,   9898670138 nodes; Combining...  1091.898 s
Frame-group 112x/305x:  1586381124 nodes,   26292432549 total; Expanding...  799.776 s; Merging...  433.193 s,  10790449772 nodes; Combining...  1192.808 s
Frame-group 113x/305x:  1703425669 nodes,   28718601596 total; Expanding...  846.978 s; Merging...  464.410 s,  11644535260 nodes; Combining...  1298.006 s
Frame-group 114x/305x:  1853760277 nodes,   31301004556 total; Expanding...  933.011 s; Merging...  517.147 s,  12640671486 nodes; Combining...  1423.755 s
Frame-group 115x/305x:  1987851483 nodes,   34086708787 total; Expanding...  979.382 s; Merging...  562.723 s,  13609443979 nodes; Combining...  1538.211 s
Frame-group 116x/305x:  2149358121 nodes,   37049247769 total; Expanding... 1067.752 s; Merging...  604.872 s,  14698747962 nodes; Combining...  1673.972 s
Frame-group 117x/305x:  2303575973 nodes,   40222158727 total; Expanding... 1141.447 s; Merging...  658.063 s,  15793980335 nodes; Combining...  1808.015 s
Frame-group 118x/305x:  2473923242 nodes,   43595329509 total; Expanding... 1236.520 s; Merging...  716.773 s,  16969036532 nodes; Combining...  1942.760 s
Frame-group 119x/305x:  2649576002 nodes,   47182009903 total; Expanding... 1313.570 s; Merging...  786.272 s,  18197626403 nodes; Combining...  2042.613 s
Frame-group 120x/305x:  2828775985 nodes,   50993876908 total; Expanding... 1536.721 s; Merging...  831.909 s,  19457683807 nodes; Combining...  2194.487 s
Frame-group 121x/305x:  3024928635 nodes,   55021142047 total; Expanding... 1533.567 s; Merging...  902.607 s,  20816702628 nodes; Combining...  2357.891 s
Frame-group 122x/305x:  3215493859 nodes,   59296580832 total; Expanding... 1573.038 s; Merging...  971.258 s,  22170985833 nodes; Combining...  2540.376 s
Frame-group 123x/305x:  3428832949 nodes,   63793925944 total; Expanding... 1765.153 s; Merging... 1044.165 s,  23646702347 nodes; Combining...  2713.133 s
Frame-group 124x/305x:  3634005550 nodes,   68555967018 total; Expanding... 1895.493 s; Merging... 1100.785 s,  25106323895 nodes; Combining...  2902.572 s
Frame-group 125x/305x:  3860296866 nodes,   73552360190 total; Expanding... 1917.387 s; Merging... 1188.484 s,  26681410179 nodes; Combining...  3120.558 s
Frame-group 126x/305x:  4081994992 nodes,   78822776113 total; Expanding... 2011.709 s; Merging... 1241.969 s,  28251088022 nodes; Combining...  3331.824 s
Frame-group 127x/305x:  4317027382 nodes,   84344251780 total; Expanding... 2124.081 s; Merging... 1303.480 s,  29905888922 nodes; Combining...  3543.336 s
Frame-group 128x/305x:  4555382902 nodes,   90142182508 total; Expanding... 2232.205 s; Merging... 1367.214 s,  31586083727 nodes; Combining...  3774.209 s
Frame-group 129x/305x:  4795921756 nodes,   96209888674 total; Expanding... 2352.776 s; Merging... 1451.615 s,  33305054305 nodes; Combining...  4014.208 s
Frame-group 130x/305x:  5049457199 nodes,  102550903766 total; Expanding... 2483.152 s; Merging... 1533.148 s,  35089278232 nodes; Combining...  4283.957 s
Frame-group 131x/305x:  5295118537 nodes,  109179432282 total; Expanding... 2673.343 s; Merging... 1619.202 s,  36867012833 nodes; Combining...  4519.787 s
Frame-group 132x/305x:  5561011178 nodes,  116077879904 total; Expanding... 2797.407 s; Merging... 1712.640 s,  38745890632 nodes; Combining...  4811.499 s
Frame-group 133x/305x:  5814090512 nodes,  123277619203 total; Expanding... 2928.777 s; Merging... 1812.424 s,  40588729205 nodes; Combining...  5091.129 s
Frame-group 134x/305x:  6088964050 nodes,  130748298378 total; Expanding... 3023.762 s; Merging... 1901.855 s,  42548463672 nodes; Combining...  5357.165 s
Frame-group 135x/305x:  6352841560 nodes,  138527884982 total; Expanding... 3065.081 s; Merging... 2000.115 s,  44465900236 nodes; Combining...  5667.550 s
Frame-group 136x/305x:  6633945327 nodes,  146586896669 total; Expanding... 3249.302 s; Merging... 2091.069 s,  46493679040 nodes; Combining...  5975.276 s
Frame-group 137x/305x:  6910317486 nodes,  154956358516 total; Expanding... 3395.196 s; Merging... 2195.454 s,  48492913416 nodes; Combining...  6304.349 s
Frame-group 138x/305x:  7195353725 nodes,  163620021369 total; Expanding... 3508.834 s; Merging... 2289.406 s,  50572366132 nodes; Combining...  6639.192 s
Frame-group 139x/305x:  7483804027 nodes,  172590983246 total; Expanding... 3622.179 s; Merging... 2496.300 s,  52653839572 nodes; Combining...  7551.324 s
Frame-group 140x/305x:  7771566861 nodes,  181872245984 total; Expanding... 3832.702 s; Merging... 2504.517 s,  54772052436 nodes; Combining...  7603.459 s
Frame-group 141x/305x:  8069810586 nodes,  191458518772 total; Expanding... 4053.333 s; Merging... 2620.118 s,  56932890066 nodes; Combining...  7787.964 s
Frame-group 142x/305x:  8359679929 nodes,  201369342732 total; Expanding... 3986.191 s; Merging... 2692.783 s,  59083337909 nodes; Combining...  8051.729 s
Frame-group 143x/305x:  8664759057 nodes,  211585050436 total; Expanding... 4063.266 s; Merging... 2829.403 s,  61316348660 nodes; Combining...  8426.575 s
Frame-group 144x/305x:  8958528156 nodes,  222135105590 total; Expanding... 4218.100 s; Merging... 2910.799 s,  63505964081 nodes; Combining...  8780.055 s
Frame-group 145x/305x:  9267722858 nodes,  232996549811 total; Expanding... 4421.673 s; Merging... 3022.191 s,  65803631315 nodes; Combining...  9166.136 s
Frame-group 146x/305x:  9569805096 nodes,  244197871354 total; Expanding... 4942.366 s; Merging... 3103.561 s,  68051605140 nodes; Combining...  9563.288 s
Frame-group 147x/305x:  9881528662 nodes,  255725152015 total; Expanding... 4722.052 s; Merging... 3290.583 s,  70410971775 nodes; Combining... 10006.666 s
Frame-group 148x/305x: 10195730915 nodes,  267593844344 total; Expanding... 4684.661 s; Merging... 3414.529 s,  72738071189 nodes; Combining... 10466.269 s
Frame-group 149x/305x: 10511472806 nodes,  279808827720 total; Expanding... 4878.529 s; Merging... 3461.296 s,  75162986805 nodes; Combining... 10926.758 s
Frame-group 150x/305x: 10840009875 nodes,  292367390359 total; Expanding... 5138.343 s; Merging... 3570.582 s,  77587837983 nodes; Combining... 11328.140 s
Frame-group 151x/305x: 11161228513 nodes,  305295463989 total; Expanding... 5361.737 s; Merging... 3678.505 s,  80080185384 nodes; Combining... 11820.638 s
Frame-group 152x/305x: 11504793093 nodes,  318571825450 total; Expanding... 5781.096 s; Merging... 4004.907 s,  82616474000 nodes; Combining... 12877.644 s
Frame-group 153x/305x: 11834264247 nodes,  332238551779 total; Expanding... 5838.554 s; Merging... 3949.686 s,  85181720567 nodes; Combining... 12878.671 s
Frame-group 154x/305x: 12190865395 nodes,  346265310920 total; Expanding... 6762.832 s; Merging... 4167.324 s,  87832589379 nodes; Combining... 13423.926 s
Frame-group 155x/305x: 12532285131 nodes,  360699859555 total; Expanding... 6253.812 s; Merging... 4257.040 s,  90481763048 nodes; Combining... 13839.634 s
Frame-group 156x/305x: 12899098801 nodes,  375511770030 total; Expanding... 6598.704 s; Merging... 4426.528 s,  93243817224 nodes; Combining... 14433.001 s
Frame-group 157x/305x: 13256665919 nodes,  390745106338 total; Expanding... 6605.503 s; Merging... 4541.692 s,  95992642632 nodes; Combining... 14992.572 s
Frame-group 158x/305x: 13631522286 nodes,  406378689821 total; Expanding... 6529.225 s; Merging... 4689.571 s,  98863402467 nodes; Combining... 15586.020 s
Frame-group 159x/305x: 14009707445 nodes,  422445462996 total; Expanding... 6486.453 s; Merging... 4805.251 s, 101738399011 nodes; Combining... 16090.048 s
Frame-group 160x/305x: 14392484581 nodes,  438938489833 total; Expanding... 6659.332 s; Merging... 4910.222 s, 104714403000 nodes; Combining... 16528.979 s
Frame-group 161x/305x: 14794110259 nodes,  455874647548 total; Expanding... 7060.461 s; Merging... 5047.988 s, 107739663875 nodes; Combining... 16757.727 s
Frame-group 162x/305x: 15186962007 nodes,  473264628707 total; Expanding... 7010.413 s; Merging... 4926.060 s, 110821241480 nodes; Combining... 17194.499 s
Frame-group 163x/305x: 15612021454 nodes,  491107235712 total; Expanding... 7214.611 s; Merging... 5123.229 s, 114010814274 nodes; Combining... 18476.597 s
Frame-group 164x/305x: 16019498723 nodes,  509431111685 total; Expanding... 7463.626 s; Merging... 5384.194 s, 117202212938 nodes; Combining... 18751.010 s
Frame-group 165x/305x: 16465517400 nodes,  528218016013 total; Expanding... 7644.341 s; Merging... 5425.027 s, 120557013373 nodes; Combining... 19135.544 s
Frame-group 166x/305x: 16892336425 nodes,  547509924370 total; Expanding... 7893.030 s; Merging... 5784.954 s, 123865363753 nodes; Combining... 20357.470 s
Frame-group 167x/305x: 17354715351 nodes,  567280339863 total; Expanding... 8198.312 s; Merging... 5853.096 s, 127371751321 nodes; Combining... 20431.997 s
Frame-group 168x/305x: 17805234590 nodes,  587572320040 total; Expanding... 8277.726 s; Merging... 6124.399 s, 130810604278 nodes; Combining... 21900.020 s
Frame-group 169x/305x: 18279420422 nodes,  608362042592 total; Expanding... 8655.541 s; Merging... 6359.663 s, 134440535705 nodes; Combining... 22874.848 s
Frame-group 170x/305x: 18754776717 nodes,  629680657586 total; Expanding... 9043.600 s; Merging... 6322.703 s, 138019833344 nodes; Combining... 22686.247 s
Frame-group 171x/305x: 19238167164 nodes,  651518549764 total; Expanding... 9033.236 s; Merging... 6480.531 s, 141748514076 nodes; Combining... 23648.296 s
Frame-group 172x/305x: 19736938804 nodes,  673884704128 total; Expanding...10284.932 s; Merging... 7102.144 s, 145474840075 nodes; Combining... 25411.170 s
Frame-group 173x/305x: 20228311590 nodes,  696790768124 total; Expanding...10788.938 s; Merging... 7326.169 s, 149269025901 nodes; Combining... 25359.743 s
Frame-group 174x/305x: 20746642894 nodes,  720217049357 total; Expanding...10689.004 s; Merging... 7499.983 s, 153138668948 nodes; Combining... 26537.158 s
Frame-group 175x/305x: 21245641871 nodes,  744200238705 total; Expanding...11236.759 s; Merging... 7789.466 s, 156971809592 nodes; Combining... 27570.507 s
Frame-group 176x/305x: 21778108738 nodes,  768694061386 total; Expanding...10950.392 s; Merging... 7910.590 s, 160968850902 nodes; Combining... 28394.213 s
Frame-group 177x/305x: 22285391145 nodes,  793758808700 total; Expanding...11112.884 s; Merging... 7945.247 s, 164825771336 nodes; Combining... 29037.499 s
Frame-group 178x/305x: 22825224615 nodes,  819324413072 total; Expanding...11660.065 s; Merging... 8398.454 s, 168917991096 nodes; Combining... 30087.228 s
Frame-group 179x/305x: 23342573674 nodes,  845465472984 total; Expanding...11970.857 s; Merging... 8548.956 s, 172801393529 nodes; Combining... 31030.695 s
Frame-group 180x/305x: 23883506152 nodes,  872104100191 total; Expanding...12297.119 s; Merging... 8846.415 s, 176945825666 nodes; Combining... 31920.228 s
Frame-group 181x/305x: 24409677921 nodes,  899315297361 total; Expanding...12380.964 s; Merging... 9022.984 s, 180860548823 nodes; Combining... 32179.475 s
Frame-group 182x/305x: 24947125615 nodes,  927024917787 total; Expanding...11752.534 s; Merging... 8792.841 s, 185009370055 nodes; Combining... 32370.623 s
Frame-group 183x/305x: 25480096772 nodes,  955294424760 total; Expanding...11844.161 s; Merging... 9181.499 s, 188965173417 nodes; Combining... 33810.363 s
Frame-group 184x/305x: 26010679819 nodes,  984069778292 total; Expanding...12534.211 s; Merging... 9605.892 s, 193077659066 nodes; Combining... 35187.541 s
Frame-group 185x/305x: 26545461499 nodes, 1013384177943 total; Expanding...12903.699 s; Merging... 9666.914 s, 197068419510 nodes; Combining... 36184.446 s
Frame-group 186x/305x: 27068962816 nodes, 1043214497905 total; Expanding...12649.548 s; Merging... 9812.103 s, 201122385028 nodes; Combining... 37486.419 s
Frame-group 187x/305x: 27600166341 nodes, 1073557902050 total; Expanding...13923.403 s; Merging...10177.587 s, 205136431130 nodes; Combining... 38289.814 s
Frame-group 188x/305x: 28117656504 nodes, 1104427422165 total; Expanding...13772.204 s; Merging...10284.321 s, 209126836607 nodes; Combining... 39236.362 s
Frame-group 189x/305x: 28640760538 nodes, 1135783050819 total; Expanding...13448.417 s; Merging...10481.861 s, 213145875153 nodes; Combining... 41018.606 s
Frame-group 190x/305x: 29153695856 nodes, 1167671942329 total; Expanding...14849.029 s; Merging...10883.747 s, 217081554972 nodes; Combining... 41376.187 s
Frame-group 191x/305x: 29666540648 nodes, 1200023762711 total; Expanding...15451.535 s; Merging...11227.615 s, 221089907383 nodes; Combining... 43366.235 s
Frame-group 192x/305x: 30175030123 nodes, 1232913313326 total; Expanding...17256.763 s; Merging...11489.548 s, 224984388583 nodes; Combining... 44598.983 s
Frame-group 193x/305x: 30678210263 nodes, 1266245692623 total; Expanding...15677.786 s; Merging...11786.382 s, 228972052248 nodes; Combining... 46318.907 s
Frame-group 194x/305x: 31180007041 nodes, 1300116885273 total; Expanding...16153.136 s; Merging...11996.655 s, 232835485200 nodes; Combining... 47347.296 s
Frame-group 195x/305x: 31676066101 nodes, 1334417867765 total; Expanding...16149.332 s; Merging...12218.052 s, 236798555038 nodes; Combining... 48538.611 s
Frame-group 196x/305x: 32168583748 nodes, 1369253184810 total; Expanding...16244.724 s; Merging...12155.514 s, 240635407823 nodes; Combining... 49518.405 s
Frame-group 197x/305x: 32659258355 nodes, 1404511040509 total; Expanding...16607.356 s; Merging...12320.070 s, 244574306712 nodes; Combining... 50472.618 s
Frame-group 198x/305x: 33139581548 nodes, 1440292741064 total; Expanding...17024.436 s; Merging...12593.118 s, 248377116413 nodes; Combining... 52298.991 s
Frame-group 199x/305x: 33627492962 nodes, 1476499542475 total; Expanding...17431.311 s; Merging...12903.961 s, 252304746693 nodes; Combining... 53688.888 s
Frame-group 200x/305x: 34094081519 nodes, 1513211119915 total; Expanding...19571.329 s; Merging...13242.343 s, 256068255924 nodes; Combining... 54470.514 s
Frame-group 201x/305x: 34581029085 nodes, 1550357871371 total; Expanding...18928.445 s; Merging...13460.975 s, 259997432214 nodes; Combining... 56204.929 s
Frame-group 202x/305x: 35035189574 nodes, 1587986194906 total; Expanding...18166.006 s; Merging...13626.000 s, 263723741634 nodes; Combining... 57033.822 s
Frame-group 203x/305x: 35520384338 nodes, 1626062169479 total; Expanding...18704.436 s; Merging...13951.685 s, 267664486642 nodes; Combining... 58423.189 s
Frame-group 204x/305x: 35967193324 nodes, 1664597247373 total; Expanding...18888.393 s; Merging...14199.777 s, 271374695113 nodes; Combining... 60035.343 s
Frame-group 205x/305x: 36447293346 nodes, 1703590399055 total; Expanding...19319.811 s; Merging...14504.497 s, 275314795691 nodes; Combining... 59998.886 s
Frame-group 206x/305x: 36894227868 nodes, 1743023228602 total; Expanding...19144.689 s; Merging...14573.056 s, 279045821718 nodes; Combining... 62154.572 s
Frame-group 207x/305x: 37364584819 nodes, 1782923062178 total; Expanding...19046.463 s; Merging...14318.688 s, 282968184980 nodes; Combining... 69368.219 s
Frame-group 208x/305x: 37815733847 nodes, 1823248946517 total; Expanding...18708.863 s; Merging...14474.217 s, 286745144536 nodes; Combining... 68531.435 s
Frame-group 209x/305x: 38274525090 nodes, 1864043167500 total; Expanding...19872.440 s; Merging...15338.606 s, 290635106606 nodes; Combining... 65242.689 s
Frame-group 210x/305x: 38731122470 nodes, 1905259499030 total; Expanding...19339.127 s; Merging...14964.389 s, 294471250751 nodes; Combining... 74643.567 s
Frame-group 211x/305x: 39177741289 nodes, 1946939322257 total; Expanding...27656.360 s; Merging...15431.558 s, 298322083566 nodes; Combining... 79823.997 s
Frame-group 212x/305x: 39636929586 nodes, 1989041569640 total; Expanding...20834.673 s; Merging...18137.012 s, 302209282616 nodes; Combining... 81798.462 s
Frame-group 213x/305x: 40075309335 nodes, 2031596905786 total; Expanding...19363.260 s; Merging...15559.266 s, 306037568884 nodes; Combining... 68799.119 s
Frame-group 214x/305x: 40531302352 nodes, 2074579997954 total; Expanding...21963.661 s; Merging...16757.527 s, 309948487007 nodes; Combining... 72090.053 s
Frame-group 215x/305x: 40966953004 nodes, 2117996833988 total; Expanding...28875.926 s; Merging...16901.855 s, 313780673761 nodes; Combining... 74264.276 s
Frame-group 216x/305x: 41412984324 nodes, 2161845362562 total; Expanding...20215.893 s; Merging...16120.427 s, 317676360591 nodes; Combining...106502.693 s
Frame-group 217x/305x: 41852967386 nodes, 2206100521212 total; Expanding...23010.079 s; Merging...16287.809 s, 321546992623 nodes; Combining... 77703.416 s
Frame-group 218x/305x: 42281337933 nodes, 2250790572353 total; Expanding...21224.555 s; Merging...18799.357 s, 325381994909 nodes; Combining... 78650.069 s
Frame-group 219x/305x: 42730283504 nodes, 2295852384022 total; Expanding...21226.415 s; Merging...19291.434 s, 329304332247 nodes; Combining... 86432.519 s
Frame-group 220x/305x: 43137689072 nodes, 2341345479278 total; Expanding...21527.247 s; Merging...20926.561 s, 333053322168 nodes; Combining... 91861.488 s
Frame-group 221x/305x: 43592341035 nodes, 2387175084445 total; Expanding...21301.188 s; Merging...19944.954 s, 336995400700 nodes; Combining... 95663.792 s
Frame-group 222x/305x: 43977691585 nodes, 2433418829589 total; Expanding...22631.095 s; Merging...21221.822 s, 340631423983 nodes; Combining... 88552.267 s
Frame-group 223x/305x: 44427648046 nodes, 2479963821022 total; Expanding...22682.974 s; Merging...21504.715 s, 344526856996 nodes; Combining... 85462.533 s
Frame-group 224x/305x: 44793601895 nodes, 2526887691784 total; Expanding...22309.724 s; Merging...20074.809 s, 348033091437 nodes; Combining... 89043.732 s
Frame-group 225x/305x: 45222267286 nodes, 2574082653094 total; Expanding...22111.673 s; Merging...17819.543 s, 351777188245 nodes; Combining... 80577.677 s
Frame-group 226x/305x: 45571829261 nodes, 2621600115184 total; Expanding...22190.828 s; Merging...23857.127 s, 355137891891 nodes; Combining... 91662.141 s
Frame-group 227x/305x: 45959463473 nodes, 2669360934866 total; Expanding...23781.976 s; Merging...20545.831 s, 358610444184 nodes; Combining... 87846.242 s
Frame-group 228x/305x: 46295442943 nodes, 2717369672606 total; Expanding...23372.442 s; Merging...18570.708 s, 361798818443 nodes; Combining... 90478.584 s
Frame-group 229x/305x: 46625863313 nodes, 2765597445393 total; Expanding...25336.200 s; Merging...19216.351 s, 364898786904 nodes; Combining... 92275.565 s
Frame-group 230x/305x: 46945916956 nodes, 2813984975780 total; Expanding...26370.882 s; Merging...19265.636 s, 367867748651 nodes; Combining... 95796.334 s
Frame-group 231x/305x: 47208576028 nodes, 2862567783798 total; Expanding...25966.004 s; Merging...19651.571 s, 370522383290 nodes; Combining... 95773.568 s
Frame-group 232x/305x: 47506126016 nodes, 2911227132027 total; Expanding...28352.731 s; Merging...19957.681 s, 373213845832 nodes; Combining...106389.344 s
Frame-group 233x/305x: 47699219453 nodes, 2960047092418 total; Expanding...26396.811 s; Merging...20845.315 s, 375393960664 nodes; Combining...100003.163 s
Frame-group 234x/305x: 47963046580 nodes, 3008876706755 total; Expanding...25016.782 s; Merging...21320.666 s, 377731486844 nodes; Combining...103981.382 s
Frame-group 235x/305x: 48094124970 nodes, 3057823885568 total; Expanding...25360.762 s; Merging...22076.219 s, 379467845449 nodes; Combining...103014.976 s
Frame-group 236x/305x: 48308242664 nodes, 3106739110851 total; Expanding...25522.654 s; Merging...20757.575 s, 381368447890 nodes; Combining...103763.963 s
Frame-group 237x/305x: 48392274459 nodes, 3155713781271 total; Expanding...26276.838 s; Merging...21055.917 s, 382720220331 nodes; Combining...110597.198 s
Frame-group 238x/305x: 48541517020 nodes, 3204642156209 total; Expanding...26442.405 s; Merging...21552.046 s, 384123059746 nodes; Combining...105592.629 s
Frame-group 239x/305x: 48596814743 nodes, 3253563745206 total; Expanding...26892.190 s; Merging...20957.745 s, 385172146808 nodes; Combining...103404.805 s
Frame-group 240x/305x: 48670716470 nodes, 3302446340104 total; Expanding...26956.166 s; Merging...21478.326 s, 386051932581 nodes; Combining...105666.336 s
Frame-group 241x/305x: 48713115719 nodes, 3351254693883 total; Expanding...24946.363 s; Merging...21548.295 s, 386873608234 nodes; Combining...104067.269 s
Frame-group 242x/305x: 48712014444 nodes, 3400042071079 total; Expanding...24553.023 s; Merging...22380.096 s, 387266102696 nodes; Combining...103083.457 s
Frame-group 243x/305x: 48749469802 nodes, 3448697827703 total; Expanding...26520.192 s; Merging...22055.157 s, 387902504986 nodes; Combining...111803.647 s
Frame-group 244x/305x: 48683833342 nodes, 3497347104745 total; Expanding...24568.839 s; Merging...22050.942 s, 387898641728 nodes; Combining...106211.066 s
Frame-group 245x/305x: 48715232557 nodes, 3545823519184 total; Expanding...24290.441 s; Merging...21246.109 s, 388360612320 nodes; Combining...107536.535 s
Frame-group 246x/305x: 48606589077 nodes, 3594298254753 total; Expanding...24777.400 s; Merging...21639.689 s, 388088924994 nodes; Combining...108341.298 s
Frame-group 247x/305x: 48621182799 nodes, 3642577132536 total; Expanding...25078.195 s; Merging...21717.085 s, 388344963302 nodes; Combining...111428.303 s
Frame-group 248x/305x: 48494454064 nodes, 3690842861745 total; Expanding...25835.893 s; Merging...21943.279 s, 387941244141 nodes; Combining...110896.682 s
Frame-group 249x/305x: 48480275322 nodes, 3738907655109 total; Expanding...24254.549 s; Merging...21361.166 s, 387958438076 nodes; Combining...112003.553 s
Frame-group 250x/305x: 48358038098 nodes, 3786934211667 total; Expanding...24973.200 s; Merging...21536.912 s, 387530170280 nodes; Combining...113121.858 s
Frame-group 251x/305x: 48303164893 nodes, 3834766678865 total; Expanding...24429.512 s; Merging...22044.173 s, 387274861330 nodes; Combining...117508.681 s
Frame-group 252x/305x: 48199601152 nodes, 3882523554657 total; Expanding...24528.007 s; Merging...21382.044 s, 386882696396 nodes; Combining...119062.352 s
Frame-group 253x/305x: 48098928696 nodes, 3930097788704 total; Expanding...24420     s; Merging...21154.210 s, 386345791324 nodes; Combining...115564.546 s
Frame-group 254x/305x: 48015968536 nodes, 3977556662813 total; Expanding...25913.379 s; Merging...22555.312 s, 385987330645 nodes; Combining...119996.247 s
Frame-group 255x/305x: 47872460843 nodes, 4024840010025 total; Expanding...24656.815 s; Merging...24011.728 s, 385194579495 nodes; Combining...120803.157 s
Frame-group 256x/305x: 47800058782 nodes, 4071967383160 total; Expanding...24261.705 s; Merging...21287.348 s, 384805196006 nodes; Combining...122182.225 s
Frame-group 257x/305x: 47624572290 nodes, 4118917275774 total; Expanding...26187.549 s; Merging...21921.853 s, 383811902277 nodes; Combining...121034.596 s
Frame-group 258x/305x: 47545583463 nodes, 4165672178525 total; Expanding...23723     s
[Fri Feb 16 00:22:36 2024] Exit found (at frame 2582), tracing path...
[Fri Feb 16 11:08:53 2024] Found (at 2554)!
[Sat Feb 17 03:22:47 2024] Found (at 2518)!
[Sat Feb 17 03:22:48 2024] Found (at 2508)!
[Sat Feb 17 03:22:48 2024] Found (at 2498)!
[Sat Feb 17 03:22:48 2024] Found (at 2488)!
[Sun Feb 18 03:03:48 2024] Found (at 2433)!
[Sun Feb 18 14:40:30 2024] Found (at 2403)!
[Sun Feb 18 14:40:30 2024] Found (at 2393)!
[Sun Feb 18 14:40:30 2024] Found (at 2383)!
[Sun Feb 18 14:40:31 2024] Found (at 2373)!
[Sun Feb 18 14:40:31 2024] Found (at 2363)!
[Sun Feb 18 14:40:31 2024] Found (at 2353)!
[Sun Feb 18 14:40:31 2024] Found (at 2343)!
[Sun Feb 18 14:40:31 2024] Found (at 2333)!
[Sun Feb 18 14:40:31 2024] Found (at 2323)!
[Sun Feb 18 23:28:00 2024] Found (at 2295)!
[Mon Feb 19 13:15:34 2024] Found (at 2222)!
[Mon Feb 19 19:44:39 2024] Found (at 2183)!
[Mon Feb 19 21:18:56 2024] Found (at 2093)!
[Tue Feb 20 00:13:28 2024] Found (at 2074)!
[Tue Feb 20 02:19:00 2024] Found (at 2044)!
[Tue Feb 20 03:07:58 2024] Found (at 2034)!
[Tue Feb 20 03:55:35 2024] Found (at 2024)!
[Tue Feb 20 04:41:57 2024] Found (at 2014)!
[Tue Feb 20 05:27:03 2024] Found (at 2004)!
[Tue Feb 20 06:11:01 2024] Found (at 1994)!
[Tue Feb 20 06:53:49 2024] Found (at 1984)!
[Tue Feb 20 07:35:25 2024] Found (at 1974)!
[Tue Feb 20 08:16:01 2024] Found (at 1964)!
[Tue Feb 20 10:30:23 2024] Found (at 1945)!
[Tue Feb 20 11:09:11 2024] Found (at 1935)!
[Tue Feb 20 20:22:35 2024] Found (at 1862)!
[Tue Feb 20 20:53:17 2024] Found (at 1852)!
[Tue Feb 20 21:22:51 2024] Found (at 1842)!
[Wed Feb 21 06:24:39 2024] Found (at 1769)!
[Wed Feb 21 08:50:33 2024] Found (at 1733)!
[Wed Feb 21 10:11:14 2024] Found (at 1714)!
[Wed Feb 21 10:32:31 2024] Found (at 1704)!
[Wed Feb 21 14:15:59 2024] Found (at 1658)!
[Wed Feb 21 14:32:07 2024] Found (at 1648)!
[Wed Feb 21 14:47:29 2024] Found (at 1638)!
[Wed Feb 21 16:27:41 2024] Found (at 1601)!
[Wed Feb 21 18:00:49 2024] Found (at 1573)!
[Wed Feb 21 18:48:54 2024] Found (at 1552)!
[Wed Feb 21 18:58:45 2024] Found (at 1540)!
[Wed Feb 21 19:08:09 2024] Found (at 1530)!
[Wed Feb 21 19:17:04 2024] Found (at 1520)!
[Wed Feb 21 19:25:33 2024] Found (at 1510)!
[Wed Feb 21 19:33:37 2024] Found (at 1500)!
[Wed Feb 21 19:41:18 2024] Found (at 1490)!
[Wed Feb 21 19:48:34 2024] Found (at 1480)!
[Wed Feb 21 19:55:28 2024] Found (at 1470)!
[Wed Feb 21 20:02:02 2024] Found (at 1460)!
[Wed Feb 21 20:08:15 2024] Found (at 1450)!
[Wed Feb 21 20:14:08 2024] Found (at 1440)!
[Wed Feb 21 21:06:43 2024] Found (at 1412)!
[Wed Feb 21 21:11:26 2024] Found (at 1402)!
[Wed Feb 21 21:15:52 2024] Found (at 1392)!
[Wed Feb 21 21:20:04 2024] Found (at 1382)!
[Wed Feb 21 23:20:44 2024] Found (at 1309)!
[Wed Feb 21 23:36:06 2024] Found (at 1281)!
[Wed Feb 21 23:49:49 2024] Found (at 1269)!
[Thu Feb 22 01:05:15 2024] Found (at 1169)!
[Thu Feb 22 01:28:42 2024] Found (at 1105)!
[Thu Feb 22 01:35:15 2024] Found (at 1077)!
[Thu Feb 22 01:37:59 2024] Found (at 1056)!
[Thu Feb 22 01:42:39 2024] Found (at 1020)!
[Thu Feb 22 01:43:18 2024] Found (at 1010)!
[Thu Feb 22 01:43:54 2024] Found (at 1000)!
[Thu Feb 22 01:44:25 2024] Found (at 990)!
[Thu Feb 22 01:44:53 2024] Found (at 980)!
[Thu Feb 22 01:45:18 2024] Found (at 970)!
[Thu Feb 22 01:47:17 2024] Found (at 949)!
[Thu Feb 22 01:50:01 2024] Found (at 885)!
[Thu Feb 22 01:50:08 2024] Found (at 875)!
[Thu Feb 22 01:50:44 2024] Found (at 847)!
[Thu Feb 22 01:51:18 2024] Found (at 801)!
[Thu Feb 22 01:51:33 2024] Found (at 771)!
[Thu Feb 22 01:51:57 2024] Found (at 698)!
[Thu Feb 22 01:52:00 2024] Found (at 668)!
[Thu Feb 22 01:52:03 2024] Found (at 632)!
[Thu Feb 22 01:52:05 2024] Found (at 604)!
[Thu Feb 22 01:52:05 2024] Found (at 592)!
[Thu Feb 22 01:52:06 2024] Found (at 571)!
[Thu Feb 22 01:52:07 2024] Found (at 543)!
[Thu Feb 22 01:52:07 2024] Found (at 513)!
[Thu Feb 22 01:52:07 2024] Found (at 503)!
[Thu Feb 22 01:52:08 2024] Found (at 376)!
[Thu Feb 22 01:52:08 2024] Found (at 340)!
[Thu Feb 22 01:52:08 2024] Found (at 330)!
[Thu Feb 22 01:52:08 2024] Found (at 320)!
[Thu Feb 22 01:52:08 2024] Found (at 292)!
[Thu Feb 22 01:52:09 2024] Found (at 256)!
[Thu Feb 22 01:52:09 2024] Found (at 228)!
[Thu Feb 22 01:52:09 2024] Found (at 198)!
[Thu Feb 22 01:52:09 2024] Found (at 188)!
[Thu Feb 22 01:52:09 2024] Found (at 115)!
[Thu Feb 22 01:52:09 2024] Found (at 105)!
[Thu Feb 22 01:52:09 2024] Found (at 95)!
[Thu Feb 22 01:52:09 2024] Found (at 31)!
[Thu Feb 22 01:52:09 2024] Found (at 12)!
[Thu Feb 22 01:52:09 2024] Found (at 0)!
nymx: Claiming for judging.
nymx: Exquisite work! The effort that you put into this is something to be proud of. I love puzzle games, and this one was a treat to watch. I examined your run, against the WR, and you clearly show lots of strength. Great job!
Accepting!
Note to Publisher: I made an attempt to correct the cycle count, but I never saw the results from it. It could already be fine. Don't know though.
despoa: Processing...
nymx: Uploading improvement movie.
nymx: Replacing once again with a version provided by despoa.

Show more

Hide
1 2
Posted: 2/22/2024 8:34 PM
Quote
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15577
Location: 127.0.0.1
This topic is for the purpose of discussing #8905: Nitrodon, ZenicReverie, CyberShadow, Sand, Alyosha & Deadcode's GB Kwirk "Going Up?" in 15:15.89
Posted: 2/22/2024 9:45 PM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
This is amazing work! That 3-6 was very surprising, I never would have thought that shoving that 3x1 all the way to the right could have been part of the solution. 3-7 also looks super smooth now, really cool. The other small improvements were also neat though I'm a little disappointed in myself for not finding that 2-8 or 3-1 route. I always like seeing big projects like this come to fruition, even if some of the levels are still out of reach. Great work!
Posted: 2/23/2024 2:50 AM
Quote
Sand
He/Him
Player (143)
Joined: 6/26/2018
Posts: 175
This is absolutely amazing! Brilliant work. Coincidentally I started working on a Kwirk solver about a month ago, not being aware of the ongoing DDD work. This is way beyond what I was able to do. I was only able to find solutions for 19 of the 30 levels. (The easy ones: most of those can be solved in 10 seconds or less using just RAM as storage.) The only improvement I had found over [4105] GB Kwirk "Going Up?" by Nitrodon, ZenicReverie & Alyosha in 15:46.03 was 100 steps in 3-1, same as this submission. I didn't get as far as starting to TAS the levels in an emulator, but I can confirm that your frame/step counts match my predicted ones for the levels I was able to solve: 1-1, 1-2, 1-3, 1-4, 1-5, 1-6, 1-7, 1-8, 1-9, 1-10, 2-1, 2-3, 2-4, 2-5, 2-10, 3-1, 3-2, 3-3, 3-5. I see DDD-Kwirk takes into account that in multi-player levels, a "Switch" move immediately after another "Switch" is 2 frames slower. I think you can save 2 frames in 2-9 by reordering moves to break up an instance of consecutive "Switch" moves. Starting at frame 24745, the sequence goes: 
(playing Pete) Left Down Up (Switch to Kwirk) (Switch to Eddie) Right Right Up Up (Switch to Pete) Left Left Down Left Left Down (Switch to Kwirk) Up Up
You can move one of Kwirk's later "Up" moves to be in between the first two "Switch"es, without interfering with the rest of the sequence: 
(playing Pete) Left Down Up (Switch to Kwirk) Up (Switch to Eddie) Right Right Up Up (Switch to Pete) Left Left Down Left Left Down (Switch to Kwirk) Up
The only other level where this could matter (levels with 3 or 4 players) is 3-8, and it looks like that one is already free of consecutive "Switch".
Posted: 2/23/2024 7:18 AM
(Edited: 2/23/2024 10:40 AM)
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
Alyosha wrote:
This is amazing work! That 3-6 was very surprising, I never would have thought that shoving that 3x1 all the way to the right could have been part of the solution. 3-7 also looks super smooth now, really cool. The other small improvements were also neat though I'm a little disappointed in myself for not finding that 2-8 or 3-1 route. I always like seeing big projects like this come to fruition, even if some of the levels are still out of reach. Great work!
Thanks very much, and thanks for your previous work on Kwirk! I too thought the end position of that 3x1 was strange, and was watching the solution backtrace closely until it went far enough back for me to see why it did that. Was pretty cool once it became clear.
Sand wrote:
This is absolutely amazing! Brilliant work. Coincidentally I started working on a Kwirk solver about a month ago, not being aware of the ongoing DDD work. This is way beyond what I was able to do. I was only able to find solutions for 19 of the 30 levels. (The easy ones: most of those can be solved in 10 seconds or less using just RAM as storage.) The only improvement I had found over [4105] GB Kwirk "Going Up?" by Nitrodon, ZenicReverie & Alyosha in 15:46.03 was 100 steps in 3-1, same as this submission. I didn't get as far as starting to TAS the levels in an emulator, but I can confirm that your frame/step counts match my predicted ones for the levels I was able to solve: 1-1, 1-2, 1-3, 1-4, 1-5, 1-6, 1-7, 1-8, 1-9, 1-10, 2-1, 2-3, 2-4, 2-5, 2-10, 3-1, 3-2, 3-3, 3-5.
Thanks very much! And quite cool that you were working on a solver of your own, even if it's perhaps not as powerful. Your set of 19 optimized levels is exactly the same set that CyberShadow optimized before I joined the project.
Sand wrote:
I see DDD-Kwirk takes into account that in multi-player levels, a "Switch" move immediately after another "Switch" is 2 frames slower. I think you can save 2 frames in 2-9 by reordering moves to break up an instance of consecutive "Switch" moves. Starting at frame 24745, the sequence goes: 
(playing Pete) Left Down Up (Switch to Kwirk) (Switch to Eddie) Right Right Up Up (Switch to Pete) Left Left Down Left Left Down (Switch to Kwirk) Up Up
You can move one of Kwirk's later "Up" moves to be in between the first two "Switch"es, without interfering with the rest of the sequence: 
(playing Pete) Left Down Up (Switch to Kwirk) Up (Switch to Eddie) Right Right Up Up (Switch to Pete) Left Left Down Left Left Down (Switch to Kwirk) Up
The only other level where this could matter (levels with 3 or 4 players) is 3-8, and it looks like that one is already free of consecutive "Switch".
Very nice! I confirmed that this works and saves 2 frames in both DDD-Kwirk and BizHawk. I'll be updating the movies and adding credit for you. [Edit: It is done.]
Posted: 2/23/2024 1:08 PM
Quote
GJTASer2018
He/Him
Joined: 1/24/2018
Posts: 303
Location: Stafford, NY
The remaining levels not solved by DDD are 2-9, 3-4, 3-8, 3-9, and 3-10. For these it may be impossible to do so (at least without a supercomputing cluster), due to exploding exponential complexity (and in the case of 2-9 and 3-8, there are 3 or 4 player characters, making it even worse).
It might be worth asking the good people over at BOINC to see if this could be turned into a distributed computing project in some way. This way you won't have to wait (or rent supercomputer time out of your own pocket) to tackle these levels. :)
c-square wrote:
Yes, standard runs are needed and very appreciated here too
Dylon Stejakoski wrote:
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
^ Why I don't have any submissions despite being on the forums for years now...
Posted: 2/23/2024 1:14 PM
(Edited: 2/23/2024 1:15 PM)
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
GJTASer2018 wrote:
It might be worth asking the good people over at BOINC to see if this could be turned into a distributed computing project in some way. This way you won't have to wait (or rent supercomputer time out of your own pocket) to tackle these levels. :)
I don't think DDD would be particularly conducive to that, because all the threads have to communicate what they have found so it can be sorted and deduplicated. But that's tens of terabytes of data (or more) every day at the later stages of a complicated level, not particularly practical to send over the Internet ;-)
Posted: 2/23/2024 10:34 PM
(Edited: 2/23/2024 10:41 PM)
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
https://tasvideos.org/UserFiles/Info/638443243569823355 I'm not sure what happened, but it seems like all the moves in the last 2 levels are taking too long to move after a block has been placed. Here is a partial improvement of those levels. I didn't check earlier levels, or checked if they had always been that way in previous movies. EDIT: Looks like this happens in the earlier levels as well, even in the Gambatte movie, perhaps a bug in the script?
Posted: 2/23/2024 11:15 PM
(Edited: 2/24/2024 12:20 AM)
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
Alyosha wrote:
EDIT: Looks like this happens in the earlier levels as well, even in the Gambatte movie, perhaps a bug in the script?
Oh dear. Looks like an error in DDD-Kwirk's model of the game's logic. It had a fill taking 26 frames, but it actually takes 18 frames (so a push+fill takes 10+18=28 frames). Thanks for pointing this out. If you have more edits to demonstrate, could you please use the Gambatte version? I get 2000 fps with it, and only 200 fps with GBHawk, so takes a long time to fast forward. So anyway, yeah, this means I'm going to have to re-solve all the levels that involve filling holes. Wow.
Posted: 2/24/2024 12:27 AM
Quote
Sand
He/Him
Player (143)
Joined: 6/26/2018
Posts: 175
Deadcode wrote:
It assumes that a push-fill always takes 10 frames to push and 26 frames to fill. But with your demonstration, it appears that sometimes it only takes 28 frames total.
That explains something for me. When I posted the comparison in Post #527971, at first not all my frame count predictions matched the ones in this submission. Some of mine were faster in multiples of 8: e.g., 8 frames faster, 56 frames faster, 16 frames faster. I deduced that the mismatches were in levels in which blocks were pushed into holes, and the reason was that in my solver, I had coded the cost of pushing a block into a hole as a flat 28 frames. After I edited my program to make pushing blocks into holes cost 10+26 frames, all my frame count predictions matched up, so I assumed I had just made a careless mistake when first measuring the cost myself. (I also found Post #215759 which corroborated 10+26.) But now I suppose that I really had correctly measured 28 frames when I tested it myself the first time. Unfortunately I don't have movie files, but if I had to guess, I probably would have been testing frame timings with the 2×3 in 1-4 or the 1×1 in 1-5.
Posted: 2/24/2024 12:34 AM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
Deadcode wrote:
So anyway, yeah, this means I'm going to have to re-solve all the levels that involve filling holes. Wow.
Why do they need to be resolved? Isn't just going back and removing the extra frames at each hole fill sufficient? The original reason I stumbled upon this is that I wanted to look at 3-9 again (but my idea didn't pan out.) But yeah if I have anything else I'll use gambatte version for convenience.
Posted: 2/24/2024 12:50 AM
(Edited: 2/24/2024 1:41 AM)
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
Alyosha wrote:
Why do they need to be resolved? Isn't just going back and removing the extra frames at each hole fill sufficient?
Well, probably most of them will end up being the same, but perhaps some solutions can be faster now by filling in extra holes.
Deadcode wrote:
Oh dear. Looks like an error in DDD-Kwirk's model of the game's logic. It had a fill taking 26 frames, but it actually takes 18 frames (so a push+fill takes 10+18=28 frames).
Actually... it looks like 10+26 was correct for Diagonal View, and that it's 10+18 in Bird's-eye View only! So Bird's-eye View doesn't just save 1.408 seconds, it saves 14.384 seconds! (Or maybe more if some levels can be faster by filling in more holes.)
Sand wrote:
But now I suppose that I really had correctly measured 28 frames when I tested it myself the first time. Unfortunately I don't have movie files, but if I had to guess, I probably would have been testing frame timings with the 2×3 in 1-4 or the 1×1 in 1-5.
So does that mean you were doing your test runs in Bird's-eye View even though I hadn't submitted my TAS yet?
Posted: 2/24/2024 2:55 PM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
https://tasvideos.org/UserFiles/Info/638443831255464202 I saved 2 steps in 3-9 with better use of the 'T' shaped block in the first half of the level.
Posted: 2/24/2024 6:57 PM
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
Alyosha wrote:
https://tasvideos.org/UserFiles/Info/638443831255464202 I saved 2 steps in 3-9 with better use of the 'T' shaped block in the first half of the level.
Nicely done! This saves 18 frames. I will incorporate it into this submission, and move your name forward in the credits. How are you writing the replay in the same clean export format as I've been using, which only holds the joypad button for 1 frame exactly when it's needed? In your 2018 and 2020 TASes, the joypad inputs were held down in the way that would be done when actually playing the game in an emulator.
Posted: 2/24/2024 7:51 PM
Quote
Sand
He/Him
Player (143)
Joined: 6/26/2018
Posts: 175
Deadcode wrote:
Sand wrote:
But now I suppose that I really had correctly measured 28 frames when I tested it myself the first time. Unfortunately I don't have movie files, but if I had to guess, I probably would have been testing frame timings with the 2×3 in 1-4 or the 1×1 in 1-5.
So does that mean you were doing your test runs in Bird's-eye View even though I hadn't submitted my TAS yet?
Correct, I was using bird's-eye. Besides finding bird's-eye easier to read, I found a post at speedrun.com that says "you want to make sure that you use bird eye as view mode, this mode alows you to move faster after a cutscene." I should mention that I tested the timing of a couple of level transitions in diagonal and bird's-eye, and I didn't find a difference. I'm not sure what I was doing wrong/differently. I may have only timed the flashing "exit" animation and the stripes "enter" animation; does the lag happen in the "You did it!" screen? I regret not saving the recordings, but anyway here are excerpts from my notes: 
Birds-eye level transition
10295 -> 10296 -> 10518 223
11370 -> 11593
11907 -> 12129 222
16094 -> 16316 222
16550 -> 16774 224
17041 -> 17265 224
17731 -> 17955 224

Diagonal timings
1-1 in	1146 -> 1317	171
1-1 out	1527 -> 1725	198
1-2 in	1781 -> 1952	171
1-2 out	2118 -> 2316	198
intra-level frame count is as predicted, for 1-1 and 1-2 at least

Birds-eye timings
1-1 in	1180 -> 1351	171
1-1 out	1561 -> 1759	198
1-2 in	1814 -> 1985	171
1-2 out	2151 -> 2349	198
intra-level frame count is as predicted, for 1-1 and 1-2 at least
Posted: 2/24/2024 8:13 PM
(Edited: 2/25/2024 12:25 AM)
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
Sand wrote:
Deadcode wrote:
So does that mean you were doing your test runs in Bird's-eye View even though I hadn't submitted my TAS yet?
Correct, I was using bird's-eye. Besides finding bird's-eye easier to read, I found a post at speedrun.com that says "you want to make sure that you use bird eye as view mode, this mode alows you to move faster after a cutscene."
Oh, interesting. So it seems the speedrunning community had rediscovered this independently in 2017 (since I had not posted about my 2013 finding until this submission), but the TAS community was unaware of it until my submission. It's pretty silly that that speedrun.com page links a Diagonal View TAS, and yet apparently nobody there bothered to tell TAS'ers about the Bird's-eye View speedup, as it still wasn't being used in the 2018 and 2020 TASes. It also appears that the speedrunners were unaware of the push-fill speedup, as that page only mentions a cutscene speedup.
Sand wrote:
I should mention that I tested the timing of a couple of level transitions in diagonal and bird's-eye, and I didn't find a difference. I'm not sure what I was doing wrong/differently. I may have only timed the flashing "exit" animation and the stripes "enter" animation; does the lag happen in the "You did it!" screen?
Look at the instances of BIRDS_EYE_VIEW in DDD-Kwirk/Kwirk_bk2_export.cpp (or here). Its effect depends on the level.
Posted: 2/24/2024 8:31 PM
(Edited: 2/24/2024 8:32 PM)
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
https://tasvideos.org/UserFiles/Info/638444031574122837 2 steps saved in 3-10, couldn't find anything new in the other non-optimal levels, but that was a fun revisit.
Deadcode wrote:
How are you writing the replay in the same clean export format as I've been using, which only holds the joypad button for 1 frame exactly when it's needed?
I just use TAStudio.
Posted: 2/24/2024 9:22 PM
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
Alyosha wrote:
https://tasvideos.org/UserFiles/Info/638444031574122837 2 steps saved in 3-10, couldn't find anything new in the other non-optimal levels, but that was a fun revisit.
Awesome, thank you! This too saves 18 frames.
Posted: 2/25/2024 6:31 PM
(Edited: 2/26/2024 1:28 AM)
Post subject: Replay file updated
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
These post-submission improvements have all been incorporated into this BizHawk 2.9.1 (Gambatte core) replay file, along with fully optimizing its UI delays. This is now meant to be the primary file associated with this submission, so please ignore the "15:27.21" one and use this 15:13.34 one instead when judging the submission. Edit: Now fully optimized for real (with some help from TAStudio), bringing it down to 15:12.62: This replay file.
Posted: 2/25/2024 7:20 PM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
Deadcode wrote:
These post-submission improvements have all been incorporated into this BizHawk 2.9.1 (Gambatte core) replay file, along with fully optimizing its UI delays. This is now meant to be the primary file associated with this submission, so please ignore the "15:27.21" one and use this 15:13.34 one instead when judging the submission.
Seems like there are still some script issues. The very first start input can be pressed 10 frames sooner. Also a lot of levels are 2 frames late on the first move, with some even being 4 frames late.
Posted: 2/25/2024 8:49 PM
(Edited: 2/25/2024 9:49 PM)
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
Alyosha wrote:
Deadcode wrote:
These post-submission improvements have all been incorporated into this BizHawk 2.9.1 (Gambatte core) replay file, along with fully optimizing its UI delays. This is now meant to be the primary file associated with this submission, so please ignore the "15:27.21" one and use this 15:13.34 one instead when judging the submission.
Seems like there are still some script issues. The very first start input can be pressed 10 frames sooner. Also a lot of levels are 2 frames late on the first move, with some even being 4 frames late.
Well, that first-start thing is confusing. I couldn't press start 1 frame earlier, so I assumed I had it as early as possible. Apparently it doesn't poll for that start every frame. What's even worse is that if Start is already being held on that frame, it doesn't work. It has to be pressed from a released state. So a binary search doesn't work to find the optimal frame. How am I supposed to find this? Individually trying every single frame within a range? (I tried that now, and it confirmed your finding of 10 frames, but it's pretty tedious.) And absolutely none of the levels were any frames late; I confirmed that (not only for the first moves of levels, but for all 95 instances of UI delay). Now, if you were testing that in a version of the replay where you already removed 10 frames before the first start, that would likely throw everything off, so I'm guessing that's what you did. Which is rather upsetting, because it took me a lot of time to do that, and now it's apparently wasted, because it was all based on starting the game 10 frames later than optimal. Edit: You seem to have sent me on a wild goose chase, Alyosha. I went through all the delays in the first set of 10 floors, and not a single one could be reduced by 1 frame. Are there parts of the UI beyond the first-start-press that also don't poll every frame? Could you please provide actual exact examples of what you found, or a replay file demonstrating it, instead of the vague information you gave above?
Posted: 2/25/2024 9:59 PM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
TAStudio is really helpful for cases like this since you can (generally) see where input is accepted. Here is the first start press in your movie, you can see one green input frame 10 frames earlier: Here is the first move in level 1-2, you can see the 'left' button is pressed on the fourth (green) input frame but input is accepted on the second:
Posted: 2/25/2024 10:10 PM
(Edited: 2/25/2024 10:42 PM)
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
Alyosha wrote:
TAStudio is really helpful for cases like this since you can (generally) see where input is accepted.
Okay, that's neat in principle, but in practice, it's just plain wrong. According to its graph when I tried it just now, level 1-1's input can start 1 frame earlier, but if I edit the replay file to do that, it doesn't work. Did you try applying any its hints besides the one about first-start being 10 frames earlier? Edit: It appears that there is a grain of truth in what it shows, but it's distorted. It showed me level 2-1's movement could be started up to 5 frames earlier, and that didn't work (and neither did 1 frame earlier, or 3), but 4 frames earlier did work, and so did 2 frames earlier. So the accurate display would show the gaps for what wouldn't actually work, but TAStudio misleadingly shows a continguous list of 5 frames. Still, it can at least provide a hint at what to try. Also, it's annoying that it doesn't show the "comments" that I put in my replay file, e.g.: 
|....S....| Level 1-5
And I made it display some other comments as well, to help with finding delays to reduce. TAStudio doesn't show these.
Posted: 2/25/2024 11:04 PM
(Edited: 2/27/2024 9:43 AM)
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
Alyosha wrote:
Here is the first move in level 1-2, you can see the 'left' button is pressed on the fourth (green) input frame but input is accepted on the second:
Wait, what? How are you interpreting that graph in that way? It shows 4 frames in a row that are all the same color, against a gray* background. Can you actually tell just by looking at it that it accepts input on the 2nd? Why not the 1st? *I guess it's grayish cyan, using a color-picker, but to my protanomalously colorblind eyes it looks gray. That's not the problem though, as all 4 frames in a row from 1313 to 1316 are the same green (I had to check, to make sure there wasn't just some color difference I wasn't seeing)
Posted: 2/25/2024 11:25 PM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
Deadcode wrote:
Wait, what? How are you interpreting that graph in that way? It shows 4 frames in a row that are all the same color, against a gray* background. Can you actually tell just by looking at it that it accepts input on the 2nd? Why not the 1st? *I guess it's grayish cyan, using a color-picker, but to my protanomalously colorblind eyes it looks gray. That's not the problem though, as all 4 frames in a row from 1313 to 1316 are the same green (I had to check, to make sure there wasn't just some color difference I wasn't seeing)
All the later moves also accept input on the second green frame and not the first, so I guessed it was the same for the first move. It's just something you get a feel for with experience.
Posted: 2/26/2024 1:42 AM
(Edited: 3/6/2024 10:01 PM)
Quote
Deadcode
He/Him
Player (6)
Joined: 7/27/2016
Posts: 15
Saved another 0.72 seconds (primary-submitted replay file for this submission) using the information TAStudio provided, and that truly appears to be the best possible with this set of solutions. (But I still find it a bit of an inconvenient way to do this; a log file would be much better. And then at first I thought, after seeing what TAStudio could do, that it explained how you did this:
Alyosha wrote:
https://tasvideos.org/UserFiles/Info/638443243569823355 I'm not sure what happened, but it seems like all the moves in the last 2 levels are taking too long to move after a block has been placed. Here is a partial improvement of those levels.
But it appears that TAStudio loses the ability to do that magic when the GBHawk core is in use, and the replay file you posted was based on the GBHawk one. So how did you do that? Edit: I've added lag-frame detection to my replay frame logging script. It works even with the GBHawk core, unlike TAStudio: 
  1278:   
  1279:   
  1280:   
  1281:   
  1282:   
  1283:   
  1284:   
  1285:   
  1286:   
  1287:   
  1288:   
  1289: ! 
  1290: ! 
  1291: ! 
  1292: ! P1 Left
  1293:   
  1294:   
  1295:   
  1296:   
  1297:   
  1298:   
  1299:   
  1300: ! 
  1301: ! P1 Left
  1302:   
  1303:   
  1304:   
  1305:   
  1306:   
  1307:   
  1308:   
  1309: ! 
  1310: ! P1 Left
  1311:   
  1312:   
  1313:   
  1314:   
  1315:   
  1316:   
  1317:   
  1318: ! 
  1319: ! P1 Left
  1320:
And then I can just use the regex (! \R[^!\r\n]+){2}! \w to find instances of too-late input. Edit: Or (\] \R[^\]\r\n]+){2}\] \w on the latest version of the script (still linked above) which shows when the input was read in fractions of a frame relative to the current frame.
1 2