^ 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.)
Assume that some console game could be made to do things that are not normally possible by using a modified emulator. In other words, an emulator that's not emulating the hardware completely accurately, but has something extra or modified about it. Would that be acceptable?
Because I would consider using a custom driver completely akin to using a modified emulator. It's not something that's done with solely controller input on an unmodified game running on an unmodified machine anymore.
Emulator Coder, Site Developer, Site Owner, Expert player
(3580)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Warp wrote:
Assume that some console game could be made to do things that are not normally possible by using a modified emulator. In other words, an emulator that's not emulating the hardware completely accurately, but has something extra or modified about it. Would that be acceptable?
Because I would consider using a custom driver completely akin to using a modified emulator. It's not something that's done with solely controller input on an unmodified game running on an unmodified machine anymore.
I don't agree with your analogy at all.
In Doom, you set up your drivers. What drivers do you think should be allowed then?
In more modern consoles with flash ROMs and support for firmware upgrades, would you consider it valid to use a custom firmware (that allows doing things that are not normally possible)?
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.
In more modern consoles with flash ROMs and support for firmware upgrades, would you consider it valid to use a custom firmware (that allows doing things that are not normally possible)?
That's not a suitable comparison. Doom supports X and Y, most things provide X input, some things provide Y input, you want to ban the use of Y input because... it's less popular? In your example you're talking about modifying a console to support more than it originally supported, extending its support, or changing what it supports.
Emulator Coder, Site Developer, Site Owner, Expert player
(3580)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Alyosha wrote:
, 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.
We could do that, but the reality is that we are only going to get submission for one of those types. The Doom TAS community has already settled this over a decade ago. The TASers and the community are already establed and their notion of a TAS record is already set. Imo, it seems silly to arrive a decade late to the party and try to start setting all the rules.
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.
Joined: 4/17/2010
Posts: 11541
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I'm finally catching up on this subject yay!
adelikat wrote:
Imo, it seems silly to arrive a decade late to the party and try to start setting all the rules.
Agreed. 2 decades late is much better!
Linguica wrote:
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 really feel allowing unhinged input digitally possible with External control driver (which was in fact used by a few real devices) is the only way.
If we rely on what is possible on keyboard+mouse, then strafe50+turning should be banned. But it's traditionally allowed in replay files... because it's possible to do it with External control driver... which makes a whole bunch of other non-standard inputs possible... which are still banned regardless.
There's no logic in the current rules, only whatever happened to be a tradition, based on community feelings and things like https://compet-n.gamers.org/index.php?page=compet-n_rules
Indeed in TASing, we don't care which input devices you use, we only care what is digitally possible to send to games (left+right, hidden SNES buttons, etc). Doom absolutely supports all those non-standard inputs and processes them fine.
Yes LMP is a problematic format, and it's probably too late to make it go away, especially when we can't offer a better alternative. And nobody is TASing Doom on DOS in libTAS.
But I just wondered what should be allowed in a theoretical Doom source port for BizHawk (which nobody ever asked for lol), and it made me study this subject.
Best we can do is provide a config option to enable/disable External control driver, which would apply different limitations to possible range of input. But it doesn't look like it's possible to make a converter from LMP into emulator presses, because LMP hosts player actions not inputs, and it lacks a bunch of meta actions like menu access.
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've TASed Doom quite a bit over the last few years and thought I'd share my thoughts about movement speeds and input constraints, but the more I've thought about it the more I realize how unusual some of the Doom community decisions and historically accepted standards regarding this topic have been. Existential crisis time?
Anyway, my opinion has always been that if the original, unmodified game could be controlled with real, commercially available hardware as was detailed in Linguicas Doomworld thread linked above, then any inputs producible in that scenario are fair game, especially in a TAS context of all things which surely is the absolute pinnacle of seeking to exploit game quirks such as this. The fact that that input device may not be a typical one like a keyboard or a mouse to me is irrelevant; it may of course be a niche and uncommon device, but if it is a real one that really exists and really works it is no less real or legitimate than a keyboard or mouse. Mentions of parallels between this situation and a modified emulator, custom console firmware etc are, I think, not fair comparisons because the examples given in that Doomworld post are of the original Doom 2 executable, not a game that was modified to implement some otherwise unavailable in-game feature. I'm specifically interested in whether the inputs are technically legitimately possible in any context, not whether they are likely or common or easy, because that is the criteria I personally feel needs to be met before I start deliberately placing SR/SL50 on turns in my demos, and I feel it has been.
Not that this was really brought up, but I also think that whatever implications this may have for non-TAS speedruns are irrelevant for the purposes of determining what is acceptable in a TAS context. It's an interesting and probably important discussion for the Doom speedrunning scene but I don't think any outcome of that discussion could have any influence on the legitimacy of those inputs in a TAS, for the reasons above.
Regarding turbo stuff, runs that have player inputs exceeding a movement value of 50, whether that value is as low as 51 or as high as 128, have been historically differentiated as turbo demos. If those speeds could be reached without the -turbo launch parameter by using certain hardware, then I suppose the distinction is ultimately somewhat arbitrary, but I feel keeping input values at or below 50 is a sane line in the sand and I absolutely think that having the distinction is worthwhile, as the game becomes very different with turbo inputs. If your movement values are 51, they may as well be 127/128, but a run with these speeds is massively different with very different considerations. I also think that because it allows you to very quickly and easily reach the games speed cap of 30 units/tic which is otherwise unreachable with regular running speeds, it removes a significant part of the skill required to TAS well, another reason to differentiate the two. Turbo runs and "regular speed" runs are apples and oranges IMO, for more reasons I could get further into but wont here. Turbo runs are great but they're their own thing.
Also just as some fun trivia it may interest you to know: Doom accepts a strafe-right value of 127 and a strafe-left value of up to 128, HOWEVER, the maximum value for both move-forward and move-backward is 127. This is because a "move backwards 128" input happens to be the exact byte value that happens to be the demo end marker of the .lmp format. This means it is technically faster to always be straferunning to your left instead of your right in a built turbo demo using the maximum accepted speeds, though the difference is so minor that it would be incredibly unlikely to save even a single frame.
Anyway, frankly I dunno how much this will impact any decisions or directions or anything but I'm quite interested in this stuff and couldn't help but chip in.
----------
Another thought I had while writing this is that I guess TASVideos.org is not necessarily constrained to the .lmp format. It is the standard within the Doom community for historic and strong pragmatic reasons, I think it's a very valuable and useful thing, but that could just be me talking from a position of being so used to them that I can't really imagine otherwise. The reason I mention this is that one of their primary constraints is that turning angles when recording demos are constrained to 256 different values (referred to as shorttics), where as you have up to 65536 turning angles (referred to as longtics) in typical play. Longtics make it significantly harder to perform certain tricks like glides and tricks where you stick to walls to maintain/gather momentum, but they also technically present an opportunity for an extremely small degree of optimisation in an extremely optimised TAS setting, and also may be more generally comfortable to a TASer that isn't concerned with extremely razor-sharp optimization of movement tricks. I won't be moving away from producing .lmp demos for my Doom TASes but it'd be interesting to see a format that did something different.
Oh, and another restriction of the .lmp format is that you cannot record multiple episodes of Doom 1 in the one demo, which prevents full game runs. The solution would either be adopting the -chain_episodes feature of the DSDA-Doom source port (which raises its own dealbreaking concerns, mostly that the pRNG value when moving to new episodes from prior ones has a 1/256 chance of being the proper one when starting the episode normally & that it'd completely remove any hope of verifying the runs on the original game) or, obviously far more likely, developing your own format.
I'm not proposing moving away from .lmp, just sharing my thoughts :) I'm keen to keep an eye on any discussion surrounding this topic.
Joined: 4/17/2010
Posts: 11541
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Wow thanks for the post, almostmatt1! I think your input here is infinitely valuable as you've been the one producing top-notch movies using the old method for years, and you have both the first-hand TASing experience and technical understanding of how things work in the game in general.
I agree that this can't be solved how we liked to solve things 10-15 years ago by simply imposing another limitation nobody asked for. We've officially become author focused, and it's clear that both input methods are incredibly interesting to the authors as well as the viewers. The only tricky part is drawing the line between those 2 methods lol.
I completely agree that whatever is digitally possible to send to the game, and whatever is can process, is legitimate input in a TAS setting. So use of external input API is essential for unlimited Doom experience. On the other hand there's several decades of tradition and it has its value that's beyond just nominal. And one of the most tricky subjects is that there's discrepancy between what can be sent to the game using keyboard+mouse and what a demo file can contain.
I think if we end up having a bizhawk core for Doom, the unhinged input option (relying on external input API) is a must, because TASing is about pushing games to their legitimate limit, we're just interested in the very concept of that. And with that input method there's a ton of room to go beyond LMP limitaitons. If it makes the game easier to TAS then it's an incredible plus because the core may end up seeing some use in its own regard.
Then there's demand for it to be compatible with LMPs because it's what all past and current Doom TASers use. So exposing all the LMP input (which is events and not kypresses) also sounds like a good option, like a different controller type. It's unclear to me how it'd work with the core, because then it'd need to run those events like there's an LMP file currently being replayed. Otherwise how else do we handle the menuing and all that meta stuff?
And finally as some middle ground, to me it makes perfect sense to just expose keyboard+mouse as any other core would, to be the most faithful to running Doom on your machine as is, without LMPs or unhinged input drivers. Basically a casual Doom frontend, that also happens to have all the hawk features.
I'd personally make the keyboard+mouse control scheme the default, and provide an option to switch to LMP format input or to external input API input.
For sure the latter would look completely different from anything we've seen before in Doom, so it'd perfectly be its own separate category. The difference between LMP and keyboard/mouse may be smaller tho. So I'm unsure if there's need to be a category distinction between them. Maybe yes? But if it's only a difference of a few frames, then maybe not? Maybe they'd be within the same category and we'd just judge by whether overall speed tech has improved or not?
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.
LMP, regardless of its flaws and the -args approach to set it up, still saves all necessary information.
In Doom 1 (aka Ultimate Doom) you cannot play another episode after you finish one. You stare at the ending screen with the text being printed in. No action can be done to jump to the next episode immediately. You need to press Esc, select another episode and difficulty, like you would do if you start that episode on the first place.
Metadata stuff will look the same in all TASes: you invoke Main Menu, select episode (if it's Doom 1) and difficulty, and all this will take a couple of frames. Does it worth it? In some emulator core settings you can set a specific date and time to get a better RNG for your TAS. Why not do the same for Doom, including other LMP demo header parameters, including the episode number and the difficulty?
Another niche point is killing monsters and the main hero at the end of Doom 2, which LMP doesn't record (it gets stuck at Zombieman), but it's not needed in a TAS.
--
Regarding "keyboard + mouse" input, I dislike this idea.
Keyboard gives you a limited set of possible inputs. Mouse has to command all other input ranges for your movement and your turns.
In case of Strafe50, it requires more manual actions. To make SL50 (strafe left), you hold A, Run button (in case, you have autorun = 0 in your dsda-doom.cfg), Strafe button and drag you mouse all the way to the left. I will go nuts if I have to do this in TAStudio, even with its frame copy-paste-clone options.
Maybe you can achieve MF50 SL50 with mouse input alone, I don't know, but it's gonna be another torture to enter mouse coordinates, like (255, -255) or (65535, -65535), to achieve this.
You may propose to use an input interpreter then, to ease the entering of input, but it begs the question: why do you specifically need "keyboard + mouse" input if you effectively end up doing the same that LMP format already stores in? I don't know how the input gets parsed by the game, but I won't be surprised if that's the way the game actually does it.
To quote my proposal from Discord,
"It's gonna be much easier to update XDRE with a "real-life human gadgetless control" mode (or compet-n control restrictions) which will automatically fix MF50...127 to MF50, and change SR50 to SR40 if turning commands are present."
TASing is like making a film: only the best takes are shown in the final movie.
Joined: 4/17/2010
Posts: 11541
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Options exist for people who prefer different things. For casual play you don't think about how many degrees of movement you're currently sending to the game, or what your exact speed is. You just use the same things it was normally played with - keyboard and mouse. Bizhawk is not limited to TASing, it's used by lots of people for casual play too, one of the reasons being better user experience than what retroarch offers. Then there are probably people who want to experience this game the same regular way as every other bizhawk core allows, while also using some TAS tools. Nobody is going to lose anything simply from us providing people options.
In Doom 1 (aka Ultimate Doom) you cannot play another episode after you finish one. You stare at the ending screen with the text being printed in. No action can be done to jump to the next episode immediately. You need to press Esc, select another episode and difficulty, like you would do if you start that episode on the first place.
This to me is a hint that we can't limit it to the LMP control scheme, because to be 100% compatible with LMP replays we'd have to limit that control scheme to what that system has. You can't tell bizhawk to run several LMPs during the same movie recording session that is usual to hawk. It's either one or the other, hence the option which to use for a given session.
It's gonna be much easier to update XDRE with a "real-life human gadgetless control" mode (or compet-n control restrictions) which will automatically fix MF50...127 to MF50, and change SR50 to SR40 if turning commands are present.
Again why not have both? It's possible to TAS MAME and Amiga in libTAS but we still added them as bizhawk cores, just because that user experience is valuable too. And people who didn't have years of using some pre-existing setup for Arcade TASing are currently prefering bizhawk over libTAS. Whoever prefers XDRE will just keep using it, or maybe switch.
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.
