Sorry if this belongs in Windows Games, I figured it'd be more relevant here since this is about engine modding rather than TASing the actual game...
Short version is, I'm going to be working on glq-rr and q2-rr, which will be rerecording versions of GLQuake and Quake 2.
After some discussion, these are going to be based on as unmodified as possible source bases for maximum authenticity, but with some input timing tweaks to improve consistency.
For Quake 1, authentic behavior is 10-72 FPS depending on how fast the game can get input. However, because Quake 1 uses non-incremental timestamps that are almost always 10 FPS aligned, running at 72 FPS causes animation-bound actions to act 10% slower than intended. Because of this, frame time will be set to 1873 / 2^14 seconds, which is just enough slower than 70 FPS to prevent frame slippage for 80 seconds, a.k.a. the slowest level in QdQwav.
Quake 2's maximum client FPS is configurable, but the default range is 20-83.333 due to the rate limiter being msec based. I'm going to change that to 100 so msec times are consistently 10, also aligning with the server's fixed 10 FPS rate.
The input will allow anything that can be legally sent to a server, which includes effects from manipulating the move speed cvars. Console commands will be allowed in Q2 as long as they are commands that transmit to the server to prevent malicious use.
glq-rr will work with Quake-compatible mods, but q2-rr will not.
Google Code page:
http://code.google.com/p/qtasI've uploaded an alpha build to the Downloads tab!
See http://code.google.com/p/qtas/wiki/ConsoleCommandsAndCvars for a list of console commands and cvars you can use. Note that you need to actually be in a game for the vast majority of them to work.
If you need to launch it in windowed mode, use the -width -height and -window command line parameters. i.e.:
glq-rr.exe -width 640 -height 480 -window
If you want mouselook permanently enabled, you should create a file named autoexec.cfg in id1 with the text:
+mlook
Known issues:
- Pause does not sync. Pausing from menu and console has been intentionally disabled. It's my intention that pause will be re-enabled in later builds because it can be used to manipulate the RNG, but there are problems with getting it to display correctly.
- View will drift if playing back an input file with mouselook disabled.
This is very interesting, q1 was the game that got me into speedrunning and i have always wished TASing for it to come some day. Cvars seem interesting, i'll test later today.
TAS Quake ? Human records are already very high, games have been done to death.
How do you intend to (help) make a TAS more entertaining ? Is it even worth the effort ?
I never sleep, 'cause sleep is the cousin of death - NAS
Why not? Same could be said about any highly optimized game. There are always new tactics to use in TAS, given how complex quake is. The only drawback would be non-smooth mouse movements in frame advance demos which could hinder (or just completely destroy) entertainment for casual players.
That being said, i tested rerecording today and everything worked perfectly (i've just used low timescale and savestates in e1m1 though), except for explosions, which werent visually completely erased after loading a savestate. Also rr_recordinput cvar does not exist?
p.s. Is it possible to include a speedometer? Like the one that is used in half-life runs.
TAS Quake ? Human records are already very high, games have been done to death.
How do you intend to (help) make a TAS more entertaining ? Is it even worth the effort ?
There are runs on the site barely faster than the current human record (i.e. SMB), but even barring that, there are plenty of things which could probably be optimized by better movement and shot timing, especially since both are very dependent on timed-fuse explosive boosts.
FWIW, I don't plan on making any runs with this. I know next to nothing about speedrunning Quake, I just know a lot about the engine internals, but I've seen people wishing something like this existed, so I'll make it exist.
abyrvalg wrote:
The only drawback would be non-smooth mouse movements in frame advance demos which could hinder (or just completely destroy) entertainment for casual players.
I'm considering adding playback smoothing to mitigate that if it becomes a problem, viewpoint memo is definitely happening.
except for explosions, which werent visually completely erased after loading a savestate.
Yeah this is kind of expected. Fixing effects that go away on their own is kind of low-priority, but if you run into anything that doesn't go away (i.e. I think door noises are sticky right now), I'll see what I can do.
Also rr_recordinput cvar does not exist?
Fixed the docs, that cvar doesn't exist (use rr_record).
p.s. Is it possible to include a speedometer? Like the one that is used in half-life runs.
Frame counters and other important figures in the HUD are on the short-term todo.
Also, qgl-rr should work with Quake server mods (i.e. new progs.dat), and they should stay synced unless the mod makes unexpected RNG calls.
I'd absolutely love to see a Quake TAS run. I tried to make an IL run of e1m1 Nightmare 100% using your mod but I ran into some issues (mainly with the Grunts behaving differently when playing back the inputfile). I'm not sure if this is caused by me using the mod incorrectly or if it's an issue within the mod itself. Anyway, this mod is definitely a good start and could become great with a bit of polish.
Uploaded a new version to fix the probable cause of the desync issue:
http://code.google.com/p/qtas/downloads/detail?name=glq-rr-v121210a.zip
Server actions that normally execute before the client gains control (4 frames) are now properly executed when rr_framelimit is zero, and time-based RNG advances will no longer desync if frame stop is disabled by a console command.
