Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Tangent wrote:
jlun2 wrote:
mklip2001 wrote:
If I recall correctly, Arc or FODA figured out this kind of way to trigger the credits around the time of the last published run. There was some discussion in the forums that ultimately rejected this kind of ending for looking sloppy. I guess standards about input endings have changed enough, though, in the last years.
It's a pretty good-looking improvement of a pretty mediocre game. It is annoying how many lives you have to lose, though, to get the Game Over.
I thought it was more acceptable now because this game will be vaulted regardless based on the current movie's rating anyways. :P
Well, this only displays the ending screen. The actual ending has its own music and when you press start goes into a second quest. Pokemon had a similar situation. It looped continuously on ending screens, but didn't actually reach the standard completed state, and that was ruled as being not a valid ending. I'm almost certain something like this has come up with a couple other games too (like, they were supposed to create save data but didn't, I think?), but which ones escape me at the moment.
Oh, this is interesting, I actually didn't realize it didn't reach a normal ending state since I never beat the game normally, (I only was aware of this trick from the AGDQ run)
Well no matter, I can just post an alternate file that beats the game normally, it will still be ~15 seconds faster then the original run due to the first wall clip. A judge can decide what to accept.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
As ventuz is no longer working on this one, I have taken it up and have been doing a bit of investigating into why the walking through wall glitch works, and how to make it faster.
So far what I found is that the glitch appears to be a bit of poor programming combined with a bit of lucky interrupt timing.
Here is the code where everything goes wrong:
$FEA4:85 D5 STA $00D5 = #$94 A:06 X:02 Y:05 S:EC P:nvUBdIZC
.
.
.
$C298:40 RTI A:01 X:00 Y:3D S:7A P:nvUBdIzC
.
.
.
$FD6D:A5 D5 LDA $00D5 = #$06 A:3D X:00 Y:3D S:7D P:nvUbdIzc
$FD6F:60 RTS (from $FDD3) --------------------------- A:06 X:00 Y:3D S:7D P:nvUbdIzc
$EAE9:C9 72 CMP #$72 A:06 X:00 Y:3D S:7F P:nvUbdIzc
$EAEB:B0 21 BCS $EB0E A:06 X:00 Y:3D S:7F P:NvUbdIzc
The problem is that normally, $00D5 is $#94 and the CMP #$72 fails. However, the interrupt call set $00D5 to #$06, so it passes. From there it goes on to increase the players x position. The code seems to reuse a lot of these addresses several times per frame, so its not really surprising something like this comes up.
At the moment I have no idea if manipulating this is possible at all.
EDIT: at the moment, my record for getting through the first wall is roughly 750 frames. I think I can save at least 100 off of that. Actually I'll probably continue from where kyman left off.
EDIT2: I don't think the second death skip will be faster. It turns out that you have to go further through the wall then initially thought using the glitch (since more wall is on the other side) The glitch also seems to happen much less frequently there.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
@Samsara: thanks for the encode! I was going to try making one...but then forgot.
@AngerFist: Thanks!
@mklip2001: The power up is just a projectile weapon that drops from an enemy. It is actually a fairly common drop, I get it right at the start of level 3 (you can tell when the circle appears next to the sword at the bottom of the screen.)
@NitroGenesis: I would say ~85% of the run is the same inputs. Most of it is pretty straightforward stuff, not much point starting from scratch.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I'm also considering a redo on the first stage, but first I need to find out how to reproduce this glitch:
http://youtu.be/LDkal0qreEI
I believe I know why this glitch happens after doing some testing on my own. I haven't gotten that exact thing, but have gotten similar. (Same effect, but it goes away since I keep getting hit.)
It seems like what is happening is the enemy grabbing you falls just in range of a power attack after you knock him off of you (the pink one.) The game immediately adjusts the players position when you are about to execute it, but the enemy stands up on the same frame, so there is no way to complete the animation, leaving the player with hyper speed but no where to go.
It's rare because the enemy lands near you while you face the other way, uncommon and usually he will already stand up before reaching this position.
I've only gotten this glitch when knocking enemies off from the front, as in this video. This seems to be the key, as it for some reason knocks them behind you.
I believe something similar happens when picking up the motorcycle while facing the wrong way. You get warped to the right position (you can even see it happen to yellow player in the demo.) Of course the motorcycle doesn't change its state like the enemy does.
I don't think it is of much use.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
well I am making slow progress on various fronts.
Since Dooty's inputs resync in the piano roll style input format, we'll probably just be continuing on to level 2.
@Dooty do you know anything about RNG in this game?
My next thought is to try and check if levels can be worked on independently and resynced into a complete run later. So far my testing ran into desync do to lag, causing inputs to be missed (I think do to 1 frame inputs) So I would need to figure out how to make inputs robust to lag before continuing down that road.
But there is big gains in simplifying the whole process if it works out, so I'll be putting effort into testing it.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Given the comments by MESHUGGAH, abyrvalg, and Aqfaq on the previous page, there is clearly a lot of room for development here.
And regardless of what the Doom community might have settled upon, the very first line of TASvideos introduction is:
Here at TASVideos, we strive to push games to their limits.
And in this case the limits seem to lie beyond what is currently established.
However I am aware that the biggest hurdle here is simply a lack of interest, and no one can be forced to take interest in something. This is after all merely a hobby. So this thread may have been DOOMed (sorry) from the outset, until someone actually creates something new to make use of all these arguments.
How is it useless? Do you think it is not very optimized? It has 27000 rerecords and looks pretty good to me.
I managed to extract your inputs from the movie into a .csv file, so I'll see what I can do with it looking at different parts of the level, but I try not to reinvent the wheel.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Given this:
Truncated wrote:
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.
and this:
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 would say it should be acceptable to use such inputs as drivers such as the wingman warrior can generate.
Even if the warning "... is turbo" pops up, it is still not cheating, since its just exploiting poor programming, which TASes do all the time.
Perhaps DOOM TASes are best split into 2 categories, 1 where -control is not allowed, and one where it is. The first category would be keyboard and mouse only, so they would be directly comparable to real time runs (which at least real time runners would maybe find interesting.)
The second category allowing -control would be open at least to any drivers demonstrated to exist (I don't see why writing your own wouldn't be allowed, but it would have to be demonstrated.) This category would necessarily include the existing TASes, as strafe50 + turns is not available without it.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Dooty wrote:
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!
yup, I got that far : )
...but not much further, it seems the game does some weird things with inputs, when I get one character doing what i want and try moving on to the other two, I noticed occasionally that the first character can drop an input somehow. So I've had to take itvery slow and haven't had a lot of time to work on it either.
Being able to edit input in a .csv is the only thing that is saving me. How did you ever do this with a game controller D:
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
^ That was well known to be possible, I think the question that everyone is trying to answer is what to do with the extra elements that the data structure allows. The poster in the doom forum even made a very similar comment when asked about the situation:
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.)
which indeed seems to be the same thing that remains to be sorted out here. (Well, the issue besides the demo file format itself, which at any rate seems not likely to be resolved easily.)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Alright already under 30 now!
Although I think I made the mistake of doing all the easy ones first, so now when I get stuck its hard to tell what to do next. I tried kabuki quantum fighter, and while some frames can be saved here or there it throws things off in other levels, so I have yet to save any frames overall.
Combatribes will probably take a while, so there probably won't be much more movement here until some of the others finish their runs.
As a side note, the other end of the longest non-obsoleted runs list is becoming pretty interesting too. A couple of stars (ninja gaiden 2 and super C), and some other interesting games like Star Fox and metroid fusion appear now. I wonder what can be done with star fox now with the newer emulators.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Finally starting this run (after becoming frustrated on Kabuki Quantum Fighter)
DiscoRico and I are teaming up!
So far I got a basic input file editor Lua script working for final burn alpha, and with it found the first frame on which you can insert a coin (53) so that is a good start!
I do not expect progress on this to be rapid, but slow and steady should create a good run.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Truncated wrote:
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.
The support comes from command line instruction '-control', which as far as I understand it provides an input structure that the driver writes to and then is passed to the game.
The reason this allows strafe50+turns is that the game code won't call the routine that initiates the turn while in the strafe50 state. But the structure can be filled with the a turn value independently and sent to the game anyway, which fails to perform the same check on it. (I hope that is right)
So allowing strafe50+turns is allowing the call of the '-control' instruction, which does seem to mean that all available states would have to be allowed (going backward faster than 50 etc) otherwise it would be a case of saying "you can use '-control' but only to do strafe50+turns" which seems a bit arbitrary. However no runs do that so this is still hypothetical.
I guess my question here is when are command lines instructions such as that valid? Had the instruction simply been '-strafe50+turns' would that be allowed? Or since the game ordinarily doesn't support it would it be considered a cheat? A more obvious example would be '-run at speed 100' or some such thing.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
This is a fascinating technical dilemma, I'll be very interested to see where the line is drawn.
Samsara wrote:
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?
It was, but MESHUGGAH seems to have put some effort into dissecting the game, and raises some real concerns.
As I understand it, the problem is that the replay format bypasses the game engine processes in recreating the movie.
Playing the game: Input->Game Engine->movement
While the replay uses the movements the file contains directly, even though they are not derived from original inputs.
This is complicated by the '-control' command line instruction, which seems to allow for non-standard input, which can none the less be considered 'officially' allowed due to the existence of such a command in the first place.
MESHUGGAH's point (I think) is that the fact that the replay movies sync in the original DOOM does not mean that actual inputs could have produced that list of movements, i.e. playing the replay file is different then playing the game. But, this is what Truncated partly justified the original acceptance of the movie on.
It's an interesting dilemma, but I wonder if it's interesting enough to change the precedent set by the now 3 publications?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Ferret Warlord wrote:
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.
none. I tried many locations and many angles.
I was only able to get a clip in the stair type sections of the dungeon, but not very far into the wall.
Well, you are very good at frame advance : )
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Thanks for clarifying that.
The code that causes the final boss fight to end is only called in that particular room, so if anything strange is happening with the dragon it is a different cause altogether.
I experimented a bit, the only things I have deduced is that the moving platforms don't move until you land on them. You can also land on the neck of the currently active dragon head.
However you can't transform on the dragon, so you can't go through the fight without landing on them sadly to test.
I did notice that it is slgihtly faster to transform after getting the purple crystal instead of before, because it kills all your momentum after you pick it up. Implementing this saved 5 frames.
Still looking into that falling through platforms glitch.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
FatRatKnight wrote:
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.
Great!
I hope you find a game that suits your taste.
With that and fist of the north star, the list is already down to 30! Although I do expect progress to slow down.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Dacicus wrote:
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.
I implemented this, it saves about 30 frames total.
scubed wrote:
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.
Not sure what this is, I'll have to keep looking into it.
I also figured out what room 1 is, it is the top of the tower. The special code in $A87B is written to keep Kuros from jumping to the left to reach the second level knights guild, so nothing special happening there.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
feos wrote:
Can you tell why it's not worth it?
It's just my opinion that whatever we put in a 'technical showcase' should meet the highest standards of what is authentically possible, but certainly the community can collectively decide where they want to draw that line.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
True wrote:
keep in mind there are more human inputs than controller inputs.
I like that : )
But I'm not really sure what you are proposing. Would you go with something even more general?
@feos: 'prowess' may have been poor word choice there. 'Innovation' would probably be better. But anyway, in your example a bot-generated run on wii would be interesting, but I had something different in mind for technical innovation, more along the lines of what the games and hardware can do.
I'll give another example, the fancy new n64 emulator CEN64 (or any ongoing emulator developments) if completed would be in its own right a technical achievement that would allow much more accurate TASes for that system to be generated, but as an example of what can be done with a game or hardware, it wouldn't provide anything new by itself. I hope this is a clear example.
As for Adelikat's question of what is a showcase and not moon, in my mind it is like the complement of the question mark box designation. The top tier examples that can be considered cutting edge technically (even if their entertainment value is minimal.) The benefit is that it sets these runs apart in an easily accessible and searchable place, as opposed to being in the sea of ~900 moons TASes.
For how they are picked, I think Grincevent said it pretty well. The 'beating the game' requirement might also help clarifying as well.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Samsara wrote:
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.
Cool! I'll make note of that. I don't think there is any hurry or anything, but I'm happy more of the list is claimed then I originally thought.
Only 2 runs left in the 2XX series, anyone interested in Lagoon?
I'll probably do Combatribes ... if I can find the motivation. If anyone wants to team up on that one too I am willing!
