* Value was getting populated even when it was irrelevant. That's fine, just move it after the valueless parsemode switch.
* Oh, it's struppr'd, of course it's going to compare badly with a lowercase string.
* ...oh, strncmp returns zero when it's equal, not true. Right.
<root>/toaster/smilespatch.wad and !LSF test exe updated on the FTP, btw.
* Create a normal skin, but replace the S_SKIN lump with an almost empty one named P_SKIN.
* Provide "name = existing skin name as one of the first line (comments allowed)
* Reset individual spritenames back to zero sprite2s (or one for SPR2_STND to prevent complete removal) via "reset = SPR2_****" statements.
* No support for changing skin properties that are non-visual at the moment, but I don't really feel like it's wise to have those changable with patch alone. (Hello, tons of "modern Sonic" wadfiles which just change vanilla Sonic's ability to CA_HOMINGTHOK!)
* Sprites patch over.
To see an example in action, look at <root>/toaster/smilespatch.wad.
Spindash dust
Charging a spindash kicks up dust, we all know this feature was dying to get in at some point. Bubble and flame forms of spin dust are included from FSonic, for underwater and elemental respectively.
Oh, and as a bonus I reorganised the spindash/spinning/other ability2 stuff code to look a bit neater and more organised.
New resources:
* MT_SPINDUST - the object
* S_SPINDUST1 to 4 - the normal form's states
* S_SPINDUST_BUBBLE1 to 4 - the bubble form's states
* S_SPINDUST_FIRE1 to 4 - the bubble form's states
* SPR_DUST - the normal form's sprite set (uses frames A to D, just pinch FSonic's sprites really)
* SPR_FPRT - the flame form's sprite set (frame A only)
SF_NOSPINDASHDUST disables spindash dust for a character
See merge request !52
*Added FLIPX/FLIPY support for multi-patch textures and single-patch textures without holes
*Added FLIPY support for single-patch textures with holes; I'll sort FLIPX support out later
I'm convinced there's going to be some stupid side effects from doing this, but it's the quickest way I can fix the polyobj planes not all appearing anyway
* Camerascale, shieldscale, height and spinheight are now player attributes which are set to the skin attribute on skin change, not read directly from the skin.
* P_GetPlayerHeight and P_GetPlayerSpinHeight are now macros instead of functions.
* Extra protection against switching to a locked skin.
* flips the sprite ala MFE_VERTICALFLIP except you don't need to flip the direction of gravity for the object just to draw upside down
* stacks properly with reverse gravity
* Sets the sortscale of the mobj to that of its tracer.
* Basically, Smiles' tails won't clip through shields thanks to this.
* http://gfycat.com/GraveGlassEwe
* Also has support for chains of MF2_LINKDRAW!
Also, I added more sortscale handling in the places where I forgot it.
I probably need some help with the maths here to get this to work nicely. http://gfycat.com/LimpAgedDowitcher
http://i.imgur.com/UyOKX5u.png <-- this common glitch with crawlas given MF_PAPER (THEY'RE NOT GOOD AT TURNING NEAR EDGES) used to show the behind-crawlas in front of the front-crawlas.
Unfortunately, I've just discovered this issue (which happens with the old version of the sorting code too): http://i.imgur.com/QNjbATB.png but to be fair these crawlas have gotten stuck inside the edges of this platform, so I'm not sure I can do anything about this without cutting off Sonic's feet when he stands on the ground? shrug
* MF_AMBUSH is now MF2_AMBUSH, because it's something you turn on in a map editor, not with a SOC definition.
* Where MF_AMBUSH was is now MF_PAPER.
* MF_PAPER accesses all the stuff I did previously in this branch...
* ...as well as turn on paper-thin collision detection between mobjs, which I've gotten working but isn't perfect but it's still good enough for non-solid objects!!
* recognising that the offsets weren't going to be accurate if you just SWAPPED yscale and yscale2 over 180 degrees
* taking scale into account consistently
also, some optimisations
also, i've sussed out WHAT'S going wrong here - the topleft pixel of the sprite will always be rendered at the height on the screen it would be rendered otherwise, which is causing the waving. now to figure out what to change to get that to move appropriately...
