Exactly which version do you refer to as original? I got no results with 1010, 1107, 1110.
I wonder if Spider-Waffle knew about this, but maybe he didn't use it because it was rather extreme? (like the healthdoor glitch).
He didn't know about it at all, or any other fastfire tricks. And the health door would be pretty extreme relative to the pretty weak advantage. Since he was limited to 100 fps the door was ten times less effective compared to HL21.
Nope, the Super Mario 64 TASes make testament of the tricks that are completely impossible for humans to perform. Such as the backwards long-jumping, specially the Infinite Staircase skip.
Irrelevant to the point. The point being that HFR isn’t possible in realtime. Imagine a TAS bot playing in realtime, it wouldn’t be able to use HFR glitches. Hence HFR glitches wouldn’t be legal for a TAS either IMO. But the runner in question approved that a HFR category would be suitable so it doesn’t matter anymore.
Besides, aren’t that SMB trick just limited to the standard joystick not being able to press up and down simultaneously?
I was also wondering what bound you to just 100aa? Why not 1000 or 10000? And why not 100000 maxspeed and 100000 maxvelocity?
This is what I don’t like with changed server settings, it quickly goes out of hands.
I must say I’d like to see if you can beat my noclip run though : p
Hmmm… I get it. You’re right about his FPS disadvantage, it would take him ~40 seconds to get to ~4000hp and to make up for that he would have to make damage boosts all over the place. I understand, though, that he didn’t use the Healthdoor glitch because:
This run does not make use of the infinite health door glitch which was discovered while the run was in progress. I thought the glitch was rather extreme and would take away the beauty of all the exact health and armor planning.
First: I need you to define “real time”.
Second: Irrelevant indeed, and I understand your point, however I’m just letting you know that “If possible in a TAS, then, it should be possible in a RTS” is not a rule of thumb in the creation of such runs. I don’t know how did you come to this consensus. You can’t Backwards Long Jump in SM64 in a RTS, you can’t use HFR tricks in HL in a RTS.
Also, you’re confusing two games with two completely different physical engines, and it’s probably from the SMB runs that you came to the above conclusion: The fastest SMB RTS so far is 4:58.14, and the fastest SMB TAS so far is 4:57.31… I think you’re getting my point by now.
What? BLJ’s are not only completely possible in real time but they are very easy as well, and a crucial part of the “16 Star” RTA category. Not sure where you got that idea.
Also untrue. As someone who has done TAS work with SM64 and Ocarina of Time, opening up the emulator does not suddenly give you magical powers. You are still forced to play within the limits of the game. Note that completely impossible != not feasible. Everything you see in an SM64 TAS is POSSIBLE in real time, but due to the nature of the trick that would assumingly require multiple frame perfect inputs in a row, it is not realistic to do in real time (it would be very, very hard). For reference, here is a video of the 120 Stars SM64 TAS with all the inputs being fed into a console. https://www.youtube.com/watch?v=BFBGWrGT1E8
My point is that, like others have said, if it is literally not possible or cheating in a real time run, it should not be used in a TAS. This is a rule for the TAS of any other game, and is just common sense.
Unrelated, but the TAS of SMB uses SDA timing (from power on) while RTA runs start as soon as they gain control of mario, so the TAS, converted to real time, is about 4 or 5 seconds faster, rather than 4 frames as a lot of people seem to think.
HFR isn’t only slowmotion. It bends time on every axis. If Half-Life could be replayed like demonstrated above, HFR would simply not be feasible in my mind at least.
Well fuck, I stand corrected. Just watched the 0-star run in SDA. The guy clearly uses BLJ with an appropiate set up in a few places… and at the infinite staircase too.
I have exagerated indeed then, however console verification doesn’t demonstrate that the run can be done using your fingers and a controller, just checks for emulation hacks and such s tuff. Also, careful planning of inputs to achieve a trick that are very unlikely to do with just pushing buttons =/= magical powers, I never said that.
This is the fourth correction I get in less than an hour, I think I should start watching more videos and getting my facts straight instead of relying from my shitty memory and assumptions.
Okay we’re getting a little off-topic now, I think we should make a poll whether people want to see Movement Stalling in a future TAS by airstrafers’ team.
We did our testing on Protocol version 45, 1.1.0.8. It’s strange that the trick doesn’t work on the versions you mentioned. A moment ago we downloaded the version of WON you linked in the tutorial thread, and yeah it didn’t work. Perhaps the code for these versions is too old.
Thanks for testing on those versions.
You need to be clear whether you’re referring to movement stalling or host_framerate itself.
[ul][li]If you mean movement stalling, then yes you’re absolutely right in that it isn’t legal for TAS and we most likely won’t use it in our runs.
[/li]
[li]If you mean host_framerate itself, then the phrase “bends time on every axis” is misleading. As we argued earlier, as long as you restrict the range of host_framerate (i.e. don’t go below 0.001) for easier recording and fairness, then it doesn’t change the physics or anything like that.
Think of it as a tool for recording. If a demo is recorded with host_framerate 0.001, the result would be indistinguishable from another demo that is recorded in constant fps_max 1000. If you think (for example) host_framerate 0.004 screws the game up as compared to fps_max 250, then please tell us exactly what game physics is altered. As far as we know, changing host_framerate doesn’t introduce any glitches unless the value is below 0.001 or above 0.05, corresponding to above fps_max 1000 and below fps_max 20. That’s why we agree to restrict them after reading your initial post.
[/li][/ul]
In principle we could do TAS using fps_max 1000 and not host_framerate 0.001, but then we have to pray to Zeus, Thor, Shangdi, Vishnu and our ancestors so that the game doesn’t lag or conspire against us. host_framerate 0.001 is lag-proof and desync-proof, unlike fps_max 1000. In real time it is very difficult to get rid of desync, but in theory, it is possible if you have a sufficiently fast computer. Wikipedia on TAS (emphasis by us):
“To find a game’s theoretical limit — runners are interested in discovering the fastest possible completion time for a game with perfect play.”
That’s because 100AA is the most common alternative to the usual 10AA category. Many people are familiar with 100AA and many people have some experience strafing in this setting. In contrast, much fewer people did any strafing in, say, 1000AA, 10000AA, 123AA, 321AA, 1111AA, 48375890182930AA and so on. This is likely the reason why Zezima242 did a 100AA run instead of 234AA, 1337AA, 100000AA. Also, almost no one did runs in sv_maxspeed 100000.
100AA is part of the culture. It’s not as arbitrary as it may seem. Even the Kreedz tutorial mentioned 100AA. Everyone from all over the globe in the kz community knows what 100AA means. Not to mention the countless maps out there that are designed just for 100AA. Surely you did quite a bit of testing in 100AA too, otherwise you wouldn’t have known that the test chamber can be skipped by strafing alone as you pointed out in Zezima242’s thread.
It’s clear that 100AA is a widely recognised category.
We don’t intend to do any run in 1000AA. We also don’t want to change sv_maxspeed. That reply to Arianon was just for academic interest: we love studying the maths of strafing and we (naïvely?) want to share the knowledge. We’re truly sorry if this offended you, but your reaction to that is quite strange and puzzling.
Well maybe by a few seconds at most? Though a TAS like this should be quite easy to do. Just calculate the exact viewangles and the number of "wait"s to put. Alternatively, write down a bunch of viewangles for each map on a paper, then during the run use Bunnymod Pro to check the viewangles while noclipping.
Edit: Oh you mean beating your noclip run with our 100AA TAS? Well, we’ll see
Yeah, 100aa is integrated into the community, judging by the amount of maps designed for it. At least half of bhop maps are designed for 100aa. Perfect 1000 fps though brings up the side of it nobody have ever seen before - up to 2k in 4.446 seconds is well… Unexpected. As for me, I’d love to watch (and do :o) 100aa 1kfps TASes, because they seem to be pretty intense.
Someone should do a TAS of Half-Life with all these craziest techniques and host_framerate commands (no sv_airaccelerate tho). I really want to see by how much this game can be destroyed.
We did our testing on Protocol version 45, 1.1.0.8.
Wasn't that the version when Bunnyhop cap got introduced?
http://wiki.sourceruns.org/wiki/Game_versions
I was mainly refering to glitches caused by HFR, such as movement stalling. So I’m pleased that you agree with me on that one.
And if you’re sure there is no other effects on the HFR range you listed. It seems fine to use for any non realtime speedrun. So I think we understand each other.
About 100AA. The testchamber skip was just a qualified guess from my side. I only have experience from 100aa in CS surf maps. 1) Those maps that are designed for 100aa. Half-Life however is not.
"To find a game's theoretical limit — runners are interested in discovering the fastest possible completion time for a game with perfect play."
2) Using 100aa sets a new theoretical limit irrelevant to the standard game and other speedruns.
Those two things is why I don't like 100aa or other changes.
You are ofc free to do whatever you want. It will surely be one hell of a speedrun. But it will be viewed upon like Canine described.
Oh you mean beating your noclip run with our 100AA TAS?
So I’m testing the autojump part of high aa compatibility, and I seem to have a mistake in there… TAS team, can you check what is the fastest possible time from 0 to 4k ups? Use any accelerate and airaccelerate, sv_maxvelocity set to 4000 and standart sv_maxspeed (320). I got 4.288 seconds and if there’s no error in my calcs, then it’s the fastest way to get to 4k with any accel/airaccel and standart maxspeed. Well, not counting the float precision and anglemod mistakes.
Nice work, that’s very close to our time. In [tt]sv_airaccelerate 100[/tt] and [tt]sv_accelerate 1005[/tt] we got 4.242 seconds. Increasing those values won’t change the result. We have an algorithm to somewhat deal with anglemod, which is probably the reason why we’re slightly faster here.
We jump when the speed reaches 3565.571 ups, which is after 590 frames of groundstrafing. We found the “boundary speed” simply by solving this equation.
Yeah, my equation seems correct. For sv_accelerate 1005 and sv_airaccelerate 100 the result bordervel ends up set to 3565.519043. Maybe I’m missing something on float precision, but whatever. I’ve yet to try actually timing 0 to 4k on this ground accel (I used 1000), I’ll add to that post as soon as I do that.
Update: same time.
I added a console print to PM_Accelerate to see where the problem might be, and I get some weird stuff: even though in client I set my angle so that the angle between current velocity and wishvel is 90 degrees (currentspeed should be equal to 0), but the log shows that currentspeed is actually even up to values like 0.28. It also varies between server PM_Accelerate and client PM_Accelerate, but large values pop on both sides.
Few months ago we discovered that the game seems to do evil things like [tt]pmove->angles[YAW] = anglemod(pmove->angles[YAW])[/tt] before pm_shared computations at the server side. This means that usually the yaw angle you set in client will not be the same yaw angle received by the server. The code that does this resides in some closed source part of the game engine which you can’t modify.
There is a float to int cast in anglemod, thus rounding the yaw angle slightly. For example, if 123⁰ is the yaw angle you set in client, then the server will receive anglemod(123) which is 122.9974365⁰. See that this is a multiple of 360/65536 ≈ 0.0054931640625. Consequently, the angle between wishvel and pmove->velocity will not be exactly 90⁰ and so currentspeed is nonzero. The strafing inevitably becomes less perfect.
I attempted to make a simple algorithm that reduces the anglemod effect in some cases, but that brought the time down only by 0.001s, as I thought. So it is really my fault somewhere in the angle calculation code probably. I think I will just upload the current version, and if I figure out what’s causing the problem I will update the relevant parts of the mod.
Though a TAS like this should be quite easy to do. Just calculate the exact viewangles and the number of "wait"s to put. Alternatively, write down a bunch of viewangles for each map on a paper, then during the run use Bunnymod Pro to check the viewangles while noclipping.