This means that, if the three paths are not the same, you should be able to tell if at least one of them has a file that just had a bad MD5. Most relevant for Linux peeps I expect.
Note: Untested as of writing
* Fix that one comment Digiku mentioned. ;P
* Make extra lives/100 ring rewards consistent between lives being relevant and lives being infinite/not present, which was a problem this branch made evident when Race ended up getting the infinite lives symbol!
* Again, tweak the spawning code to take maximum advantage of these gains.
* Fix potential crashes with MT_NULL mace/chain types supplied.
* #ifdef out the height-clipping code. It needs more TLC than I can give it right now, and the existing behaviour is less obviously broken (sadly enough).
* Fix chainmace points, which were apparently broken without anyone realising.
* Completely rework how mace/chainbars are spawned to reduce the number of matrix multiplications required EVEN FURTHER!
* Reimplement the maceretry solidity stuff (effect 4).
* Flip the mminlength stuff so that existing dev maps don't break badly.
* Fix hacky chainbar grabbing.
* Tweak height of tinychain a smidge.
* Fix ability to turn chains (still disabled by default, just at least want the option...)
* Replace max speed setting with a "minimum chainlink distance" setting - if greater than zero, that many chains will not be spawned from the center outwards. Doesn't affect the head of the chain at all, since otherwise what's the point? :V
* Handle all chain objects as a hnext/hprev chain.
* When removing mobjs with hnext/hprev, "repair the chain" (make the h links meet).
* Fix hidden slings, which I accidentially broke when I revamped maces the first time.
* Kill MF2_MACEROTATE. Not needed for anything anymore.
* P_MaceRotate now available to Lua to make up for it.
* Related: Made modifying hnext/hprev using Lua safer, so it keeps the reference counts in play.
The rules for accompanying flags are:
* If FF_TRANSLUCENT, deflag FF_CUTLEVEL and flag FF_EXTRA | FF_CUTEXTRA.
* If not FF_TRANSLUCENT, flag FF_CUTLEVEL and deflag FF_EXTRA | FF_CUTEXTRA
* If FF_SOLID, deflag FF_CUTSPRITES
* If not FF_SOLID, flag FF_CUTSPRITES
This reverts commit 73c7df6f5b.
Why: FF_TRANSLUCENT is often packaged with flags FF_EXTRA, FF_CUTEXTRA; for intangibles, FF_CUTSPIRTES; in some cases (?), FF_CUTLEVEL. I *think* the rules are consistent amongst predefined FOFs, but maybe there are exceptions?
There's too much that can go wrong with assuming too many flags for an FOF. Just make it the modder's responsibility to tag this special to the proper translucent FOF.
