Half Life TAS

2009-06-17 11:27:15 am

In this post (http://speeddemosarchive.com/forum/index.php/topic,10143.msg284135.html#msg284135) dex illustrated the power of scripts to create TASes of FPS games, something I've been curious about for some time.

This raises the possibility of someone beating Spider-Waffle's Half-Life run using an enormous script.

I do not have the scripting knowledge to do this (although I may learn and have a go), but I'm wondering if there's anyone out there who does and would considering creating such a run.

Thread title:

Incoherence

2009-06-17 11:35:59 am

I love YaBB 1G - SP1!

Making a script to run 100m in a straight line taking the maker many many hours to do will be nothing compared to the script it would take to run Half Life.

ExplodingCabbage

2009-06-17 11:57:28 am

Agreed it will take a long time, but probably much less than Spider-Waffle took on his segmented run.

Lag.Com

2009-06-17 11:59:13 am

sda loyalist

Quote from ExplodingCabbage:

Agreed it will take a long time, but probably much less than Spider-Waffle took to write his comments.

fixed

krael

2009-06-18 01:29:19 am

Verified verifier and hangaround :)

Quote from Incoherence:

Making a script to run 100m in a straight line taking the maker many many hours to do will be nothing compared to the script it would take to run Half Life.

Dex wrote a little further down in the post, that he created a script completing the level with the fastest time ever in SDQ history.

So it's definately possible, and I would say Quake requires significantly more tricks and bugabusing than Half-Life would. Naturally, HL is alot longer than Quake is, but my point being alot of the game would be the occasional bunny-hopping + gauss-cannon backfiring to increase speed etc.

dex

2009-06-18 07:54:47 am

Invisible avatar

Well, if the core bunnyhopping script was made, it would be reusable for 80% of the run, since the best HL bunnyhop technique is slightly less dependant on speed. With that, the basic tricks like gauss boosting etc. are quite simple; the real effort would be the remaining 10% of the difficult tricks that require a lot of precise controls.

It's way too much effort for me to put in, though, even if the bunnyhop script would be as reusable as I think it would. Especially since that would never pass verification; I mainly did the 100m script as an experiment and to illustrate my 'movement scripts are bad' point. Also, most people from the Quake site doubted a script that would achieve a time that would rank very high was possible (remember, the map is quite a contested one, and as robust as the scripting engine is, mouse movements are still smoother and therefore theoretically more suitable for achieving great bunny results). That an unoptimised script made in a few hours beat all the previous human results by a *huge* margin is what I consider a successful experiment, and I don't intend to spend time on something that would require work of an incomparably big magnitude. Smiley

Well, if the core bunnyhopping script was made, it would be reusable for 80% of the run, since the best HL bunnyhop technique is slightly less dependant on speed. With that, the basic tricks like gauss boosting etc. are quite simple; the real effort would be the remaining 10% of the difficult tricks that require a lot of precise controls.

It's way too much effort for me to put in, though, even if the bunnyhop script would be as reusable as I think it would. Especially since that would never pass verification; I mainly did the 100m script as an experiment and to illustrate my 'movement scripts are bad' point. Also, most people from the Quake site doubted a script that would achieve a time that would rank very high was possible (remember, the map is quite a contested one, and as robust as the scripting engine is, mouse movements are still smoother and therefore theoretically more suitable for achieving great bunny results). That an unoptimised script made in a few hours beat all the previous human results by a *huge* margin is what I consider a successful experiment, and I don't intend to spend time on something that would require work of an incomparably big magnitude. :)

ExplodingCabbage

2009-06-18 07:58:41 am

Do you reckon TASvideos would accept a single-script HL run?

dex

2009-06-18 08:23:30 am

Invisible avatar

I doubt that, however it won't hurt to ask. Smiley

Also, making a single script would be hard (desynchs on level change). However, that could be avoided by making many scripts, binding them to buttons 1-9, and binding a bind cycle to 0; then just using the corresponding binds during the loading of the levels :).

