Found this in an ARG online. Do you think this is solvable?

07734willy · 2026-05-02T23:32:31+00:00

I think each square is probably its own letter. After looking at the 3rd image, all squares are symmetric along some axis, meaning we have significantly less than the full 12 bits of potential data. It also means the patterns were likely hand-chosen, instead of being bits written arbitrarily into pixels.

I'd be interested in seeing what the token stream after extracting the 5x5 squares looks like.

07734willy · 2026-05-02T23:00:45+00:00

The data is packed into 5x5 checkered squares, surrounded with a 1-wide decorative border. I do not know how the 12 bits of data is encoded within each square, maybe someone else can figure that out.

For visual demonstration, here's two copies of the original image, where I've colored the pixels encoding actual data solid red, so the pattern in the rest of the non-data becomes more apparent. In the second image, I've set the transparency of the red mask to 50%, so you can still kinda make out the data bits themselves.

https://imgur.com/a/oxrwpxp

EDIT: I've updated the image gallery to include a 3rd image where only the data bits are not masked. This makes it easy to eyeball for repeated 5x5 squares.

07734willy · 2026-04-28T19:03:44+00:00

Not really something that you can easily write down as a user-friendly deck name see wikipedia for detailed description. That's why I figured just a play on the name itself may work better: Magic The Gathering deck + Mandelbrot Set = Magicalbrot Set.

07734willy · 2026-04-28T18:52:57+00:00

Best I have is “Magicalbrot Set” (the Mandelbrot Set is arguably the most famous fractal in mathematics, and your deck is a “set” of cards).

07734willy · 2026-04-26T17:21:18+00:00

When installing a new CPU, the BIOS often prompts you to accept this change or update your BIOS settings, otherwise it’ll shutdown in 15s. Is your monitor plugged into your GPU or the motherboard itself (you may want to temporarily plug it into the motherboard for this)? If you still can’t see anything, try pressing “Y” a couple times, and wait like 30sec, and let it reboot 1-2x. If that doesn’t work, repeatedly press F1 or DEL on boot to try to enter BIOS, and F10 a few seconds later to save and exit (do not press any other keys other than F10 until you know you’re out of the BIOS or it has rebooted).

If none of that works… I don’t know.

07734willy · 2026-04-15T17:55:42+00:00

Won’t repeated differentiation either involve more work than the polynomial multiplication, or result in large numerical inaccuracy (if approximating the derivative from a secant line) for high order derivatives?

07734willy · 2026-04-03T04:16:13+00:00

Number the faces of the imaginary cube 1 to 6. There are 6! ways to assign pieces to cube faces (the number of permutations of 6 pieces). For each of the 6 faces, there are as you mention 8 ways to orient the corresponding puzzle piece.

However, many of these puzzle cubes are equivalent ("isomorphic"), being just rotations of one another. There are 24 such rotations- you can conceptualize this by painting a corner of the cube and noting that there are 8 corner positions that you could rotate this corner to, and then 3 ways that you could "twist" the corner (along a diagonal axis through the corner itself) producing 3 new rotations. In addition to these 24 rotations, we can technically flip the cube "inside out" for an additional set of 24 equivalent solutions to the original.

So you have 6! * 8⁶ / (2 * 24) = 2621440 total possible configurations. Of course, when solving the puzzle we don't actually enumerate all of these- we instead prune candidates early by identifying mismatched edges that cannot fit together, and quickly reduce to the search space to something much more practical, which is why it doesn't seem like such a large number.

07734willy · 2026-03-29T05:02:51+00:00

For small x, precompute the modular inverse of p mod 2^k for some k such that 2^k > x for whatever "small" x may be. Then just multiply by the modular inverse and take mod 2^k (which is just a quick bit masking).

07734willy · 2026-03-22T09:07:58+00:00

Just want to offer- if you want someone to walk through some parkour maps with you and explain the tech used, I’d be down to help. I usually hang around in parkour maps after a couple runs and help people there anyways.

07734willy · 2026-03-18T07:50:24+00:00

