TASVideos

Posted: 4/10/2023 7:26 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Just a thought to consider regarding “unhoarding”… Sometimes what may appear as submission spam is simply someone finalizing a number of runs of various games all around the same time. That author may have worked on some of those games for over a year. But because they were working on multiple games simultaneously, they coincidently finished multiple runs in short order. Then even if they uploaded/submitted nigh immediately once each of the runs were ready, it appears as spam on the workbench when it’s really just coincidentally close completion of the TASes in question.

Posted: 4/7/2023 1:36 PM
(Edited: 4/7/2023 1:36 PM)

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Is your goal to have Mario die as quickly as possible? Or is it to have the minimal input to get a game over? Because if it’s the latter, you literally only have to press Start one time to start the game. That’d be the shortest input to game over.

Posted: 4/5/2023 4:02 AM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

FractalFusion wrote:

For a moment, I thought it was related to [4380] VEC Spike by EZGames69 in 04:31.04. Now I wonder how many more games named "Spike" there are out there.

I’ve got a WIP of Spike’s Peak for A2600.

Posted: 3/31/2023 9:18 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

LogansGamingRoom wrote:

when i try to go on the home page, it says this: System Error An unexpected error has occurred. The information has been logged and will be investigated as we continue to improve the reliability of the site. Status Code 500 - Internal Server Error

The problem is being worked on.

Posted: 3/31/2023 9:14 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Ok, people. I need some feedback. An "any%" run of this game has previously been submitted and rejected due to the game version. To put it as succinctly as possible: though some considered Original Edition to be a separate game and desired publication along side basic NES Donkey Kong, the ultimate judgement was to not accept Original Edition for its own "any%" run due to the extra stage content increasing the overall time, and to just leave NES Donkey Kong as the "any%" run of the game. That judgment also deemed that an "all items" run should use Original Edition over NES Donkey Kong as it showed getting more items due to the additional stage. So in effect, the decision meant that the site (at least at that time) was going to consider both games as different versions of the same game and not allow side-by-side publications. I'm asking for thoughts on revising this position. FWIW, the discussion at the time centered around 2 things: 1) if the games were separate or not and 2) authorship. For my personal opinion, with the recent loosening of rules as well as changes from a tier based to a class based publication system, I feel that the additional stage in Original Edition offers enough different content to warrant publishing both "any%" and "all items" of both games along side each other even though all other stages are (or nearly are) identical time wise. That said, if the general consensus is to only keep one of these games for each branch, I'd suggest Original Edition for both "any%" and "all items" in order to show the more 'complete' version of the game. TL:DR I think we should publish both NES Donkey Kong and Donkey Kong: Original Edition along side each other, but am looking for feedback from the community before making a final judgement on this submission. This submission is otherwise acceptable from an optimization standpoint.

Posted: 3/24/2023 3:26 PM
(Edited: 3/24/2023 3:41 PM)

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

OtakuTAS wrote:

Score attack/endless games must complete to game to where there is no new content.

It is no longer a hard requirement to complete all new content in endless games. We recently changed the rules to only require 1 loop of looping games even if there is new content beyond. Pertinent Rule:

https://tasvideos.org/MovieRules wrote:

If there's no clear ending, end after completing the first full game loop. However you may play further and end after any of the following: All unique content (enemies, level layouts, game mechanics, etc.) is exhausted and completed. The loop with the hardest in-game difficulty (enemy speed, AI, etc.) is completed. In games with a score counter, you may end when you reach the maximum score the game allows.

In other words, there are multiple potential end points for looping games. So the main thing to check with this particular game is how many courses are included in 1 loop of the game. Finishing all those courses would then be the minimum requirement for completion. EDIT: Another consideration is, when the looping starts, the loop may not go all the way back to the first stage. A game may only loop later courses. For example: Game A has 5 stages, begins looping after the 5th stage, and loops all 5 stages: 1-2-3-4-5-1-2-3-4-5-... Game B has 5 stages, begins looping after the 5th stage, but only loops the 3rd-5th stage: 1-2-3-4-5-3-4-5-3-4-5-... In both of these scenarios, only 5 stages would need completed to have the minimum required 1 loop. But for authors wanting to do one of the more complete options, runs completing more than 1 loop would be a different number of levels needing to be completed. If both games stopped adding new content after the 2nd loop, Then Game A would require completion of 10 stages to exhaust new content, while Game B would only require 8 Stages to do the same.

