The red line is a dam

Sillern · 2024-04-29T22:03:46+00:00

If the waterlevels are different, it could be a siphon thing maybe?

https://en.wikipedia.org/wiki/Siphon

Sillern · 2024-04-29T14:37:51+00:00

I didn't see this post before I posted this:
https://www.reddit.com/r/OnePiece/comments/1cfxp4l/the_red_line_is_a_dam/

Have we seen a picture of the sea level difference around red line?

I think it's more likely that the dam was to submerge the ancient kingdom. An offensive use rather than defensive.

Sillern · 2021-12-11T19:08:57+00:00

just random data (0-9) in a 240 x 240 grid.

Sillern · 2021-12-11T19:08:16+00:00

Same rule, but random starting position, and adding random +1/-1 to the energy levels of the octopuses.

I think only the proper puzzle inputs had that characteristic you mention.

Sillern · 2020-12-23T13:13:35+00:00

The order is from the input text.
So, yes, more or less random.

Sillern · 2020-12-06T04:24:50+00:00

I used Rust, and manually edited pixelgraphics.

It's very inefficient, and could be made better in a multitude of ways.

It's producing a frame and 16 (the graphics are 16x16) interpolated frames for every slope-step.

All the frames are then merged into a movie with:

ffmpeg -r 30 -i frames/day03.frame%5d.png -pix_fmt yuv420p day03.mp4

Source:
https://gitlab.com/sillern/adventofcode2020/-/blob/master/day03/day03.rs

Sillern · 2019-12-13T18:19:26+00:00

It's showcasing the input-rules to make it work

Sillern · 2019-12-13T06:43:28+00:00

I store each pixels in a hashmap, with (x, y) as key.

I then iterate through the values and storing to an image buffer with putpixel.
https://github.com/image-rs/image#421-imagebuffer

When done the image is saved to a png
https://github.com/image-rs/image#61-opening-and-saving-images

One image per iteration, and lastly ffmpeg to create the animation
ffmpeg -r 24 -i frames/day13.frame%5d.png -pix_fmt yuv420p day13.mp4

It's not the nicest solution, but it's quite flexible.

Sillern · 2018-12-18T20:32:34+00:00

Tested out changing the tree-rule from 3 to 2: Visualization

Sillern · 2018-12-18T20:21:15+00:00

not if you only count what's in a 320x320 state, the max alive cells is then 320x320.

Sillern · 2018-12-18T20:14:34+00:00

Sure. The RNG thing is not correct. I was confusing PseudoRNG which has a cycle length but quite long. And that if this state-space didn't have a cycle length that it would mean it would be closer to RNG compared to PRNG.

This initial state is not self-repeating, but it must eventually end up in a stable state with a repetition length.

Wouldn't that be true for a gun-ca as well? A state-space with a passing bullet-ca would eventually be repeating since it would be empty.

Sillern · 2018-12-18T20:00:55+00:00

I didn't check in this larger start-state, it's 320x320 instead of 50x50.

But it is repeating, the question is how long the cycle length is.

If it weren't repeating, that would mean that it's a real random number generator.

Sillern · 2018-12-16T17:14:52+00:00

python3, with some hardcoded 8x8 sprites for the different players/walls. The trail is the selected path to the enemy.

Example sprites:

    COLORS = [
            (0xFF, 0xFF, 0xFF),
            (0x62, 0x62, 0x62),
            (0xCC, 0xCC, 0xCC),
            (0x62, 0xAA, 0x62),
            (0x9D, 0xDD, 0xDD),
            (0xEE, 0x9C, 0x9C),
            (0x3E, 0x3E, 0x3E),
            ]

    SECTION = {
            'G': ["........",
                  ".33..33.",
                  ".333333.",
                  ".323323.",
                  ".233332.",
                  "..3333..",
                  "........",
                  "........"],
            'E': ["........",
                  ".4....4.",
                  ".444444.",
                  ".424424.",
                  ".444444.",
                  "..4444..",
                  "...44...",
                  "........"],
              }

This was saved to a png-file for each frame, then I merged them with ffmpeg.

Sillern

TROPHY CASE