The situation in general
We TAS software, which is games, in isolation.
We heavily depend on absence of external modifications to that software, and we guarantee they're not applied. This is important for the validity reasons. Which, in turn, is important when we want to keep TASing impressive, entertaining, legitimate in terms of competition, available to everyone due to equality of initial conditions.
We allow any input the software in question allows us to send to it. We don't care whether this input is actually processed, accounted for, causes bugs, or just subtly changes the game state. This is why we allow contradictory directions on the D-pad, Reset while saving, using input bits that aren't present on the official controller, and so on and so forth.
We do not allow events of the physical or hardware world to be used in TASes. Because these can't be emulated. You can not emulate effects of kicking the console, pulling the cartridge out half-way, room temperature affecting startup state, random bit decay, etc. Emulation means we reproduce the logic of the software. Simulation means we try to reproduce a physical event we can't fully understand nor recreate.
Game image is written on a read-only medium, and is stored by the physical representation of bits on it, but we don't care about their physical nature: the bits only contain the
information in a machine readable form, but the very logic (program) behind this information can be encoded in any way we want. So we copy this program on our hard drives and use it for TASing. We basically
decode the information contained on the game medium, and disregard the physical side of things.
The rules
The rule about game integrity that I added recently reflects all of the above. We only TAS game programs, and we want only game programs to be TASed.
Swapping disks in unintended order breaks the integrity if the original program. The program was designed as a whole, and then broken into disks so it could fit. It's not like it's represented as separate independent chapters that we play in the order we're asked to play them. The game explicitly needs the next disk, because it's written to be consecutive - integral.
Adding disks that aren't required consecutive parts of the original game program has the same problematic aspects, so it's also not allowed. In this case one is not TASing the original game at all anymore, and irrelevant data is being fed to the console, so this may count as modifying the game image, which is fundamentally banned.
Additionally, the above scenarios also make a breach in the software world we're dealing with, and introduce physical and hardware events. Those events can't be emulated, as I said, aren't reproducible or deterministic, so we can't afford introducing them into your system. After all, in our emulators we even patch away actual non-determinism of the console, because we prefer verifiability of movies and sync stability of savestates. Not that inserting irrelevant images can't be emulated, but it's a step out of our
game-software-in-isolation environment. Since we depend on this isolation's integrity, any breach in it causes all sorts of problems, like legitimacy issues in the eyes of the community, undefined initial conditions for the competition, undefined borderline between emulation and simulation, undefined reliability and stability of emulation, and likely some others.
Exceptions?
This is a tough problem.
Given all of the above, this particular game is known to have content that can
only be unlocked if irrelevant images that don't belong to the game are used. Trying to work around this would require starting from an emulator savestate, as even save file can't carry or generate all the needed info we need here. So first of all, I think we need an exception in this case.
Since it is so unique and ridiculous, I'm not even sure if we need to allow exceptions like this right in the rules. Maybe some smart way of addressing this can be added, but I can't generalize it yet.
I believe that using
arbitrary images even for cases like this one should not be allowed under any circumstances. Arbitrary means literally arbitrary: it can be an unreleased Demo disk of some Gore Grind band from Antarctica, and the movie may completely refuse to sync on anything else. Allowing arbitrary images means we invite such scenarios for
all such cases. We can't limit this to "obtainable" disks either, because this definition is even weaker, and introduces actual legal problems.
I believe that for this game, we must limit ourselves to the most effective hand-crafted image that does what the game wants from it, and nothing more. This removes the problems mentioned in the previous paragraph and allows to stick to something strongly and clearly defined, while also guaranteeing against any legality problems.
Vaultable?
Should we allow movies using images, that don't belong to the original game, for Vault? The Vault is designed to only allow things that can be easily, clearly, and unambiguously defined. While some of the Vault rues are still quite complicated in their wording (like those for sports games, or for full completion), the spirit behind them is still simple: we want clear cuts and meaningful speed competition records.
In that sense, due to all the complexity of this case-by-case exception, I do not think that we should allow use of unintended images for Vault. And the definition of intended image is the same: either the game explicitly asks for some particular image, or the publisher encourages using it, like it happens with Sonic & Knuckles and Sonic 3 (or modern DLCs maybe).
Added later:
Another way to look at this, it's similar to save anchored movies. Starting a game as it is and playing it from scratch is a vaultable concept. Using an
external resource to boost your stats is not.
This submission
If we agree on all of the above, this submission would need to be
1) replayed using the hand-crafted, most optimal secondary disk image,
2) optimal enough to be accepted,
3) entertaining enough to be accepted to Moons.
If either of these isn't met, it'd have to be rejected.
Opinions?
Are you sending their names as strings?
