Mod note: This is actually a 2:44.33 by my manual count. Beats the world record by .17. I'll post about adding decimals in the forums. I think we need them at this point! Congrats @bizarreluck !
This is done - Maybe we should roll Max damage into Any%, might make more sense.
Mod note: Time starts when the Excel splash screen first appears.
Mod Note: All sides of the credits screen seen at 32.80.
@Dragondarch - it's definitely an intentional quirk as there's versions of the game where it noticeably doesn't happen. Like on Saturn, where the intro is a movie and the timers can't run during playback, or PSX which has a reset key press that doesn't trigger the opening logo and would make it impossible to trigger and therefore useless to have. Saturn and PSX seem to handle that by making sex the trigger, though you wouldn't notice anything on PSX unless you played with it under emulation due to it's psychotic methods of randomization.
@Sheex - is this on SNES? There seems to be a variance with both Sun and Moon - I've gotten patterns where my mapper scripts predicted Moon in emulation, but upon running it again, or comparing to hardware, it was suddenly sun. That tends to be around the 5th card in a lot of patterns. I think there were another two cards that did that but I don't remember.
Just something to add, by my manual count, SNES emulation via bizhawk is 3 frames faster than a real SNES for OB. That difference came up in 20 or so manual timings, so I think it's pretty accurate.
It is definitely timing dependent. But given that Saturn, like Playstation is a disc based system, you'd need to time after loads for it to be reliable. Disc drives are impressively non-deterministic. I used sound cues for my Fireseal runs on Saturn to try to do this since they are reliably paced.
There's some evidence in the SNES code (supposedly) that the card redraw effects that happen in Jokers and Warren's final card are not actually supposed to run. If you've ever run SNES and got a pattern you were looking for but all of the sudden the last card isn't what it should be, you've seen a card redraw. That happens when your leader's luck is modified enough by the starting cards that it triggers an incredibly small chance to redraw that card based on an algorithm that selects certain "bad" cards to be redrawn or certain "good" cards to be redrawn based on the Leader's luck value + or - 50.
I can tell you it does happen, but due to the inconsistencies on hardware compared to emulator on SNES, it's difficult for me to pin down exactly how the redraw works or if it can be manipulated based on any specific thing the player does. On SNES, that algorithm is (supposedly) functionally the same as the main one due to an oversight and thus keeps track of the last drawn card, but it may not have been intended to. So the behavior we see on Saturn and sometimes Playstation may have been intended as it was meant to be truly random.
I keep saying supposedly because this information comes 3rd hand from translated ancient Japanese webrings that pulled their info from a decompilation project in 2007 that is basically vaporware now. I can't even find the mods that that were supposedly produced with it after days of fishing on Internet Archive.
Certainly could. I have some time for the next two to three weeks (I'm between jobs), so I have some time.
There's also a hacking discord for the series that's already established that might also be a logical place to add speedrunning discussions to, given how much research goes on there. I could also reach out to the Admins there and see if they'd be willing to open things up top speedrunning discussions for the games.
What do folks think is best though?
(Here's a link to the hacking discord incase anyone wanted it: https://discord.gg/SJgC6EUMne )
As far as I've tested the Item from units RNG is fixed on the act of saving/loading, so the strat I was trying for IS actually resetting and hitting a 1 frame window still. It's on a regular interval though, so on emulator I can kinda get it by listening to the music. Doesn't work on console that way, so that way is not very interesting at this point.
So... I've been testing manipulations for 100% and a possible All Stages run for SNES, and I've come to the conclusion that there's something fundamentally very wrong with how timing works for Ogre Battle under emulation, even under Bizhawk's BSNES core.
Emulation is two frames behind actual hardware on Warren's Tarot reading after timing a sampling of 30 runs. My interpretation - since manipulations for cards and items work accounting for this - is that the actual amount of lag under emulation is incorrect in many loading and high CPU situations.
This means currently that we can't trust item manipulations from units under emulation. As soon as there's enemies and multiple loads, things get very far away from hardware in my manual testing.
I've failed over 100 attempts at a chime manip just to see if this kind of thing is viable - and that's odd because I'm usually at least 1/10 on getting frame perfect stuff. So I manually timed some of the recorded failures and realized I definitely got every frame including the target on a 5 frame window. Without some automated way of testing manipulations consistently on real hardware, sadly a manipulation does not appear to currently be possible.
I do own a TAStm32 (TASbot basically) that I use to test some NES stuff for folks, and could possibly try to write something that tests all 255 possible drops from Sharom using @Dragondarch 's manipulation as a base, but unless you want to count chess games, I have had almost no luck with getting things to sync at all on my SNES consoles, and considering the precise timing required, I doubt this will be fruitful.
I'm going to reach out to some contacts in the emulation community and try to see why the lag frames aren't seemingly lining up. If anyone has any ideas, I'm all ears.
Ooh, cool.
For the record, CPT and most of the larger events DO allow Hitboxes and Keyboards so long as they meet the same bar for input handling as a standard controller or stick. There was a recent controversy with SF6 because Capcom changed the expected SOCD method that Hitboxes (and other controller types) were using by default, necessitating a firmware update on Hitbox.
Reference here: Capcom Pro Tour Cracks Down on Hitbox and Other Leverless Controllers in New Street Fighter 6 Ruleset (wccftech.com)
As of firmware 1.4, the Hitbox complies with this and is CPT legal: Firmware Update Restores Hitboxes After CPT Controller Rules Change (esports.net)
But that was only for SF6. EVO and other large events with Capcom games headlining definitely allow Hitbox. Heck Capcom Top 8 was ALL Hitboxes at EVO 2022.
The Hitbox fear is overblown - any game that's not SF6 - it follows the expected SOCD cleaning protocol. You can't charge while holding forward. And even a Hitbox in 1.4 SF6 mode just goes neutral on L+R or U+D, which is arguably less advantageous than stick.
As someone who uses both stick and Hitbox interchangeably, I don't understand the fear. If I can hit literal frame windows on stick just as well as on Hitbox with my nerve damaged hands y'all don't have an excuse. =P
When I time, I usually time it on the first frame that I see the boss health value transition to becoming 0 like you say - as a few of the videos seem to use that as the metric, but now that I look through, you're right it does seem to be less than consistent.
I usually try to use consistent visuals where possible as that tends to keep things more clear for timing, but it doesn't much matter to me. There's visuals for the final hit (either unit shake or hit flash are standard on all versions) and the start of the damage numbers (visible and pretty consistent on all versions) too that could work just as well.
Yeah, in my run, I didn't actually know Magician could go that high without literally perfect cards. Resistances are very broken on this version though, only reason why the damage rolls seem to go so high. Considering the work that went into the Human theory TAS to get that possible, it's probably quite literally a 1/25k chance of getting it in a run. Bizarreluck was really lucky to get it, even with a hermit!
Weirdly enough, despite my hand issues, I'm really good at getting frame perfect timing. Don't know if it's just that I can figure out strats like sound that work or what.
For example, in Castlevania Easy Mode I use my peripheral vison to judge the first bat movement and hit the frame perfect bat crit, and I can judge not only what pixel I need to stand on for a first frame Medusa crit (again, a peripherals trick), but use a music cue there to know when to whip. My anti-despawn map object tech that I use to try to kill bosses with in Vortex (SNES) is again a music cue, but due to that game running at like 4 fps, sometimes you just can't get it.
Since this really is a full manipulation, I think I actually needed to hit something like a 10 frame window out of Warren's tarot reading to get all the RNG I need, so I think I figured I really couldn't waste any time selecting anything but the 1st option. There's no good way to tell if I lost frames anywhere. Since everything I do on the in battle map is done to retain some specific in battle RNG so the card does enough damage and the Tigerman does hit, the only concern was getting the timing fast enough and not taking too much time moving units. There's a surprising amount of leeway in movement, timing, and map position to get exact same RNG. Only the Card pattern is actually frame perfect, I believe.
If we could fully crack how "lag" works - and by extension, how pathing works - there's another 4-5 seconds to save, if not more. I took a brief look but what I found in emulator did not seem to match on console, so I scrapped trying things specifically to reduce "lag" in runs.
Someone could also just do exactly what I did only faster or with slightly more optimal routing. I'm fairly sure the TAS movement might be possible for really amazingly handed humans, it would just require routing for it in a way that's SOMEWHAT reproducible. Something I wasn't really able to do unfortunately.
Fair enough - that's actually a good point!
Interesting - I've only ever had runtime errors, so that's good to know. Yeah, I agree, given that knowledge, option 2 seems like a bad idea and would be too beneficial to for folks. So much so that someone might try to exploit it.
I think in this case, it would be relatively easy to discern a real crash as it always crashes due to run time errors that are visible. We could exclude other events that look like crashes and make it a rule to capture the crash runtime error by either capturing desktop or switching to the error message in capture.
Perhaps we could be lenient in areas where there's no benefit - like crashes that happen coming out of a level since it's so common - there wouldn't be a benefit there as it always takes longer to restart the game and you've already passed the screens that take the most time. Plus you haven't seen any RNG yet. But that's the only case I can think of.
I do agree though, all of the runs that are under an hour, I see no need to include in this. There's almost never any crash that occurs in those due to where they fall relative to the amount of cutscenes, and ample reason to believe there might be attempted abuse in shorter runs.
@xSoapBubble recently brought up a good point - how does everyone feel about adjusting times for game crashes? I personally think this is pretty fair for the longer runs given how frequently this game implodes, but I have some times that would be affected by this drastically so I might be a bit biased.
If there were a way to fix it I might be less inclined - but there really isn't. I've tried an extensive number of things to get it running in a more stable fashion, and nothing works. You can take a look in the discord for a history of what's been tried. Might have more folks willing to run the game knowing that a crash won't affect them as much.
As for the timing we could do any of the following:
-
Deduct the time of the crash to the start of the selection of the next level.
-
Deduct the time of the crash to the start of the selection of the next level next level. If the crash happens in a level, deduct he time spent in the incomplete level from start to the restarting of the same level.
We could also switch to in game time, but I'm a little wary of that as it might lead to folks min-maxing the item system without consequence which isn't really in the RTA spirit, and it would also be incredibly rough to do for the runner and the mods on longer runs.
Let me know what you think!