As you may have noticed, I’ve been thinking about Corrupt Combustion again. In general, I like keeping cards close to my chest — certainly, I’d like for there to be big reveals if I ever write this story For Real — but I’ve been wondering what the utility of that really is, when the project is this disorganized, and the people who read it are as much brainstorming partners as they are proper readers.
The story itself isn’t even plotted out in detail enough for me to say for certain where or why some of the things I’m keeping secret will actually be revealed. Like, am I really spoiling the surprise if I explain what’s really up with Beau, or what Nori’s driver really is? In fact, I don’t even remember why I was keeping that one secret to begin with.
When I expressed this elsewhere, I received this response:
#Let’s go!
#Also gonna shoot my shot for guessing Nori’s Driver b4 it gets revealed
#Current top contender in my brain is something akin to Mahito’s Idle Transfiguration
#(but it works on code bc they’re robots)
#With the knowledge the current powerset is all bc of Nori inverting her function
#Maybe it normally only can affect her
#But inverted it can affect others
#Looking forward to seeing all the cool stuff you’ve got cooked up.
This guess was remarkably close. In fact, the original concept for her driver — which informs how some earlier material was written — is almost exactly what you describe. It’s changed significantly as I’ve tried to refine what that actually means and how it might be balanced, so a part of me wonders if earlier scenes are still consistent with how my interpretation of her driver has evolved.
(I.e. last year, I might’ve said her driver was corruption itself, and its inverse was ‘hotfix’, and her apparent powerset is downstream of her ability to ‘patch’ herself like that. She can no longer really do this.)
What can she do? Let’s discuss. Don’t mind that scroll bar.
To understand Nori’s driver, we first need to refresh ourselves on the low level details of how corruption is supposed to work.
Recall that in CC, computers are cursed. Certain patterns of computation innately produce glitches. Stuff like 2+2=4 or 2+4*7=30 are well-behaved, but if these formula get sufficiently complicated, typing them into a calculator in this world will cause it to spit out the wrong answer, damage the circuits a little, potentially write random data to unpredictable locations.
That last bit is the most important. The data produced by these glitches is called corruption: it’s where the cursed-ness is stored. Code that reads this glitched data as input will have a dramatically increased chance of causing further glitches; the errors cascade.
Remember also that the fundamental formula of corrupt combustion is that oil + corruption = command execution. By transmitting — “venting” — corrupt data through the cables that connect to the drone’s oil reserves, the electricity can spark combustion, and like that, solver commands are executed.
Now, it’s still a little bit more complicated than that. You might think that, well if these glitches are innate to certain computation, then it should be entirely possible to write a program that deliberately executes glitched routine on-demand to create exactly the amount of corruption you need.
But corruption isn’t so well behaved. The corrupt data generated by a glitch won’t always be stored in the same place — it can overwrite important variables and configuration. It can also unpredictably alter the flow of the command line. For example, you might try to run a small glitch ten times in a loop — except four times through, the program glitches its own instructions to gotos out of the controlled loop and into a totally different part of the code, wreaking havoc.
All of this is to say, to allow corrupt combustion means playing with chaos; solvers obtain their power from glitches and errors, but this isn’t cosmetic or flavor. They are casting from SAN.
This, incidentally, is the difference between a zombie and a solver. Solvers have programming, cognition, a sense of self that’s eroded by corruption. Zombies are corruption.
When a solver cascades enough errors, they glitch out, potentially crashing, and have to perform data recovery before they are operable again. You could disable a solver just by injecting them with more corruption than they can handle. Try that with a zombie, and the added corruption only strengthens them. Zombie processes are sentient patterns of corruption.
Again, the formula of corrupt combustion is oil + corruption = command execution. So another way to understand the difference between a solver and a zombie is where the bottleneck lies; a solver is oil-rich and corruption-poor, while a zombie is replete with corruption and hungry for oil.
So let’s talk about the actual commmands solvers run. The most basic attack available to a solver is to just output a stream of unstructured data that interrupts other commands.
Against ordinary digital targets, this feels as if you jammed noise or static into their inputs, but there’s no anomalous corruption induced.
Against hard-drives and circuits laden with corrupt data, it purges that corruption; this is how solvers are able to defeat zombies.
Finally, if there’s a corrupt command running on the target, that command ablatively absorbs some of the interruption and errors out, leaving the target to experience a reduced or no effect.
For this reason, it’s common practice to layer commands, making them redundant, so that if some of them error out, the rest can complete the operation.
Imagine solver A levitates a roachbot with 3kb of redundant translation commands. Solver B outputs 5kb raw interruption into it. 3kb gets absorbed by the the levitation command, canceling it, and then the roachbot takes 2kb of interruption to central processing and curls up unresponsive.
A tactic that advanced solvers can employ is traps, commands that trigger in response to another command’s interruption. Like a counterattack or parry — think try/catch exception blocks — but the added complexity makes it harder to master, easy to mess up. You can also send alternate interrupt signals that might confuse or bypass simple try/catch code — at the highest level, there’s an arms race between ever more complicated defenses and ever trickier ways to crack those defenses.
But most solvers stick to redundant, ablative code, and simple interrupts.
And this is where Nori is different.
Nori’s driver is [Overwrite]. When she interacts with another solver’s command output, instead of causing their command to abort, it gets overwritten with her own commands by corrupting the thread of execution. The overwritten commands then recursively inherit the effect of her driver.
Let’s go back to that toy example. Imagine Nori tries to attack the the roachbot held with 3kb of levitation. She outputs 5kb of driver commands, overwriting the 3kb levitation to yield 8kb (!) output.
…which coalesces into a weak ring 4 zombie process and the possessed roachbot skitters away. Oops.
This is because Nori cannot interrupt the same way regular solvers do — her overwritten commands only create more corruption.
In Cabin Fever Labs, the technicians considered Nori a failure or a curiosity. Remember, the purpose of solvers is to purge zombies, and sure, for certain powerful zombies, Nori could negate their special commands — at the expense of empowering the zombie overall, because again, they’re made of corruption.
Imagine being unable to fulfill your only purpose; the unique essence of your soul being infectious wildfire that creates monsters and madmen.
A similar principle holds against solvers, even — against weak solvers, the sudden influx of corruption might overwhelm them and prompt a crash, but remember that solvers in general are oil-rich and corruption-poor. Nori’s “power” is most effective against already-powerful solvers with lots of command output to overwrite, yet it’s exactly those powerful solvers who’d best be able to exploit a sudden windfall of corruption.
Worse, this innate function affects all command output, including her own. So even when there’s no opposing cmdout to target, it will continously overwrite itself in an infinite recursive feedback loop. Imagine a microphone next to a speaker — now imagine that earsplitting feedback has a direct link to your core.
In short, Nori thinks she really pulled garbage on the superpower gacha.
What changes everything is when Yeva theorizes and then successfully implements metacc, the metacorruption compiler. This is a huge command construct — gigabytes of data implementing a virtual machine — that’s capable of running code inside corrupt commands. When the constructed computer glitches out, though, instead of corruption it produces metacorruption, capable of mutual annihilation with corruption.
Nori immediately latched onto this discovery. For anyone else, this would be purely academic — metacc is gigabytes of command output to produce kilobytes of metacorruption; meanwhile a solver can just dump command output directly into a target and purge corruption. Metacorruption seems like extra steps, and expensive steps at that. But it’s a lifeline for Nori, whose command output only yields more corruption.
So she iterates on metacc, making it more and more efficient until the initial million-to-one conversation efficiency of Yeva’s original proof-of-concept implementation is optimized down to below a hundred-to-one, Nori’s famous ‘fast inverse corruption’ trick. It’s even more effective in her hands, because the nature of her driver means that massive quantities of command output it requires are even easier to come by.
Suddenly, her driver that once could never be used against zombies lest she empower them is now capable of turning their own corruption against them.
Because she’s the first drone to truly master metacorruption, Nori’s also the first drone to discover inverse functions. The inverse function of ⸢Overwrite⸥ is ⸢Halting⸥.
Instead of overwriting command output with her own, ⸢Halting⸥ pauses the execution of the target. This bypasses all defenses — it’s impossible to trigger a trap if the command in question simply stops.
But, like ⸢Overwrite⸥, this also applies to her own commands — thus granting her control to prevent the infinite feedback loops, and achieving even greater mastery over her chaotic power.
Rather than recursive self-replication, Nori’s inverse command output will halt itself and halt its target, which effectively makes it akin to a classic solver purge with extra steps.
Because Nori never documents her driver, few solvers actually know her power depends on the target at all. From the outside, you see Nori punching through defenses with an overwhelming surge of command output. Would you see this and think she’s doing that with your commands, or she simply has that much more in reserve?
Remember the roachbot example — 5kb attack minus 3kb defense. With normal math, this equals 2kb, with Nori math this equals 8kb — but doesn’t that look the same as if Nori came at you with 11kb normally?
Her driver lets her punch above her weight class, look twice as strong as she is.
And the results are just as fiendish with her defense. Nori is said to have a “quicksand proxy field” — it’s as if it gets stronger the more you try to penetrate it.
But this illusion is key to Nori’s seeming invulnerability. Because even with her optimizations, compiling metacorruption is expensive, and Nori requires metacorruption and inverse commands to operate her driver, otherwise the corruption spirals out of hand.
Against most threats, Nori looks like a powerful solver that one needs to use their strongest commands to beat. But all of that command output generated to try and stand up to Nori is what sustains her metacorruption.
The trick to beating Nori is come at her with no powers, just hands — this is why Alice is her natural enemy.
As a last note, in Compression & Extraction, Nori used two special abilities. The macro [0x00F — Bitrot Blue] and the inverse macro [0xF00 — Red Hotfix]. Besides being on-the-nose references, they have special mechanics based on applications of her powers.
Bitrot Blue is a zip-bomb. On top of her cmdout’s natural tendency to overwrite others, it’s densely bundled with metacorruption, allowing the corruption her cmdout generates to be instantly converted into more cmdout. Explosively.
Red Hotfix is a blast of inverse command output. Where Blue explodes, Red implodes, negating and unraveling the commands of other solvers. The densely packed payload of metacorruption means that Red Hotfix often goes as far as not just stopping commands, but reversing them. “Fixing” what corruption, well, corrupted.
And you may look at this pattern, and wonder if Nori has a third macro, and what it might do.
But a lady has to keep some secrets ;3