We have been calling it a performance. It involved heavily rehearsed actions, memorized speeches, taking the audience into and through an alternate reality and then lifting the curtain at the end, cues for off-screen tech folks (the person SSH'd into TASBot's eyes, and the GDQ staff member controlling the Twitch overlay, to change them at key moments), Staff Roll and bows at the end, costume choices, we even discussed makeup (like TV makeup, not for beauty reasons) but ended up not doing it.
This thread is not about whether Triforce% is accepted to TASVideos or not, but how it will be accepted. The admins have already decided that it will be accepted. Again I will emphasize that I don't have any personal stake in this decision: I'm not in the TASVideos community, our project was already successful, it will have basically no impact on my life whether there is a page on this site about it or not. And in fact, having the project banned because it was too outside-the-box might be a tempting badge of honor.
It seems there are two main objections from the community: that Triforce% breaks a bunch of rules, or that it's not really about the rules but that the site's principles of integrity must be maintained, meaning reproducibility. Maybe we can figure out a way to recruit some speedrunner, get them to learn the setup, send them a TAStm32, and have them independently reproduce most/all of the run. For those who raised this objection, would this be good enough? Or would it have to be reproducible by any person on the internet, with no speedrunning skill and no hardware replay device (which is not possible, meaning the requirement of reproducibility actually means Triforce% should never be accepted)?
100% of the tools are publicly released. What is not released is certain copyrighted data which was injected. If you would like to review our tools, you are more than welcome to; if you have any questions about where things are (the TAStm32 custom firmware and the scripts for the host computer are in other public repos separate from the triforce-percent Github), feel free to reach out.
I think the only way to verify the integrity of a live event would be to have a TASVideos.org representative present and examining hardware and software at the live event. They would need to check for things like, that we didn't put a flashcart PCB into the OoT cart shell, or a Raspberry Pi into the N64 shell. They would also have to independently verify GDQ's extremely complex signal chain, to ensure the game video and audio were actually coming from the console rather than from some recording. Realistically, either this person is dwangoAC and the verification is already done, or the verification is impossible for past events and very likely infeasible for future events, meaning live TAS content would continue to be excluded from the site.
What aspect specifically are you referring to? Triforce% uses the unmodified game; it was played on real, original OoT 1.0 US carts at SGDQ and ESA. Is the "nothing more than" you're referring to the requirement of the TAS replay device with custom firmware (i.e. not emulator compatible)? Is it the fact that a human speedrunner is needed to set up the initial state? Is it the fact that some of the injected data is not released due to copyright?
In any case, "would it really be too much to ask if we required these types of submissions to [do anything]" makes complete sense if the site is making rules which are guiding what people do and don't do in TASes being created for submission to the site. It does not make sense if there is an existing, already completed project which was not created with the site in mind. Rules established now can't put constraints on our design decisions starting the project almost three years ago--all they can do is accept or reject the submission as of now. Furthermore, the need for a human speedrunner is a reality of the console/game which we could not work around. If the TASVideos.org movie rules had been somehow unavoidably imposed on us in 2019-2020, Triforce% would have never existed.
I'm interpreting this to mean, "can you set up the build toolchain so that the user adds the copyrighted content themselves", rather than "please distribute the copyrighted content" as dwangoAC interpreted it. The answer is still no though, for a few reasons.
For some content, such as textures from OoT used in our custom scenes, this would be very much possible, the work just hasn't been done yet. It would be a matter of adding to a few Makefiles to extract certain textures from the input ROM in certain formats and add them to Blender scenes and C scene files. Note that contents from the user-provided input ROM are used in many places in the build toolchain already.
For some content, such as the Running Man boss, it could have been created in a fashion where we could have distributed all of our work without any copyrighted content, but the person who made it unfortunately did not make it that way. For the Running Man in particular, the contributor gave him an IK skeleton to make animating him easier, but this makes the custom animations incompatible with the vanilla skeleton. Therefore, in order for him to be usable, the model must be exported with the new skeleton. Since we can't distribute the model and the existing skeleton is incompatible, he can't be distributed in a usable form.
For some content, modifications which can't be scripted were made to copyrighted content. The primary example of this is the BotW models, where dozens of hours of work was done by another contributor and myself to simplify their meshes and convert them to the needed formats for the N64. This obviously can't be done by a script, and the "derivative work" models are still copyrighted.
With that said, the content that we're distributing is maybe 85% or so of all the content shown at GDQ, and nearly everything up to the Running Man is distributed and usable. Is there really an integrity concern that, a third party can reproduce the first half of the run and use ACE to add custom actors, cutscenes, game mechanics, and so on, but then someone thinks we might have cheated and modded the ROM in the second half? What if we replaced all the copyrighted textures with public domain ones, and the BotW models with some generic Creative Commons person models, and so on--would that still mean the run was not reproducible because we didn't inject the exact same data as we did at SGDQ?
Here is a list of all the TASVideos rules I believe Triforce% violates:
"Use an official release of an approved emulator" / "Judges and Publishers will attempt to verify that your input file syncs on an officially released build of an accepted emulator. If your run fails to sync on an official release, it cannot be verified, and thus cannot be accepted." Triforce% does not work on emulators (see below), and if a hacked emulator was developed which could support it, this would still not be an official release. Note that there is no carve-out for console verification; TASes which work on console but not on emulator are not allowed on the site.
"Always record new movies from power-on or SaveRAM". The TAS aspect of Triforce% starts from a state set up by a human speedrunner. Furthermore, none of the TAS parts of Triforce% were ever "recorded" in the traditional sense--they were all generated by scripts. I think this rule probably means "movies must start from power-on (etc.)", but technically, any TAS run which was generated rather than recorded violates the rule as written.
Goal choice: "Standard" is out of the question, among the reasons being "Arbitrary Code Execution (ACE) is only allowed in Standard as an any% speedrun". For "Moons", we have a few issues:
"Your goal choice should be clearly defined and sensible, especially to those who do not know your chosen game" is questionable, especially for the finale sequence.
"Your movie must beat the game" / "Playarounds and freeruns must still beat the game"--well, we reached a Staff Roll and a "The End" screen, but not by traditional definitions.
"the spirit of the original game should be maintained"--we are proud of our work, and if anything, it was an issue that much of our content was TOO believable. However, it could easily be argued that Twitch chat etc. was not in the spirit of a '90s game.
"copyright should not be infringed. Fair use applies here"--we believe that our SGDQ performance was well within fair use due to its overwhelmingly transformative nature and other factors, but we also believe TASVideos is not going to want to host movie files which contain copyrighted assets encoded as button presses.
"Your TAS must be reasonably optimized"--the RTA portion was not optimized by TAS standards, as it was by a human and using "marathon strats". The rules of course don't have any allowance for a TAS containing an RTA segment.
"Your submission must be reproducible"--Triforce%, minus certain copyrighted content, is reproducible on console, but it requires a human leaderboard-quality speedrunner and a TAStm32 V2 or V3 board. Both the fact that certain content would be omitted compared to the live run and the human+hardware requirements are impediments to counting this as following the rule.
Regarding why Triforce% does not work on emulators--there are three issues.
As part of the ACE bootstrappers, code is modified to poll the controllers 8 times per frame (VI) instead of once. To our knowledge, no N64 emulator with TAS playback tools supports this.
Once this mode is activated, a set of scripts on the computer and the custom firmware on the TAStm32 encode data into controller inputs on controllers 2-4. The actual set of controller inputs is generated on-the-fly--it isn't in some file on our computer. Other scripts could be written to generate this set of controller inputs on the computer, but even if this was done, TAS tools would have to be developed to allow TASing the gameplay on controller 1 while the other controller inputs were being streamed in. This would also require custom changes to an emulator.
We use certain graphical effects, including via patches to microcode, which are not supported by most N64 emulators (including BizHawk). Also, emulators using a recompiler core may crash, as Triforce% uses self-modifying code.
Keep in mind though: these issues are in relation to whether a hypothetical TAS movie file containing all the inputs which were actually made to the console at SGDQ 2022, given that a hypothetical perfect emulator (which is another can of worms) existed and was an official/accepted emulator, should be accepted. The question here is whether Triforce%, the showcase performed at SGDQ 2022, should be accepted.
One other thing to mention:
The Triforce% runs shown at SGDQ and ESA were performed on unmodified ROMs. Our other showcases of the project not involving Savestate used a mod to get ACE quickly, because neither dwangoAC nor myself have the speedrunning skill to do it.
Unlike dwangoAC, I'm an outsider to the TASVideos community and I don't have a vested interest in whether the project is accepted here or not. I think it is obvious that Triforce% cannot be accepted under the current set of rules. In particular, the site seems to be all about letting people download a TAS movie file and watch it on their own emulator, which is not possible for many reasons described above. If the site wants to make some new category for things like this, great! If the community feels that it's too fundamentally contradictory to the site's purpose, no hard feelings from me.