R_SkinUnlock defines the circumstances under which a skin is available. For simplicty's sake, I've currently bound it to an S_SKIN variable so I can toggle it easily, but it WILL be replaced with a hook into the savegame system at some point.
* Currently has three tiers of unlock - freebie (forceskin or modeattacking via a loaded replay), Ringslinger Only, and SP/Coop and Ringslinger.
* I don't know anything about netcode so I basically decided to make R_SkinUnlock relevant only under local circumstances, try as hard as possible to stop bad skin info from getting sent to the server, and then admit defeat once the server has the information. If this is a bad choice, please discipline me and show me how to fix it.
* Character Select now checks for whether the character is hidden or not on menu load and does/undoes it based on that info, but will never touch one disabled via SOC. I also used this opportunity to optimise, checking for/filling out charsel pictures instead of doing it later. (It now also includes special casing for a select screen with zero characters!)
* Mode Attack now hides hidden characters in its character select based on SP rules.
Things that still need to be done:
* ForceSkin_OnChange. Is there a graceful way to handle this?
* No obvious skin name conflicts. Add a salt to the names of hidden skins, and then remove it when they're unhidden?
* The gap between Knuckles' skin number and the first custom character anybody adds will be way too obvious. A seperate hidden skin numbering system? Start at 32 and count up from there? There's a few ways...
* 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.
For GCC 6.1 builds
I do not know what I was doing:
NULL checks
building without BLUA support
functions that do not depend on outside vars should be tagged with "const", AKA, FUNCMATH
See merge request !89
* 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.
* Characters disabled through SOC are outright removed. No awkward gap in scrolling - no hint they were ever there in the first place.
* Vertical loop - the character select images are visually continuous. No matter where you are in the chain, you'll always see a hint of the character above or below your current selection in the chain.
* Smooth scrolling - Moto and Prime showed me a gfy from back during 2.1 development where it was super smooth. I didn't make it as slow as that one, but the smoothness was easy to add and the reason it was removed previously - gaps in the character select leading to varying speeds - is no longer relevant.
* 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.)
Some slope improvements/fixes (plus P_GetMobjGravity)
Dear Red, I did some things.
* Made the slope flag SL_NOPHYSICS actually have an effect like we wanted to, but didn't get around to implementing yet - activated by setting the slope's linedef flags to have ML_NOSONIC.
* Made downhill slope thrusts proportional to an object's gravity and friction.
* To make the above happen - seperated out the gravity value finding code in P_CheckGravity into a seperate function, P_GetMobjGravity. (p_mobj.c, p_local.h) I also made this function available to Lua.
* Turned those PANIC n console messages (which would inevitably be followed up with a crash, since we're accessing invalid memory immediately after) into a descriptive I_Error.
* Put the SRB2CB type-shimming behind an ESLOPE_TYPESHIM ifdef.
* Removed SPRINGCLEAN-ifdef'd code.
* Cleaned up some eosteric comments.
* NEW SINCE RED +1'd THIS: The teetering code now takes slopes into account pretty well. There are edge circumstances as outlined in commit 9d221f4f3f, but this is unilaterally better behaviour in every way and the teetering code was kind of a mess anyways.
* NEW SINCE RED AND ALAM +1'd THIS: P_ReverseQuantiseMomentumToSlope. Simple function that replaces the inverse angle stuff (which also wasn't using InvAngle, just ANGLE_MAX - angle - which is inaccurate!!)
Current testing files available at /toaster/slptst3.wad and /toaster/gravitytest.lua on the ftp.
I want to do more to the branch like implement SL_ANCHORVERTEX in the near future, but this is probably safe to merge in its current state.
See merge request !77
Climbing on one-sided linedefs
Does what it says on the tin. You couldn't before, now you can.
With this branch, thok barriers are now completely optional for maps with no aesthetic need for sky-topped walls. All the bugs and complications that exist with climbing right now still exist, except now there's one less issue making them suck forever and now Nev3r will be very happy.
Do I need a testing .wad? It's... not that hard to create a very small map and go nuts with Knuckles in it. I have one, but uploading it to the ftp almost feels insulting.
See merge request !90
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.