Scepheo

2009-06-18 08:51:09 am

Uhm... The HL source is easy to edit. Simply built in frame advance, savestates and voìla, one TAS-able game done. No need for scripts.

dex

2009-06-18 11:34:19 am

Invisible avatar

In fact, there's host_framerate and saves already. Though hfr almost assuredly changes physics the same way it does in Quake. So no modification needed.

Cabbage meant a pure HL run with just scripts, though, just chose the 'TAS' label for it (since, let's face it, a TAS it would be).

ExplodingCabbage

2009-06-18 12:37:15 pm

Quote from dex:

In fact, there's host_framerate and saves already. Though hfr almost assuredly changes physics the same way it does in Quake. So no modification needed.

And saves cause warping. So Scepheo's idea is a good one and would add something.

Scepheo

2009-06-18 02:21:10 pm

Quote from ExplodingCabbage:

Quote from dex:

In fact, there's host_framerate and saves already. Though hfr almost assuredly changes physics the same way it does in Quake. So no modification needed.

And saves cause warping. So Scepheo's idea is a good one and would add something.

And just to add to the point made, does host_framerate allow you to look at each frame as long as you want, then go to the next one when you press a button?

Plus there are probably a ton more features you could build in, like continuing a previously made demo, memory reading (luck/physics manipulation) and I'm sure there's plentyful more.

Spider-Waffle

(user is banned)

2009-06-18 04:53:49 pm

Don't think! feeeeeal

Would be interesting, I really don't think one script would be plausible, the slightest change in fps would desync it easily. I think you'd in the least need to make a new segment and script for each level. It would be a lot of work, at least 3 years I would think. I'd be really impressed if you could just write a script that could beat my first level time, like the first 7 seconds of the game.

I think the HL TAS mod would be a much better way to go. A truely optimized TAS would be impossible, but a good one would have the screen constantly shaking violently, like vibrating basically.

Scepheo

2009-06-18 05:15:00 pm

If done right, a TAS-mod should be useable for all game running on this engine (and the experience could be used to make a TAS-mod for Source games). And I think that if it's done, they'll discover quite a few new tricks that can only be done when you have frame-by-frame precision. So my guess is quite some time could be shaven off. It'll probably look awful though (as Spider-Waffle said, you'll basically be making hard right and hard left turns every other frame) but it should be fast as hell.

krael

2009-06-19 12:46:26 am

Verified verifier and hangaround :)

Quote from ExplodingCabbage:

Do you reckon TASvideos would accept a single-script HL run?

I'm pretty sure they would.

I just asked in there, stay tuned for an answer.

error1

2009-06-19 02:53:39 am

Not a Zelda 2 refrence

Tasvideos wouldn't accept a video or a script, but they might accept a demo file. Right now they only accept movie files for emulators so there would have to be an new rule to allow it.
A modded HL that could record demos that would sync on the unmodded game seems like the way to go.

Scepheo

2009-06-19 07:11:46 am

Quote from error1:

Tasvideos wouldn't accept a video or a script, but they might accept a demo file. Right now they only accept movie files for emulators so there would have to be an new rule to allow it.
A modded HL that could record demos that would sync on the unmodded game seems like the way to go.

From a previous thread, I got the idea that demo's contained entity positions and states rather than input. So unless you actually add objects/weapons/characters to the game (which, for a TAS, you shouldn't) demo's will always sync on the unmodded game.

error1

2009-06-19 10:34:24 am

Not a Zelda 2 refrence

I didn't realize that but it it makes sense. TASvideos doesn't normally need to check submissions for cheating because if it syncs and beats the game then it's imposable to cheat, I guess you can't do that with demos.

Kabuto

2009-06-19 12:45:19 pm

TASVideos will only accept "demos" that contain player input only; for new demo file formats you even need to proof to them that it's actually that way (usually a documentation of the file format will do, there are many coders over there who can verify such demos).
Of course, that requires modifications to Halflife, most important that it always advances a fixed (or possibly variable but then of course also stored in the demo file) amount of game time between 2 consecutive frames, to ensure that the demo file achieves the same result when played back.

