^ 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: 11537
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.
