Hi. I'm moozooh, sometimes known as Vladimir Sergeyev, a technical writer/editor/translator/language specialist by trade. Most of you have likely seen me around as I've been with TASVideos for ~18 years on and off at this point, most of which I spent as a forum moderator, wiki editor, and, for the past four or so years, Discord moderator as well. Right now I'm one of the oldest still-active staff members around, probably only second to adelikat. Basically a living cryptid, borderline undead.
In the light of this announcement, I'd like to share an amusing anecdote. In late 2015 I was appointed starman. Yes, that was a thing back in the day; nothing to do with the David Bowie song or the John Carpenter movie. During my short and otherwise uneventful tenure, I sent a message entitled "The TASVideos takeover plan" (in Russian) to feos, who lived an hour-something away by train at the time. That's the subject line I came up with to lure him out to have a meeting and discuss our evil plans a revision to the starring and recommendations policy and related things. It was a great and memorable meeting, by the way! I did pretty much nothing else useful as a starman. Wait, what do you mean by "that wasn't useful, either"?
Fast-forward some eight years, and both feos and I are senior staff. What a... coincidence, h-huh? Certainly not in any way related to that message, trust me!
But frankly, all things considered, this shouldn't come as a surprise. This community is very dear to me, and I'm thankful to the staff and other members with whom I've communicated over the years for treating me well and willing to forgive my sudden and often prolonged disappearances. No matter what happens, I always come back here, and I always receive a warm welcome. I want to share this experience with other members and give back to one of the few places on the internet that actually feels like home.
Hence, as of today, I've taken on the role of a senior moderator. No, not because it's an honorary role to recognize the elderly among us. This is a new role that was branched out from activities previously performed by admins, most notably Memory. (Thank you very much for doing this until now!) For me specifically, this promotion means at least three relatively new things that will become my duties on a consistent basis.
I'll have much deeper involvement in matters concerning moderation policy (and by extent, advise other seniors on PR, general communication, and crisis management when necessary) and the general senior-only discussions to which I had not been privy until now.
I'll be managing the moderator team. This, in turn, means both that the moderators can now turn to me for advice and final say in moderation matters, and that regular users can complain to me about other moderators' conduct or decisions. And I'll be the main person hiring moderators and letting them go. I'll still be performing my usual moderator duties myself, too, of course.
You can yell at me directly if there's some long-standing problem with moderation and nothing is seemingly being done about it or is being done backwards, and I'll prioritize it. Keep in mind that moderators and site staff are people and they can't always operate at the best of their ability or be on the same page for every question, so not every problem can be solved quickly or efficiently. But we will try to find any improvements we can implement at the time—as is The TASVideos Way™. I will conveniently ignore the fact that breaking things is also The TASVideos Way™.
As usual, everyone is also free to DM me for any other concerns—both personal and regarding other users. I can't promise I'll be able to resolve all of them, or that it will be quick, but I will listen and provide an outside-observer take on a situation, a guidance, or an explanation on how a given situation or behavior is seen through the lens of the moderation policy.
On topic of DMs and guidance, time for another anecdote: just last month a well-known TASVideos member (name undisclosed in the interest of privacy) DM'd me with a question about pooping—and I gave them an earnest answer to the best of my ability. Un-bowel-ievable, right? Can you imagine the level to which I'm willing to dirty my hands (figuratively, for now) to deal with your concerns?
...Alright, I think it's out of my system now. That fulfills the toilet humor quota. Still with me? Amazing persistence. I guess I'll take the opportunity to announce some of the near-term plans regarding moderation. You didn't think I'd take this position willy-nilly without at least some planning ahead, eh? Did you, now?
First—and this should hopefully be ready very very soon—we will implement ModMail in the Discord server. This should streamline the reporting process and enable the moderator team to efficiently take on the more delicate cases that require minimizing personal exposure for the reporter.
A report feature for the forum will also follow at some point afterwards. Crazy that we've spent all this time without one!
There are some things that I have in mind but will not make public until I understand how to best implement them. These mainly concern internal processes.
In terms of policy and response quality, I'd like to aim for incremental but noticeable improvements. Just like feos and his movie rules meta-meta-play, I'll be playing the 5D chess of moderating the moderation practice. Specifically, tightening up the bottom end (going for faster and more efficient responses, more proactive involvement when necessary) and cooling down the top end (hopefully fewer knee-jerk bans and generally more professional behavior when delivering severe punishment)..
Finally, if you've spent some time with the community, have a solid understanding of how it operates, are able to react to conflict situations and bad behavior in a calm and level-headed manner, and would like to help out with moderation, DM me on TASVideos Discord @moozooh. The more moderators we have, the easier the burden on any one in particular. Almost like a Ponzi scheme! I totally could've come up with a less unpleasant comparison!
Now go register in DTC11. It's more important than reading pathetic attempts at comedy in a staff announcement thread, of all places.
Major gameplay changes coming from skipping or trivializing content are usually called a "major skip glitch", and the category that avoids it (but not other glitches) is already standard.
No, that is just a relatively small subset of the wider range of glitches to which the audience might want to see somewhat more conventional solutions.
Examples of glitches that trivialize or skip content that aren't "major skips":
Wall zips, coordinate overflow, and other similar things in pretty much every run of Sonic 3 as well as Sonic 2 and who knows how many other Sonics at this point.
Whatever glitchy mess some of the NES Mega Man games have become, particularly the first game.
There certainly is demand for runs that are easier to make sense of, or at least ones that respect the level geometry to some extent as opposed to just going through it in a straight line. I can see Kriole's in-bounds all-souls AoS run even has a star now upon being reinstated in a separate category.
feos wrote:
Why?
Okay, fair, maybe not most of the time. But as far as I'm aware, major skips are the most common case for glitchless/low-glitch categories in games.
It's mainly the exceedingly broken games like the ones I mentioned above that warrant an extra layer of limitations that cover a lot more than just major skips.
Because what one person finds "stylistic" is what another finds annoying?
Assuming it did answer the question you quoted (it didn't, by the way), do we have annoyance anywhere in our judging guidelines as a motivating factor?
I think there is (still) some misunderstanding here in regards to this initiative. Glitchless runs are needed not because glitches are "annoying". They are needed because unrestricted runs becoming more glitched over time is a natural course of things. A core aspect of speedrunning is finding more ways to save time, and in doing so, it is inevitable that at some point meaningful content—complex and creative solutions to gameplay problems that many people enjoy seeing—is being optimized out of the runs. Common examples include things like navigating a room full of obstacles as opposed to skipping it via OoB travel. OoB is often impressive in its own right, but once the novelty wears off you begin to understand that skillful navigation of the skipped room also was entertaining—but is no longer there due to being slower overall.
In some cases (i.e. route or item set optimization) this has nothing to do with glitches, and in those cases it's the job of the Alternative class to host submissions that attempt to restore the missing content that none of the Standard categories cover. But most of the time it's down to restricting the glitch use, and that in itself is common enough to potentially warrant a Standard designation. This category isn't an outlet for making things "less annoying"; that thought doesn't even enter the equation, and it'd be a big mistake to think the staff would ever want to view things in this light. It's rude, if nothing else.
Dacicus wrote:
Back to the topic at hand, I don't see why "Glitchless" would be considered unacceptable as a goal with a separate branch if "Forgoes Major Skip Glitch" is allowed, to use the wording from Wiki: Standard.
Right, and most of the time these would be functionally identical. There is, however, a relatively tiny portion of games that are so exceedingly complex and thoroughly broken that they'd warrant both a glitchless run and a run that forgoes major skips separately. Aria of Sorrow comes to mind (boy, I sure am glad the inbounds all-souls run was restored!).
I'm starting to think this thread was cursed with –10 to reading comprehension.
Moonwalking (assuming it doesn't save any time) is an example of a stylistic choice. We aren't talking about stylistic choices. We're talking about cases where using glitches introduces major gameplay-affecting changes. So major they make people want to see a run without them: either because too much content is skipped, or because the content that isn't skipped is trivialized to an extent that makes the category less fun. Cases where TASers optimize the fun out of the movie are common, and the purpose of this category is only relevant to such cases. The goal of this thread is to come up with some general guidelines and think in advance of any challenges so that it would be easier for us decide in the future how to approach this category to maximize its purpose and fun.
Any purely cosmetic changes are completely irrelevant to this whole discussion. Besides, why would a movie with different stylistic choices but the same final time be published in a separate category? That doesn't make any sense.
But what are potential problems for games where we may try to invent this category from scratch? Do we even need any kind of future proof terms for this?
The main potential problem is mismatched rulesets (which are the definitions for our purpose) between ourselves and the RTA/unassisted community, i.e. what we want to see as the optimal ruleset for the glitchless category vs. what the playerbase and the viewerbase of the game in question wants to see. In cases where there's either no community around the game or at least no universally accepted standard for glitchless runs, and we have to come up with one, there will be situations where others don't agree. In which case we have a choice to either adapt the definition for the game in question or stand by ours if we have reasons to believe it suits a TAS better. I expect this to be decided on a case-by-case basis.
The obvious thing to do to minimize the rate and severity of mismatches is to exclude everything that people most certainly wouldn't want in a glitchless category:
Any and all forms of save/RAM corruption, including overflow glitches.
Level skips that don't involve any valid in-game skip mechanic.
Use of any leftover debug features or official cheat codes.
Out-of-bounds travel for cases where the game character violates solid room/level boundaries (i.e. by clipping or otherwise glitching through them). Situations where the character goes around the boundaries (i.e. by jumping over them, like you do in SMB1 to get to the warp zone in 1-2) would typically be considered fair game, but if it breaks the gameplay too much (as in, say, Serious Sam where you can skip about 1/3 of the game by doing so), it may need to be considered depending on the case.
Those are the hard rules; the things we can easily discard outright. The rest (the "soft" rules) should depend on the game and the impact the glitches have imo. I think generally makes more sense to err on the side of excluding everything that looks sus, but, for instance, I don't think we'll ever need to discuss whether to use mockball in "glitchless" runs of Super Metroid because over the years it has universally been normalized as a movement mechanic as opposed to a glitch. The operative word here is "normalized", as it was a result of decades of community consensus, but in our case we may have to preemptively normalize things based on the gameplay impact as said before.
DrD2k9 wrote:
Consider that some people feel that actions like wall jumping and clipping through walls (as in SMB1 & SMB3) should be considered glitches as opposed to simply being considered optimized use of normal game mechanics.
If we allow ourselves to get hung up on the semantics, the next thing to discuss is whether stabbing a person should be considered murder as opposed to an optimized use of the knife. Your Honor, I only used the knife for its intended purpose! You can always arrive at unintended results even if you limit yourself purely to intended mechanics. Hence, rather than the mechanics, you need to draw the line at the results you want to achieve using them, or at least follow the lines drawn by somebody with authority to do so.
This is exactly why feos is talking about alleviating player/audience concerns as opposed to coming up with rigid definitions. If there's a vocal support for a run that omits something that is far too effective—whether a programming oversight or a design oversight—then it's a "glitch". Let's just go with that to make things simpler for ourselves. We're ultimately a content platform for serving runs audience wants to see. It may result in things becoming vague every now and then, but as far as I'm concerned it's better to present two run categories that the audience wants to see the most as opposed to two run categories that follow the definitions most neatly. Definitions are a convenience feature, not a goal unto themselves.
EZGames69 wrote:
My only issue with making it standard is not every game has their entire speedrun changed just because they don’t go for glitches. If a speedrun for a game happens to be purely glitchless, but has one glitch that saves like 2 seconds (in say a 20 minute run), then would it make sense to have both a normal TAS and a glitchless TAS where the only difference is that one rather insignificant change?
I don't know if it's reasonable to expect anybody to do a new 20-minute TAS for an insignificant change. Sure sounds like too much effort.
In any case I don't see the issue. People (including myself at the time) were constantly fearmongering about site bloat when the site had less than 300 runs total. Now it has over 3000, a full order of magnitude more than back then, and exactly nothing bad happened as the result; in fact, it's been something to celebrate. Gee, the 2007 me must feel like an idiot (and would be right to). If the argument requires you to constantly shift the goalposts of the bad thing you're expecting to happen, it's a horrible argument.
What Mike said is correct; the site has been moving toward accepting more content, and this includes having more categories with restrictions and rulesets popularly accepted in the relevant communities. So if the dominant ruleset for TAS stuff in the Elma community is "no divide-by-zero error", then it shouldn't be a problem to have that as a category here.
The only think I'm not certain about is running individual and custom levels because the site isn't designed for that at the moment, so you can only potentially submit a full game run. But that would already be cool enough.
Combining the Elma community tools with our tools could break the game wide open. Piano roll input editor in particular would be a complete game-changer.
Also, a bit of a tangent, but are there any plans for a new Elma Done Quick?
A couple of years later but finally there are news about this. After more than a decade since the last video it's happening again. The world premiere is planned for 15th July at 10pm Finnish time.
Oh yes, I am familiar with your work on PoP. Didn't know you've made that into a (more) generalized solution since, that's very cool.
I realize it's a horrible workload for a GPU, which, I'm sure, is why nobody has ever seriously considered it, but I'd be interested to know where the limits of this approach are because GPUs allow for just so much better (and cheaper) scaling that it can overcome the lack of speed just in volume. Because, say, if this is just 1/10 the speed of a consumer CPU, we're still more than good to go. If it's somewhere between 1/10 and 1/20, we're still good to go at a big enough scale. Between 1/20 and 1/50 could be problematic, at least in the near term. Slower than 1/50 is where I'd say it's completely infeasible.
So here's a horrible idea. Bear with me for a bit.
Right now, emulator botting is fundamentally a single-threaded endeavor, and CPUs haven't undergone a drastic progress in that department lately (the best consumer CPU you'll find today probably won't even be 1.5 times faster on a typical ST task than my 5.5 years old i3-8350K from 2017 overclocked to 5.1 GHz). So if we want it to handle a complex enough task, we either have to run multiple instances of the emulator and make each instance search through a dedicated chunk of input permutations, or, in some very specific cases, we isolate the game logic entirely and then turn it into a parallelized code to be executed completely separately from the emulator. Both are very labor-intensive (especially the latter, which also requires reverse-engineering and knowledge of a high-performance programming language), don't have a generalized solution, and in the former case still don't run very fast, either.
The fact that emulator code is mostly not parallelizable has been a serious problem for botting and the main argument against porting it onto CUDA or another platform using compute shaders to take advantage of GPUs' massive parallelism. However, that argument has historically been built around the speed of a single emulator instance, which would most likely be slower in this case, and it's a valid argument if we want to prioritize that.
But do we? What if we use it to run multiple cores, each within its own waterboxed instance, all in parallel?
Sure, each one would be slower, but on the other hand, we can run as many as we can fit into VRAM without much (if any) overhead, unlike running them on a >8-core CPU. Assuming a single core instance for a 8/16-bit platform takes roughly 200 MB on average (I just pulled that number out of my ass, don't judge me), and we're using a graphics card with 12 GB of VRAM (a GTX 1080 Ti, RTX 2060-12, RTX 3060, or RX 6700 XT, most of which can be found for a couple hundred USD on the aftermarket), we can fit up to ~60 instances of our core at the same time, with a single interface for managing their inputs. So even if it makes a single core run about twice as slow as it would have on a modern 5 GHz CPU core (out of my ass again), that's still a whopping 30x net speedup for the purposes of botting in particular. And a graphics card with 16, 20, or 24 GB would result in a proportionately larger speedup still, which would make it a really damn good generalized solution in the longer term as VRAM sizes keep increasing at a faster rate than the number of high-performance CPU cores. And then there's the possibility of running 3-4 GPUs on the same machine, and you can see how well it scales in principle. We're looking at overall speedups of at least two orders of magnitude in the near-term: up to 500x could already be achievable with today's technology if my napkin math here is anywhere close to realistic. And from there, we only need a relatively minor step towards a folding@home-style parallel computing network run by other TASVideos members on their own GPUs, each able to pick the games to which they'd like to dedicate their compute resources.
I've avoided the obvious elephant in the room, which is whether that's feasible to implement at all, to which my answer is: honestly, I don't know. But if it is, it's something worth considering, as the optimization problems we're encountering become progressively more complex with both old and new games, so we'll be relying on bots more, not less, over time.
Lol, hi Pearl. :D
Sick run, loved it! I thought for a bit for some potential avenues for improvement, but it doesn't look like any of them compare to simply grazing more (or, to put it more precisely, minimizing the time spent not grazing). So if any improvement comes along, it'd probably come up with more efficient grazing routes that minimize idle time between bullets.
Also, am I to assume you'll be also doing RF2 and/or Jet at some point? I'd love to see either, but particularly Jet, of course.
Team 8's 1-1 and Team 6's 2-2 and 4-1 blew my mind. The permasprint setup on 5-1 was wonderful as well; I didn't consider that method. That is some serious outside-the-box thinking, and a well-deserved win on that account alone.
I'll post more in-depth thoughts and detailed comparisons of my own for all the runs sometime later this week—there's a LOT to discuss there for sure. Technique use was all over the place among the top three teams, and degree of optimization seemed to vary wildly between sections. Absolutely fascinating how different the runs ended up being.
I'd like to once again thank Samsara for the amazing game choice. Who knew an obscure commercial flop would end up such a gem under TAS conditions?
The requirement of having to prove that there is a definitive maximum score. That might work for games where you can easily score high enough to max out a counter at something like 999999, but not for other situations. I never understood why score runs should be judged that way, it's like asking people to proof that the time for a speed-oriented TAS can never possibly go lower.
When was the last time you looked at that rule? I can't find the requirement you mentioned.
I think they're referring to the 2019-era wording on how scoring goals were handled. Which—I completely agree—was silly.
Thankfully, we've already moved beyond that, and the current intention is to move further towards unbinding score attacks from full completion rules and eventually treat score as a standalone optimization metric just like time.
Right, rather than parametric categories to search by, they are curated lists for which runs are selected manually.
As is always the case with significant rule changes, all relevant rejected submissions will be re-evaluated to see if they meet the new requirements; if they do, they will be accepted and published, so there's a high chance that GD will lose some more entries in the near future.
The revamp is meant to open the site to more potential goal choices; the list of newcomer recommendations still depends on the quality and entertainment value of movies rather than their goal choice per se, so it would be an entirely different discussion as to which of them will make the cut.
Dunno about a month, but our team is cutting it pretty close as well, with one member completely unavailable, another quite busy, and the remaining two sharing the time zone, so I'd be fine with any extension if only to give ourselves an extra breather (1–2 weeks would be enough for us). We're putting that time to good use, though; I'm extremely confident in our work.
FatRatKnight wrote:
Though I won't exactly make it that easy, so it'll be some sweet stuff at the top if our team misses first place this time.
Agreed. A normal mode run with warp glitches and a warpless hard mode run would be best.
mklip2001 wrote:
As long as this doesn't count as abuse of a debug code or anything (like the GT Code in Super Metroid), I'm all for it.
The rules have a specific provision allowing cheat or debug features built into the game so long as they're accessed in an unintended way, such as via a glitch. This is exactly one of those cases since the warp room that is normally accessed via a password (which wouldn't be allowed) is instead glitched into.
On another note, I've thought that the inability to smell and taste is a common symptom among coronavirus affected patients. Did I miss something in your post regarding this or this isn't a common observation in other countries? This information came between 2019~2020.
These actually started being widely reported already after I had made my last edit to the post (for example, here's the corresponding edit to the Wikipedia article dated 26 March, a day after I had made my last edit at the time, citing the symptoms as "less common").
There was also some misinformation floating around at the time because the mechanics behind smell and taste loss wasn't well-understood. The initial reports quoted medical specialists saying the reason was concentration of the virus in the upper respiratory tract directly damaging local parts of the tissue responsible for olfaction. This was false. SARS-CoV-2 was later confirmed to be actively neurotoxic much like many other viruses, as well as causing indirect damage to all sorts of tissue via blood clotting (see thesetwo articles for examples). The information on this aspect of it has been very intermittent and took a while to arrive at a suitable level of verification because it highlighted overlooked general mechanisms of viral infections. You might have noticed anticoagulants being prescribed to patients and working extremely well relieving them of symptoms that they normally don't even treat at all (e.g. fever).
I'll need to clean the OP up a little bit and update it with new knowledge. It was mainly intended to provide an immediate digest for people to avoid misinformation and stupid mistakes so I kind of stopped when I thought it had served its purpose. But a lot of it has aged by now.
EZGames69 wrote:
All I can gather from those sources is that Bacterial resistance is caused by many things in human nature, not just modern medicine. So to say that modern medicine is problematic because it causes bacteria to be resistant to antibodies is just misleading.
Medicine isn't; its application is. For what it's worth, antibiotic and antimicrobial resistance is recognized by UN and its affiliated structures as a global threat. Indeed, the primary cause is the overuse of antibiotics because that effectively breeds stronger bacteria at a greater pace than new antibiotic research is able to keep up, and it becomes a race where the stakes are continuously driven up because the bacteria can mutate pretty much indefinitely and the same cannot be said with confidence about our ability to develop new antibiotics. The overuse in question happens routinely in underdeveloped countries, but if we're to look at it fairly, you could probably count the countries where that doesn't happen on one hand. For example, here in Russia, patients with mild COVID symptoms were pretty much at a greater risk of contracting a life-threatening bacterial infection if hospitalized than dying from COVID itself. Hospital infections are very hard and/or expensive to treat because their spread and continuous presence at a hospital is already indicative of their ability to survive standard hospital treatments. One of my friends who barely survived a tick-borne meningoencephalitis was killed by an AMR infection during recovery because the treatments did nothing to help the weakened immune system. These things are a real threat but they don't receive the attention they deserve.
AMR's sister issue is pesticide resistance which, similarly, breeds superweeds, which is another pressing concern because regular pesticides are by themselves a threat to ecosystems and human health, and adding a potential global food supply crisis time bomb to the issue doesn't help it at all.
pirate_sephiroth wrote:
This virus spreads violently fast, however the mortality is very low.
Low compared to the most deadly viruses out there, sure. It's actually crazy high compared to any other globally spread virus of the last hundred years, give or take. I mean, how many viruses you know that have caused excess mortality of at least 3 million people worldwide in a single year? That is approximately 100 times more than the average annual fatality rate of flu and more than 10 times the annual fatality rate of battle conflicts worldwide. In fact, it's about close to a fatality rate you'd expect from a world war. I mean, sure, it's not the end of the world, but on the other hand, people in general wouldn't start worrying about any sort of the actual end of the world until after too late. There's little use in worrying at the point where you can't change anything anymore. That's the back side of skepticism.
pirate_sephiroth wrote:
Now you remember a certain country mysteriously having a surplus of personal protective equipment just ready for exporting at very low prices, for no reason at all?
If you mean China, they were already the world's leading supplier of PPE and had the largest percentage of population using it regularly for manydecades. And unlike all other major industrial countries, China is also uniquely equipped to shift its production efforts in whatever way its government commands. There is a very good explanation why China was able to get ahead of other countries' manufacturers easily. The perks of centralized control, if you will.
pirate_sephiroth wrote:
What about the skeptics who will think the media companies are just exaggerating again and won't do anything until it's too late?
I think you're overestimating the power of the media companies. While it's true that they exert a huge pull over the population, it hasn't been remotely enough to get people in some of the most affected countries to vaccinate quickly and avoid engaging in behavior promoting faster spread of the virus. Some of this was due to conflicting messages, but otherwise it's just because it's simply not as powerful as some like to portray.
pirate_sephiroth wrote:
Also "flatten the curve" was a hilarious meme.
A lot of people died in places where hospitals became overcrowded and doctors had to choose whom to save. Aside from excess deaths that could've been avoided, it's taken a heavy toll on the doctors' mental health. Not very hilarious if you ask me.
I don't understand this sentence (the part after the dash). We don't expect emulation accuracy to get worse over time, so we don't explicitly invalidate gains new movies get from worse accuracy. Implicitly we do ignore such differences, but why does it affect priority of resyncs?
Not of resyncs per se; the way we treat emulation differences has made me think—perhaps mistakenly—that even if, say, there were two movies submitted independently and at the same time, with no discernible difference in gameplay, the movie made on a more accurate emulator would be preferred even if slower due to extra loading lag and such. If this is a correct impression then there is also no reason not to give priority to a more accurate movie if it is available.
feos wrote:
We don't disallow other people from resyncing movies to work on console. There's no explicit rule for resyncs, even though this thread was made so we could have one. The situation of console resync being added only happened once, and we can still tweak it as we need.
What we explicitly disallow (EDIT: I guess the better word would be discourage) right now is submitting such movies, but what I mean more specifically is having an updated movie be the base of a publication regardless of the procedure through which it was offered. There are some published movies resynced for console verification that have no gameplay improvements in the resyncs themselves but none of them are anything more than a sidenote on an existing publication at best.
Both the way the rule is worded right now and the way publications of runs later resynced to console are presented makes it look like we don't really want this kind of contribution and only reluctantly acknowledge it. I'm not saying that's how we treat it in reality—but that is how we project it outwardly via our documented policies and behavior. In this respect I also want the rules to read in a more welcoming way even if they don't exactly lead to a significant difference in operation. (Same motivation as removing references to words like "proper" or "serious".)
feos wrote:
Mothrayas and adelikat disagree with changing authorship here (even to co-authorship).
That's actually not what they're disagreeing with.
If you reread my initial post, I'm describing two different situations there: one where a movie is resynced without an attempt at improvement (in which case no change in authorship occurs at all) (1), and one where an improvement is attempted but sufficiently proven to be unattainable (2).
TiKevin83's submission is situation #1 for which no change of authorship is being discussed at all. Mothrayas and adelikat did not and could not disagree with co-authorship under the conditions outlined for situation #2 because that wasn't even set up for discussion at the time. What was being discussed was closer to situation #1.
What Moth explicitly disagreed with and dedicated an entire paragraph of his post is removal of the original authorship credit, which is not at all what I'm suggesting at any point, and would never do.
feos wrote:
How do we verify this?
On a case-by-case basis in a similar way as we handle other uncertain situations: by relying on the author's research and judge's discretion. Basically, what a judge would be trying to determine in this case is whether the new author's research offers a deep enough insight into the game that it proves they would've found an improvement if they were any, and hence warrant a joint credit for the work they've done. If it only relies on already-existing research, it would simply be treated as a regular resync; i.e. rejected and used to update an existing publication with a mention in the publication text and such if other conditions discussed earlier are met.
In other words, in this situation the new author already needs to demonstrate effort worthy of full credit to earn just the joint credit. Think about it from their perspective, too: when they set out to improve a run that falls under the situation we're discussing they don't know beforehand that they won't be able to find an improvement, yet they still put in all the work that would be necessary to find one. It's not their fault if there is nothing left to improve. But their effort still does contribute something meaningful despite that, so in my opinion a co-authorship is warranted in such case.
feos wrote:
I HATE this. We do not, ever, unpublish movies. We do not erase them from the database. If it was created, accepted, and published, it is a valid verified record. We are an archive of records among other things. We want to be persistent and reliable. And the work that was invested in it should not be undone. I'm scared to even think of other potential "reasons" to erase a movie from the site. The only reason this should ever happen is accidentally using an entirely wrong movie or having a movie containing illegal data in it somehow. Erasing it doesn't only say it's bad to have it on the site (we backwards-obsolete impossible movies that were proven to have relied on emulator bugs), it says it's dangerous to still host it! There's no reason to act like the pre-resync movies are that bad.
Okay, that argument itself is entirely fair, but I think it's somewhat misguided. The way I see it, we're already doing a thing that is very similar with the way we replace submission files when an improvement is made in the time window between submission and publication. As far as I'm aware, those do, in fact, get erased—or at least they aren't available in any way a regular user (or even one with slightly elevated privileges like myself) can access. I think we need some kind of consistency between this, because a resync to fix emulation issues without affecting anything else is, to me, no different from trimming unnecessary input at the end or something else like that: a minor fix not affecting the movie as a whole or its creative choices in particular.
I think it's entirely fair to have everything available in history as long as the superior version is the one the publication is based on. I'd love to hear more opinions on this from movie authors as well, but I think it's a very reasonable take.
I can't really express my potential fear of someone misusing this system who would try to resync very old movies which probably gets new windows of possibilities which the previous TASer didn't had as the emulator wasn't published at the time.
There is no real misuse possible with this because a TAS that is merely resynced without any sufficient evidence that no further improvements to it are possible will retain only the original author's credit, and everyone else will also benefit from a more accurate representation of the game in the TAS. Even when there is evidence that no further improvement is possible, the resync has to solve noticeable issues coming from emulation inaccuracy, and the original author will still keep their credit in any case. The original author is never harmed by this, and the audience wins every time.
Some examples of what can motivate people to resync TASes without remaking them would be console verification (when they're doing the verification themselves; this has actually happened multiple times) and TASers working on emulator improvements (Alyosha has been brought up before); in other words, situations where it's a byproduct of a greater goal.
Of course, people aren't going to be lining up to do this; it's still only going to happen once in a while. I'm just not okay with rules explicitly prohibiting useful contributions when there's really no harm in them.
Nach's stance is that obsoletions must contain actual gameplay improvements, so resync submissions shouldn't be accepted. But he prefers another way of recognizing efforts like this: adding an updated movie to the publication. That way, the current publication persists as perfectly valid (because not syncing on console doesn't inherently mean the movie is invalid, and console sync has never been a requirement), and the publication also persists with all its content. And at the same time, the resynced movie gets the proper place right in the publication module, duly supported by the site as an update of (still) the same movie.
This option doesn't seem to have any downsides, and in future, it wouldn't even need new submissions. But actual regulations will be decided later, when Nach is around next time.
This subject came up recently as I've been going through the Rules page to fix wording and inconsistencies. For the record, this is how the relevant rule looks right now in entirety:
If time is gained from using a more accurate emulator but gameplay hasn't been improved, such a movie will be rejected. However, if improved emulation introduces more lag, extends the cutscenes, or slows down gameplay in some way, yet the actual gameplay has improved, such a movie will be considered a valid improvement.
To reformulate, this rule disallows submitting resyncs and gives preference to longer but more accurate movies as long as there are gameplay improvements.
If a resync is warranted without redoing the movie from the ground up, the current practice as quoted earlier is for the authors themselves to upload it if they decide to redo it on a more accurate emulator, and for that movie to be added to the current publication without changing the encode or the final time listed on the publication page.
There are several issues with this.
1. Accuracy is downplayed. Despite being a more faithful representation of the game, which should always be preferred with all else being equal, the resync is essentially relegated to being a sidenote—even though in theory it should take priority since the rules invalidate gains made thanks to emulation inaccuracies. If there is an easy way to achieve this without remaking most of the movie, we have no reasons to disallow it.
2. Nobody is allowed to offer a resync on behalf of the author (under the original author's name, of course) if they aren't around. That situation has, in fact, happened in the past, when adelikat submitted a resync of Phil & Genisto's Circus Charlie in their name, having failed to find meaningful improvements. And it was accepted because the previous run was made on a horribly inaccurate, long-deprecated emulator, and there was an effort going on to replace all runs made on it with something better. This situation is liable to repeat in the future as TASes become better-optimized, and we'll likely run into it whenever we orchestrate new efforts to get deprecated emulators off the site and find other movies without known improvements.
3. It creates a potential for a situation where a submission can be rejected or be stuck in limbo simply because gameplay changes resulting from using a more accurate emulator are too minor or uncertain to be meaningfully classified as improvements (e.g. different RNG values), regardless of what name it is submitted under.
I propose changing it in the following way:
1. Minor resyncs where relatively few actions need to be taken to achieve sync on a more accurate emulator can be added to the existing publication as per the current practice, but the time and encode should be changed appropriately and the old movie file removed from the publication page. Having a less accurate movie made on a deprecated emulator alongside a more accurate one serves no functional purpose. A link to it can remain in the submission message for posterity. Such resync can be offered by whoever as long as the credit remains with the author(s) of the original movie. This addresses concerns #1 and partially #2.
2. Situations where a different author had genuinely tried to find gameplay improvements but failed, yet their effort resulted in a different (more accurate) time compared to the original movie, this is best done via a separate submission, and credit can then be shared between the author(s) of the original movie and the author(s) of the attempt at improvement. This addresses concern #3 and the other half of #2.
3. Once a movie is confirmed to sync on console, no future resyncs for it are necessary.
The rule would then be formulated as such:
If an improvement to an existing publication is made using a more accurate emulator, the timing difference coming from emulation accuracy will be discounted, and judgment will be made according to improvements in gameplay. Situations where a shorter movie would be obsoleted by one that is slightly longer because of the more accurately emulated lag, load times, etc., should thus be expected.
A submission made on a more accurate emulator that fails to improve upon an existing publication in gameplay will be rejected. An exception can be made as long as all of the following conditions are met:
1) the existing publication has no documented improvements;
2) the author of the movie intending to replace it has failed to find improvements but can prove their due diligence in trying;
3) the change of emulator has lead to fixing immediately evident presentation issues (wrong visuals/sound/game behavior) and/or made it sync on console.
The authorship will be shared between the authors of both movies in this case.
Note that if you would like to offer a resync of an existing publication on a more accurate emulator in order to fix said presentation issues and/or make it sync on console without looking for other improvements, you're free to upload it to Userfiles and notify a judge. If it is deemed warranted, the file will be used to update existing publication directly without change in its authorship.
This is Dragon's Lair, except the lair is Titanic and the dragon is Mode 7. Otherwise just as glacially paced. I definitely would've preferred the English version as well just for more readable cutscenes, though.
What happens to the character after he bangs the roof with the pipe?