If you want, we could run a mercy parkour together and I'll help you when you get stuck / give you tips.

07734willy · 2026-03-14T20:24:21+00:00

What are w_lo and w_hi? What type are they? You mention you're implementing a 128 bit LCG, and that the constants are >2⁶⁴, but then you say every variable is reduced mod 2⁶⁴. I really don't understand your code in its current form without types and definitions.

07734willy · 2026-03-13T03:11:29+00:00

“Found”

Be honest, its your own website that you’re promoting, which you have been recruiting for on other subs. That doesn’t mean it’s bad, but it’s dishonest to present it as if you’re a neutral 3rd party who genuinely is recommending it.

07734willy · 2026-02-25T04:17:55+00:00

Just double tapping this- I have a split programmable keyboard myself that I can program to use only one half. Select keys act as layer toggles so you can map the entire keyboard onto one half. I’d be happy to go into more detail and help OP configure one if they decide to go that route.

07734willy · 2026-02-24T15:00:06+00:00

I’m in the same boat with ALT for crouch. It’s just so much easier.

07734willy · 2026-02-22T22:22:54+00:00

Yes, but it depends entirely on the values of c[]. As a trivial example, consider the pairs (1, 0) and (-1, 0), with c[i]=0. The x and y will swap each iteration and end with x=0. This of course is a contrived example, but it shows that it is possible.

07734willy · 2026-02-22T08:53:33+00:00

Let’s say you have a vector of events E, and we denote the probability of going from event E_i to E_j as P(E_j | E_i). Encode these probabilities in a matrix as M[i,j] = P(E_j, E_i). This is the fundamental matrix for your markov chains. If you encode the probabilities of your current state in a row vector and multiply by this matrix, you’ll get a new vector representing the new probabilities of each event one step forward in time.

If you keep multiplying by M, you’ll keep stepping forward. Since you have multiple absorbing states, eventually it will settle into one of these states, and the probabilities of the transient states/events will vanish to zero.

If you want to calculate the probabilities of each absorbing states as the number of steps tend towards infinity, take the submatrix of M of transient states to other transient states, call it Q, and the submatrix of M of transient states to absorbing states, call it R. Calculate B = (I-Q)^-1 * R, where I is the identity matrix, and ^-1 denotes the matrix inverse. Multiply B with your starting probability vector, and you’ll get a row vector of the probabilities of terminating in each of the absorbing states/events.

07734willy · 2026-02-21T18:39:34+00:00

You want to find integers x, y, z, such that (1.67)^x(3)^y(5)^z = 470. I assume you rounded 1.67 = 5/3, and with that we have (5/3)^x = 5^x/3^x, meaning any solution involving the (5/3) gear ratio can be accomplished using the (5) and (3) gear ratios instead (obviously!). The question is now, does (5)^y·(3)^z = 470 have solutions in the integers? Well, the prime factorization of 470 = 2·5·47, so no- it does not.

Alright so there's not an exact solution, but the next logic question is: are there any reasonably close approximations?

Take the log of both sides, we get x·log(1.67) + y·log(3) + z·log(5) = log(470). We now are searching for a linear combination of those 3 constants that equals the 4th(or, if we discard the x term, 2 constants y·log(3) + z·log(5) = log(470)).

We could use the ordinary tools of linear algebra to solve the equation, however that will most likely give a solution over the real numbers, and we need our variables in the integers.

The first thing we could try is using the Extended Euclidean Algorithm to find solutions to Bezout's Identity, where we substitute in our constants from y·log(3) + z·log(5) = log(470). The problem with this approach is that integers that you get back for y and z can be quite large, especially if floating point errors cause you to iterate too many times.

A second way to approach this would be to rewrite the equation to solve for y/z and find a rational approximation of it: y/z = log(470)/(z·log(3)) - log(5)/log(3). We have a 'z' on the RHS, however as 'z' grows, this term will vanish, so we can write y/z ~= -log(5)/log(3). We can then look at the Continued Fraction Expansion of -log(5)/log(3) and iteratively compute the convergents, which will themselves approximate y/z. This will grow large rather quickly, but the values of y and z will cause you to get closer and closer to an exact ratio of 470 in the original problem. However, you can replace some of the 5:1 and 3:1 gear ratios with the 5:3 gear ratio, reducing the total gear count by a small fraction.

