currently anything that wrecks a block issues a followUp for wreckSplash iff there are options for where the debris goes. However, now that 'foo', [], {min: 0} works, i should be able to put splash picking inline, possibly by breaking getWrecked() into separate splashOpts() and the actual wrecking (which would be passed a splashZone: Cell[], i guess).
con: makes all current wreck actions more complex as they now add the wreckSplash in
pros: gets rid of a followUp, maybe? Or maybe I should put all the logic into a generic wreck action, and make wreckAction a separate action that dispatches to the generic wreck after checking its conditions and setting hasActed etc. hm.
currently anything that wrecks a block issues a followUp for wreckSplash iff there are options for where the debris goes. However, now that
'foo', [], {min: 0}works, i should be able to put splash picking inline, possibly by breaking getWrecked() into separate splashOpts() and the actual wrecking (which would be passed a splashZone: Cell[], i guess).con: makes all current wreck actions more complex as they now add the wreckSplash in pros: gets rid of a followUp, maybe? Or maybe I should put all the logic into a generic wreck action, and make wreckAction a separate action that dispatches to the generic wreck after checking its conditions and setting hasActed etc. hm.