Yeah it is after a reset, should be good. Just resubmit the run thanks.

After re-watching, if you can clean up the platforming while you switch grips, it seems like a minimal time loss on the change up, and it could save 1-1.5 seconds over a 4 cycle, which already saves ~ 2 seconds.

So 3 seconds to save and 6 predator fights would be about 18 seconds if you somehow got all 3 cycle fights, which seems crazy to think about due to the RNG nature of the predator jumps lol.

You seem pretty consistent at least getting a back-up 4 cycle for a few of the fights, and your timing & mashing are really good. Hopefully you can get a 3 cycle in a run/pb.

I have a theory that there is a small window where you can shoot predator before he jumps to prevent him from moonwalking on the first cycle, but thats another project for a different time. If there was a manip to prevent predator from the horizontal jumps that would be a huge time save as that could basically guarantee 4 cycles or even 3 cycles.

I worked out that it is exactly 209 frames or 3.484 seconds from selecting continue to the first frame that Arnie spawns (sprite is visible on screen).

This could help for timing/frame counting of runs since most people dont have an input display for console, and some of them have a little bit of latency anyways.

Obviously this assumes that the player is holding A after continue is selected to get through the level screen as fast as possible.

Not that predator runs need to be frame counted, but thought it would be nice to have this information somewhere.

Hell yeah dude! Looking at it again, it appears that the first shot is either first or second frame, and the last shot appears to be last possible frame as well. Either way, the timing is super tight.

Very well done! Slaughterhouse told me back in the day that 5 hits/cycle was possible, but I never saw video of it, and the best I could do was a 4 cycle.

Pretty sweet to see verification that it is in fact possible. GGs

As far as I know the predator spawn is RNG and no known manipulations have been discovered. It's been a while since I've ran it, but I know each Big Mode has varying degrees of when the Predator spawns and even, when the certain rock patterns spawn. Example, in big mode 3 there can be a difference of ~10 seconds depending on 1) if you rocks spawn quickly 2) predator spawns instantly and 3) how long it takes to clear the projectiles to get the predator off the end of the screen.

Slaughterhouse did a bunch of TAS work on this game a long time ago. I believe he noted the spawns were RNG. I haven't really looked into it other than noticing the different time loss/saves for each pattern.

I couldnt really find any information on this, and while you listed some boards that have allowed it, there are others that have not. Typically if we cant verify an emulator's accuracy we dont accept runs on it.

Have you captured any runs using this emulator?

Thanks for the heads up on RetroArch being used by the system.

Category rules state that RetroArch isnt explicitly banned, but the run must list the version and specific core used, must show that run overhead is not enabled and have the frame rate displayed.

Looking at the manual for the Retron5, it doesnt appear to have any similar feature to run ahead, but I could not find any information on what core used etc. It also allows for switching of refresh rate between NTSC and PAL regardless of actual region.

Based on this I would lean towards not allowing since there is no great way to show accuracy. If more information is available, we can revisit this.

Yeah, if you are playing on original cartridge or flash cart like everdrive or powerpak, that should work fine. Keep in mind that the Retron clones may cap at 60 fps and not 60.09 so it may be slightly slower but that probably wont effect timing too much in shorter runs.

I'm not too familiar with android emulators myself. I'll look into it, but Razor is right, alot of smart phone emulators aren't very accurate, which is why the aren't typically allowed.

I believe that this is the first time (to my knowledge) of using a keyboard in runs has been brought up.

In a prior post, I did mention that i don't recall a run ever being rejected for lack of input display but it could be requested to provide the input logs in the future.

The concern with keyboards is that they can be mapped to have multiple inputs simultaneously (L+R, U+D, etc) which are banned in the rules. Some emu players also display the inputs which is why I suggested it originally as a fairly easy method for the player.

Hi there! While keyboards are not explicitly banned for emulator use, the rules do say that turbo and simultaneous left+right or up+down inputs are banned. They are banned because those inputs are impossible to perform on a standard NES controller.

If you do use a keyboard, please make sure the input display is shown on the screen as well as the normal identifying emulator/version info in your submission.

Thanks for asking and good luck in your attempts!

A maxout category is interesting and certainly worth adding if enough people have interest/runs in it.