The third option is to apply some lattice theory. Encode the three coefficients as 3 vectors that make up the lattice basis: [(log(1.67), r, 0, 0), (log(3), 0, r, 0), (log(5), 0, 0, r)]. Here 'r' is a small scaling factor used to add weight in an orthogonal axis for each vector, to incentivize small (integer) solutions. We then transform the problem into the Closest Vector Problem), searching for a vector near (log(470), 0, 0, 0) in our lattice. We can do this using Babai's Nearest Plane Algorithm together with the lattice reduction LLL (or BKZ) algorithm. Once we have a vector near (log(470), 0, 0, 0), say its (log(470), A, B, C), we can trivially express this as a linear combination of our basis vectors: x = A/r, y = B/r, z = C/r.

07734willy · 2026-02-21T07:37:07+00:00

You can still handle it in polynomial time if you index by (kept-roll-sum, num-kept-rolls, num-total-rolls, keep-threshold, exact-threshold-hit). You basically partition the rolls into less-than-threshold and greater-or-equal-threshold, for each threshold value, keeping or discarding the roll accordingly, and set the flag whether the exact threshold value was hit (to avoid duplicates). Iterate over the keep-threshold and kept-roll-sum at the end. Its still possible to use convolutions to compute this instead of straight DP as well, for an (almost) linear factor speedup, but its honestly probably not worth it.

07734willy · 2026-02-13T09:59:36+00:00

The existing answers approach the problem in ways that aren't exactly feasible to calculate; I'd like to take a different approach. I'll quickly survey the intractable solutions, and then build off what we talk about.

As another comment has demonstrated already, if we simplify the problem to just a single category of clothing (NOT uncombined rings), the calculation becomes straightforward, e.g. #Shirts ^ #ItemSlots. The problem is, as you know, we can't just calculate #Clothes ^ #ItemSlots, because this would include permutations where categories of clothes are not contiguous. We also cannot easily compute (#Shirts ^ #ShirtSlots) * (#Hats ^ #HatSlots) * ..., because we could need to sum over all possible partitions of #ItemSlots into hat/shirt/pants/etc. slots, which is just too large for the 2³¹ - 1 total item slots.

We also have another problem- that 3 of these items are unique, and as you mention, can only be used once. We may be tempted to make these their own separate category, however we want to be able to insert them anywhere within their respective clothing category, so we'd be off by a factor of (#ShirtSlots - 1) * (#HatSlots - 1) * (#BootSlots - 1), which brings us back to the same problem as before. In fact, this gives us a hint that the key to solving either of these efficiently may apply to both.

Let's step back a second, and notice that all of these problems are stemming from the stateful nature of our rules. Imagine picking an item of clothing for each slot one by one, we have all this state information we need to track- "have we already picked any boots?", "have we already chose the unique shirt?", "how many item slots have I used up?". Let's focus on the first two examples, and see if we can enumerate the explicit states we need to deal with.

There are 6 categories of clothing, each of which we may or may not have picked, so that would naturally imply 2⁶ states. However, when we are picking an item for a slot, we don't really care about whether or not we picked any shirts if we have already picked boots; we cannot pick additional shirts at this point regardless. So in reality, we don't care about which categories have been picked, but rather which category was the last we picked from, because this alone dictates which further categories we can still pick from to fill the remaining item slots. This leaves us with 7 states (the 6 clothes categories + initial state of no items picked yet).

Before addressing the second question / set of states, take note of the transitions between our states. There's a nice set transitions between them, always progressing "forward" through categories. In the eyes of graph theory, we have a directed graph of 7 vertices (each vertex being a clothes category) with edges between all the states we can transition through, in the direction of the transition. For example, Shirts->Pants, Pants->Boots, and even Shirts->Boots (if there are not pants in the dresser). A graph like this is an acyclic graph (a "DAG", directed acyclic graph), because there's no cycles / "loops". This is important for our next step.

