Added extra boolean for P_SlideMove forceslide, since kart's walls are almost all bouncy slidemove will almost always bounce things instead, even if we don't want it to.
The issue was that because both them and the player had MF_SOLID, the tmfloorz of the spring was getting set to above the player (or vicea versa with tmceilingz), forcing it upwards with them under certain circumstances.
Now, springs only acknowledge the solidity (for purpose of tmfloorz/tmceilingz) of objects they CAN'T launch.
-------
Accelcode now factors in forwardmove value rather than a boolean. This is used to enable clutching (or whatever you call it; accel+brake) to give its own result.
Fixed Thwomps killing players rather than crushing them.
Reverted buggy collision experiment from previous version.
--------
Hardcoded Collide.lua.
Added player boolean array "Collide", used by Collide.lua.
Walls are now bouncy by default again, like they were in 1.09.
Buffed Orange Drift sparks, the boost now lasts 60 frames up from 40.
-------
Diagonal springs now keep your current speed if you are faster than their set speed. This only affects players for now.
Offroad is no longer handled by &256, and is now handled by &2, &3, &4; Damage (Damage (Water), Damage (Fire), and Damage (Electric))
Starpost mobj radius and height have been reduced to 1*FRACUNIT, this should fix the checkpoint infinispawn bug.
Mushrooms rewritten to not use Instathrust, instead they jack up your accel to 10x. Feels nicer.
Floor mushroom panels no longer activate while above them
Mushrooms force player to accelerate (and cannot brake)
K_PlayTauntSound works now. (YES YES YES HUP HUP YES HUP HERE WE GO)
Star and Mega sfx might stop correctly now in netgames (need to test)
Item box radius and height increased from 32 to 36.
HOWEVER, since these changes to PIT_CheckThing do raise questions about whether there may be unintended side effects here. As a result, I may remake this for internal only if necessary.
Wall collision fixes
Fixes included in this branch:
* A fix for a specific crash encountered in a SUGOI map (sound familiar?) caused by bouncing off a wall adjacent to a slope
* A fix for solid midtextures not accounting for Effect 3/Peg Midtexture properly (https://mb.srb2.org/showthread.php?t=41462)
* A fix for solid midtextures not accounting for texture y offsets properly for non-Lower Unpegged/Peg Midtextured midtextures
* A fix for solid midtextures not accounting for "infinite" repeats (Repeat Midtexture + no repeat count set)
* ~~A fix for Effect 4 on Polyobject First Line making that particular linedef's midtexture solid in addition to making planes visible - this is not wanted if you want a polyobject with both visible planes and full intangibility.~~ Apparently they never did this anyway, don't mind me \o/
See merge request !104
. tmthing can be NULL if called from PTR_SlideTraverse, so we should use slidemo instead
This fixes a crash that occurs in yet ANOTHER SUGOI map, involving bouncy walls next to sloped floors/ceilings
- Now checks whether the player's top is below the bottom of the fan/gas jet, instead of its bottom. zdist calculation not affected.
- mo->standingslope is NULL'd so the player isn't launched off at a wacky angle. (I also did this for springs, since Prime mentioned it was a problem for them too.)
The whole thing needs a refactor in general, but it's almost 2am here, I need my sleeb, and this fix would probably break something with 2.1 climbing if I made it any more/less (depending on viewpoint) complicated.
Fix for teetering on PolyObjects
So... somebody goofed and didn't realise PolyObject sectors could be added to the sector node list for each object (which is referenced by mobj->touching_sectorlist), via their linedefs if they are nearby the player (yes, PolyObject linedefs are special and get to move about the level). As it turns out, this allows even INTANGIBLE PolyObjects to make you teeter in a seemingly inexplicable way.
What is happening is that PolyObject sectors, when they are added to the mentioned lists, are then checked under normal sector teetering conditions - if the player is above the floorheight by 24 FUs, you're officially teetering unless stated otherwise. The actual PolyObject teetering code can't help you here if the conditions are right, especially if they're taller than 24 FU in height.
There are a number of things wrong with the teetering code in general that I'd like to sort eventually, but at least now teetering on PolyObjects is fixed at last ...right? Please check the branch out if you can to check this, obviously.
See merge request !54
