Extra rmreqs to enabler.
It isn't that simple. We can't specify what extra an enabler is about at the moment. (The local range of an extra requirements means "on this tile".)
Reply To kvilhaugsvik
It isn't that simple. We can't specify what extra an enabler is about at the moment. (The local range of an extra requirements means "on this tile".)
I think this ticket would be impossible to implement in 3.1, and I don't think lack of it really breaks anything. Retargeting to 3.2.
alienvalkyrie Reply To kvilhaugsvik
It isn't that simple. We can't specify what extra an enabler is about at the moment. (The local range of an extra requirements means "on this tile".)
There is now #43808 for this.
Reply To alienvalkyrie
Reply To kvilhaugsvik
It isn't that simple. We can't specify what extra an enabler is about at the moment. (The local range of an extra requirements means "on this tile".)
There is now #43808 for this.
So that blocker is cleared from S3_2 and later.
Reply To cazfi
and I don't think lack of it really breaks anything.
I still don't see why we would want to do this, even if it would now be possible -> not considering critical for 3.2.
alienvalkyrie Reply To cazfi
I still don't see why we would want to do this
I do like the idea of unifying things, trimming unnecessary parts (and potential sources of bugs) from the code.
What I'm not happy about (and the main reason I didn't pick this up right after #43808 was done) is the quadratic (well, rectangular?) blowup in enablers that rulesets might need (and that rscompat needs to create) if a single remove action has both multiple different enablers, and removes multiple different extras with different rmreqs. I'm not convinced saddling ruleset authors with that is a good idea; we might want to at least keep rmreqs in place until we can replace it with a different (better) two-layer solution ruleset-side.
Reply To alienvalkyrie
Reply To cazfi
I still don't see why we would want to do this
I do like the idea of unifying things, trimming unnecessary parts (and potential sources of bugs) from the code.
Yea, if this would allow deprecating extra rmreqs completely. But seems to me that we still need both ways to express things, and this ticket is only about changing how supplied rulesets are implemented wrt extra removal actions.
All rmreqs using actions are now enabler controlled. This should allow moving the requirements to the action enabler.