TASVideos

Posted: 4/19/2023 1:26 PM

Quote

DrD2k9

He/Him

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

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

MrTASer wrote:

Should I end input at the frame which could barely make the car complete a lap or at the frame where the lap completes fastest? When I stop input on frame 4573, the transaction begins at frame 4631. When I stop input at frame 4587, the transaction begins on frame 4623.

This is a stylistic choice. If you do the one with slightly longer input that finishes the race faster, and someone submits a run that was identical except with the shorter input at the end; it would not obsolete yours. They would have to find other improvements in addition to simply stopping the gas earlier on the last lap.

Posted: 4/18/2023 4:33 PM

Quote

DrD2k9

He/Him

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

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

BlackWinnerYoshi wrote:

While trying to make my own version, I found additional RAM addresses:
0016 lap number
0017 laps
001B frames
001C seconds
001D tens of seconds
001E hundreds of seconds
Which means you can complete three laps of the first track on Hard mode in 16.32 seconds. Except you can select six or nine laps, should the maximum be chosen here as well?

It's not necessary to select a higher number of laps for an any% run. A run that chose to do more laps may potentially be acceptable, but it would depend on whether or not the staff/judges felt that a TAS of the game with races of 9 laps each would be considered Full Completion as a distinct branch. If so, it may be publishable along side an any% run. If, however, it was decided that 9 lap races weren't distinct enough for a Full Completion branch, the shorter run would be the desired run for publication.

Posted: 4/17/2023 1:18 PM

Quote

DrD2k9

He/Him

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

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

MrTASer wrote:

Thanks for pointing that out. I will make a complete TAS as soon as I can do. Should I cancel this submission?

You can if you want to. But it’s not absolutely necessary, if you think you’ll be completing it in the near future. I can update the submission movie with the completed version if you upload the new one to userfiles.

Posted: 4/16/2023 7:48 PM
(Edited: 4/16/2023 7:51 PM)

Quote

DrD2k9

He/Him

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

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

MrTASer, What you have presented here looks pretty good from a standpoint of optimal play/movement. Unfortunately, I have two problems with this run that I think you should consider addressing before I issue judgement: 1) This run is incomplete, in my opinion.

There are 4 different tracks selectable from the main menu. I feel that all four tracks should be completed to consider this game 'complete'.
As this game isn't endless/looping, but also doesn't have a technical 'endpoint', a suitable endpoint needs to be determined.
Completing only 1 track just seems to ignore the other tracks.
Completing all 4 tracks would exhaust the unique content of this game and make for a more concrete 'endpoint'.

2) Even the one track that is presented is improvable (in a way).

On the main menu, three difficulty levels are offered: Easy, Medium, and Hard--with Medium being the default. Harder difficulties allow for the car to go faster; thus yielding shorter potential race time.
Here's a screenshot of a test I did of the same track as this submission except using Hard difficulty. It shows that it's possible to beat Track 1 by 5 seconds over the submission.

While doing the run on Medium (default) difficulty isn't an outright reason for rejection; a run that did use a harder/faster difficulty would potentially obsolete the lower/slower difficulty. So, if you're goin to be adding the other three tracks, it seems prudent to go ahead and update to Hard difficulty for this track also. Something to remember for your future TAS work is that going immediately with a game's default settings is not always ideal when aiming to create an optimized TAS. Always strive to do some basic research on the game you're wanting to TAS before actually starting to make your TAS; then, while actively TASing, try different options/approaches to determine which methods will truly yield the fastest/best TAS.

Posted: 4/13/2023 6:54 PM

Quote

DrD2k9

He/Him

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

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

Auto renewal isn’ta bad idea. We could try that first and see if it helps better than the current untimed limitation. And if we see the same or similar problems to what we have now, we could then try eliminating the role outright. a timed limitation may be more incentivizing for a new TASer to improve than an indefinite limitation.

Posted: 4/10/2023 7:26 PM

Quote

DrD2k9

He/Him

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

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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 (2056)

Joined: 8/21/2016
Posts: 1011
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.

Posts for DrD2k9