Is such modding of HL possible? AFAIK they never released the source code.

OlikA

Edit history:

OlikA: 2009-06-20 12:03:59 pm

2009-06-20 11:23:55 am

I think that you are not familiar with fps-death (http://kreedz.pri.ee/download.php?view.5) or demolyser (http://www.a-gaming.ru/files/view/cs/904.xhtml).

Of course these applications are not able to generate raw input from demos, but you have a GREAT chance to filter out cheaters. Better than nothing, if you ask me.

Kabuto

2009-06-20 03:07:04 pm

You're right, I didn't know these tools. But on TASVideos they want absolute certainty that a "demo file" is legit. And for TAS this can only be provided by demo files containing input only.

Scepheo

Edit history:

Scepheo: 2009-06-22 06:24:54 am

2009-06-21 11:59:03 am

FPS doesn't matter for synchronization, as the demo file simply contains the input that was processed each frame. So the first frame it reads the input of the first frame, the second frame it reads the input of the second frame. Time doesn't matter. If the game lags, so will the input. If the game runs at 5 billion FPS, it will read the input at 5 billion FPS.

The problem lies in the fact that HL is a PC game, and therefor loading doesn't always take the same amount of frames. Which means that sometimes you'll have to open a door on frame 1267, and other times at frame 1294. That's what causes desync.

Spider-Waffle

(user is banned)

2009-06-21 10:20:49 pm

Don't think! feeeeeal

Of course you could go on with the project even though TASvideos won't host it; I'm sure many other sites will. Not that youtube isn't the one that will get you most popularity anyway.

quadrazid

2009-06-22 01:18:17 pm

Svart Lyser Tronen

Quote from Scepheo:

does host_framerate allow you to look at each frame as long as you want, then go to the next one when you press a button?

Plus there are probably a ton more features you could build in, like continuing a previously made demo, memory reading (luck/physics manipulation) and I'm sure there's plentyful more.

I really don't see what frame by frame advance gonna add to HL speedrunning, but the other stuff sounds great!

It seems interesting.

Scepheo

2009-06-22 03:01:27 pm

Quote from quadrazid:

Quote from Scepheo:

does host_framerate allow you to look at each frame as long as you want, then go to the next one when you press a button?

Plus there are probably a ton more features you could build in, like continuing a previously made demo, memory reading (luck/physics manipulation) and I'm sure there's plentyful more.

I really don't see what frame by frame advance gonna add to HL speedrunning, but the other stuff sounds great!

It seems interesting.

Being capable of jumping the exact first frame you hit the ground for perfect bunnyhopping, without scripts or any unnecessary input due to mouse wheel spamming. A frame is the smallest unit of "game" happening. So if you do something on the first frame possible, you're literally doing it as soon a possible. It can be done no sooner, absolutely not.

So you can press the use button the first frame possible, for optimal door opening. Or trigger events by standing in the "trigger area" for exactly one frame. And you could find new bugs that require frame perfect timing.

[quote="quadrazid"]
[quote="Scepheo"]
does host_framerate allow you to look at each frame as long as you want, then go to the next one when you press a button?

Plus there are probably a ton more features you could build in, like continuing a previously made demo, memory reading (luck/physics manipulation) and I'm sure there's plentyful more.
[/quote]

I really don't see what frame by frame advance gonna add to HL speedrunning, but the other stuff sounds great!

It seems interesting.
[/quote]
Being capable of jumping the exact first frame you hit the ground for perfect bunnyhopping, without scripts or any unnecessary input due to mouse wheel spamming. A frame is the smallest unit of "game" happening. So if you do something on the first frame possible, you're literally doing it as soon a possible. It can be done no sooner, absolutely not.

So you can press the use button the first frame possible, for optimal door opening. Or trigger events by standing in the "trigger area" for exactly one frame. And you could find new bugs that require frame perfect timing.