Move docs to main repo (#2583)

.github/workflows/deploy-pages.yml

@@ -0,0 +1,47 @@
+name: Publish docs via GitHub Pages
+on:
+  workflow_dispatch:
+  push:
+    branches: [1.20.1]
+    paths: ['docs/**']
+
+jobs:
+  build:
+    name: build docs
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        working-directory: './docs'
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          ref: '1.20.1'
+          sparse-checkout: './docs'
+      - uses: actions/setup-python@v4
+        with:
+          python-version: '3.11'
+          cache: 'pip'
+      - run: pip install -r ./requirements.txt
+      - uses: actions/cache@v4
+        with:
+          key: 'mkdocs-cache'
+          path: './docs/.cache'
+      - name: Build static files
+        id: mkdocs
+        run: mkdocs build
+      - name: Upload pages as artifact
+        id: artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          path: './docs/site/'
+
+  deploy:
+    runs-on: ubuntu-latest
+    needs: build
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    steps:
+      - name: Deploy Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

docs/.gitignore

@@ -0,0 +1,8 @@
+env/
+venv/
+.env
+.venv
+[Ii]nclude
+[Ll]ib
+[Ss]cripts
+site

docs/CONTRIBUTING.md

@@ -0,0 +1,144 @@
+# Contributor Info / Styleguide
+
+For consistency, please follow the following styleguide when submitting PRs.
+
+
+## Filenames & Basic Page Structure
+
+The file structure and basic page layout must follow these conventions: 
+
+- For each section, create a directory with a short, descriptive name in `Title Case`.
+- File names should only contain `A-Z`, `a-z`, `0-9`, `-` and `_` (no spaces).  
+- Directory names must use dashes (`-`) instead of spaces.
+- If you want to add a short description of what a section is about, include an `index.md` in its directory.
+- Every page of the docs must include a Markdown front matter block, containing _at least_ its title, followed by
+  two empty lines.
+- Every page must start with a level-1 heading. No other level-1 headings may be added.
+
+Note that the page name/title must be as short and descriptive as possible, as it's displayed in the navigation area.  
+You can, however, choose a longer version for the page _header_:
+
+```markdown
+---
+title: My Page Name
+---
+
+
+# This is my Custom Page Header!
+
+Page content here...
+```
+
+Contrary to filenames, both the title and header are **not** limited to specific characters. 
+
+
+## Empty Lines
+
+Please consider the following conventions for empty lines:
+
+- At least two empty lines before each heading
+- Exactly one line after each heading
+- Separate each "element" of a page by an empty line inbetween
+  (code blocks, lists, [admonitions](https://squidfunk.github.io/mkdocs-material/reference/admonitions/), etc.)
+
+
+## Formatting
+
+Please use the following formatting rules for standard markdown:
+
+- Use double asterisks for bold text (`**bold**`) and underscores for italics (`_italics_`)
+- Each code block must include a language whenever possible, so that syntax highlighting is applied correctly
+
+
+## Index Pages
+
+Only use index pages for a short description of what the current section is about.
+
+Do not include any important documentation on index pages!  
+You may link to certain relevant pages (either inside the current section, or in other sections) though. 
+
+
+## Admonitions
+
+Use [admonitions](https://squidfunk.github.io/mkdocs-material/reference/admonitions/) in the following situations:
+
+- If you want to provide potentially useful, additional info about a feature, use an `info` admonition.
+- For "see also" references, use an `info inline end` admonition.
+- For tips / recommendations on _when_ or _how_ to use a feature, use he `tip` admonition type.
+  - For general notes on _when_ or _how_ to use a specific feature (in development related docs), use the `note` type.
+- For warning about possible bugs or unwanted behavior, use the `warning` type.
+- If a feature may result in destructive actions in certain scenarios, use the `danger` type.
+- For providing code examples, use the `example` type.  
+  - **Always** provide a title for code examples, even if it's simply "Example usage".  
+  - Use collapsible blocks (`??? example "my example title"` instead of `!!!`) for code examples where possible.  
+    _In some situations this might not be as useful as using a non-collapsible block. Just fall back to `!!!` in these cases._
+- For pages or sections that are not documented yet, use `!!! failure "Not yet documented"`
+- For links, use the (custom) `link` type.
+
+We suggest adding an empty line after the title for consistency, like in the following example.  
+It is **strongly recommended** to include a custom, descriptive title for your admonition, if possible.
+
+
+```markdown
+!!! note "My descriptive title"
+
+    This is my note's content
+```
+
+
+### Admonitions for experimental or not-yet-merged features
+
+If a feature is either not yet merged or simply not stable yet, please add a title-only `warning inline end` before its
+description, as shown below.
+
+For additional info (e.g. which branch the feature is currently in), add a `<br>` tag in the title, followed by the
+additional info in italics.  
+If your additional information needs to be more detailed than that, consider using a collapsible admonition instead.
+
+```markdown
+!!! warning inline end "Not merged yet.<br>_Branch: `my-branch-name`_"
+
+Paragraph containing the feature's description...
+```
+
+Here are some good examples you could use as the first line of your warning:
+
+- Experimental
+- Unstable
+- Not yet implemented
+- Not merged yet
+
+
+## Annotations
+
+Use [annotations](https://squidfunk.github.io/mkdocs-material/reference/annotations/) in the following situations:
+
+- Explanatory comments in code examples (preferred over including these as an actual comment)
+- Additional explanations to a specific aspect of your documented feature
+- An explanation for a technical term used in your documentation
+
+There must be an empty line before the first annotation or they won't work properly.
+
+Also add an empty line between each annotation if at least one in the current block is longer than a single line.  
+In that case, add two empty lines after the end of the annotation list.
+
+Annotations must be numbered starting at 1 **for each block** of consecutive annotations.  
+If they are separated by another element, you need to start at 1 again for the next block of annotations:
+
+
+~~~markdown
+```java
+someVar.someMethod(); // (1)
+return someVar; // (2)
+```
+
+1. annotation 1 for the first code block
+2. annotation 2 for the first code block
+
+
+```java
+someVar.anotherMethod(); // (1)
+```
+
+1. annotation 1 for the second code block
+~~~

docs/LICENSE

@@ -0,0 +1,121 @@
+Creative Commons Legal Code
+
+CC0 1.0 Universal
+
+    CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+    LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
+    ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+    INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+    REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
+    PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
+    THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
+    HEREUNDER.
+
+Statement of Purpose
+
+The laws of most jurisdictions throughout the world automatically confer
+exclusive Copyright and Related Rights (defined below) upon the creator
+and subsequent owner(s) (each and all, an "owner") of an original work of
+authorship and/or a database (each, a "Work").
+
+Certain owners wish to permanently relinquish those rights to a Work for
+the purpose of contributing to a commons of creative, cultural and
+scientific works ("Commons") that the public can reliably and without fear
+of later claims of infringement build upon, modify, incorporate in other
+works, reuse and redistribute as freely as possible in any form whatsoever
+and for any purposes, including without limitation commercial purposes.
+These owners may contribute to the Commons to promote the ideal of a free
+culture and the further production of creative, cultural and scientific
+works, or to gain reputation or greater distribution for their Work in
+part through the use and efforts of others.
+
+For these and/or other purposes and motivations, and without any
+expectation of additional consideration or compensation, the person
+associating CC0 with a Work (the "Affirmer"), to the extent that he or she
+is an owner of Copyright and Related Rights in the Work, voluntarily
+elects to apply CC0 to the Work and publicly distribute the Work under its
+terms, with knowledge of his or her Copyright and Related Rights in the
+Work and the meaning and intended legal effect of CC0 on those rights.
+
+1. Copyright and Related Rights. A Work made available under CC0 may be
+protected by copyright and related or neighboring rights ("Copyright and
+Related Rights"). Copyright and Related Rights include, but are not
+limited to, the following:
+
+  i. the right to reproduce, adapt, distribute, perform, display,
+     communicate, and translate a Work;
+ ii. moral rights retained by the original author(s) and/or performer(s);
+iii. publicity and privacy rights pertaining to a person's image or
+     likeness depicted in a Work;
+ iv. rights protecting against unfair competition in regards to a Work,
+     subject to the limitations in paragraph 4(a), below;
+  v. rights protecting the extraction, dissemination, use and reuse of data
+     in a Work;
+ vi. database rights (such as those arising under Directive 96/9/EC of the
+     European Parliament and of the Council of 11 March 1996 on the legal
+     protection of databases, and under any national implementation
+     thereof, including any amended or successor version of such
+     directive); and
+vii. other similar, equivalent or corresponding rights throughout the
+     world based on applicable law or treaty, and any national
+     implementations thereof.
+
+2. Waiver. To the greatest extent permitted by, but not in contravention
+of, applicable law, Affirmer hereby overtly, fully, permanently,
+irrevocably and unconditionally waives, abandons, and surrenders all of
+Affirmer's Copyright and Related Rights and associated claims and causes
+of action, whether now known or unknown (including existing as well as
+future claims and causes of action), in the Work (i) in all territories
+worldwide, (ii) for the maximum duration provided by applicable law or
+treaty (including future time extensions), (iii) in any current or future
+medium and for any number of copies, and (iv) for any purpose whatsoever,
+including without limitation commercial, advertising or promotional
+purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
+member of the public at large and to the detriment of Affirmer's heirs and
+successors, fully intending that such Waiver shall not be subject to
+revocation, rescission, cancellation, termination, or any other legal or
+equitable action to disrupt the quiet enjoyment of the Work by the public
+as contemplated by Affirmer's express Statement of Purpose.
+
+3. Public License Fallback. Should any part of the Waiver for any reason
+be judged legally invalid or ineffective under applicable law, then the
+Waiver shall be preserved to the maximum extent permitted taking into
+account Affirmer's express Statement of Purpose. In addition, to the
+extent the Waiver is so judged Affirmer hereby grants to each affected
+person a royalty-free, non transferable, non sublicensable, non exclusive,
+irrevocable and unconditional license to exercise Affirmer's Copyright and
+Related Rights in the Work (i) in all territories worldwide, (ii) for the
+maximum duration provided by applicable law or treaty (including future
+time extensions), (iii) in any current or future medium and for any number
+of copies, and (iv) for any purpose whatsoever, including without
+limitation commercial, advertising or promotional purposes (the
+"License"). The License shall be deemed effective as of the date CC0 was
+applied by Affirmer to the Work. Should any part of the License for any
+reason be judged legally invalid or ineffective under applicable law, such
+partial invalidity or ineffectiveness shall not invalidate the remainder
+of the License, and in such case Affirmer hereby affirms that he or she
+will not (i) exercise any of his or her remaining Copyright and Related
+Rights in the Work or (ii) assert any associated claims and causes of
+action with respect to the Work, in either case contrary to Affirmer's
+express Statement of Purpose.
+
+4. Limitations and Disclaimers.
+
+ a. No trademark or patent rights held by Affirmer are waived, abandoned,
+    surrendered, licensed or otherwise affected by this document.
+ b. Affirmer offers the Work as-is and makes no representations or
+    warranties of any kind concerning the Work, express, implied,
+    statutory or otherwise, including without limitation warranties of
+    title, merchantability, fitness for a particular purpose, non
+    infringement, or the absence of latent or other defects, accuracy, or
+    the present or absence of errors, whether or not discoverable, all to
+    the greatest extent permissible under applicable law.
+ c. Affirmer disclaims responsibility for clearing rights of other persons
+    that may apply to the Work or any use thereof, including without
+    limitation any person's Copyright and Related Rights in the Work.
+    Further, Affirmer disclaims responsibility for obtaining any necessary
+    consents, permissions or other rights required for any use of the
+    Work.
+ d. Affirmer understands and acknowledges that Creative Commons is not a
+    party to this document and has no duty or obligation with respect to
+    this CC0 or use of the Work.

docs/README.md

@@ -0,0 +1,24 @@
+# GregTech CEu Modern Documentation
+
+This documentation project is built using [MkDocs](https://www.mkdocs.org/#).
+
+For an automatically updating live preview in your browser, run `mkdocs serve`
+
+
+## Installing Required Dependencies
+
+To install the required dependencies, please run `pip install -r requirements.txt`
+
+
+## Used MkDocs Plugins
+
+The following plugins for MkDocs are being used:
+
+- https://squidfunk.github.io/mkdocs-material/
+- https://github.com/lukasgeiter/mkdocs-awesome-pages-plugin
+
+## Contributing
+
+When contributing to this project, please refer to the [Styleguide](./CONTRIBUTING.md).  
+I know it's kinda long, but it will help in keeping the documentation consistent. You will also find examples of
+when to use specific features of mkdocs and mkdocs-material.

docs/content/.pages

@@ -0,0 +1,5 @@
+nav:
+  - 'Home': 'index.md'
+  - 'Gameplay'
+  - 'Modpack Authors': Modpacks
+  - 'Developers': 'Development'

docs/content/Development/.pages

@@ -0,0 +1,7 @@
+nav:
+  - index.md
+  - Glossary.md
+  - External-Resources.md
+  - FAQ.md
+  - General-Topics
+  - ...