Set a sidedef's midtexture to "TRIPWIRE" to turn that line
into a tripwire.
Players can't drive through a tripwire and will bounce
back at high speed if they're in one of the following
states:
1. Invincibility / Grow
2. Sneakers
3. Flame Shield dash
4. >200% on the speedometer
Hitting a tripwire plays a sound, sends you into hitlag,
then plays another sound when the hitlag is over. The
sounds used depend on whether you can drive through the
tripwire.
See notably the finish line. Basically respawning exactly on a line can let you
cross it twice, if you crossed it before respawning, or NOT cross it, depending
on which direction you drive after landing. So this just respawns very slightly
before the line so you can cross (or not cross) it normally.
Not convinced that the small speed benefit from P_AproxDistance is worth the "aproximate"[sic] results it gives. Let's instead try a define to replace it with FixedHypot. In Lua, the function gives a deprecated warning.
Inspired by the hyperwall fix for vanilla, except for everything. From little testing, actively improves waypoint checks, bumping, speed checks, wall collisions, Jawz targetting, Lightning Shield attacks, so on.
The only way I see this as a potential downgrade is A_Look (and related functions) getting slower, which are barely used in Kart.
This should fix the janky falling off steep slopes and let you cling to them.
Because when falling off a sector the edge of the player must not intersect
the edge of the higher sector, it is trickier than step up. The height
difference at the line must be stored to be useful.
This is for slopes. When moving across a slope the height changes. Therefore
compare the height at the edge where slopes meet so only a wall will block the
player, and not a very steep slope.
* If you collide with a line belonging to a polyobject, you should NEVER have to care about any FOFs that might be present in either sector of the linedef. This could lead to colliding with ghostly FOFs that aren't actually there or something dumb, if someone decided to give either of the polyobject's control sectors FOFs for some reason. We don't want that, obviously.
* Polyobjects without POF_CLIPPLANE apparently are supposed to have a top and bottom "physical" height of value INT32_MAX and _MIN respectively, according to P_CheckPosition ...let's be consistent with this.
* Finally, there is no more need for that back = front nonsense hack anymore with my changes made.
