Showing a warning when attacking a territory where units can scramble.
-
heh heh I wonder if the AI could use it ? I know I need as much help as possible. Not just in triplea but life in general
-
@beelee The code for this feature is actually taken from the AI as it already does a check to see what units can scramble to territories its considering attacking.
-
Nice ! Sorry AI
-
Did this discussion and its results have any effect on coding and implementing this feature?
I see the pull request has been merged now .... -
@Panther The feature is behind the 'beta-feature' test flag available in 'game settings > testing', and is now available for experimentation. Merge is not the end of the story, it's the start, see: iterative-development
It's a project anti-pattern for PRs to be open for long periods of time (ideally it's hours or a day or two). https://blog.newrelic.com/culture/long-running-branches-considered-harmful/
We are labor-scarce, we tend to take longer, but even so PRs are ideally merged relatively soon so we can avoid the risk and unnecessary overhead of long-running branches.
-
@LaFayette I understand. I was just asking.
How do we keep track of the ideas developed during a discussion?The feature for now has been included "as is" with the normative power of the fact.
How to make sure that the result of this discussion will be considered/implemented at any time?This topic will get buried in forum history soon.
-
@Panther not easy questions to answer it turns out:
How do we keep track of the ideas developed during a discussion?
There is not set process. Keeping track of 'feature requests' is done via larger list in forums, for a specific feature, there is nothing set. The answer to this I don't think changes whether we are pre-merge or post-merge of the first version of a feature. We should not expect for updates to have every feature on the first version. Merges are not indicating that a feature is done and complete and will not be touched, but it means we have a minimum, useful start. For example, detecting a scramble is a feature, displaying the warning is a feature that builds on top, and giving an option to hide/ignore or always show the warning is yet another feature. It's not just one feature, but a set of features, we should not try to build it all at once.
The feature for now has been included "as is" with the normative power of the fact.
I respectively disagree with the concept of 'normative power of the fact'. I see many shortcomings from legacy technology that have morphed from "we don't do this because the technology does not allow us to", to "it is a rule that we don't do this". We lose sight of when we don't do something because we couldn't, rather than shouldn't. Having access to the code history, a number of things are clearly accidental and limitations rather than intentional rules.
To illustrate this difference in perception, a good example is spaces in names. Many years ago, lots of code was rushed out. Shortly later, it was realized that tracking users by name is not a great thing and there are problems with it. There was more code added to handle this situation, hence why duplicate logins get the " (1)" appended to them and a rule was added to disallow spaces in names so that player tracking strategy (by name) would work. Later the context was forgotton, lost, polished over, and the original: "we hacked up some code and made a bad decision and then hacked in even more code to make it work", morphed into: "It was wisely decided and mandated that users should have no spaces in their names."
So maybe to another extent I agree actually to this "normative power", but I'd point out that a number of the norms are accident, not the results of reasoned decisions. We have the power to release frequently now, to make updates to the codebase without huge overhead, so we can change things. Before it was all a process of sending email patches to Veqryn to be included on the next release, that is a six month turn-around, something that we do now in hours.
This topic will get buried in forum history soon.
The merged feature is behind the 'beta-feature' flag. It won't come out from that for a bit. That helps ensure we keep working on it. This thread won't drop in history quite that fast.
A bigger issue is we need to decide requirements for the next iteration sooner, rather than later. If we can't come up with those requirements, the coder will do their best and will be forced to decide them where needed. If we delay on defining requirements, it's going to be a headache and lost effort.
I expect @Alexei-Svitkine will jump in at some point, summarize the suggestions and discuss pros/cons and which ones he thinks are feasible and best to continue exploring.