Posted: 3/22/2023 3:54 PM
(Edited: 3/22/2023 5:36 PM)

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Deleted...I shouldn't have gotten into this.

Posted: 3/21/2023 10:53 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Regarding rerecord counts in submissions: Spikestuff makes an excellent point regarding rerecord counts being used to validate/explain why a poor/high quality movie is poor/high quality. And this particular use of rerecord counts (assuming they are accurate in the first place) is a very valid reason to (at minimum) maintain keeping the rerecord count in emulator input files. Yet, I'm inclined to agree more with feos regarding listing of rerecord counts; in that we limit publication of rerecord count only to movies where the author explicitly requests it. Specifically, listing rerecord count in submissions provides potential viewers an opportunity to pre-determine whether or not they think a submission will be of poor or high quality. This anticipated quality level may then bias their actual viewing of the run and cause them to deem the run either as having more/less quality than they would otherwise have done had they not started with a preconceived expectation. This could occur in a couple different ways depending on what the initial expectation is. 1) RR count is low and quality is assumed poor by the prospective viewer; who then deems a truly poor quality run as even worse than they would have otherwise, or a good quality as significantly higher than they would have otherwise because it significantly exceeded their expectation. Beyond this, it's also possible that a low rerecord count may bias a potential viewer's expectations so severely that they may choose not to even watch a run that they may otherwise enjoy and/or be impressed by. 2) RR count is high and quality is assumed good by the prospective viewer; who then deems a truly good quality run as even better than they would have otherwise, or a poor quality as downright awful because it didn't come close to their expectation. Bottom line, rerecord counts should never be used to set one's expectations for a submission. They should ONLY be used, as mentioned above, to explain why a movie is the quality that it is. Rerecord count alone should never be used as a reason to NOT watch a movie. Regarding inclusion of rerecord counts on official publication encodes: As published runs have already been deemed of high-enough quality to be published in the first place, including the rerecord count here doesn't really serve much purpose, in my opinion. I can't really see any particular pro to having it listed in the encode. I can however see some potential cons: 1) A high/very high rerecord count may potentially detract other TASers from trying to beat the current publication. This could theoretically limit discoveries from being found because no-one looked into the game further. 2) A low rerecord count may unfortunately dupe a TASer (particularly newer TASers) into thinking that not much work was needed for a current publication and that they may be able to beat it easily. Then when they actually get into the process of TASing the game, they become discouraged for not being able to beat something they expected would be easy to beat. 3) Having rerecord count listed on publications provides for a method of competition that really shouldn't be a method of competition on our site. Some TASers may want to have the highest count, others may want to have the lowest. I recall someone a while ago in the discord server effectively boasting about making a TAS with legitimately zero rerecords because they seemed to think that was something to be proud about. (Not that there's anything wrong with being proud of any legitimate accomplishment, but it was a perfect example of the wrong view of our site). Our site is based primarily on optimization quality with a secondary emphasis on entertainment...not on how simply/complexly one achieves that goal. Regarding rerecord counts in general: I primarily don't put much stock in the values presented due to issues of accuracy/tracking including (but not limited to): emulator crashes, using multiple project files instead of branches within one project file, and manual editing ability of the input file itself. A rerecord count is only truly comparable to another when it's regarding the same game, and then only when both movies are being authored by TASers who hold equal knowledge of the game prior to starting the construction of the TAS. Any difference in knowledge will impact what one TASer does over the other and may result in more/less rerecords due to said knowledge. The discrepancy between rerecord counts then wouldn't be a fair comparison of actual work put into the TAS. Comparing rerecord counts of one game to another makes no sense whatsoever. For one game, 10,000 rerecords may be quite a lot; while for a different game, 100,000 rerecords may be miniscule. Low rerecord counts don't mean poor quality. If a game is simple enough to understand from an optimization standpoint, it may not take many rerecords to produce a truly optimized run (Duck Hunt: Game A). Likewise, high rerecord counts don't mean high quality, they just mean stuff changed a lot. It's absolutely possible to spend thousands upon thousands of rerecords optimizing a sub-optimal route. All this shows, in my opinion, that the value presented by rerecord count only holds true meaning after a movie has already been watched. And only then as a data point aiding in clarification on why the resulting movie is the quality that it is. For this reason, I feel that if someone truly feels they need to know the rerecord count before watching a run, the impetus should be on them to look it up from the input file. We shouldn't blatantly provide it ahead of time. TL:DR I agree with feos. Going forward, we should eliminate public display of rerecord count on submissions and publications' encodes unless explicitly requested by the author in their submission notes. I don't feel it's necessary to retroactively change all current/obsolete publications (not that we couldn't...someone may just be really bored someday and want something to do). All that said: If rerecord counts are maintained, given the inherent issues I have with the statistic, I see no good reason to continue truncating botted rerecord counts. To me, a rerecord is a rerecord regardless of how that change was produced. So if we are going to keep them around. I feel we should stop automatically reducing botted runs to 0 rerecords (or any other arbitrary number just because that's what the author believes they did manually).

Posted: 3/13/2023 7:39 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

WhiteHat94 wrote:

Gryzor (Contra). Port of the arcade version. I used spread the whole run but I think Laser is potentially faster, tho you would need to be much more precise with it. I abuse deaths in the final stage cause it seems much faster than fighting the bosses. RTA run - https://www.youtube.com/watch?v=_VwI449-JaI

I started a TAS of this a while back. And IIRC, I was using laser. I might need to go dig that out again.

Posted: 3/6/2023 6:49 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Nice work with the improvements so far. I still think there's more potential, so I'm going to go ahead and set this submission status to "Delayed" and see if I can't help more directly with further input improvements. If I can find more, I'll un-claim this for judging. I'll see if I can find you on discord and touch base.

Posted: 3/3/2023 5:23 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

enderpal7. I've come across a couple details that will improve this run. None of them, at this point, would result in rejection. But I wanted to check with you and see if you wanted to implement these things before this submission is fully judged. Specifically: 1) You can start the game 5 frames earlier (on frame 352) and clear the intro text faster (on frame 375). This will get into the first stage faster. 2) As you've already mentioned in the submission notes, killing unnecessary enemies adds time to the run due to the end-stage score tally. You kill an unnecessary enemy in stage 1. This can be removed and improve the time. 3) It's not intuitive, but in the Space-Shooter stages shooting actually delays the end of the stage. I'm not sure exactly why this is the case, but I'm guessing that shooting somehow affects the game's autoscroll code. So I'd recommend eliminating all shooting in these stages (except the final one which obviously require shots at the end to finish). 4) There are also a couple places where movement optimization can be improved (jumping over one of the volcanoes in stage 2 for example). Unfortunately, changing the above stuff will impact movement sync so some movement improvements may not still be valid after resyncing. Hitboxes are weird in this game. Just let me know if you want to update the run before it's judged, or if you want it judged as is.

