Enemies movement/position has been manipulated. RNG is manipulated to kill each pig with 2 shots. Damage received by imps also has been manipulated.
E3M2 - Slough of Despair
New route. Green Armour will be useful in E3M7.
E3M3 - Pandemonium
Neat movement in narrow corridors. Via firing a handgun monsters position has been manipulated.*
E3M4 - House of Pain
Same here*. Yellow key was picked up through the wall.
E3M5 - Unholy Cathedral
With the right movement/position of the player teleportation can be skipped. Same applies to the blue key grab, so there is no need of lowering the pedestal.
E3M6 - Mt. Erebus
RNG is manipulated to deal maximum damage and kill more enemies.
E3M7 - Gate to Limbo
Lost soul's position is manipulated to be able to rocket jump strait to the exit. Clumsydoomer helped with this RJ, but refused to be a co-author.
E3M8 - Dis
RNG is manipulated to kill the Boss with one charge.
I saw this on your youtube channel a while back and was wondering if you would submit it. Glad you did! I saw that you have done episode 4 as well, will you also be submitting that?
Two questions. When comparing to your previous TAS of episode 3, two levels are slower (though neither by a second):
- E3M2. 0:12.89 in new run, 0:12.74 in old. Probably because you pick up green armor, which is needed for rocket jump in E3M7?
- E3M8. 0:07.86 in new run, 0:07.66 in old. I don't understand why. You say that you finish the boss with one shot, and the old TAS used two - but two shots seem to be faster? You have the ammo for it in the new version as well.
Joined: 3/21/2015
Posts: 29
Location: 66th region, Russia
Doom speedrunners don't care about saving bits of a second because intermission screen time is more important for us. Local rules are different and we aren't used to them yet.
Yes, 2 shots seem to be faster because it takes more time to wait for the BFG traces to deal damage than to fire another shot. I'll ask Akse if it's worth fixing.
Doom speedrunners don't care about saving bits of a second because intermission screen time is more important for us. Local rules are different and we aren't used to them yet.
Yes, 2 shots seem to be faster because it takes more time to wait for the BFG traces to deal damage than to fire another shot. I'll ask Akse if it's worth fixing.
Yeah, I understand that intermission screen is historically more relevant, because it used to be the most exact you could get for Doom speedruns. When editing movies at a per frame/tic level though, it doesn't seem relevant any more...
According to Doom wikia: "The function M_ClearRandom resets both functions' indexes (P_Random and M_Random) to zero. It is called during initialization of each new level so that demos will be the same each time they are played, and so that multiplayer games are synchronised."
So if the RNG seeds are reset every new level, the final level input from the old TAS could be copy-pasted and still sync. Doesn't seem like too much trouble for someone who knows how.
Doom speedrunners don't care about saving bits of a second because intermission screen time is more important for us. Local rules are different and we aren't used to them yet.
Yes, 2 shots seem to be faster because it takes more time to wait for the BFG traces to deal damage than to fire another shot. I'll ask Akse if it's worth fixing.
Yeah, I understand that intermission screen is historically more relevant, because it used to be the most exact you could get for Doom speedruns. When editing movies at a per frame/tic level though, it doesn't seem relevant any more...
According to Doom wikia: "The function M_ClearRandom resets both functions' indexes (P_Random and M_Random) to zero. It is called during initialization of each new level so that demos will be the same each time they are played, and so that multiplayer games are synchronised."
So if the RNG seeds are reset every new level, the final level input from the old TAS could be copy-pasted and still sync. Doesn't seem like too much trouble for someone who knows how.
That information is incorrect. M_ClearRandom is only called at the start of a game.
I saw this on your youtube channel a while back and was wondering if you would submit it. Glad you did! I saw that you have done episode 4 as well, will you also be submitting that?
Hell yeah! I'll wait 'till this one get published, then i'll submit another one. I guess, it would too much otherwise.
Truncated wrote:
Two questions. When comparing to your previous TAS of episode 3, two levels are slower (though neither by a second):
- E3M2. 0:12.89 in new run, 0:12.74 in old. Probably because you pick up green armor, which is needed for rocket jump in E3M7?
Yes, it's because of GA.
Truncated wrote:
- E3M8. 0:07.86 in new run, 0:07.66 in old. I don't understand why. You say that you finish the boss with one shot, and the old TAS used two - but two shots seem to be faster? You have the ammo for it in the new version as well.
No, it's not two shots. In my e3dq310 i started to charge earlier. In this run i need time to switch from RL to BFG.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Does this use strafe50 and turning at the same time? If yes, are we just going to ignore the question of whether that should be allowed?
I'd classify it in a similar category as abusing emulator bugs.
So there shouldn't be an ending sequence after this movie?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Noone isn't never going to not publish this! (You should do it.)
And yes, the ending sequence has to be added. Let me know if I should help out.
Warp wrote:
1) Does this use strafe50 and turning at the same time? 2) If yes, are we just going to ignore the question of whether that should be allowed?
3) I'd classify it in a similar category as abusing emulator bugs.
1) Yes.
2) It was discussed at length in our first Doom submission.
http://tasvideos.org/forum/viewtopic.php?t=16510
I judged that it would be allowed:
"I was asked to comment on Strafe50 while turning. Aqfaq's reasoning is sound, it can be compared to left+right. It is not possible to press normally, but it can be accomplished with a modified controller in both cases. The game accepts Strafe50 and turning as valid input when it receives it. This is not true for all input which can be sent, for example sending quicker running input than normally possible makes Doom go "Indigo: is turbo!" to warn viewers/other players that the player Indigo is cheating."
3) It can't be an emulator bug because it syncs on real hardware (or at least original Doom executable on Dosbox).
I mean, I added blank frames to the movie, but the ending just doesn't start. Just like in the author's encode.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Reply to Truncated (too many quotes):
1. Congratulations on allowing players to use whatever arbitrary values that isn't replicable with real conditions. Yes, the game accepts GF90 too, can I submit it then as an "experimental exception"...?
2. Seriously, just proove me wrong, are you going to say that the judges' task is ask whatever TASer about his viewpoint and run a demo in a dos EXE? Can I finally get some response about what the hell are you doing?
Regarding the fantastic "reasons":
- No, it's not left+right, it has nothing to do with the possibilty to PRESS the buttons. It's about the game DOESN'T PROCESSES THE INPUT you give, meaning YOU CAN'T DO WHAT THE GAME DOESN'T DO. How the fuck do I need to emphasize this?
- No, the game doesn't says "Indigo: is turbo!" for quicker running, it's only activated if 2 conditions are met, which is absolutely obvious in the source code, I would like to ask you to read my General\DOOM rules thread and educate yourself.
3. You are fucking hilarous, I'm done.
edit: oh, and as I've already mentioned on a few places multiple times, none of these TASes are high quality (void glitch is possible on many places yet not used and totally suboptimal at e3m5 or e3m6 whatever. movement is totally sluggish (player waits for 20 tics and go forward if he magically gets into the teleport), do I need to fucking continue?
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Joined: 11/13/2006
Posts: 2794
Location: Northern California
MESHUGGAH wrote:
do I need to fucking continue?
I wasn't fucking aware you had fucking started. By all fucking means, you fucking need to fucking continue.
Watching an argument would be more entertaining than watching the run, anyway.
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Thank you for making me urbandictionary this word. Now make me unread it.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 11/13/2006
Posts: 2794
Location: Northern California
xy2_ wrote:
ah, the good ol' samsara switch-a-roo
Ah, the good ol' "poster with one-month old forum account thinks they know me well enough to assign a kitschy, alliterative name to what they perceive to be my behavior".
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?
TASvideos Admin and acting Senior Judge 💙 | CohostwarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Why was none of this brought up sooner in any of the other submissions?
Obviously because of HYPE!!! And I now see what can of worms we've opened :)
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
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?
Reply to Truncated (too many quotes):
1. Congratulations on allowing players to use whatever arbitrary values that isn't replicable with real conditions. Yes, the game accepts GF90 too, can I submit it then as an "experimental exception"...?
Allowing turning and strafe50 doesn't mean allowing any input. I guess you could submit a movie which uses max turbo and see if people think it's entertaining. For other movies we will stick to max speed 50.
MESHUGGAH wrote:
2. Seriously, just proove me wrong, are you going to say that the judges' task is ask whatever TASer about his viewpoint and run a demo in a dos EXE? Can I finally get some response about what the hell are you doing?
Finally? Did you ask me before? Look, it's very unfortunate that I didn't see your thread in the General forum, and that you didn't post in any of the submission threads, but I don't think we need to be hostile.
To judge the movies, I did this:
- Searched for faster movies (for example on Compet-N and DSDA)
- Ran the movie in the original Doom on Dosbox to verify that it synched.
- Inspected the LMP file in LMPC. This detects movement >50 in any direction.
- Watched the movie to see if it seemed well played.
MESHUGGAH wrote:
Regarding the fantastic "reasons":
- No, it's not left+right, it has nothing to do with the possibilty to PRESS the buttons. It's about the game DOESN'T PROCESSES THE INPUT you give, meaning YOU CAN'T DO WHAT THE GAME DOESN'T DO. How the fuck do I need to emphasize this?
- No, the game doesn't says "Indigo: is turbo!" for quicker running, it's only activated if 2 conditions are met, which is absolutely obvious in the source code, I would like to ask you to read my General\DOOM rules thread and educate yourself.
Yes, I know that the game only actually checks forward movement, so it would be possible to run backwards/sideways faster than 50 and not get the turbo message. (None of the submitted movies do, though.) Elsewhere in the code (line 413 in g_game.c) it seems obvious to me that 50 is the intended max speed in all directions.
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.
MESHUGGAH wrote:
edit: oh, and as I've already mentioned on a few places multiple times, none of these TASes are high quality (void glitch is possible on many places yet not used and totally suboptimal at e3m5 or e3m6 whatever. movement is totally sluggish (player waits for 20 tics and go forward if he magically gets into the teleport), do I need to fucking continue?
Where and when did you mention this multiple times? I can't find a single post by you in any of the Doom submissions, until now. That's where I looked for criticism of the submissions, obviously.
Like I said, I checked around if there was any faster movies, but couldn't find anything. The Doom community seemed to agree that these were the best there were. But if you know of some way to improve them, great for you! I look forward to your submission.
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.
I mean, I added blank frames to the movie, but the ending just doesn't start. Just like in the author's encode.
Guys please address this too.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I mean, I added blank frames to the movie, but the ending just doesn't start. Just like in the author's encode.
Sorry, I forgot to reply to this in the middle of everything else.
The ending doesn't start because you are encoding it with PrBoom. PrBoom adds a status screen after the last level, which is not present in original Doom. In original Doom, the ending starts.
You can modify the movie to add an extra use command to start the ending in PrBoom, I think. Let me know if you want me to do it.
