3.1.1.2 Remote deconstruction wrote:Builders that are in the process of forwarding or moving base are able to deconstruct or destroy the main base remotely to prevent the structures from falling into enemy hands. The ability to veto this decision is given to all teammates for a short period. After that buildables either deconstruct over time (dretches can hurt them) or they simply blow up, not returning build points but not decreasing confidenced either. There are two targets to chose from: The main base area (anything in range of the main buildable and anything that depends on the buildables in range) or all marked structures. The main buildables are always unaffected. They will automatically get marked when the feature is used against the main base though. Sanity checks will ensure that the feature can only be used when a number of critical structures survives the process.
Ishq wrote:I agree that this is a problem. I instead propose a more sophisticated system. At the moment we have mark and deconstruct. This can be reworked to be deconstruction priorities instead of marking and deconstructing. Sample priorities can be: (names to be decided)
1st (deconstruct now)
2nd (deconstruct to provide bp for the next struct built)
3rd (deconstruct to provide BP for the next struct built of the same type)
4th (deconstruct after all free BP has been depleted)
This is a more flexible system for determining when a buildable should be deconstructed. There really is no need for the original implementation where the team wants to get rid of structures without caring that they get the bp back and losing confidence, because this implementation is akin to a large scale basenade and can already be done by grabbing a painsaw and killing structs, or of course, basenading (though that's a bit more expensive).