Posted: 3/1/2023 1:50 AM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

signupredir26, What is the primary goal of this run? Is there something about this that is meant to distinguish it from our current publications as a different branch/goal other than just beating the game?

Posted: 2/26/2023 12:51 AM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

It would ultimately depend on how the game is coded and how the answers are stored in that code. Some games do have the answers directly coded in with hex values being equivalent to a specifical letter in the alphabet. But to my knowledge there's no generalization of this practice for similar games.

Posted: 2/18/2023 4:06 AM

Post subject: Review

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Review/Snipe: I was able to get this to sync with ROM Venice Beach Volleyball (AVE) [!].nes which is the same hash. While this run does beat the games of volleyball quicly by serving only ace serves, unfortunately, I was able to find a much faster way to do this than what is presented in this submission. Instead of serving on the last possible frame, if one serves on the first possible frame, an ace serve occurs as well. I have submitted a run of this improvement. I'm sorry, ShesChardcore. I'd recommend cancelling this submission.

Posted: 2/18/2023 1:33 AM
(Edited: 2/26/2023 9:36 PM)

Post subject: Review

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Review: I couldn't find a ROM that matched the SHA1 hash in the .bk2 0B6D75BCC99D34A42CD58558CB555C6A80ACC263, but the run still syncs on one with this hash EE3603417CCB2058866B6C16396503609EF272AE. (headerless hash = A017A0A0AEE71FEA7BCFCB5D889E710516AB330C) I couldn't find any further improvements. This run looks solid and is an improvement over the current publication.

Posted: 2/17/2023 4:32 PM

Post subject: C64 Desync (loading related?)

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

copy of github issue: https://github.com/TASEmulators/BizHawk/issues/3563

