Post by Aqfaq

Posted: 5/29/2015 12:07 PM

Post subject: DOOM rules / detailed informations?

Quote

MESHUGGAH

Other

Skilled player (1918)

Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯

Just recently saw that DOOM submissions uses LMP, the demo file containing instructions for each frame. Apart from the link to the submission from latest news article (DOOM submission accepted) and 1 line of Doom in the rules (DOOM: .lmp), I didn't found any discussion or set of rules regarding authenticity. My questions: 1. How did you verified the LMP file? Does Doom checks each frame input authenticity or just replays it as-is, allowing you to reject variable value limits? All I can see around g_game.c // DEMO RECORDING is using as-is. 2. How did you verified that the LMP instructions does the same thing in the game? I'm unfamiliar with Doom's source code, but I see a lot of "if (demo)" branches at the network code (d_net.c). Tried to look up the number of polls in a tic but the source code is too long (I'm just interested in the answers, not trying to prove anything without knowledge lmao). 3. What settings you are allowed to change? Things like setting the maximum memory allocatable (can be done by adding a parameter), changing the time of your machine (not sure if the game uses really the OS's time, just saw i_gettime.c) Sorry if these questions were already answered, I didn't found anything but that submission thread with very minimal informations of verification. edit: no, http://tasvideos.org/Natt/Doom.html also doesn't answers these questions.

PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...

Posted: 5/29/2015 3:59 PM

Quote

Warp

Banned User

Joined: 3/10/2004
Posts: 7698
Location: Finland

I apologize for barging in, as I know next to nothing about Doom's demo file format, but I had similar concerns when the first PC Doom TAS was submitted. If I understood correctly, the Doom demo file format cannot be tampered with, and it is possible for it to descync if you try. This is because (if I understand correctly) it contains pretty much the equivalent of key presses at each frame. (This is, AFAIK, unlike eg. Quake's demo file format, where each "frame" simply consists of the world positions and orientations of all objects, and thus could be easily tampered with without causing any kind of desync, and could be hard to distinguish from a legit run.)

Posted: 5/29/2015 4:10 PM

Quote

adelikat

He/Him

Emulator Coder, Site Developer, Site Owner, Expert player (3574)

Joined: 11/3/2004
Posts: 4754
Location: Tennessee

I'll add that when judging a doom submission, the movie is replayed in native doom (typically by running Doom in DosBox) as part of the verification process. If the movie were to exploit modifications/features of prboom for instance, it would not play back in an unmodified doom. I'm aware that this doesn't particularly address any of your questions.

It's hard to look this good. My TAS projects

Posted: 5/29/2015 4:19 PM

Quote

MESHUGGAH

Other

Skilled player (1918)

Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯

Warp wrote:

If I understood correctly, the Doom demo file format cannot be tampered with, and it is possible for it to descync if you try. This is because (if I understand correctly) it contains pretty much the equivalent of key presses at each frame.

A demo lump is a sequence of instructions which tells the game engine what actions the player will perform: when he will take a step forward, turn around, shoot, switch weapons, etc. It is interpreted by the engine as keyboard and mouse input, thereby allowing anyone to watch a recreation of the original recorded actions. If you read the structure of these tics here, you will see that it isn't stores keypresses like emulator movie formats. "Replayed in native doom". I'm talking about exploiting the LMP format. Just like everyone else exploiting demo files (series of net_send packets or instructions, not obvious key series) for games famous of competitiveness. Do I need to list them?

PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...

Posted: 5/29/2015 6:12 PM

Quote

abyrvalg

Joined: 6/9/2011
Posts: 29

