Towards a newer, better space casino in 2.1

[h.q.droid]

I fired up ghidra and researched for random number manipulation possibilities again in 2.1, and found interesting changes. In short, the global quality / additional product RNG is now shared by much fewer, and much more predictable things. And with the addition of universal signals, TAS-style random number manipulation becomes tangible with in-game mechanics only.

The RNG algorithm is similar to 2.0 so I'm skipping it (check link at the end for code). For now it's enough to know it's possible to compute an arbitrary future value of the builtin RNG using an AND-XOR matrix multiplication, which is possible with in-game combinators. In 2.1, the global RNG is shared by:

- Quality rolls at the beginning of recipe-crafting (basically all thing-makers that are not miners), it seems always rolled, even for with crafts with +0% quality
- Additional production rolls at the end of recipe-crafting (e.g. recycling an iron gear will roll once to see whether you get an iron plate)
- Mining (likely one roll for big/quality miner resource consumption + one roll for quality). In 2.1, productivity mining seems batched so there is only one roll no matter how many ores are produced simultaneously
- Flickering of glows: confirmed for heating tower and nuclear plant, suspected for fusion plasma maker and accumulators
* Particle effects: confirmed for gun turret shooting, suspected for other turrets
* Unknown `randomPosition()` calls: suspected for Fulgora lightening or asteroid spawning. It no longer happens on every tick, became much more scarce.
* Didn't check in 2.1 yet: was used in computing heat transmission across heat pipes in 2.0

The '-' ones are somewhat controllable: you can "stop the world" during critical moments. Nuclear plant can be stopped by denying fuel and fusion plants can be denying coolant. Fulgora lightening can be "controlled" too by performing critical actions during Fulgora days. Asteroid spawning doesn't happen often for stationary platforms. Providing there is no shooting anywhere, we can get dozens of ticks where we *completely control* the quality RNG.

Now to utilize the control, we need to first leak the 88-bit RNG state. It's trivial to leak 1 bit by recycling an iron gear wheel and checking whether it produced an iron plate. The main obstacle is the opaque internal update order of Factorio, which isn't even visible to mods. However, while entities in a surface are updated in a dynamic and uncontrolled order, ordering *between* surfaces are likely deterministic (unconfirmed yet). So theoretically, if we launch 88 consecutive space platforms, then give them one recycler each and synchronize the recyclers, we can leak the complete RNG state in a single tick. The 2.1 universal signals allow us to transmit them to some Nauvis control center for RNG prediction.

With state leaked, it's possible to predict many future bits in parallel. If we aim for a 1/40 roll to directly make rare from common or recycle rare to legendary, we can predict 6 bits for 88 future rolls and get one with 89.2% chance. This prediction will be used to reprogram the 88 platforms: those getting bad rolls play with iron gear wheels, the few getting good rolls make / recycle big stuff like rocket silos, personal fusion reactors or capturing rockets. As long as only one thing goes through the first / last tick of crafting every platform, their ordering should remain predictable.

This design allows one to get legendary *anything* in a single upcycle, with fixed 25% yield. It can also enable in-space productivity loops like brick=>10 concrete=>10 bricks, or lossless promethium chunk upcycling, by manipulating recycler output as well. The catch is:

- Between the state-leak tick and the manipulation tick, i.e., during the matrix multiplication:
* You can't make or mine anything anywhere
* All reactors must be off, you can still get power from the non-glowing parts: heat exchangers, turbines, and likely fusion generators
* No shooting anywhere
* Could require Fulgora day
* We could have to bet on no asteroid spawning
- 66-88 iron gear wheels consumed as catalyst for each run (likely worse than normal recycling since you want to do them on known bad rolls)
- Need 88 platforms with strictly controlled launch order to reliably leak state
- The required combinator logic would be impractical to create by hand and some lua would be required to create the required blueprints

I haven't done the lua-ing yet. Just decided to share the preliminary results first.

For other people interested in reverse engineering: in 2.1.9, there is a dedicated function `rollQuality`, which takes a random number as input. You can set a break point at its start, then inspect the upper level of call stack and look for access to `DWORD PTR [reg+0x414]` to find out the quality RNG address (which is that `reg+0x414`). Then set a read/write breakpoint at it to see where it's used. It's best done in map editor where you can step single ticks.

Link to previous research in 2.0: viewtopic.php?p=653823#p653823

[radical_larry]

Very interesting idea, but I wonder if getting full control over RNG is feasible at all. It might make more sense to use approximate knowledge of the RNG state to increase quality results, on average, instead of aiming for perfect results.
I'm thinking something like counting cards in blackjack, keeping track of your current advantage. If you know you're in a range of RNG states and then you calculate what the average of the next few rolls is going to be, then if that's favorable you turn on your quality machines all at once to consume those "good numbers".

[h.q.droid]

Very interesting idea, but I wonder if getting full control over RNG is feasible at all. It might make more sense to use approximate knowledge of the RNG state to increase quality results, on average, instead of aiming for perfect results.
I'm thinking something like counting cards in blackjack, keeping track of your current advantage. If you know you're in a range of RNG states and then you calculate what the average of the next few rolls is going to be, then if that's favorable you turn on your quality machines all at once to consume those "good numbers".

That's a valid point. I have considered that before, but an obstacle is the RNG being actually good statistically: it's very unlikely to get a range of good numbers for a large range. It could be feasible for a narrow enough range though, like <=8 rolls.

[radical_larry]

Since the RNG has an 88 bit state as you say, it would be possible to pre-calculate the best sequences according to certain criteria, like highest averages over a certain length. Then build a system in game that detects when that part is likely to come up next to turn on all your high throughput quality recipes. That means you wouldn't need a large range of good numbers, you just need to pre-calculate a lot of good, small ranges. And running through the RNG state quickly with more random events actually becomes advantageous to the process, instead of hindering it, as those ranges are hit more often, increasing throughput.

[Hurkyl]

You're underestimating how big an 88-bit state space is.

If you progressed through a million different states every tick, you would still need to wait over a billion centuries to get through them all.

[radical_larry]

You don't have to, that's what the precalculated ranges are for. The quicker you move through the RNG state, the more of them you hit in a given time, regardless of how large the whole RNG state actually is.

[Hurkyl]

If you precompute a billion ranges spread out around the cycle (and how are you going to store those anyways), then you'll just need to wait one century to advance to one of them.

And you don't have the time to do the precomputation anyways, unless you find some mathematical weakness in the RNG that can be exploited to skip that work.

[radical_larry]

Huh, you're right, 2^88 is quite a lot more than I thought, even with how quickly that xorshift can be computed.
I guess the calculations would have to be done dynamically inside the game to try and predict the next RNG results. Might be a lot of logic to account for missed RNG calls and dealing with the whole uncertainty around it, unless there's a really smart way to do it.

[h.q.droid]

Just to be sure, I rechecked the period of the RNG setup, it's 2147483647*536870911*268435455, i.e. (2**31-1)*(2**29-1)*(2**28-1), roughly utilizing the full 88-bit state. There isn't a period-related weakness.

I was thinking on predicting enough future states quick enough so that they can be used before any uncertain RNG calls could kick in, and re-leak the state every time since it's just recycling 88 iron gear wheels.

[vemusa]

In terms of leaking RNG state, what about recycling repair packs instead? This can leak 2 bits per recycle, right?

[Nidan]

Yes, any random result where the number of possible outcomes is a power of 2 with even odds works best.
Technically, any random result helps, but then you'll have to deal with partial bits, and, in case of uneven odds, getting different amount of information depending on the result.