-
Notifications
You must be signed in to change notification settings - Fork 118
Creating documentation for Modders #1799
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
base: main
Are you sure you want to change the base?
Creating documentation for Modders #1799
Conversation
|
Perhaps this should go into the GeneralsWiki Repo? Not sure if there are any Doc maintainers left currently. User DevGeniusCode lead the overall doc effort previously. |
|
I added this here because it needs to stay updated with any new features or fixes. It should be part of the normal contribution flow so that whenever someone adds a new feature, the related info is exposed to modders and included in the docs. That’ll help keep the modding documentation always up to date. I’m already working on expanding and complete the docs to cover everything, just need reviewers to help keep things consistent and correct any mistake. Once it’s all in place, I think we should mention this in the contribution guide — so devs remember to update the modding docs whenever they add or change something that affects modders. Keeps everything easy to maintain long-term. |
|
It certainly is nice to have such extensive documentation like that. If Docs are added to this repository, can it then still be used in the Wiki page? I am not sure how this works, but right now all Wiki pages are in the other Repository (GeneralsWiki). How many more documents are expected to be added here? And how will these be maintained, given the volume of information they hold? |
|
I’m not completely sure if we can merge this directly into the Wiki page, but it should be possible since everything there is in Markdown anyway. my plan initially was to publish it through GitHub Pages. As for the number of documents — my plan is to eventually cover every aspect of the ini files, including all entries like objects, weapons, and configurations such as GameData, AIData, and the different modules. I’ll start with the ones that are used most often and gradually work through the rest until everything is documented. Right now, the main thing i need to make sure the layout and style of the current documentation feel right. Once that’s settled, I can keep all the new docs consistent and follow the same structure moving forward. |
You'd probably need some kind of CI flow either from this repo to push to the wiki repo or on the wiki repo to pull part of this one. My only concern would be if we wanted to start adding images to the documentation, I'd prefer to limit the amount if binary blobs in the repo, especially if there is a risk of them needing updating as time goes on. |
|
I am inclined to say for now let's push these docs to the GeneralsWiki repo, and if we really need the Docs besides Code, then we move them later from Wiki to Code. This way you can iterate quicker and experiment, because we can just give you Maintain permissions on the GeneralsWiki repo and let you commit whatever in any quantities. |
|
On the other hand, when Wiki is meant to be kept in sync with evolution of Code, then it would be better to be coupled in same Repository. This is true for the whole Wiki. So for example when VC6 is dropped, remove VC6 from wiki. What is the reason for Wiki to be in a separate repository? Does it need to be separate for GitHub to be able to show it in the Wiki tab? |
I can't find in Discord what the original reason was, but it has merit to do documentation in a separate repository for a number of reasons:
In my software business we ran in similar issues, particularly non-coders contributing to documentation, requiring them to send word-documents to developers. |
While you make some valid points, I’d have to disagree with a few of them. From my experience working in different development environments, the most effective approach has usually been to keep documentation tied directly to the code. Having the docs in the same repository ensures they stay up to date with every change — developers can be required to update the relevant documentation as part of their pull requests. The skill gap can be mitigated since most doc updates from developers are small and focused on specific features, and with the help of generative AI tools, maintaining good-quality documentation has become much easier. When combined with a well-known unified structure and layout, generativ AI can produce consistent and professional results even from developers who aren’t experienced writers. I can actually speak from my own experience here — I’m not a great documentation writer myself, and English isn’t my first language. But if you review the docs I’ve created, you’ll find them well written thanks to clear instructions and multiple AI promt editing cycles that helped me compensate for my weaker writing skills. I do agree with your point about the higher frequency of documentation updates, but separating repos doesn’t necessarily solve that. In my point of view, intensive and complex documentation auch as this should be handled using specialized tools or platforms, while the documentation in GitHub repos should remain relatively lightweight and closely aligned with the code. |
|
How and where would you publish this documentation? |
The initial thought was to use GitHub Pages, but since the docs are just Markdown files, they’re quite portable and can be published through pretty much a lot of tool or platform. |
Yes, exactly — that’s the main reason I’m trying to add the docs to this repository. Keeping them here ensures the wiki/Docs stays in sync with the code as it evolves. |
Change the documentation folder structurtre and enhanced documentation across various game modules, including detailed descriptions, properties, examples, and usage guidelines. Key updates include: - Comprehensive overviews for `ParkingPlaceBehavior`, `ActiveBody`, `HighlanderBody`, `HiveStructureBody`, `ImmortalBody`, `InactiveBody`, `StructureBody`, `UndeadBody`, `MaxHealthUpgrade`, and `ProductionPrerequisite`. - Added a work-in-progress section for the `Object` class in `Object.ini`. - Expanded the `DamageType` enum documentation, detailing interactions with weapons and armor, and introduced the new damage type `DAMAGE_FLESHY_SNIPER`. - Updated the `KindOf` system overview and provided examples of various flags. - Described the bit flag system for visual states in `ModelConditionFlagType`.
This pull request adds a first set of documentation files and starter pages
What is included
ModdingDocs - a starter collection of pages that explain BodyBehaviors. Those pages set the expected layout and tone.
community driven code of generals
Why
Scope
Follow-ups
Notes
The pages are intentionally incomplete at this point. The pull request only sets the format also review process.