I think the main reason why it wasn't added before is a small percentage of the community has the skillset to maxout and an even smaller portion of that also speedruns Tetris. Lanks did address in his previous post requesting the category.

Also, a lot of players that do play for score, use different versions of the game that show various stats instead of the original game. I am unsure how many of those players would want to replay their games on an unmodified version for speedrunning purposes.

That being said, if the community does want a maxout category we can look into adding too. (Probably any level start as opposed to specifying like the main 100 lines category)

Categories fr NTSC and PAL have been added. Good luck everyone!

this looks good to me. I like Razors idea. Very recently a similar category was added to the tengen board as well. Will talk with NesC about adding this soon.

I agree with reaching out to the runner to see if they still want their time on the board. In some instances, where all source vods have been deleted or moved (i.e. youtube) the runner may wish to keep their times out and are merely achieving or finding a better place to store the vods. In other cases, maybe the runner wishes to have their videos/runs removed entirely. Either way best to double check.

Typically we dont submit videos for other runners on their behalf and I would think that the opposite should be true too. Just my 2 cents.

In the past few years, more mods have been added because the que of verifying runs was adding up and it could take a few weeks for new runs to get verified. Moderation is a completely voluntary and unpaid position. We are doing what we can to both timely and accurately verify runs.

Also, adding ms to times will make each submission inherently inaccurate since some runners may use their live splits times and others may not use ms at all. In turn, we would have to download each vod to frame count it (even then it would not be 100% accurate since Youtube caps the frame rate, any vods from there may be missing a few frames). This would also mean rejecting runs that have frame rate issues.

At any rate, it appears this is only an issue due to having a tied WR. Currently neither Jospeh or Jonus have expressed any issue to have their runs re-timed. As far as creating an arbitrary threshold to re-time competitive runs (similar to SMB) I am not 100% against it, but am not convinced it is necessary yet. SMB has over 900 runs compared to 123 Tetris runs for the 100 line category.

Here's what I posted in the other thread about this:

The other mods can chime in if they want, but until recently there wasn’t a big need for such precise timing. While the board has grown (a good thing!) I’m not sure if millisecond timing is necessary yet.

As someone who verifies a lot of the runs; including occasionally having to frame count to verify times without a time or inadvertent early/late splits, I see several issues with this.

1. Like justinman said, you’d have to retime runs which is big commitment since you would need to frame count the vods to verify the precise timing. Even if you said only count those times under a threshold, it would still require determining an arbitrary threshold to have those runs frame counted.

2. All future runs would need to be frame counted as well. This would drastically slow down the verification process. Currently, the mods can verify runs fairly quickly. However, if we have to download VODs, watch, then frame count each run, chances are verification will be much slower. I am certainly not opposed to this in theory, but would want the majority of the community at least to be supportive of this change since it would affect everyone that wants to submit new runs.

3. There is also an issue with VOD availability. Some people link their twitch highlights and others upload to YouTube. Just the process of having to find the VODs and then download them can add work. Additionally, depending on the platform, the VODs will have different FPS. While the NES rate is 60.09, many people can only capture at either 30 or 60 FPS which results in different frame counts. I also believe that YouTube caps its uploads at either 30 or 60 FPS (may be wrong?) Either way this would require another step of equalizing all the frame counts based on a set frame rate, which is not stipulated in the current rules.

The PAL times are under Misc so both NTSC and PAL have separate categories and they cannot be cross submitted.

Sorry, I must not have seen this originally. There aren't any plans to add a B-Type category to the main board currently. However, another option is to request a category extension board and have it run separately there. This is the first request I have heard, so I am not sure how many actual runs/runners would be interested in doing this as well as moderating it. If you have any interest in either post here, and then we can see if any interest warrants the creation of a new board.

I finally got around to updating the rules to include the items we discussed here and some other basic stuff.

All runs must include video and if using emulator, please do not alter the layout (if using modified for hi score pb runs). Also, please specify emu used (if not on approved list) and if using retroarch, you need to specify version and core used, display frame rate, and must show on video that the run overhead option is not enabled.

I don't think this should change too much, since 95% of runs already do this. Thanks!

Added switch to platforms. It appears that Switch caps at exactly 60 FPS. This means that identical runs on NES and Switch will be slightly slower. But it is added for accessibility.