Top Secret Mom Lore

[As you may have noticed][prev], 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. [prev]: repair-slither.html 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][tumblr], I received this response: [tumblr]: https://www.tumblr.com/snugglesquiggle/772610823318388736 > #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+47=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,[^fail] while a zombie is replete with corruption and hungry for oil.[^styx] [^fail]: Drones have failsafe routines that instinctively take hold whenever they reach a critical threshold of corruption. there's something that speaks to me about the image of a solver instictively venting an excess of corruption via combustion, oil burning away --- overheating themselves just to stay sane. [^styx]: One reader saw this, and concluded that this would make zombies walking batteries for powerful solvers. This doesn't work. A solver drone's relationship to corruption is defined more by how much risk they feel comfortable taking, rather than how much corruption they quantitatively have access to. Solvers are not corruption-poor because corruption itself is hard to come by --- just deref NULL[Now, it's not literally an easy as segfaulting. How much corruption a glitch generates depends matter of entropy --- predictably triggering a glitch has diminishing returns --- and its relationship to the surrounding program. Just like a ball has more energy atop a hill, a glitch can generate more corruption in a complex system --- if it breaks a pattern. And of course, since corruption can do work, creating it costs energy. All of this is to say, even if you had zero self preservation, you wouldn't be able to instantly summon a bunch of corruption. Still, slurping zombies just doesn't really solve your problems. ]{.note} --- what's scarce is controlled corruption. 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.^[And it's why solvers are all but required to fight zombies --- workers tend to just become host to the corruption. Still, if the zombie process is starved of oil and electricity for long enough, it will slowly fade.] 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.[See also: the concept of radiation hardening in programming.]{.note} 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]{.spell}. 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.[If nothing else, Nori was useful for ensuring the technicians had no shortage of zombies for testing other solvers against.]{.note} 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 so