New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Analysis of stealth, steamroller, and wings flags #4
Analysis of stealth, steamroller, and wings flags #4
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your submission. It's really helpful to have people join the team. I haven't looked at any of the other documentation work, so if your stuff is consistent with the rest, then take my comments with a grain of salt.
@jwmelto; thank you for your comment, it is appreciated. I wrote the documentation with an entirely different mindset than I now get to see is actually sought after. I'll reform the entire documentation from grounds up, focusing more on analytical examination and breakdown. |
Thank you so much @tainn1 for your contribution, we really appreciate it! Overall feedback: it looks really good! I wouldn't go as far as starting over. I agree with @jwmelto's feedback on how to keep the documentation more objective so those just changes really necessary. Something for the project to figure out is how we want to standardize documentation. What headings do we want to use across all flag docs? We currently have As for mentions of BZDB variables, we also need to decide on how much we should mention them. I'd lean towards brief summaries of them in the flag docs so server owners and map makers know which variables are tied to the flag. But actually being able to configure them, should be left to separate documentation (BZDB docs) when we eventually get to documenting that. |
@allejo; thank you for your feedback. I agree that having some sort of standardization would be good. That said, though, it might prove to be quite difficult to achieve it, at the very least more than initially anticipated. To connect this with your second point that is BZDB variables, it just becomes an inconsistent mess if we truly want to analyze these flags in their full functionality. That is because BZDB variables range from one flag not even having them, all the way to the flag's actual potency being entirely in the hands of the slight changes and modifications to these variables. As such, if we wanted to fully analyze flags, we would be required to include BZDB mentions extensively at some, less so at others, and be unable to have them in yet others (such as stealth), since those flags don't have their own variables to modify. Due to that being the case, standardization could be an issue. One approach could be to just assume all BZDB variables are default and examine the flags from there, it shouldn't be an issue to reach some sort of a standard from there. It would also make our lives much easier, but since these variables play such a big role, we would have to mention them in some place. Perhaps externally and in a document that is specific for them, in order to keep the pages clean, but that's just one of the ideas. Then comes another issue that is the demand to actually change the default values of the BZDB variables to balance out the potency of flags, which could make the flag documentation outdated right away if we were to do it prior to the changes of defaults, and should our documentation truly focus on defaults. |
Thanks! This has been merged. |
No description provided.