* FF_MIDDLESTARTCHANCE - has a 50% chance of starting the spr2 or FF_ANIMATE animation halfway in
* FF_SPR2ENDSTATE - if var1 == S_NULL, don't loop, just stop incrementing the frames. Otherwise, go to the state represented by var1.
The former is just something I did for fun, the latter is something that'll come in handy when porting in new-character-moves.
* radius - sets the player's radius for that skin.
* height - sets the player's normal height for that skin.
* spinheight - sets the player's spinheight for that skin.
* shieldscale - see http://i.imgur.com/BQ5DhKC.png for justification
* If a character select character image is not set, don't iterate every tic - iterate on first image get and then save to the struct.
* A character select screen with only two characters now has special case handling.
* A memory leak in the making has been plugged. (specifically, picname not being Z_Free'd if the loop fails to do so)
* Logic/operation simplification.
Also, some typo corrections and clarity case movements of stuff in other files I've been looking at.
* SF_NOJUMPSPIN - Player's height is full whilst jumping, SPR2_JUMP defaults to SPR2_SPNG instead of SPR2_SPIN, and the player goes into fall frames if they start moving downwards or use their ability.
* PA_JUMP - for jumping (upwards in the case of SF_NOJUMPSPIN.
* SF_NOJUMPDAMAGE - Ala rosy.wad, don't damage enemies, etc when jumping into them.
* SF_STOMPDAMAGE - Just for fun. Ala in Mario, always damage enemies when you land on top of them (your gravity reference, not theirs).
* SF_MARIODAMAGE - SF_NOJUMPDAMAGE|SF_STOMPDAMAGE is reasonably accurate to the Mario games, and might as well be surfaced as such.
Also, a minor change:
* Instead of not spawning the revitem if your SPR2_ is SPR2_DASH, don't spawn it if it's set to 0. This requires the player.dta I uploaded a couple days ago to behave as it was previously.
* Don't get stuck in spindash frames if your maxdash is 0, and don't flash rolling frames if you're on goop.
* SPR2_PEEL, SPR2_SPEE.
* S_PLAY_PEEL, S_PLAY_SUPER_PEEL.
* PA_PEEL.
* Dashmode actually starts charging from runspeed instead of the arbitrarily calculated (normalspeed - 5*FRACUNIT). This just made things easier, honestly, and it's 1 FU of difference compared to the current test case.
- Press spin in midair to stomp directly downwards (losing horizontal momentum), creating a flickering fireball around you.
- No bouncing on enemies, item boxes, etc - just go straight through.
- Hurts other players on touch whilst you're stomping.
- Spawns a bunch of flames around you when you hit the ground.
Also:
- Electric shield's ability now uses different sounds, because I'm picky.
- 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.)
Sectorlist traversal
MOM GET THE CAMERA
There's a LOT of code in the source that ended up mixing m_snext (the node for the next thing in the sector's thinglist) and m_tnext (the node for the next sector in the thing's sectorlist), so I renamed the following:
* m_snext ==> m_thinglist_next
* m_sprev ==> m_thinglist_prev
* m_tnext ==> m_sectorlist_next
* m_tprev ==> m_sectorlist_prev
Then, I changed all the instances where the code was trying to go m_thinglist_next on a mobj's touching_sectorlist (which would've just gone to the node for the next thing in the same sector, instead of the node for the next sector for the same thing). Notable samples:
* FF_SHATTER blocks now disappear the moment you go into their sector. You still can't give FF_SOLID to them because in that case they will still stop you if you never enter their sector at all (ie - clip on corners), but having them nonsolid no longer allows you to phase through entirely without busting them (which was the whole downside of making them intangible in the first place).
* You can now bump into multiple Mario blocks at a time, even if you're not exclusively in their sector.
* No more getting randomly stopped on the edges of bouncy FOFs.
* Landing on polyobjects might behave a little more consistently at the edge of their host sector.
* Teetering did a SHITTON of code that basically never got executed, and then had directly-blockmap-accessing code as a backup. The code was activatable by replacing the m_thinglist_next with m_sectorlist_next, but it behaved SUPER differently from what we're used to with teetering (if the player mobj's edge was JUST off the edge of a platform, you ended up in teetering frames - even if it looked like you could stand) so I ended up removing that section entirely.
Any objections?
See merge request !85
Also, the teetering angle on slopes is now FRACUNIT/2 because there's literally no way to stand still on a slope that steep unless it doesn't have physics.
Two interesting points of note:
* The touchspecial sector flag seems to actually do its job now.
* Detection of sectors with polyobjects in seems to have done this incorrectly, but this doesn't mess with anything about touching the polies themselves so it seems to really only handle edge cases where the polyobject was too close to the border of another sector (which would've likely made rendering glitches anyways).
* There was a whole swathe of teetering code that was basically never run properly because of this mistake. I did a simple fix at first, but you started teetering whenever you were slightly less than your radius away from a sector's edge, which was completely different and undesirable behaviour. Instead, I cut out the code that was never running, and just left the hacky method in instead since it was more accurate to what we want in general.
Issue was caused by attempting to traverse the sector's thing-touching-list across all the things in the sector (which would inevitably have the same sector as the first node in mobj->touching_sectorlist) instead of traversing the thing's sector-touching-list (which has the same thing but different sector references).
I wonder how many times AJ copypasted this code with absolutely no idea why it wasn't working properly. I'll figure that out tomorrow, maybe set up some compiler macros so this mistake is never made again. For now, I must sleeb.
* Only change texture when stationary or moving down, for additional fidelity to source material. This has zero overhead, and actually might REDUCE lag in some circumstances... my nitpickiness wins again.
* Apply ML_EFFECT1 to it to make it invisible and intangible (removing (FF_SOLID|FF_RENDERALL|FF_CUTLEVEL) from it) from every side except the bottom. Becomes visible and tangible when it's hit once. Might fuck over players in mp, but really our Mario blocks are so high in the air (and we'd need to update Pipe Towers to take advantage anyways) that they're super unlikely to get a kill this way
* Checks for the Brick Block have been switched over to the presence of FF_SHATTERBOTTOM instead of checking for the source linedef's flags every time.
For the object...
* Tag via its angle field
* Number of objects to spawn per tic around it via its z field, if zero then just spawn at center
* Is flipped if given MTF_OBJECTFLIP.
Now there's a linedef type 15!
* Tag is tag of object(s!)
* Object type set via concatenation of frontside textures, MT_PARTICLE is default
* The length of the linedef is the radius the particle is spawned out (zeroed if z field is 0)
* Frontside x offset is speed upwards
* Frontside y offset is number of degrees to turn each tic (zeroed if z field is 0)
* Frontside floor and ceiling heights are the heights in which the particle is bound through some fun mathematics and/or BDSM
Of course, not every story has a happy ending.
* A_ParticleSpawn no longer accepts objects via its var1 because of how specialised it's gotten. Considering it can be set via abuse of actor->cvmem, I don't consider this an issue. Maybe you might disagree.
Linedef type 14 (Bustable block parameter)
* Applied to one of the linedefs of any FOF's control sector
* Concatenation of frontside textures is MT_ object type to spawn, defaults to MT_ROCKCRUMBLE1 if not present
* Sound played when being busted is object type's activesound
* Frontside x offset is spacing (in fracunits) of spawned particles, defaults to 32<<FRACBITS
* Frontside y offset is the fuse of spawned particles in tics, defaults to 3*TICRATE, if set to -1 assume infinite lifetime
* Effect 1/Slope Skew flag makes particles fly out
Linedef type 250 (Mario Block):
* No Climb flag turns it into a brick block (busts when hit from the bottom, player hits their head/fist/whatever, no more upwards momentum)
* Actively impede your acceleration
* Make your animation speeds faster whenever you're moving (to give off that Looney Tunes effect)
The former change is something that was present in the few low-friction circumstances in the classics, and makes low-friction surfaces more of an active challenge. The latter change is just something I did for fun to more clearly communicate that things are different with the physics here.
High friction surfaces DO NOT involve any of this, since it ended up basically cheesing their existing gameplay.
*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...)
*The No Physics flag now works (Red, you might want to doublecheck this to see whether I haven't missed any eosteric stuff out). Going downhill is a little bumpy, and I'm not sure whether that's good or not. Someone help me out here?
*The SRB2CB typeshims are now behind #ifdef ESLOPE_TYPESHIM instead of #if 1 for easier disabling.
*Slopes' downhill thrusts are now scaled with regards to object gravity. This is actually untested in gravities other than normal and reverse normal but it's one line which can be easily reverted in that circumstance. I also checked with MI to make sure this is how it's calculated elsewhere, so fingers crossed this doesn't cause any edge cases.
*As a consequence of the above point, there's now a function in p_mobj.c/h that returns an object's internal gravity - seperated out from the logic of P_CheckGravity, which really didn't need to be so monolithic. Multiply by global gravity to get the thrust. This should probably be available to Lua somehow, but I have absolutely no idea where to start with that. Wolfs, maybe?
Non-comprehensive test file available at /toaster/slptst3.wad on the ftp.
NiGHTS hotfix
Fixes the following issues relating to playing as NiGHTS Super Sonic that apparently popped up between 2.1.14 and next (mostly due to the changes to SRB2's trig stuff it seems):
* Super Sonic drifts to the side at some angles around an axis, and is unable to go directly upwards or downwards as a result
* Drilling to the side when on the ground causes the drill sound to constantly restart
* CEZS's start not actually being lined up properly with the first axis means the player is not able to go backwards along the track (because the player is not actually aligned with the track properly, preventing you from touching the attached line transfer)
* trying to hug some walls such as the tall wall before the library section of CEZS allows Super Sonic to go through them
These fixes needs proper testing before this branch can be merged in, in case they accidentally break other things as a result or something.
See merge request !71