LMP isn't a very good format, it basically doesn't store inputs per se. Instead for each frame it stores stuff like "accelerate forward by 49 units/sec^2", "turn 179 degrees to the left", and whether the Use/Fire buttons are being held or not. That's it. Anyone can boot up a hex editor and set acceleration at each frame to as high as 4 times the regular maximum. This is easily detectable with basic tools (or even notepad), and even the doom engine itself will output a message about the player running at turbo speed. All of those invalid inputs are easily detectable in fact, but there's one problem - our knowledge about doom engine isn't perfect, which has lead to a lot of questionable TAS runs over time. The "strafe-50 problem" is the most widely known one, - it's possible to create a LMP which, for a given frame, states "accelerate_right_50 + turn_wherever". Each of those actions is possible to do on its own, - accelerating sideways at 50 units is a common trick, turning left/right is a basic function, but there's one issue with this: you can't do both of them in the same frame by using mouse, keyboard, or dual mice/keyboards. There's currently no known way of producing such input, only theories about it being possible with a joystick. It's "good enough" for most people, but some community members reject it and restrict themselves to "accelerate_right_40 + turn_wherever" inputs. There are other interesting issues that arise from LMPs not being able to store actual keypresses. For example, if one decides to record a speedrun of some level, and then checks his demo in a hex editor or other tools, he'll most likely find that the first several frames (after the header) are all zeroes. This dead no-input zone can last for as long as ~0.3sec, and if you're going for a world record in a small map, that can be a significant handicap. But in all TASes that got submitted to this site so far, player always starts running instantly, and moreover - as soon as level loads, he's already looking in the direction he wants. It's trivial to hex-edit such LMPs, but is it possible to actually produce valid inputs within a game that lead to that result? In this case the answer's yes, it's been shown that it's possible.

Posted: 5/29/2015 6:29 PM

Quote

MESHUGGAH

Other

Skilled player (1918)

Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯

"you can't do both of them in the same frame" if it's impossible by human limitations, I think it's OK to use it. If it's possible to recreate it real-time (with tools), than it's should use that way, otherwise the TASer exploits the nature of LMP. BTW from the doom wiki, I've thought it's possible in real time but hard to pull it off. "It's trivial to hex-edit such LMPs, but is it possible to actually produce valid inputs within a game that lead to that result? In this case the answer's yes, it's been shown that it's possible." Where? And... how can you proof that you are able to press an input on the very first frame without tampering with the LMP? Only "easy" thing comes in my mind is simply modifying the source code to warn the user about the first G_BuildTiccmd (ticcmd_t cmd) with the tic number. edit: "This is easily detectable with basic tools" - I wonder how a judge would find 1 tic of 51 or whatever arbitrary strafe value in the midst of framecount*~~140~~ 4 bytes + header, but I guess they used some sort of utility to filter this out, right? not just blindly accepting user input without sanitizing first and just thinking "wow it runs in dosbox this is totally legit" edit2: I've exported the 3 demos from doom.wad. Beginning of the demo files: Demo1: 6*WT, GB4, 3*WT, GF50.... Demo2: GF15, 6*WT, GF11, 3*WT, GF1, WT... Demo3: GF50, 5*WT, GF9, 4*WT, GF25.... Well, doesn't proves anything so far, I was expecting all of them starting with 6 WTs. edit3: Tried to look up for SR50 technical background from doomworld. The only post (Doom2 thread where probably Akse and Aqfaq discuss) I found about SR50 gives some verification to the above exported (doom1) Demo inputs: "for example you can only turn in the first tic of the next map, then on the 5th-8th tic but I don't know for sure about this" Well, I'm kinda disappointed that a game released in 1993 and probably also the root of all TASes doesn't have all the techical informations or proofs what's possible, also considering that we have the source...

PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...

Posted: 5/29/2015 8:53 PM

Quote

abyrvalg

Joined: 6/9/2011
Posts: 29