Summary I have had a number of instances where TASing using the C64 core results in desyncs after TASing a while and then clearing greenzone. Specifically, I'll load/run a game and begin TASing. Then after clearing greenzone the game will load in differently causing a desync for inputs beyond the loading process. I'm wondering if this has to do with changes in input during loading and/or savestates during loading affecting the Loading process of the games, but I don't know how to describe much beyond this. I can say that nearly every time I've had this occur, the loading time after clearing the greenzone appearss to be faster, but not always. I've only ever TASed in BizHawk using TAStudio, so I don't know if anyone donig classic frameadvance TASing would also experience this issue. In discussing with NYMX, he has also seen this issue. I probably should have reported this issue before, but wasn't sure exactly how to describe it. I'm not even sure what I have described is enough for the devs to go on. Repro I unfortunately don't have a way to definitively reproduce this bug. Soemtimes it happens, sometimes it doesn't. Output There are no error codes associated with this bug. Host env. -I've had the issue with multiple host computers from different manufacturers (MSI, Dell, HP) with both AMD and Intel processors. -I've seen this issue over multiple versions of BizHawk. I'm fairly confident I've seen as far back as version 2.0, but I can't remember exactly when I first encountered it to know if I also saw the issue in 1.x.x versions.

Posted: 2/13/2023 8:28 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

I personally don't see a problem with resetting the FRAMES variable usign this POKE command in either ZXS or C64 runs/TASes. To me, this is akin to pre-setting the RTC clock on other systems in order to manipulate RNG--which we currently allow (DOS, some handhelds, etc). The key to allowing something like this for C64 and ZXS, in my opinion, is that the POKE command must be performed before the LOAD command. If it was done after the LOAD but before a RUN command on C64 (and possibly ZXS, as I'm not as familiar with that system), the POKE could potentially modify what the game has written to RAM, which would be more like cheating as the game is already (at least in part) loaded into memory. Therefore, (theoretically) any RAM location could be manipulated by a POKE command prior to loading a game. When the game loads it will either overwrite whatever data is in RAM or ignore it. Any leftover/ignored RAM not specifically set by the game could theoretically be any value, and thus fair game for pre-load manipulation. A pre-load POKE command wouldn't modify the game in any way but simply change pre-load RAM status. If the game reads any of this pre-load RAM information, I see no reason why such modification of that RAM shouldn't be allowed. Ultimately, the site staff will have to make this decision though. FWIW, the console verification of my Gameboy Donkey Kong run required a separeate program to be run first to initialize the RAM (that's not directly initialized by the game) to a specific value to allow RNG to match what was created in BizHawk. Off the top of my head, I cant currently remember if BizHawk pre-initializes all RAM values to 0xFF or 0x00, but the initial RNG seed for Donkey Kong is pulled from a region of RAM not initialized by the game itself--which could be any value on a real system. The separate program just made it match BizHawk for console verification reasons.

Posted: 2/10/2023 1:20 AM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

GJTASer2018 wrote:

"Plexar was here" - I wonder who or what this "Plexar" is. None of the sources you used seem to mention that message, and neither does the Digit Press database. GameFAQs shows part of the message in their image gallery on the game, but no one seems to have asked about it there. Even trying to look at the archive of GameWinners doesn't seem to yield anything. Do you have any idea what this message is about?

It’s graffiti. http://manillismo.blogspot.com/2010/12/plexar-was-here.html?m=1

Posted: 1/31/2023 10:36 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Simply becasue we already accept DOS stuff, that might be a version to consider.

Posted: 1/25/2023 4:20 AM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Precedent regarding not using level select codes from the Movie Rules before they were simplified:

No skipping to the end with a password The point is to demonstrate how quickly a game could be beaten if the player had superhuman abilities; skipping major sections of it with a password defeats the purpose.

Granted, humans can use level select passwords/cheat codes...so does TASing with these options simply show superhuman ability of using those options? Personally, I don't think intended level select methods should be allowed in most cases (this one included), but ultimately the staff/judges will have to make a decision on this one. Now if a glitch were abused to skip the levels, that's a different situation. For what it's worth: this run, as presented, looks pretty decent at a cursory glance and is relatively entertaining. If the judge/staff decide the level skip is acceptable, I don't readily see any other reason to reject this submission.

Posted: 1/1/2023 12:41 AM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

I'm seconding ShesChardcore. Amazing level of quality production from a first year.

Posted: 11/26/2022 7:02 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

feos wrote:

But we can still have guidelines on what is most likely a videogame, and what is most likely not. For example, a videogame requires repeated player input to advance. It also has some kind of gameplay, usually posing a challenge, a way to lose and to win. What else?

Just a brief comment on winning/losing: some games (a number of adventure games, for example) cannot actually be lost, aside from the player just giving up because they can't figure out how to win. That said, the vast majority of applications qualifying as "games" would still retain some sort of win condition (assuming one accepts our site's derived win conditions for looping games).

