Behaves ALMOST as you'd expect. It gets the z position of the slope at the player coordinates when it comes to the sectorlist check (which is first), though, so there's a few oddities that are amplified with steep slopes:
* If the slope's sloping away from you at a steep angle, you might not be able to step down onto it, but you won't teeter (because it's at a step-down-able height if it extended to directly beneath you)
* If the slope's sloping towards you at a steep angle, you might end up in teetering frames when you're able to step down onto it (because it's NOT at a step-down-able height if it extended to directly beneath you)

HOWEVER, it would be pretty obnoxious to hold back code which is functionally superior in every way otherwise, and it doesn't really seem like there's a good way to get that checked tbph

Basically this makes sure numwadfiles is updated before loading the SOC/Lua scripts, so if a Lua script calls COM_BufInsertText with the contents "addfile scr_mysticrealm.wad" it can't overwrite the last written wadfile slot! Not that COM_BufInsertText really should be used like that to begin with

Reccomended by MI: Dividing by the original friction value just so slopes with normal friction don't behave differently between next and this branch.

*Didn't take into account object scale
*Doubled force when on the ground (ignore what the comment of the line I moved says, it was relevant for slopes...)

This also led to a mistake with slopes, where I was double-multiplying by the gravity constant to get half (because of a quirk of numbers...)

Let's multiply the thrust by the mobj's friction. You should have less chance of purchase on a slippery slope (tee hee) and more on a rough one, but the slopes were basically identical during testing before I implemented this change.

Moved the standingslope check in P_ZMovement to after the FOF and height adjustment as it is in P_PlayerZMovement, as reccomended.

Doesn't actually stop Crawla jittering, but might as well make it happen for consistency's sake.

Reviewed by @RedEnchilada

OpenGL: Fix lower unpegged texture offset, fix lower unpegged + effect 1 so the texture actually skews

in an I_Error print!
[/rhyme]

This fixes certain sector specials and linedef executor specials etc not accounting for players/mobjs touching sloped FOFs

Okay, now vertex slopes aren't placement-order-dependent any more. Hopefully this is the best way to handle things.

When you haven't found all the vertices, it's just not safe to carry on. Hit them with a descriptive I_Error so they don't get confused as hell like Glaber did. http://mb.srb2.org/showthread.php?t=41455 for reference.

Also took the opportunity to nuke or otherwise neuter a bunch of Kalaron's bizzare ramblings (most are questions which have long-been answered by Red's efforts) at the same time.

Holy shit. I spent two hours staring at how garbage this code was and didn't even realise it was #ifdef'd out behind a define not even mentioned in doomdef.h. It's not actually used anywhere (superseded entirely by the much nicer, much more relevant P_NewVertexSlope()... out with you, ancient, foul demons who should've been SPRINGCLEANed long ago.

Travis ci

Ok, now SRB2 on travis-ci is tested to be compiled against 17 buildsets

Now, what am I doing wrong?

See merge request !74