"otherwise the TASer exploits the nature of LMP" - yep, that's exactly what we're doing right now, and it's been going on for many years, which is a pretty big problem. There are few posts on the doomworld forums that discuss the possibility of producing a strafe50-on-turns input by using weird joystick drivers (?) or something along those lines. As of now, none of such approaches have been publicly displayed anywhere. I can look up some of those posts on doomworld forums tomorrow. "This is easily detectable with basic tools" - there are tools that quickly scan LMPs for str50-on-turns / str50 / turbo and various other things. LMPC comes to mind, i've never used it myself though. Regarding the first few frames in demos - most non-tasing speedrunners have learned to shove input into their runs as soon as possible, it's not difficult and is in fact one of the oldest techniques, but it's not something entirely intuitive and robust. I described it in my post mostly because it's a relevant issue that i happened to have remembered off the top of my head, and it shows one of the problems with the LMP format and all the ambiguity it introduces into TASing. Also you're correct, it's most likely impractical to attempt to actually "prove" the statement i made in the previous post. The only work that has been done in this field is just a few speedruns that demonstrated that with the original doom2.exe you can make a demo start with a GF50 SR40 TRXXX tic, with subsequent tics being GF50 SR50 ones. And the same fact applies to a LMP which runs through more than one level. It's probably safe to assume that the same fact would apply if you record runs for other WADs, or if you play Ultimate Doom / Final Doom / Boom. If someone was willing to somehow verify it by studying the code, that'd be awesome.

Posted: 5/29/2015 9:10 PM

Quote

MESHUGGAH

Other

Skilled player (1918)

Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯

Thank you for your input abyrvalg. I'm not a judge or anyone who makes rules, but I believe that these Doom TASes shouldn't be accepted until anyone is able to verify these ambigous/hypothetical stuffs. Well, I'm pretty sure I won't dive in the source code nor install any dev environment, but I would like to see (and probably help in some way) getting some basic rules with technical explanation about Doom. I think the first few things needs to be revised is - is it possible to do SR50 and turn around without using cheats (Doom's external control API? maybe.) - what and when can be put inside tics (mostly referring to the first 15 tics on each level) - do we really want to rely on a demo format...

PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...

Posted: 5/29/2015 9:19 PM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11480
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

MESHUGGAH wrote:

- do we really want to rely on a demo format...

The second half of Post #404554 addresses 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.

Posted: 5/29/2015 9:45 PM

Quote

MESHUGGAH

Other

Skilled player (1918)

Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯

feos wrote:

MESHUGGAH wrote:
- do we really want to rely on a demo format...
The second half of Post #404554 addresses it.

I don't understand. So it's a "no" from the judges but accepting LMP files because... ?

PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...

Posted: 5/29/2015 9:51 PM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11480
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

MESHUGGAH wrote:

feos wrote:
MESHUGGAH wrote:
- do we really want to rely on a demo format...
The second half of Post #404554 addresses it.
I don't understand. So it's a "no" from the judges but accepting LMP files because... ?

It's a personal opinion of a single judge (that I agreed with finally), but the site policy is to allow internal Doom demos as the least harm, since not having any Doom TASes here is worse. Then we will eventually be able to improve the situation, but no one knows when. Everyone seems to agree that Doom demos being accepted is an exception, not a rule, whenever possible we try to accept only stripped inputs.

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.

Posted: 5/29/2015 9:55 PM

Quote

MESHUGGAH

Other

Skilled player (1918)

Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯

Care to elaborate what does TASVideos benefit from submitting/accepting whatever months old TASes for a video game (unbiased, rejecting the "root of tasing" thing) that based on weird assumptions/observes? I'm really interested in the reasons why is this allowed as an exception but many smaller things are not (fucking FDS roms). edit: just to make sure, if I would have know that Doom uses LMP as input submission, I would have already raised my voice about this... idea.

PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...

Posted: 5/29/2015 10:09 PM

Quote

ars4326

He/Him

Experienced player (778)

Joined: 12/8/2012
Posts: 706
Location: Missouri, USA

MESHUGGAH wrote:

Care to elaborate what does TASVideos benefit from submitting/accepting whatever months old TASes for a video game (unbiased, rejecting the "root of tasing" thing) that based on weird assumptions/observes? I'm really interested in the reasons why is this allowed as an exception but many smaller things are not (fucking FDS roms).

Going along with Feos's post, I'd also say that having DOOM TASes available for the general audience is among the biggest benefit. On the YouTube channel, Akse's Ultimate Doom 'Episode 2' publication has accumulated over 3300 views. That's well above the average view count that most publications get on the channel. With that stated, hopefully the situation can be ironed out better in the future.

"But as it is written, Eye hath not seen, nor ear heard, neither have entered into the heart of man, the things which God hath prepared for them that love him." - 1 Corinthians 2:9

Posted: 5/29/2015 10:59 PM

Quote

MESHUGGAH

Other

Skilled player (1918)

Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯

Okay, I will just simply swallow the reasoning behind yours logic. I guess there is no hurry in anything, so I will just come back when some progress happened on the verification side.

PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...

Posted: 5/30/2015 9:51 AM

Quote

Dimon12321

He/Him

Editor, Reviewer, Experienced player (596)

Joined: 4/5/2014
Posts: 1223
Location: Romania

Which .wads are acceptable for publication? Do you agree with accepting megawads which are provided in this thread: http://www.doomworld.com/vb/doom-speed-demos/18410-welcome-to-the-demos-forum-includes-prboom-plus-usage-info/ There are also some info about PrBoom+ usage.

TASing is like making a film: only the best takes are shown in the final movie.

Posted: 5/30/2015 12:03 PM

Quote

henke37

Editor

Joined: 3/10/2010
Posts: 899
Location: Sweden

The only difference between the tics struct and normal key presses is that input mapping has taken place. Now, there is the question: can the input mapping result in all possible tics values? No. Some are blatantly bogus, for example moving faster than the normal maximum speed. In other words, some fields have range limits. So, the implementation has some problems here, it records absolute values, not normalized values. This complicates validation since some of the range limiting is done in the missing input mapping step. But does this make it a format unsuitable for secure speedruns? I do not think so, while there is an additional burden of input validation, it is still possible to ensure that people obey the letter of the rules the game is made of.

Posted: 5/30/2015 5:56 PM

Quote

jlun2

Skilled player (1742)

Joined: 9/17/2009
Posts: 4984
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"

I know nothing of Doom demos, but... Given that they are judged competitively with other demos, and not real time runs, how exactly does cheating occur if technically everyone has the same access for tools? I know if the game records positions that would make runs several seconds long, but what happens if someone made an "invalid" argument (whatever that may be) for this particular format? Does the game utilize it, or does it ignore it? In fact how abusible is this format?

LLCoolDave wrote:

This seems to be competing for the "Worst looking TAS of 2011" Award.

Posted: 5/30/2015 6:29 PM

Quote

Warp

Banned User

Joined: 3/10/2004
Posts: 7698
Location: Finland

Shouldn't TASes always reflect what is physically possible (at least in theory, assuming a perfect player)? In other words, should TASes be always at least in principle "console-verifiable"? In this particular case, a Doom TAS ought to be acceptable if one could build a device that you connect to the keyboard and mouse ports of a PC that's running doom, and have the machine recreate the TAS by feeding keyboard&mouse input to the PC. (This would be equivalent to a perfect player playing the game.) If the TAS contains things that cannot be physically replicated with mouse&keyboard input only, then is it acceptable?

Posted: 5/30/2015 6:59 PM

Quote

Tangent

Joined: 3/9/2009
Posts: 530

Warp wrote:

Shouldn't TASes always reflect what is physically possible (at least in theory, assuming a perfect player)? In other words, should TASes be always at least in principle "console-verifiable"? In this particular case, a Doom TAS ought to be acceptable if one could build a device that you connect to the keyboard and mouse ports of a PC that's running doom, and have the machine recreate the TAS by feeding keyboard&mouse input to the PC. (This would be equivalent to a perfect player playing the game.) If the TAS contains things that cannot be physically replicated with mouse&keyboard input only, then is it acceptable?

I'm pretty sure that the Super Mario World ACE runs apply input that no controllers can generate, so the answer is seemingly yes.

Posted: 5/30/2015 8:11 PM

Quote

feos

Site Admin, Skilled player (1254)

Joined: 4/17/2010
Posts: 11480
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg

Tangent wrote:

I'm pretty sure that the Super Mario World ACE runs apply input that no controllers can generate, so the answer is seemingly yes.

I'd draw the line between what a game can handle and what a console can handle. If something that a console can't handle is sent to the game, it's breaking the rules. But as long as the console can receive some input, it's legit. So ACE runs that use buttons not present on 1st generation original controllers isn't automatically illegal. Dancing with a tambourine around your console is illegal input, the console has no idea about it. So yeah, if it's possible to send input to Doom that computer can not generate with any of its device supposed to send such input, it is also illegal.

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.

Posted: 5/31/2015 3:31 PM

Quote

Warp

Banned User

Joined: 3/10/2004
Posts: 7698
Location: Finland

abyrvalg mentioned above something that providing the input to Doom such that the end result is strafe50-on-turns would require a specialized joystick software driver or similar. If that's true, then that would mean that it's not possible to get that input to the game via normal means (ie. a normal PC that has its normal/standard OS, drivers and game), even if we allowed an input device that supplies data to the computer that normal keyboard/mice can't produce. If all of this is correct, then it becomes an interesting question whether a TAS using strafe50-on-turns can be considered legit or not. (Argument pro: It's input that the game supports, and could theoretically be supplied to it if we allow special drivers/devices. Argument con: It's input that cannot physically be produced by any existing controller device nor supported by the computer/OS, which is technically speaking against the rules, or at least the principles of TASing.)

Posted: 6/2/2015 7:47 AM

Quote

MESHUGGAH

Other

Skilled player (1918)

Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯

^ g_game.c @272th line. Newbie explanation: if you press the strafe button, using the "turn keys" will change the side speed and won't issue cmd->angleturn. edit: checked the source code and I'm pretty sure that it's impossible to do in vanilla Doom (SR50 and turning at the same time). Some ports have slight modifications that can be abused to SR50 and 180 turn but it's another story. Regarding doomwiki, the wallrunning page also contains ambigous conditions, currently I can't verify my observations without more knowledge of the code. edit2: anyone has the dos ~~port~~ version's source code? only the ticcmd build function required. edit3: judging by the source of (unofficial) Doom External Control API, one could inject whatever instructions to abuse these ticcmd properties. Don't know if the game makes any checks from these inputs. edit4: -control parameter added in Doom v1.4, make your conclusion yourselves. edit5: I tried to register to doomworld.com. Couldn't go past the captcha test lmao. Apart from the already known illegal inputs, note that the units of GF and GB is also limited, meaning you can't change them by 1 press in real (valid, verified) conditions. I've forgot to take this account in to my demo.

PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...

Posted: 6/10/2015 4:29 PM

Quote

Warp

Banned User

Joined: 3/10/2004
Posts: 7698
Location: Finland

Warp wrote:

If all of this is correct, then it becomes an interesting question whether a TAS using strafe50-on-turns can be considered legit or not.

Given that the TASes are being published without even a question, I assume the implicit answer is "yes, it is considered legit". Still would have liked to hear an official argument for why, though. I commented in one of the submission threads that I would almost consider this in the same category as abusing emulator bugs. Of course it's not the exact same thing, but some parallels could be drawn.

Posted: 6/16/2015 3:06 PM

Quote

adelikat

He/Him

Emulator Coder, Site Developer, Site Owner, Expert player (3574)

Joined: 11/3/2004
Posts: 4754
Location: Tennessee

Relevant here I think

It's hard to look this good. My TAS projects

Forum General DOOM rules / detailed informations?

Forum

General

DOOM rules / detailed informations?