Posted: 11/12/2022 8:09 PM
(Edited: 11/12/2022 8:17 PM)

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

Firstly, I want to say that I've been waiting for a full TAS of this game for a while now, and had even considered attacking it myself. Review: Syncs on FCEUX 2.2.3 (yea I should probably upgrade this sometime soon). Desyncs on BizHawk when converted to .bk2 - Even when adjusting the first few inputs to get the first stage starting correctly, desync occurs by the end of the first stage. I'd be concerned that trying to fuly re-sync this for bizhawk may be a major challenge with RNG manipulation. Full transparency, I did not watch the entire run at normal speed, I watched it completely at turbo-speed. From what I saw, the run looks pretty solid overall. Regarding optimization: Since the game limits the collapse of buildings to one-at-a-time, optimization is effectively going to be limited to getting the first building falling as fast as possible, then attacking the remainign buildings to be ready to collapse by the time the first (or previous) is done collapsing. A cursory viewing seems to demonstrate that this is accomplished on most, if not all, levels. For anyone familiar with casual play of this game, it will be immediately noticalble how little damage is taken. This aspect of the TAS alone makes it superhuman. The only improvement I can imagine would be finding a stage where it may be possible to get a different building collapsing earlier. Unfortunately, I anticipate that this would affect RNG and require full redo of everything beyond that stage. _{If I have time before a judge ultimately decides on this submission, I may look into going through stage-by-stage and seeing if I can get differnt buildings toppling earlier, but I'm pretty limited on time right now.} One other possiblity for improving the run might be adding the 2nd player. Normally speaking, a 2nd player wouldn't speed anything up in regards to toppling buildings due to the on-at-a-time building collapse rule. However, if there are stages where Player 2 can get a building toppling faster than Player 1 can due to proximity of the building to the right hand side of the screen, it would yield a faster overall TAS. This would obviously require a complete redo of the game using 2 players. OR, if it would be acceptable, use the "join a game in-progress" feature to use this run as a base and join the 2nd player in just before the first stage where the first right hand building collapse would be faster. Personnally, I think just starting with 2 players would be the better/more impressive option. I may do a more in-depth review of optimization of 1st builidings later on if I'm able. I may also consider doing a 2-player run myself someday. I would have made a temp enocde if I could have gotten a bizhawk sync, but I couldn't. And I always seem to get crappy audio when dumping temp encodes from FCEUX, and I don't have time to troubleshoot that right now.

Posted: 10/25/2022 10:06 PM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

feos wrote:

I wonder if there are other icon options, something more default (but no less important).

What about a D-pad or joystick? They're pretty standard for most video games (with some exceptions like PC mouse/keyboard), as being able to actually control one's video game is pretty important. Added benefit of not being associated with any one particular game/series. We'd then have: A D-Pad for standard goals A music box for alternate (artsy) goals A star for the special runs as they already signify

Posted: 10/12/2022 4:56 AM

Quote

DrD2k9

He/Him

Editor, Experienced Forum User, Judge, Published Author, Expert player (2120)

Joined: 8/21/2016
Posts: 1032
Location: US

andypanther wrote:

Would it really be too much to ask if we required these types of submissions to work with nothing more than the unmodified game,...

If the primary purpose of these types of runs were to be submissions on the site, then that would be a restriction worth considering (though we already allow runs of ROM hacks, which are essentially modified games). It would also make sense to require full adherence to the current site rules, IF the primary intent was submission. But, while this run has now been submitted, the primary purpose of its creation wasn't to submit to tasvideos.org. It was first and foremost created to be presented live as a form of entertainment, art, and TAS showcase. The perspectives against having these kind of runs allowable on the site seem, to me, to center around the issue of treating them as if they were any other typical submission that was created for the primary purpose of being submitted to the site. We must realize that these aren't typical submissions. They shouldn't be judged via the typical judging process. Nor should they get a typical publication as with the main runs on our site. But none of this means that we can't/shouldn't somehow acknowledge these runs and the awareness/promotion they provide to the TASing community. They need a place somewhere on our site.

Posts for DrD2k9