- Aug 06, 2016
-
-
toaster authored
-
- Jul 18, 2016
-
-
toaster authored
-
- Jul 16, 2016
-
-
Alam Ed Arias authored
-
Monster Iestyn authored
Sideways springs, horizontal hog-launchers, perpendicular plungers... Call them what you like, they're in the code now. And have been for months! Nev3r uses the hell out of these and I'm fed up of them being <!>'s all over the place, so please have 'em in master so we can update srb2.srb and make things better for all of us. See merge request !30
-
Monster Iestyn authored
Dashmode This branch Metal Sonic's abilities (CA_DASHMODE) to the game. See merge request !26
-
- Jul 11, 2016
-
-
Alam Ed Arias authored
-
Alam Ed Arias authored
-
Alam Ed Arias authored
-
Alam Ed Arias authored
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
-
Alam Ed Arias authored
-
Alam Ed Arias authored
-
Alam Ed Arias authored
-
- Jul 09, 2016
-
-
toaster authored
-
toaster authored
Dashmode now has its own animation, SPR2_PEEL. Requires a new PLAYER.DTA. I made a lot of references to the peelout here because I'm not sure what else to call a Sonic character's faster-than-usual-running animation and SPR2_DASH was taken. * 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.
-
- Jul 07, 2016
-
-
toaster authored
-
http://git.magicalgirl.moe/STJr/SRB2Internal.gittoaster authored
# Conflicts: # src/d_clisrv.c # src/d_clisrv.h
-
- Jun 30, 2016
-
-
Inuyasha authored
-
- Jun 23, 2016
-
-
Monster Iestyn authored
-
- Jun 22, 2016
-
-
Inuyasha authored
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 9d221f4f, 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
-
Inuyasha authored
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
-
- Jun 20, 2016
-
-
toaster authored
-
toaster authored
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.
-
Alam Ed Arias authored
-
Alam Ed Arias authored
-
- Jun 19, 2016
-
-
toaster authored
...completely misunderstood the reasons we weren't merging toast_slopes, mom holy fuck i'm stupid and bad Enjoy your slopes without physics, people :D
-
Monster Iestyn authored
-
Alam Ed Arias authored
-
Alam Ed Arias authored
-
Alam Ed Arias authored
-
toaster authored
-
-
Monster Iestyn authored
-
Alam Ed Arias authored
-
- Jun 18, 2016
-
-
toaster authored
-
-
Inuyasha authored
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
-
- Jun 17, 2016
-
-
Monster Iestyn authored
-
Alam Ed Arias authored
-