Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Added buildradius checkbox to lobby options #14209
This is fundamentally wrong and suffers from tunnel vision - the ticket would be the perfect case to be resolved akin with a mutator, since you're now propagating a trait used in a single mod to be disabled in every shipped and thirdparty one (you can't really disable lobby checkboxes).
Looks better, thanks. There are a couple more minor changes you can do to improve performance:
Is this better?
Yes, just some more minor things and I hope we're done with changing the code back and forth. (Sorry for the hassle, btw...)
Congratulations to everyone for creating the worst precedent in regarding to customized lobby checkboxes! @pchote, since you were interested on the other day why I believe taht modder feedback is ignored in eaxact cases - here is one.
The CnCNetv5 client used by many TS/RA2 mods apply a rules edit behind the checkbox between the main rules and the map edits. That system should have been used here, not expanding the system with made-up arbitrary stuff.
@GraionDilach: I don't really understand your hostility towards this. This PR doesn't set a precident; it follows our conventions that were established in #11364 and prerequisite PRs. Asking a new contributor to implement a new low-level engine feature that completely changes our lobby options conventions doesn't make sense.
What does this PR does in effect on RA rules? Let me sum it up with two lines.
Where this PR does set a precedent is that lousy hardcoded lobby checkboxes which should have been implemented via custom rules are acceptable as C# code fragments and encouraged to do so. This precedent is already utilized at #14245.
There wasn't a need to completely change the lobby options besides providing a secondary method. #9422 was filed exactly for lobby options causing this level of YAML edits. Ignoring it is convenient, blowing it to out-of-proportion levels is even more convenient - especially when one decides to ignore how CnCNet TS/YR is able to utilize said system for years now.
OK, as for the help/feedback/attitude:
I checked - all you said prior to merge is "this is bad". That's all the feedback.
Now, as for the suggested implementation:
From what I've read that method sounds utterly unsupportable for more than 1 or 2 very simple mutators.
or you have these yamls in your rules folder along with all the others:
with each of those potentially having a 2-line entry (at best) for every actor in the mod.
So how about we all do something constructive for a change and try to come up with an actually good approach together?
Sorry, but i can't. I agree with @GraionDilach that Mutators as CnCNet has would be way better alternative to this. I see no problem with having 20 mutator files, probably under rules/mutators folder not directly rules.
CnCNet aside even original RA2 had a similar logic, called Game Types. Only difference ypu can only appy one of those.
Plus we already have stuff like