That's some really good news, Alyosha! Having someone else to help you out is something of great value, so good luck to you two. I'd like to be of some assistance, but since I just played the first stage, I'm afraid I can't do much. In any case, you said you found the right frame to insert the coin. I just like to point out that it's better to insert just one coin at the title screen. You can insert the other two coins later, while the name of the stage is being displayed, without losing any time. Again, good luck with your project!
I can't think of anything - the game uses the ticcmd_t structure to define the input data for each tic, and the external control API lets you pass arbitrary data to the ticcmd_t structure, which logically includes any and all "legal" configurations. I do understand the dilemma this presents. The external control API was a real, purposely built part of the original game, with at least one actual driver released for it. It seems somewhat ridiculous to disallow it as a control scheme for demo recording - what, Wingman Warriors are banned? But at the same time, it has zero sanity checking on the data passed to the game that way, and lets you ludicrously do GF127/SR127, which is, oh, a mere 359% of normal running speed. You couldn't even say "well, allow anything that doesn't result in a %s is turbo message", because the game only checks the forward component for that, so you would end up with demos with GF50/SR127, which would be just awful. Another way would be to say, "well, we'll allow the exact input supported by the default Wingman Warrior driver", which would result in GF100/SR100 with full control: GF50/SR50 via keyboard / mouse, plus GF50/SR50 from the Wingman Warrior, plus turning control from the Wingman Warrior. (Has anyone ever done this IRL? I feel like SOMEONE must have noticed that you could haul ass with one hand on the joystick and the other hand on the keyboard.)
I also know that turning during strafe50 is not possible with mouse and keyboard. It mostly seems to be a limitation of the original control scheme, because 1) strafe50 is allowed and 2) turning while strafing is allowed. The justification was that it is possible with an external driver, which Doom natively supports, so this is what a God player would use. That's what made me say that it was OK. You could of course argue that the limitation was done intentionally, and turning during strafe50 should be banned. Or that allowing movement larger than 50 backwards and sideways by using a driver was intentional. I don't think so, so that's not how I judged, but I admit we don't know.
I'm genuinely curious as to what MESHUGGAH had to say, though. Maybe we can call it the "MESHUGGAH Meltdown", in the spirit of whatever the fuck that quoted post was meant to be. Why was none of this brought up sooner in any of the other submissions?
I take it you had no luck skipping the monster in the pit? Sheesh, this run is 10 years old, and my only tools were frame advancing and an input display. I'm honestly surprised our run has held up so well this whole time.
Submitted my Gauntlet TAS. The moment you can knock one more off your list is fast approaching! I may consider another TAS from this list. I'll think about it.
Actually, it is possible to save some time (maybe a second or two) by improving the jump as Kuros enters the third wizard guild. He needs some leftward momentum as he's entering the door, and he'll make it to the top of the steps in one jump.
It is possible to jump right below the top of a platform to fall through it. There was a movie demonstrating it. Unfortunately, we weren't able to get it to work consistently. That should allow easier access to the lower cave area.
Can you tell why it's not worth it?
keep in mind there are more human inputs than controller inputs.
I've got a bit much on my plate at the moment, but sometime in the future I'd like to take a look at Star Ocean.
$B2A8:BD 3C 03 LDA $033C,X @ $033D = #$4F A:04 X:01 Y:91 S:FD $B2AB:C9 50 CMP #$50 A:4F X:01 Y:91 S:FD $B2AD:B0 AD BCS $B25C A:4F X:01 Y:91 S:FD $B2AF:AD 0C 04 LDA $040C = #$00 A:4F X:01 Y:91 S:FD $B2B2:D0 A8 BNE $B25C A:00 X:01 Y:91 S:FD $B2B4:A9 01 LDA #$01 A:00 X:01 Y:91 S:FD $B2B6:8D 0C 04 STA $040C = #$00 A:01 X:01 Y:91 S:FD $B2B9:A9 C0 LDA #$C0 A:01 X:01 Y:91 S:FD $B2BB:99 A4 03 STA $03A4,Y @ $0435 = #$02 A:C0 X:01 Y:91 S:FDRegister Y currently has a value related to Kuros' position on the screen. For no discernible reason, the code proceeds to use this register to store #$C0. The corresponding RAM address is $0435. Now, $0435 is the location of Mikail's current attack pattern. It ranges from 0-5. The game performs a check later on to check what pattern he is in, if it can't find a match (which it can't since it is set to #$C0) the fight ends. This explains why the fight ends, but not the graphical glitches. I'm not sure of the possibilities to do thing with this glitch outside this particular fight. EDIT: with some more analysis, it seems that block of code is specific to Mikail's room. The game checks a RAM address ($006B) that carries the current room designation, in this case it is 5. When it is 5 is the only time this block of code is called. As a side note, the game does another special check if the current room is 1. I so far have not found any room with such a designation, although it might be worth looking into further.
I'm picking up Metal Storm. Improved 8 frames on password input. Hopefully more to come lol.
I was working on SNES Prince of Persia, actually.
A few years ago I tried to make an arcade SF2:TWW playaround run, using glitches like handcuffs and all the other things Guile can do, invisible Dhalsim, player vs player fights, etc., although I never got far with it. A good playaround/glitchfest would probably be able to obsolete both SNES runs.