* 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.
Set up similar to NiGHTS Mare linedef executors. Give a sector the "Race
Lap" sector type, tag it, then set the frontside x-offset on the trigger
line to the lap it should activate on minus 1. There are a few flags you
can check on the trigger line to modify its behavior.
- Normally the executor will only trigger if its exactly on the lap
specified. Check Not Climbable to make it execute on laps equal to or
greater than, or check Block Enemies to make it execute on laps equal to
or less than.
- By default, the executor will check current lap with the person in
last's lap. Check E4 to instead find the current lap from the player who
triggered it. This flag is better for triggering events ahead of the
players, while the default effect is better for triggering events behind
the players.
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 8f149075a6.
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.
