@@ryankeathley995 the only major change was linuxbugs no longer working, the only other change I heard of was that sometimes stickies now phase through walls (which is less of a mechanic tweak and more so just annoying :/ )
It's more that it prevents players from turbofucking their bullet hitbox positions (because Valve couldn't be bothered to tween properly) by spamming crouch while in midair to essentially make it impossible to hit players with hitscan.
Linux bug is probably the most intriguing one imo. As far as I recall, it's smthng to do with how Linux version of TF2 (server/client) calculates the axis and rounds it out or smthng? I vaguely recall reading it, still fascinating
What I'm guessing, is that when glibc (The most widely used implementation of the standard C library on Linux) is asked to turn a float into an integer with no further context, it runs floor() on it, where the standard C library on Windows runs ceiling() on it instead.
The way I understand edge bugs and slide bugs is that physics in tf2 is handled on a subtick level, while things like teleport triggers and landing checks are only handled once per tick. For example, in a slide bug you need to first hit the floor and then the ramp. If this happens inbetween two tick updates, then tf2 will not have registered that you've landed, so you will keep all your momentum going into the ramp.
Edgebugs are kinda consistent though. if it were how you said wouldn’t it fail frequently? You can recreated edgebugs 9/10 times if you have the skill.
@@frostchak2163 They do randomly fail from time to time (similar to how bounces are random). Tempus has had to patch maps with intended edgebugs (adding something called auto edgebug) to make them consistent. A good example of an edgebug that fails is jump_dan2 bonus. If you jump off normally then you practically can't hit the edgebug, but if you crouch jump off, then you can easily hit the edgebug.
Such a good video, I watched it without skipping a thing actually. Im highly interested in bugs since my bed was infested in them. Such a good job with research, people you coresponded with, amazing edit with visual additions to the topic and your knowledge. Thanks for your work, I hope it is highly appreciated by community.
Great video, thanks for the help! After watching your wall bug section I started hitting them consistently! No one really explained how to do it that well to me and I missed out using them in comp career.
Unrelated but I saw your music choice and I have to say I love the overlap between jump and celeste players. It makes sense considering that at an even medium level theyre both about doing really technical moves that let you go at insane speeds.
The rounding error isn’t “unique to Linux operating systems.” It’s due to an issue of the Linux and Windows compilers seeing the same code in different ways
Yep, they are calling "linuxbug" what we should maybe be calling a "compiler+platform bug" because floating point behavior simply is not deterministic when comparing the output of different compilers, even under the same architecture, the compiler is free to do whatever optimizations it thinks are pertinent, leading to innacuracies, and these depend on both the underlying architecture (obviously, architecture related optimizations are the ones that make most sense, duh), the compiler's code AND the target OS for which the compiler was built (optimizations specific to OS, rare when it comes to floating point math related ones, but I've seen this happen before so not too far fetched)... and knowing that valve uses gcc on linux, and how aggressive gcc's optimizations are, it would be more appropriate to call this "GCC bug". As a matter of fact, if you pick any compiler explorer and compile the check used for the ducking calculation detailed in the jump tf linuxbug forum using GCC mingw under windows, you get the exact same problem when using -O3 (at least I have with the current GCC mingw version I use). Since compilers are free to optimize however they want, the programmers must ensure that their operations are being calculated in a way such that the compiler cannot break their floating point operations by optimizing them. Many of these bugs happen by enabling fast math flags during compilation, and something as simple as disabling such optimizations with 1 flag could have prevented this from ever happening. If this was bug bounty, I would be rich for doing something obvious that every programmer with like 5 nanoseconds of videogame industry experience would see in an instant... amazing job, valve, as always. Oh, and lest we forget, libc and precompiled binaries linked dynamically... you can't magically recompile those, and them changing their behavior between versions is basically any programmer's bread and butter, which is why they are notoriously known for breaking old games... the solution is obvious, roll your own... if they use floor(), ceil(), sqrt() or any other such functions then they are relying on the behavior of a dynamically linked function that will eventually break when the implementation changes even if your software is not recompiled. The solution is to figure out what it does and statically link what you need or roll your own implementation, as everyone sane does in the games industry...
great vid! it's good to have all of these in 1 place and with such good explanations for each. do you know if the 64 bit update will affect any of these bugs? i know that a lot of these are still possible in other 64 bit source games, but i have no idea if the timing, rarity or anything else would be changed by an update like this. i'm sure it'll be fine but it is something i considered when they first announced it
Yeah most people don't know about it, I also should have mentioned this but the limit resets if you get hit by a rocket while mid-air (and obviously will reset if you hit the ground).
as far as i know wallbug (sticking to wall; resetting all velocity) occurs when the engine has too many collision points between player's hitbox and whatever he is colliding with. (probably more than 4 or something)
Ixam, do you know anyone who made video, document or could explain tiering system in tf. *read before you sent me to firestabber video or tell that it is based on hardest jump* I asked few top jumpers and mappers and it seems like we don’t have specific measures to tell by them if the jump is tier x or tier y. People making maps literally eyeball the jump and compare this to maybe previous jump, that looks certain way and this is how they rate the tier of the jump, right? (I mainly speak about very hard maps, but not only) But this is so not precise. [Thought experiment] Imagine that someone who has 0 to none knowledge about tiering in tf, has to write a technical document about that stuff, something like actually methodological. In that case he would need to give precise answer what’s differ one jump from another if they are different tiers. Sooner or later he has to define tier, tiering and how we can even do that, lenghts, heights, reps, techniques. With maps that have all the t3 techniques it’s simple - Map consists ‘basic’ jumps in it, that player need to be somewhat consistent in them to play the map comfortable. This easy streak ends when we are climbing in difficulty. That person would have to give precise answer… eventhough quint is just t3-t4, continuous 10 quints are a bit harder (jump_sync last). Also maxxvel quint doesn’t seem to be in t3-t4 category. But the funniest thing is to give a border “when it becomes harder than the rest?”. Is continuous 10 quints higher tier than 5 continuous quints? Is maxxvel quint different tier than quint that is 15 units lower? What would make rickoconnel prelast tier lower? And what a tier harder? [you don’t need to answer that, I assume some of the players already know the answer cause they use ‘comparison’ system. The other half tho will debate what tier or jump that would be and why. But the answers are endless, that’s why I don’t think answering is useful] The fact that I even came to those conclusions make me very unsatisfied with current tiering nature, because it seems like tf is very mathematical when it comes to movement, bugs, mechanics. •It’s weird to me that you can’t tell just by height or lenght units and amount of reps if the jump is ‘this’ or ‘that’ tier… and everyone could assume tier after reading some documents about jumping•. Considering so much methodology in whole tf it’s just weird that tiering system is lacking it (at least from the theoretical standpoint or that it’s so inclusive, even people interested in topic struggling to find more info). If I’m completely wrong, you can help me find more precise answers on that topic, because maybe I didn’t search enough. I’m mainly interested in measurements if anyone making or rating map is making (which for now it seems I didn’t found them. Even mappers told me that they don’t have those, player named norf for instance). No matter what, I’m glad for this community, I participated in many constructive discussions about the topic and not only. That would be awesome to find some material about it.
Yeah honestly this topic is super interesting, it's something I've talked about on stream before. For lower tiers I believe this methodical kind of approach definitely can work, however it definitely doesn't hold up for harder tiers which I believe is what you're mainly interested in. For example it's not really possible to quantify exactly what makes a prefire jump t6 or t10, since separate prefire jumps are often unique enough you can't directily compare them (look at jump_rickoconnell 2nd last vs last; both are similar difficulty but wildly different in execution). So in general that's why I'd say specific measurements don't work for harder tiers, the fact is higher tier jumps vary so much in concept/execution it's not possible to always compare them. For another example take a look at jump_attached3 course 4 level 4; it's the only jump to ever feature this exact mechanic, so there's no possible framework or set of distances you could cross reference to say how hard it is until you actually playtest it. This might not be the answer you want, but if you wanted a more formal tiering system it would have to be statistics based imo. Things to look at could include total time first completions of a map take on average, total number of completions, average completion time relative to number of levels, how many people attempt a map vs how many people beat it, average rank of a player that beats it, etc. It wouldn't be perfect but if you want a more rigurous method for tiering this is probably the best you can do.
Is bug abusing allowed on jump records or is it like speedruns where they have glitchless runs? I feel like it's kind of cheating unless it's intended for certain maps.
Despite being called 'bugs' everything I mentioned (except linuxbugs) has been known about for a very long time and maps are made with them in mind. Also, some mechanics like edgebugs can very easily happen as an accident so banning them wouldn't make sense as they're extremely common and not always avoidable. That being said there are bugs not mentioned in this video that are considered cheating (like switching weapons to abuse regen), however this mechanic is extremely inconsistent so it wouldn't make sense as an any% mechanic