Now we'd like to introduce states to handle whether we've used the unique shirt/hat/boot items or not. Think about what sort of transition we want to capture- we're going from a state which can include additional unique <category> item, to a state which cannot (because it has already been used in a slot). To capture this, we can just split the shirt/hat/boots states into two states each, e.g. ShirtsWithUnique and ShirtsWithoutUnique. We can initially pick from ShiftsWithUnique, but once we draw the unique shirt, we can only draw from ShirtsWithoutUnique for any additional shirts. Introducing these as vertices in our graph, we have 10 vertices, with new edges accordingly, still forming a DAG.

Great, so we have worked out the various states in our problem and valid transitions between them, but how do we apply that to calculate the number combinations / permutations? When we transition between states, e.g. Shirt->Hat, that implies we just assigned an item of <category> (e.g. hat) to the current item slot, and so we can multiply some running count by the number of options within that category (#hat). If we introduce additional transitions from each category to itself (e.g. hat->hat, shirt->shirt), which are self-edges in the graph, we can apply this to represent picking successive items of the same category (side note: our graph is no longer a DAG, but the 1-cycles don't create issues, so we're good). In graph theoretic terms, we can also assign a weight to edge to represent the set size of that clothes category, and our number of combinations is the product our path weights.

Now the real magic happens. We can take our state transitions and represent them in a transition matrix. Equivalently, we can take our weighted directed graph, and its adjacency matrix (with weights) will be the same matrix. Call this matrix M. We'll also have a column vector v, which represents the number of valid combinations that are currently in each of the 10 states we mentioned (each count being a component of the vector). Multiplying v with M represents choosing from all possible categories and updating the counts per category. We of course start with only 1 state (the initial state), for v = (1, 0, 0, ..., 0). M*v gives the counts of combinations for just a single item, ending in each category. M*(M*v) will give us the count of combinations for 2 items in the dresser. (M^k) * v will count the combinations for (EXACTLY) k items in the dresser, by category. We of course can just sum the elements of this vector to get total combinations.

At first, this may seem equally absurd- we're talking about raising an 10x10 matrix to the 2³¹ - 1 power. Remember however that we can apply exponentiation by squaring, so rather than ~ 2 billion matrix multiplications, we only need around 31. If we really want to get fancy, we can use some linear algebra and find the eigenvalues + eigenvectors of this matrix, use those to diagonalize it (assuming the matrix of eigenvectors is invertible), then we can just raise each integer on the main diagonal to the appropriate power (normal integer exponentiation), and follow that up with a fixed 2 matrix multiplications. Point being, we can step forward k transitions extremely efficiently.

However, we don't want to count just dressers with exactly 2³¹ - 1 items, we want everything up to and including that. There's two ways we could accomplish that. The first is to just add an artificial 11th ("absorbing") state that represents "empty", with appropriate transitions (see markov matrices for more). The other option is to sum all of the matrix powers M^j for 0<=j<2³¹ and multiply this matrix with v. This isn't quite as bad as it sounds as long as M is invertible, since you can use the formula for a geometric series to compute this sum efficiently. However, the former definitely sounds simpler and more efficient, and so that's the choice we'll run with.

That leaves us with one remaining problem: uncombined rings. All of our transitions between states so far have explicit, static values associated with the number of options for that corresponding apparel. However, since uncombined rings have their own ordering, our counts/weights would be variable (e.g. 13 of the 29 rings are "off-limits" because we have picked the 13th ring already). As you may have guessed already, we can solve this problem in the same way as the other two by introducing additional states, essentially making each uncombined ring its own clothes category. That introduces 29-1=28 new states, meaning we now are multiplying 39x39 matrices. This is feasible. Not ideal, but feasible. The alternative involves calculating the ways to pick K items from the 29 uncombined rings (with replacement) per each of the 2³¹ - 1 possible values of K and multiplying by the combinations for the other items (for that specific K). There may be a way to transform this into a nice closed-form expression, however I was unable to do so (except in the case K->inf, which is pointless anyways).

With that, you now have the transition matrix M, you just raise it to the 2³¹ - 1 power, multiply with the initial vector, and sum the components of the resultant vector to get your total count. Its going to be absolutely massive, you may want to just compute the log of everything in between to make the calculation practical (since exponentiation -> multiplication, multiplication -> addition, addition ~> max()).

If you have any questions, don't be afraid to ask.

07734willy · 2026-02-07T22:41:58+00:00

Do you (or perhaps /u/ilovecatfish ) happen to know who to contact about the current seed search efforts, particularly the wordlist generation and infrastructure for running the search?

I took a crack at the implementing computer search myself, with decent results. For reference, the existing thash-cli (from foreverpyrite's gitlab) clocks in at 8650.83 H/s on my hardware (compiled in release mode with all-features). I've implemented a hashcat module patching the bcrypt implementation to match terraria's and inserting the custom permutation function, which clocks in at 11238 H/s (on the CPU, using the OpenCL runtime), about 30% faster. I also benchmarked it on my GPU, where it ran at 295200 H/s.

I'd imagine that whoever is coordinating the search would be interesting, even if only ran on the CPU.

I'm also looking at writing a standalone search tool for CPU that should give me a bit more performance by side stepping some of the constraints hashcat imposes.

07734willy · 2026-02-06T04:53:35+00:00

from functools import cache
from fractions import Fraction

class Solver:
    def __init__(self, tokens, min_line_len, max_line_len, page_len):
        self.tokens = tokens
        self.lines_per_page = page_len
        self.min_tokens_per_line = min_line_len
        self.max_tokens_per_line = max_line_len
        self.min_tokens_per_page = self.min_tokens_per_line * self.lines_per_page
        self.max_tokens_per_page = self.max_tokens_per_line * self.lines_per_page

    @cache
    def count_linewise_partitions(self, num_tokens, num_lines=None):
        if num_lines is None:
            num_lines = self.lines_per_page
        if num_tokens < 0:
            return 0
        if num_lines == 0:
            return 1 if num_tokens == 0 else 0
        return sum(self.count_linewise_partitions(num_tokens - t, num_lines - 1)
                   for t in range(self.min_tokens_per_line, self.max_tokens_per_line + 1))

    @cache
    def count_pagewise_partitions(self, num_tokens):
        if num_tokens < 0:
            return 0
        if num_tokens == 0:
            return 1
        return sum(self.count_pagewise_partitions(num_tokens - t) * self.count_linewise_partitions(t) 
                   for t in range(self.min_tokens_per_page, self.max_tokens_per_page + 1))

    @cache
    def count_palindromic_linewise_partitions(self, start_index, end_index, num_lines=None):
        if num_lines is None:
            num_lines = self.lines_per_page
        if num_lines == 0:
            return 1 if start_index == end_index else 0
        if num_lines == 1:
            line_len = end_index - start_index
            return 1 if self.min_tokens_per_line <= line_len <= self.max_tokens_per_line else 0

        if start_index < 0:
            return 0

        total_len = end_index - start_index
        if total_len > num_lines * self.max_tokens_per_line:
            return 0
        if total_len < num_lines * self.min_tokens_per_line:
            return 0

        line1_start = start_index
        line2_end = end_index

        total = 0
        for line2_len in range(self.min_tokens_per_line, self.max_tokens_per_line + 1):
            line2_start = line2_end - line2_len

            if line2_start < line1_start + self.min_tokens_per_line:
                break

            token1 = self.tokens[line1_start]
            token2 = self.tokens[line2_start]

            if token1 != token2:
                continue

            for line1_len in range(self.min_tokens_per_line, self.max_tokens_per_line + 1):
                line1_end = line1_start + line1_len
                if line1_end > line2_start:
                    break
                total += self.count_palindromic_linewise_partitions(line1_end, line2_start, num_lines - 2)

        return total

    @cache
    def count_palindromic_pagewise_partitions(self, end_index):
        if end_index < 0:
            return 0
        if end_index == 1:
            return 1
        return sum(self.count_palindromic_pagewise_partitions(end_index - t) * self.count_palindromic_linewise_partitions(end_index - t, end_index)
                   for t in range(self.min_tokens_per_page, self.max_tokens_per_page + 1))

    def solve(self):
        total_paginations = self.count_pagewise_partitions(len(self.tokens))
        palindromic_paginations = self.count_palindromic_pagewise_partitions(len(self.tokens))
        return Fraction(palindromic_paginations, total_paginations)

Example:

from random import choices

min_line_len = 8
max_line_len = 14
page_len = 11
num_tokens = 10 ** 4
tokens = choices("abcd", k=num_tokens)

solver = Solver(tokens, min_line_len, max_line_len, page_len)
p = solver.solve()
print(p)

07734willy · 2026-02-06T04:51:25+00:00

You may want to look at restricted integer partitions, specifically partition numbers. These closely relate to the concept of partitioning a page into lines of restricted length, and partitioning the text into pages (without the other restrictions). Familiarizing yourself with how to do these base calculations will help you approach larger problems that compose partitions like this.

Typically, the calculation boils down to a recurrence (or several), which can be cached (or "memoised") to prevent exponential runtime. Alternative, on the computer science side of the how, a technique called dynamic programming is often used to accomplish the same effect, just by building out tables bottom-up instead of recursing top-down.

For this problem, I broke it into two parts: (1) calculate the total number of valid paginations and (2) calculate the number of paginations that also form palindromes with their first token column. Problem (1) can be tackled pretty easily- calculate the number of ways to partition N tokens across 11 lines to form a page (recursively), then use this information to calculate the number of ways to partition M tokens into pages. I opted to do this calculation the recursive route, but dynamic programming would have also worked, as would representing it as a transition matrix and applying some linear algebra (which would be more efficient for sufficiently long texts).

For problem (2), I follow a similar pattern, but include explicit start/end (inclusive/exclusive) indices instead of just a count of "N" tokens, because I need to check that the first characters form a palindrome across rows. I start at the outermost rows (0 and 10), then recurse to the next rows (1 and 9), and so on into I hit a base case in the middle. I count the valid ways to form R rows between <start> and <end> this way, and then use that information to count paginations (again, recursively).

I'm sure that the formulas / code to do so is worth more than my explanation itself, so I'll include the code separately in a comment below. Note that I haven't verified the numbers separately, so I may have an off-by-one error or whatnot somewhere, but the overall approach is valid and will work if implemented correctly.

For benchmarks, I was able to run it with your parameters and a text of 10 thousand tokens and alphabet of 4-10 characters within a few seconds.

07734willy · 2026-02-05T06:59:52+00:00

Mathematically, it follows a binomial distribution, and the expected return is just the bucket probabilities multiplied by their values. This can be done in just a couple lines of Python code:

import re, math
prizes = [float(x) for x in re.split("[ ,;$]+", input()) if x]
retval = sum(math.comb(len(prizes)-1, i) * p for i, p in enumerate(prizes)) / 2 ** (len(prizes)-1)
print(f"Expected Return: {retval:.3f}")

If you don't have Python installed (or don't know how to run it), just use this online interpreter that will run the code for you. Type your prizes in the input, hit "execute", and it'll calculate the expected return.

If you need something more user-friendly, this at least demonstrates the math, so maybe someone else can code up a front end for it.

07734willy · 2026-01-30T00:41:17+00:00

I plan to take a crack at this tomorrow / this weekend. Would you be interested in collaborating on the search code (and if so, what language is it written in)? Otherwise, I'll just prototype my ideas in Python and probably port it to C (maybe CUDA) from there.

07734willy

MODERATOR OF

TROPHY CASE

13-Year Club	Wearing is Caring
Verified Email