├── .gitattributes ├── LICENSE.md └── README.md /.gitattributes: -------------------------------------------------------------------------------- 1 | # Git to autodetect text files and normalise their line endings to LF when they are checked into your repository. 2 | * text=auto 3 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | ### GNU Free Documentation License 2 | 3 | Version 1.3, 3 November 2008 4 | 5 | Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, 6 | Inc. 7 | 8 | Everyone is permitted to copy and distribute verbatim copies of this 9 | license document, but changing it is not allowed. 10 | 11 | #### 0. PREAMBLE 12 | 13 | The purpose of this License is to make a manual, textbook, or other 14 | functional and useful document "free" in the sense of freedom: to 15 | assure everyone the effective freedom to copy and redistribute it, 16 | with or without modifying it, either commercially or noncommercially. 17 | Secondarily, this License preserves for the author and publisher a way 18 | to get credit for their work, while not being considered responsible 19 | for modifications made by others. 20 | 21 | This License is a kind of "copyleft", which means that derivative 22 | works of the document must themselves be free in the same sense. It 23 | complements the GNU General Public License, which is a copyleft 24 | license designed for free software. 25 | 26 | We have designed this License in order to use it for manuals for free 27 | software, because free software needs free documentation: a free 28 | program should come with manuals providing the same freedoms that the 29 | software does. But this License is not limited to software manuals; it 30 | can be used for any textual work, regardless of subject matter or 31 | whether it is published as a printed book. We recommend this License 32 | principally for works whose purpose is instruction or reference. 33 | 34 | #### 1. APPLICABILITY AND DEFINITIONS 35 | 36 | This License applies to any manual or other work, in any medium, that 37 | contains a notice placed by the copyright holder saying it can be 38 | distributed under the terms of this License. Such a notice grants a 39 | world-wide, royalty-free license, unlimited in duration, to use that 40 | work under the conditions stated herein. The "Document", below, refers 41 | to any such manual or work. Any member of the public is a licensee, 42 | and is addressed as "you". You accept the license if you copy, modify 43 | or distribute the work in a way requiring permission under copyright 44 | law. 45 | 46 | A "Modified Version" of the Document means any work containing the 47 | Document or a portion of it, either copied verbatim, or with 48 | modifications and/or translated into another language. 49 | 50 | A "Secondary Section" is a named appendix or a front-matter section of 51 | the Document that deals exclusively with the relationship of the 52 | publishers or authors of the Document to the Document's overall 53 | subject (or to related matters) and contains nothing that could fall 54 | directly within that overall subject. (Thus, if the Document is in 55 | part a textbook of mathematics, a Secondary Section may not explain 56 | any mathematics.) The relationship could be a matter of historical 57 | connection with the subject or with related matters, or of legal, 58 | commercial, philosophical, ethical or political position regarding 59 | them. 60 | 61 | The "Invariant Sections" are certain Secondary Sections whose titles 62 | are designated, as being those of Invariant Sections, in the notice 63 | that says that the Document is released under this License. If a 64 | section does not fit the above definition of Secondary then it is not 65 | allowed to be designated as Invariant. The Document may contain zero 66 | Invariant Sections. If the Document does not identify any Invariant 67 | Sections then there are none. 68 | 69 | The "Cover Texts" are certain short passages of text that are listed, 70 | as Front-Cover Texts or Back-Cover Texts, in the notice that says that 71 | the Document is released under this License. A Front-Cover Text may be 72 | at most 5 words, and a Back-Cover Text may be at most 25 words. 73 | 74 | A "Transparent" copy of the Document means a machine-readable copy, 75 | represented in a format whose specification is available to the 76 | general public, that is suitable for revising the document 77 | straightforwardly with generic text editors or (for images composed of 78 | pixels) generic paint programs or (for drawings) some widely available 79 | drawing editor, and that is suitable for input to text formatters or 80 | for automatic translation to a variety of formats suitable for input 81 | to text formatters. A copy made in an otherwise Transparent file 82 | format whose markup, or absence of markup, has been arranged to thwart 83 | or discourage subsequent modification by readers is not Transparent. 84 | An image format is not Transparent if used for any substantial amount 85 | of text. A copy that is not "Transparent" is called "Opaque". 86 | 87 | Examples of suitable formats for Transparent copies include plain 88 | ASCII without markup, Texinfo input format, LaTeX input format, SGML 89 | or XML using a publicly available DTD, and standard-conforming simple 90 | HTML, PostScript or PDF designed for human modification. Examples of 91 | transparent image formats include PNG, XCF and JPG. Opaque formats 92 | include proprietary formats that can be read and edited only by 93 | proprietary word processors, SGML or XML for which the DTD and/or 94 | processing tools are not generally available, and the 95 | machine-generated HTML, PostScript or PDF produced by some word 96 | processors for output purposes only. 97 | 98 | The "Title Page" means, for a printed book, the title page itself, 99 | plus such following pages as are needed to hold, legibly, the material 100 | this License requires to appear in the title page. For works in 101 | formats which do not have any title page as such, "Title Page" means 102 | the text near the most prominent appearance of the work's title, 103 | preceding the beginning of the body of the text. 104 | 105 | The "publisher" means any person or entity that distributes copies of 106 | the Document to the public. 107 | 108 | A section "Entitled XYZ" means a named subunit of the Document whose 109 | title either is precisely XYZ or contains XYZ in parentheses following 110 | text that translates XYZ in another language. (Here XYZ stands for a 111 | specific section name mentioned below, such as "Acknowledgements", 112 | "Dedications", "Endorsements", or "History".) To "Preserve the Title" 113 | of such a section when you modify the Document means that it remains a 114 | section "Entitled XYZ" according to this definition. 115 | 116 | The Document may include Warranty Disclaimers next to the notice which 117 | states that this License applies to the Document. These Warranty 118 | Disclaimers are considered to be included by reference in this 119 | License, but only as regards disclaiming warranties: any other 120 | implication that these Warranty Disclaimers may have is void and has 121 | no effect on the meaning of this License. 122 | 123 | #### 2. VERBATIM COPYING 124 | 125 | You may copy and distribute the Document in any medium, either 126 | commercially or noncommercially, provided that this License, the 127 | copyright notices, and the license notice saying this License applies 128 | to the Document are reproduced in all copies, and that you add no 129 | other conditions whatsoever to those of this License. You may not use 130 | technical measures to obstruct or control the reading or further 131 | copying of the copies you make or distribute. However, you may accept 132 | compensation in exchange for copies. If you distribute a large enough 133 | number of copies you must also follow the conditions in section 3. 134 | 135 | You may also lend copies, under the same conditions stated above, and 136 | you may publicly display copies. 137 | 138 | #### 3. COPYING IN QUANTITY 139 | 140 | If you publish printed copies (or copies in media that commonly have 141 | printed covers) of the Document, numbering more than 100, and the 142 | Document's license notice requires Cover Texts, you must enclose the 143 | copies in covers that carry, clearly and legibly, all these Cover 144 | Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on 145 | the back cover. Both covers must also clearly and legibly identify you 146 | as the publisher of these copies. The front cover must present the 147 | full title with all words of the title equally prominent and visible. 148 | You may add other material on the covers in addition. Copying with 149 | changes limited to the covers, as long as they preserve the title of 150 | the Document and satisfy these conditions, can be treated as verbatim 151 | copying in other respects. 152 | 153 | If the required texts for either cover are too voluminous to fit 154 | legibly, you should put the first ones listed (as many as fit 155 | reasonably) on the actual cover, and continue the rest onto adjacent 156 | pages. 157 | 158 | If you publish or distribute Opaque copies of the Document numbering 159 | more than 100, you must either include a machine-readable Transparent 160 | copy along with each Opaque copy, or state in or with each Opaque copy 161 | a computer-network location from which the general network-using 162 | public has access to download using public-standard network protocols 163 | a complete Transparent copy of the Document, free of added material. 164 | If you use the latter option, you must take reasonably prudent steps, 165 | when you begin distribution of Opaque copies in quantity, to ensure 166 | that this Transparent copy will remain thus accessible at the stated 167 | location until at least one year after the last time you distribute an 168 | Opaque copy (directly or through your agents or retailers) of that 169 | edition to the public. 170 | 171 | It is requested, but not required, that you contact the authors of the 172 | Document well before redistributing any large number of copies, to 173 | give them a chance to provide you with an updated version of the 174 | Document. 175 | 176 | #### 4. MODIFICATIONS 177 | 178 | You may copy and distribute a Modified Version of the Document under 179 | the conditions of sections 2 and 3 above, provided that you release 180 | the Modified Version under precisely this License, with the Modified 181 | Version filling the role of the Document, thus licensing distribution 182 | and modification of the Modified Version to whoever possesses a copy 183 | of it. In addition, you must do these things in the Modified Version: 184 | 185 | - A. Use in the Title Page (and on the covers, if any) a title 186 | distinct from that of the Document, and from those of previous 187 | versions (which should, if there were any, be listed in the 188 | History section of the Document). You may use the same title as a 189 | previous version if the original publisher of that version 190 | gives permission. 191 | - B. List on the Title Page, as authors, one or more persons or 192 | entities responsible for authorship of the modifications in the 193 | Modified Version, together with at least five of the principal 194 | authors of the Document (all of its principal authors, if it has 195 | fewer than five), unless they release you from this requirement. 196 | - C. State on the Title page the name of the publisher of the 197 | Modified Version, as the publisher. 198 | - D. Preserve all the copyright notices of the Document. 199 | - E. Add an appropriate copyright notice for your modifications 200 | adjacent to the other copyright notices. 201 | - F. Include, immediately after the copyright notices, a license 202 | notice giving the public permission to use the Modified Version 203 | under the terms of this License, in the form shown in the 204 | Addendum below. 205 | - G. Preserve in that license notice the full lists of Invariant 206 | Sections and required Cover Texts given in the Document's 207 | license notice. 208 | - H. Include an unaltered copy of this License. 209 | - I. Preserve the section Entitled "History", Preserve its Title, 210 | and add to it an item stating at least the title, year, new 211 | authors, and publisher of the Modified Version as given on the 212 | Title Page. If there is no section Entitled "History" in the 213 | Document, create one stating the title, year, authors, and 214 | publisher of the Document as given on its Title Page, then add an 215 | item describing the Modified Version as stated in the 216 | previous sentence. 217 | - J. Preserve the network location, if any, given in the Document 218 | for public access to a Transparent copy of the Document, and 219 | likewise the network locations given in the Document for previous 220 | versions it was based on. These may be placed in the "History" 221 | section. You may omit a network location for a work that was 222 | published at least four years before the Document itself, or if 223 | the original publisher of the version it refers to 224 | gives permission. 225 | - K. For any section Entitled "Acknowledgements" or "Dedications", 226 | Preserve the Title of the section, and preserve in the section all 227 | the substance and tone of each of the contributor acknowledgements 228 | and/or dedications given therein. 229 | - L. Preserve all the Invariant Sections of the Document, unaltered 230 | in their text and in their titles. Section numbers or the 231 | equivalent are not considered part of the section titles. 232 | - M. Delete any section Entitled "Endorsements". Such a section may 233 | not be included in the Modified Version. 234 | - N. Do not retitle any existing section to be Entitled 235 | "Endorsements" or to conflict in title with any Invariant Section. 236 | - O. Preserve any Warranty Disclaimers. 237 | 238 | If the Modified Version includes new front-matter sections or 239 | appendices that qualify as Secondary Sections and contain no material 240 | copied from the Document, you may at your option designate some or all 241 | of these sections as invariant. To do this, add their titles to the 242 | list of Invariant Sections in the Modified Version's license notice. 243 | These titles must be distinct from any other section titles. 244 | 245 | You may add a section Entitled "Endorsements", provided it contains 246 | nothing but endorsements of your Modified Version by various 247 | parties—for example, statements of peer review or that the text has 248 | been approved by an organization as the authoritative definition of a 249 | standard. 250 | 251 | You may add a passage of up to five words as a Front-Cover Text, and a 252 | passage of up to 25 words as a Back-Cover Text, to the end of the list 253 | of Cover Texts in the Modified Version. Only one passage of 254 | Front-Cover Text and one of Back-Cover Text may be added by (or 255 | through arrangements made by) any one entity. If the Document already 256 | includes a cover text for the same cover, previously added by you or 257 | by arrangement made by the same entity you are acting on behalf of, 258 | you may not add another; but you may replace the old one, on explicit 259 | permission from the previous publisher that added the old one. 260 | 261 | The author(s) and publisher(s) of the Document do not by this License 262 | give permission to use their names for publicity for or to assert or 263 | imply endorsement of any Modified Version. 264 | 265 | #### 5. COMBINING DOCUMENTS 266 | 267 | You may combine the Document with other documents released under this 268 | License, under the terms defined in section 4 above for modified 269 | versions, provided that you include in the combination all of the 270 | Invariant Sections of all of the original documents, unmodified, and 271 | list them all as Invariant Sections of your combined work in its 272 | license notice, and that you preserve all their Warranty Disclaimers. 273 | 274 | The combined work need only contain one copy of this License, and 275 | multiple identical Invariant Sections may be replaced with a single 276 | copy. If there are multiple Invariant Sections with the same name but 277 | different contents, make the title of each such section unique by 278 | adding at the end of it, in parentheses, the name of the original 279 | author or publisher of that section if known, or else a unique number. 280 | Make the same adjustment to the section titles in the list of 281 | Invariant Sections in the license notice of the combined work. 282 | 283 | In the combination, you must combine any sections Entitled "History" 284 | in the various original documents, forming one section Entitled 285 | "History"; likewise combine any sections Entitled "Acknowledgements", 286 | and any sections Entitled "Dedications". You must delete all sections 287 | Entitled "Endorsements". 288 | 289 | #### 6. COLLECTIONS OF DOCUMENTS 290 | 291 | You may make a collection consisting of the Document and other 292 | documents released under this License, and replace the individual 293 | copies of this License in the various documents with a single copy 294 | that is included in the collection, provided that you follow the rules 295 | of this License for verbatim copying of each of the documents in all 296 | other respects. 297 | 298 | You may extract a single document from such a collection, and 299 | distribute it individually under this License, provided you insert a 300 | copy of this License into the extracted document, and follow this 301 | License in all other respects regarding verbatim copying of that 302 | document. 303 | 304 | #### 7. AGGREGATION WITH INDEPENDENT WORKS 305 | 306 | A compilation of the Document or its derivatives with other separate 307 | and independent documents or works, in or on a volume of a storage or 308 | distribution medium, is called an "aggregate" if the copyright 309 | resulting from the compilation is not used to limit the legal rights 310 | of the compilation's users beyond what the individual works permit. 311 | When the Document is included in an aggregate, this License does not 312 | apply to the other works in the aggregate which are not themselves 313 | derivative works of the Document. 314 | 315 | If the Cover Text requirement of section 3 is applicable to these 316 | copies of the Document, then if the Document is less than one half of 317 | the entire aggregate, the Document's Cover Texts may be placed on 318 | covers that bracket the Document within the aggregate, or the 319 | electronic equivalent of covers if the Document is in electronic form. 320 | Otherwise they must appear on printed covers that bracket the whole 321 | aggregate. 322 | 323 | #### 8. TRANSLATION 324 | 325 | Translation is considered a kind of modification, so you may 326 | distribute translations of the Document under the terms of section 4. 327 | Replacing Invariant Sections with translations requires special 328 | permission from their copyright holders, but you may include 329 | translations of some or all Invariant Sections in addition to the 330 | original versions of these Invariant Sections. You may include a 331 | translation of this License, and all the license notices in the 332 | Document, and any Warranty Disclaimers, provided that you also include 333 | the original English version of this License and the original versions 334 | of those notices and disclaimers. In case of a disagreement between 335 | the translation and the original version of this License or a notice 336 | or disclaimer, the original version will prevail. 337 | 338 | If a section in the Document is Entitled "Acknowledgements", 339 | "Dedications", or "History", the requirement (section 4) to Preserve 340 | its Title (section 1) will typically require changing the actual 341 | title. 342 | 343 | #### 9. TERMINATION 344 | 345 | You may not copy, modify, sublicense, or distribute the Document 346 | except as expressly provided under this License. Any attempt otherwise 347 | to copy, modify, sublicense, or distribute it is void, and will 348 | automatically terminate your rights under this License. 349 | 350 | However, if you cease all violation of this License, then your license 351 | from a particular copyright holder is reinstated (a) provisionally, 352 | unless and until the copyright holder explicitly and finally 353 | terminates your license, and (b) permanently, if the copyright holder 354 | fails to notify you of the violation by some reasonable means prior to 355 | 60 days after the cessation. 356 | 357 | Moreover, your license from a particular copyright holder is 358 | reinstated permanently if the copyright holder notifies you of the 359 | violation by some reasonable means, this is the first time you have 360 | received notice of violation of this License (for any work) from that 361 | copyright holder, and you cure the violation prior to 30 days after 362 | your receipt of the notice. 363 | 364 | Termination of your rights under this section does not terminate the 365 | licenses of parties who have received copies or rights from you under 366 | this License. If your rights have been terminated and not permanently 367 | reinstated, receipt of a copy of some or all of the same material does 368 | not give you any rights to use it. 369 | 370 | #### 10. FUTURE REVISIONS OF THIS LICENSE 371 | 372 | The Free Software Foundation may publish new, revised versions of the 373 | GNU Free Documentation License from time to time. Such new versions 374 | will be similar in spirit to the present version, but may differ in 375 | detail to address new problems or concerns. See 376 | . 377 | 378 | Each version of the License is given a distinguishing version number. 379 | If the Document specifies that a particular numbered version of this 380 | License "or any later version" applies to it, you have the option of 381 | following the terms and conditions either of that specified version or 382 | of any later version that has been published (not as a draft) by the 383 | Free Software Foundation. If the Document does not specify a version 384 | number of this License, you may choose any version ever published (not 385 | as a draft) by the Free Software Foundation. If the Document specifies 386 | that a proxy can decide which future versions of this License can be 387 | used, that proxy's public statement of acceptance of a version 388 | permanently authorizes you to choose that version for the Document. 389 | 390 | #### 11. RELICENSING 391 | 392 | "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 393 | World Wide Web server that publishes copyrightable works and also 394 | provides prominent facilities for anybody to edit those works. A 395 | public wiki that anybody can edit is an example of such a server. A 396 | "Massive Multiauthor Collaboration" (or "MMC") contained in the site 397 | means any set of copyrightable works thus published on the MMC site. 398 | 399 | "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 400 | license published by Creative Commons Corporation, a not-for-profit 401 | corporation with a principal place of business in San Francisco, 402 | California, as well as future copyleft versions of that license 403 | published by that same organization. 404 | 405 | "Incorporate" means to publish or republish a Document, in whole or in 406 | part, as part of another Document. 407 | 408 | An MMC is "eligible for relicensing" if it is licensed under this 409 | License, and if all works that were first published under this License 410 | somewhere other than this MMC, and subsequently incorporated in whole 411 | or in part into the MMC, (1) had no cover texts or invariant sections, 412 | and (2) were thus incorporated prior to November 1, 2008. 413 | 414 | The operator of an MMC Site may republish an MMC contained in the site 415 | under CC-BY-SA on the same site at any time before August 1, 2009, 416 | provided the MMC is eligible for relicensing. 417 | 418 | ### ADDENDUM: How to use this License for your documents 419 | 420 | To use this License in a document you have written, include a copy of 421 | the License in the document and put the following copyright and 422 | license notices just after the title page: 423 | 424 | Copyright (C) YEAR YOUR NAME. 425 | Permission is granted to copy, distribute and/or modify this document 426 | under the terms of the GNU Free Documentation License, Version 1.3 427 | or any later version published by the Free Software Foundation; 428 | with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. 429 | A copy of the license is included in the section entitled "GNU 430 | Free Documentation License". 431 | 432 | If you have Invariant Sections, Front-Cover Texts and Back-Cover 433 | Texts, replace the "with … Texts." line with this: 434 | 435 | with the Invariant Sections being LIST THEIR TITLES, with the 436 | Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. 437 | 438 | If you have Invariant Sections without Cover Texts, or some other 439 | combination of the three, merge those two alternatives to suit the 440 | situation. 441 | 442 | If your document contains nontrivial examples of program code, we 443 | recommend releasing these examples in parallel under your choice of 444 | free software license, such as the GNU General Public License, to 445 | permit their use in free software. 446 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Unofficial Guide to Modding Project Zomboid 2 | 3 | [![release](https://img.shields.io/github/v/release/cocolabs/pz-modding-guide)](https://github.com/cocolabs/pz-modding-guide/releases/latest) ![last-commit](https://img.shields.io/github/last-commit/cocolabs/pz-modding-guide/draft) [![License](https://img.shields.io/badge/license-FDL--1.3-orange?logo=gnu)](https://www.gnu.org/licenses/fdl-1.3) [![chat](https://img.shields.io/discord/717757483376050203?color=7289DA&label=discord&logo=discord&logoColor=white)](https://discord.gg/vCeydWCbd9) 4 | 5 | This document will focus on explaining the methodology used to create, publish and install [Project Zomboid](https://projectzomboid.com/blog/) modifications. The goal of this guide is to provide, as considered by author, the best way to create, publish and install Project Zomboid modifications. What is implied by *best way* is explained later in the guide. 6 | 7 | This document is intended to be a complete guide that guides you through the process of modding various game aspects, providing detailed examples and explaining the reasoning behind the methodology used. If you are just looking for references, tutorials, code examples or a quick guide to creating simple modifications you should read [Project Zomboid Modding Guide](https://github.com/FWolfe/Zomboid-Modding-Guide) instead which serves more as an unofficial Project Zomboid wiki. 8 | 9 | ## Contents 10 | 11 | - [How to read this guide](#how-to-read-this-guide) 12 | - [Glossary](#glossary) 13 | - [Disclaimer](#disclaimer) 14 | - [Motivation](#motivation) 15 | - [Requirements](#requirements) 16 | - [Methodology](#methodology) 17 | - [Reasoning](#reasoning) 18 | - [Design](#design) 19 | - [Version control](#version-control) 20 | - [What is VCS?](#what-is-vcs) 21 | - [Why use VCS?](#why-use-vcs) 22 | - [How to use VCS?](#how-to-use-vcs) 23 | - [Documentation](#documentation) 24 | - [Project wiki](#project-wiki) 25 | - [Licensing](#licensing) 26 | - [Freedom](#freedom) 27 | - [Which license?](#which-license) 28 | - [Steam Workshop](#steam-workshop) 29 | - [Tools](#tools) 30 | - [Environment](#environment) 31 | - [Writing code](#writing-code) 32 | - [Lua modding](#lua-modding) 33 | - [Advantages](#advantages) 34 | - [Disadvantages](#disadvantages) 35 | - [Limitations](#limitations) 36 | - [Java modding](#java-modding) 37 | - [Advantages](#advantages-1) 38 | - [Disadvantages](#disadvantages-1) 39 | - [Recompiling](#recompiling) 40 | - [The Storm Project](#the-storm-project) 41 | - [Community](#community) 42 | - [Credits](#credits) 43 | - [License](#license) 44 | 45 | ## How to read this guide 46 | 47 | Due to the large size of this guide it is **not recommended** to read it using your web browser. 48 | 49 | Instead you should use [Typora](https://typora.io/), a free and open source markdown editor. It is beautiful, lightweight and perfect for reading and writing markdown files. It features an outline panel which allows you to see the outline structure of this document allowing you to quickly go through the document and jump to any section with one click. It also has different themes to choose from, allowing you to customize your reading experience. 50 | 51 | ## Glossary 52 | 53 | - **Mod** - One or more files that modify the game either directly or through third party applications. 54 | - **Modding** - The process of modifying Project Zomboid or video game files in general. 55 | - **Mod development** - The process of creating and publishing game modifications. 56 | - **Workflow** - The set of relationships between project activities, from start to finish. 57 | - **Methodology** - An organized and documented set of procedures and guidelines. 58 | - **License** - Refers to a software license which is a legal instrument governing the use or redistribution of software. 59 | - **Java** - High level, class based, object-oriented programming language developed by Oracle. 60 | - **Lua** - Lightweight, high-level programming language primarily used to provide application scripting support. 61 | - **IDE** - Refers to *Integrated development environment* which is an application that provides tools for software development. 62 | - **Open source** - The quality of having publicly accessible design (mostly referring to software). 63 | - **Decompile** - The process of creating a source file from a compiled class file. 64 | - **API** - Refers to *Application Programing Interface* which is an interface that defines interactions between multiple software applications. 65 | - **Bug** - An error in software that causes it to produce an incorrect or unexpected result. 66 | - **Debug** - The process of finding and resolving bugs within software. 67 | - **Changelog** - Log or record of all notable changes made to a project. 68 | - **JVM** - Refers to *Java Virtual Machine* which is a virtual machine that enables a computer to run Java programs. 69 | - **Bytecode** - Code compiled to run on a Java Virtual Machine. It is usually stored in `.class` files. 70 | 71 | ## Disclaimer 72 | 73 | Readers are encouraged to remember that all information in this guide is presented as *opinion* as opposed to *fact*. Any information directing readers to do one thing instead of another is intended to be taken as *advice* as opposed to an *order*. Statement criticizing any aspect of methodology should not be taken as a *critique* of personal nature. The author of this document does not assume **responsibility** or give **warranties** of any kind. This includes responsibility for offended sensibilities, mood swings, sleepless nights or damage to your software or hardware. The author of this document also make **no guarantee** that any and all information in this guide is accurate at any time beyond the point at which it was written. 74 | 75 | Readers should note that the methodology proposed in this guide is not presented as the *only way*, but rather the *best way* of modding Project Zomboid as perceived by the author of this guide. Readers should also be aware that the methodology proposed in this guide is currently **not accepted** as the recommended way of modding Project Zomboid. This makes it more difficult to find documentation and support from community channels when using said methodology. 76 | 77 | ## Motivation 78 | 79 | The process of game modding is a fun and rewarding activity where players get to modify the game to create interesting and engaging content for themselves and others to enjoy. It can also be exhausting, time consuming and mind numbing experience with most time being spent on preforming tedious tasks, searching for documentation and solving unexpected problems. Not using the right tools or looking at the right places all lead to frustration and an eventual burnout. 80 | 81 | The primary purpose of this guide is to present an alternative way of modding that benefits both mod developers and the modding community as a whole. A way of modding that allows us to create a more sustainable culture of preserving and sharing knowledge. Nobody benefits when mod developers experience regular burnouts or when they develop mods behind closed doors and use copyright licenses to prevent others from copying their work. The culture will not change just because this guide was written, but it will hopefully inspire some to embrace a more community oriented approach to developing mods. 82 | 83 | ## Requirements 84 | 85 | - Willingness to adopt open source development workflows and principles. 86 | - Patience and dedication to learn how to use advanced tools and workflows. 87 | - Basic knowledge of creating content with which the readers wants to modify the game with. For example, if the reader wanted to learn how to implement a new or modify an existing 3D model in the game, the guide would assume the reader is capable of creating or modifying the model on his own and would instead focus on explaining the procedure of preparing the model and importing it in the game. 88 | 89 | In addition to the requirements listed above the following knowledge is recommended but not required: 90 | 91 | - Previous knowledge of Project Zomboid or game modding in general. Having previous knowledge of game modding will make the guide much easier to follow, however the guide will explain modding methodology by assuming the reader has no previous experience modding Project Zomboid or any other game. Note that some aspects of the guide are intended for modders with intermediate and advanced modding experience and will be marked as such. 92 | - Basic knowledge of software development principles and practices. This is recommended because the reasoning behind much of the methodology proposed will be easier to understand for those with some experience in developing software. However, the guide will explain the development principles and practice by assuming the reader has no previous knowledge of said principles and practices. 93 | 94 | ## Methodology 95 | 96 | Before we explain the different modding aspects, it is important to understand the proper principles and procedures with which we create and publish mods. In order to consistently create mods and keep motivated we have to adhere to sane workflows. To help others do the same we have to carefully document our project and keep it free (as in "free speech") and share it with others. Keep in mind that the methodology proposed here should be adhered to regardless of the scope or aspect of your project. The same rules apply whether you want to change a sprite texture or do a complete game overhaul. 97 | 98 | ### Reasoning 99 | 100 | The proposed methodology consists of advanced tools and workflows. Learning to apply this methodology to your modding process takes time and dedication. The justification for this investment in time is increased efficiency and more enjoyable experience. Increased efficiency leads to overall higher mod quality and more free time which can then be used to either create more mods or invest in other things in life. More enjoyable experience means we are less frustrated and more motivation to create even more amazing mods. It also helps create a more healthy community. 101 | 102 | Here are some of the common reasons mod developers give for not using advanced tools and workflows: 103 | 104 | - I am not getting paid for creating mods, it is only a hobby. 105 | - I do not need all the features provided by advanced tools. 106 | - I do not have the time to install and learn how to use these things. 107 | 108 | On the surface these reasons might feel perfectly reasonable, but let's take a closer look at each argument. 109 | 110 | - The first argument claims that **there is no need to put care and effort into something that is only a hobby**. Take for example any major open source project that is widely used by countless users on a daily basis, like Linux distributions. Linux is free software and as such does not make any money from sales. Most contributors to Linux do not get paid and are not looking to get paid. Their main motivation is not money. If the Linux community did not want to put effort into supporting the projects because *it's only a hobby and they are not getting paid for it*, Linux would not be what it is today. 111 | 112 | - The second argument claims that **since not all features of the tool are needed, using the tool makes little sense**. If we think about all the advanced tools we use in our day to day life we can easily think of numerous examples of tools that offer a lot more features then what we are currently using. Take for example your mobile phone. This is an advanced tool that you are only partially utilizing because you don't need to use the countless features it has to offer, yet you are still using it. It is clear that it offers benefits that other more simplistic contraptions (such as rocks and shoestring cups) cannot match. 113 | 114 | - The third argument claims that **the time needed to install and learn how to use advanced tools does not justify it's benefit**. This argument comes from not knowing the actual benefit of said tools. If you thought that the benefit of driving a car over riding a horse is negligible, you would never buy a car and live the rest of your life as a true cowboy. The argument also does not take into account the positive impact that using these tools and workflows in your mod development process has on the whole community. 115 | 116 | In conclusion, it should now be clear what this guide implies when labeling something as the **best way**. It is a way of doing things that is efficient, fun and benefits the community as a whole. As mentioned earlier, it is not the **only way**, and readers are always encouraged to think for themselves. 117 | 118 | ### Design 119 | 120 | Mods should be designed with usability foremost in mind, provided they will be publicly available (as is encouraged in [Freedom](#freedom) section). Many mod developers design their mods to fit their own needs without thinking much about how accessible and configurable their mod is. In most cases this is simply an oversight, but sometimes it's part of development philosophy which is a result of the *"I am not getting paid to create mods, it is only a hobby"* mentality. 121 | 122 | Each mod should have the following design qualities: 123 | 124 | - **Inclusive** - Mod names should not include names or usernames of one or more authors unless it is thematically compatible. For example, calling your clothing mod "John's Cool Clothes" is not acceptable, while calling your underwater diner mod "BlueCrab's sea diner" is acceptable since including the author fits with the theme of the mod. Including your name or username in the name of the mod communicates to everyone that this is and always will be your mod. Establishing a claim in this way prevents the idea of **collective ownership** and makes the community more atomized. Instead of focusing on their own ego, developers should try to focus on the mod idea itself, and welcome community participation. 125 | - **Configurable** - If possible, mods should offer a way to configure various settings so users can tailor their experience, as opposed to being forced to experience the game precisely how the author envisioned it. Configuration options should be accessible and easy to change. A list of configuration options along with configuration instructions should be present somewhere in project documentation. 126 | - **Modular** - Expansive mods that contain a lot of different elements should consider separating optional elements into modules or add-ons. These are separate mods that users can install at their discretion. Mod developers should be careful as not to create too much add-ons for any single mod as that makes it much more difficult to curate and maintain mod lists. As with configuration options, the goal here is to allow the user to tailor his experience. 127 | - **Independent** - Mods that depend on external components should try to integrate as much of those components as possible. Depending on other libraries and mods means that users have to download those libraries and mods, which makes mod management more difficult. Having a lot of mods with dependencies means uninstalling mods becomes a chore as users don't know which dependencies they need to keep and which can be safely removed. 128 | 129 | ### Version control 130 | 131 | In this section we are going to explain what version control systems (VCS) are, how to use them, and why they are an integral part in any mod development process. Always remember that game modding is just downscaled game development and is thus not excluded from software development practices. 132 | 133 | #### What is VCS? 134 | 135 | Here is a good summary of what version control is: 136 | 137 | > Version control, also known as source control, is the practice of tracking and managing changes to software code. Version control systems are software tools that help software teams manage changes to source code over time. Version control software keeps track of every modification to the code in a special kind of database. If a mistake is made, developers can turn back the clock and compare earlier versions of the code to help fix the mistake while minimizing disruption to all team members. It is important to state that version control is not just used to version code. It should be used on any project file that can be versioned, which includes text files, model files, image files etc. 138 | 139 | Read more about version control in this [article](https://www.atlassian.com/git/tutorials/what-is-version-control), after which you should know everything you need to get started with version control. 140 | 141 | #### Why use VCS? 142 | 143 | The main question you might be wondering is why you should use such a seemingly complex system in your mod development workflow. In addition to everything already said in the article linked above, the answer is simple: **it benefits the whole community**. 144 | 145 | When you are using version control in your project and hosting it on a repository hosting service such as [Github](https://www.github.com) you are leaving behind a complete long-term change history of every file contained within your project. This means every change made by you and others you collaborated with over the complete lifespan of development is recorded in detail. When you eventually stop developing the project it can be easily picked up by other developers and continually developed until they pass the torch to others. Introducing version control in your mod development workflow helps the community by making your development process cleaner, more readable and easier to understand and follow. 146 | 147 | Imagine if every mod project you ever came across used version control. How many outdated and abandoned mods have you seen and wanted to revive but had no idea where to begin? How many active mods struggle with simple bugs authors are unable or unwilling to resolve due to *spaghetti* code which makes them more and more reluctant to continue development with each line of code they write? The reason for this is that the authors did not keep a clean record of what they were doing. Most developers will say that documenting code is important but very few will admit that documenting project changes is equally important. 148 | 149 | #### How to use VCS? 150 | 151 | The most widely used modern version control system in the world today is [Git](https://www.atlassian.com/git/tutorials/what-is-git). When using Git every developer's working copy of the code is also a repository that can contain the full history of all changes. This ensures that your project, along with a detail record of changes is always safe as long as a single copy of your project repository is present somewhere, which should always be the case as long as you are using a repository hosting service. The recommended repository hosting service is [Github](https://www.github.com) due to it's great support for open source projects, intuitive web-interface and easy project management. 152 | 153 | - Start by [installing](https://www.atlassian.com/git/tutorials/install-git) Git. It is easy to install and works on most operating systems. 154 | - In addition to installing Git it is also recommended to install [Github Desktop](https://desktop.github.com/) (see [here](https://github.com/shiftkey/desktop) for Linux version). It is a Git desktop client which makes using Git much easier. It provides a clean user interface that keeps simple Git tasks simple and provides much needed quality of life. 155 | - Once you have Git installed read [git - the simple guide](https://rogerdudler.github.io/git-guide/) to learn the basics of using Git. 156 | - Download or bookmark these cheat sheets to help you out when you eventually forget Git commands: 157 | - [Atlassian Git Cheat Sheet](https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet). 158 | - [Simple Git Cheat Sheet by Roger Dudler](https://rogerdudler.github.io/git-guide/files/git_cheat_sheet.pdf). 159 | - [Git command references by yooksi](https://gist.github.com/yooksi/913a23562063ed1925d8064cb9ba35b3). 160 | 161 | Learning how to use version control is a long but worthwhile process. Mod developers need to be encouraged to start using version control in their mod development workflows to help improve the quality of mods and provide better community support for new modders. 162 | 163 | ### Documentation 164 | 165 | Every mod project should contain documentation that clearly states how to use and configure the mod. If there are special installation steps needed to make the mod work those should be documented as well. This documentation should be written in a `README` file that should reside in the project root directory. 166 | 167 | In addition to this, if the mod project contains code, the code itself should be sufficiently documented as to allow others to easily study and understand the code. It should also allow other developers to continue developing the project without getting in contact with the original author. 168 | 169 | #### Project wiki 170 | 171 | Larger projects are encouraged to open and maintain a wiki where they can document different project aspects in detail. For example; a mod that expands foraging should have a wiki page that lists all the different plants that can be foraged, a mod that adds more cooking recipe should list those recipes along with recipe schematics that inform the players how to use them, a mod that overhauls zombie behavior should split each behavior category in different pages and provide a detailed explanation of how exactly different aspects of behavior differ from vanilla behavior. 172 | 173 | The recommended way of creating and hosting wikis is with [Github wikis](https://docs.github.com/en/communities/documenting-your-project-with-wikis/about-wikis). It allows you to write pages in Markdown and HTML format. It also allows others to contribute either directly or via pull requests, since each wiki is a Git repository with it's own detailed history of changes. 174 | 175 | ### Licensing 176 | 177 | The final and most important aspect of modding methodology is licensing. Developing mods is a fun activity that most of us do for free, however this reason should not preclude ethical considerations. Mods should always be developed and distributed under ethical principles. 178 | 179 | As mentioned in the previous section, the main reason why mod developers should learn and practice version control is to help the community. In turn the community helps them. Nobody knows everything and the value of collective knowledge always outweighs that of individual knowledge. 180 | 181 | #### Freedom 182 | 183 | For this same reason mod developers should keep their mods open source, since version control does not benefit the community if it is kept secret. They should also guarantee users essential freedoms when using their mods. Keeping your project open source means that the source code and asset project files are open for anyone to use, study and modify. This principle allows others to contribute to the development and improvement of mods like a community. 184 | 185 | As stated by [GNU](https://www.gnu.org/philosophy/free-sw.html), free and open source software should give users the following essential freedoms: 186 | 187 | > - The freedom to run the program as you wish, for any purpose. 188 | > - The freedom to study how the program works, and change it so it does your computing as you wish. 189 | > - The freedom to redistribute copies so you can help others. 190 | > - The freedom to distribute copies of your modified versions to others. 191 | 192 | Many mod developers are hesitant to make their projects open source as they are afraid that by doing so they are allowing others to steal their work and claim it as their own. This stems from a fundamental misunderstanding of what *free software* is. When declaring your project open source you are not telling the world that you forgo all legal rights and that anyone can do what they want with your work. You are telling the world that they **have the freedom to run, copy, distribute, study, change and improve** your work, nothing more. Most open source licenses protect your work under threat of legal punishment against actions such as someone taking your work and publishing it under their name. 193 | 194 | #### Which license? 195 | 196 | Before starting a mod project you should think about [choosing an open source license](https://choosealicense.com/) that works best for you. The best choice for small and simple projects is the [MIT License](https://choosealicense.com/licenses/mit/) which lets people do almost anything they want with your project, like making and distributing closed source versions. However, if you are working on a more serious project it is recommended to use the [GNU GPL v3](https://choosealicense.com/licenses/gpl-3.0/) license which also lets people do almost anything they want with your project, *except* distributing closed source versions. Not allowing people to distribute closed source versions helps enforce the principles of free software. 197 | 198 | #### Steam Workshop 199 | 200 | When uploading your mod to the [Steam Workshop](https://steamcommunity.com/workshop/) you grant Valve the following rights: 201 | 202 | > Right to use, reproduce, modify, create derivative works from, distribute, transmit, transcode, translate, broadcast, and otherwise communicate, and publicly display and publicly perform, your User Generated Content, and derivative works of your User Generated Content, for the purpose of the operation, distribution, incorporation as part of and promotion of the Steam service, Steam games or other Steam offerings, including Subscriptions. This license is granted to Valve as the content is uploaded on Steam for the entire duration of the intellectual property rights. 203 | 204 | The excerpt above was taken from the [Steam Subscriber Agreement](https://store.steampowered.com/subscriber_agreement/#6). Many believe that by uploading to the Steam Workshop you grant Valve complete ownership and intellectual property rights to your work. After reading the linked subscriber agreement you can see that this is simply not true. You are irrevocably granting Valve certain rights for the duration of the intellectual property rights, but you still retain full intellectual property rights and Valve is not able to take those rights away from you. They are however able to exercise the rights you gave them for the full duration of the agreement. 205 | 206 | ## Tools 207 | 208 | Here is a list of essential tools that every mod developer should use: 209 | 210 | - [Notepad++](https://notepad-plus-plus.org/) - Free source code editor and Notepad replacement written in C++. It should be preferred over programs like [Atom](https://atom.io/) and [Sublime Text](https://www.sublimetext.com/) due to it's efficiency and simplicity. It is a very **portable** and **powerful** tool that allows for advanced text manipulation and formatting. You can use it's expansive search functionality to (recursively) find text occurrences in files across different directories from a single search action. It also support searching, marking and replacing text with regular expression. With that and a lot more advanced features at your disposal Notepad++ is your most efficient tool for searching, editing and formatting text. Note that this only applies to text, when writing code your preferred tool should always be IntelliJ IDEA. 211 | - [IntelliJ IDEA](https://www.jetbrains.com/idea/) - Integrated development environment written in Java for developing software. It allows you to read, write, decompile and search through game code. It also allows you to efficiently search through game scripts and other text based files with an easy to use user interface that supports search scopes and regular expressions. It is also used to setup your **mod development environment**, which is the primary reason it is recommended as an essential tool for all mod developers. Read more about setting up you development environment in [Environment](#environment) section. In addition to this it is important to note that this is the same program used by The Indie Stone developers to write game code. 212 | 213 | ## Environment 214 | 215 | Setting up your mod development environment is the first step in creating your first mod. 216 | 217 | Properly installed mod development environment will allow you to do the following from the comfort of your IDE: 218 | 219 | - Easily setup correct mod structure and assemble mod distribution. 220 | - Easily decompile and read game code with code navigation support. 221 | - Write Lua code with an up-to-date API documentation attached to project. 222 | - Launch and debug Project Zomboid with console logging and use of breakpoints. 223 | - Fully automate changelog generation and create mod distributions with a click of a button. 224 | 225 | Developers that write code will benefit from following features in their IDE: 226 | 227 | - Code analysis helps spot bugs and avoid lengthy debugging sessions. 228 | - Code navigation helps quickly track code flow and find methods, fields and classes. 229 | 230 | Since the development environment includes many interconnecting systems which need to be configured in the right order, it is difficult to setup manually. This is why [The Storm Project](https://github.com/pzstorm/) has created [Capsid](https://github.com/pzstorm/capsid). It is a [Gradle](https://gradle.org/) plugin that enables powerful IDE features and improves your modding workflow. It helps automate the process of setting up, assembling and deploying your project. Read the project [`README`](https://github.com/pzstorm/capsid/blob/master/README.md) for information on how to install, configure and use Capsid. 231 | 232 | ## Writing code 233 | 234 | Project Zomboid's codebase is divided into two main components; the *frontend* and *backend*. The frontend is written in Lua and is mainly focused on defining the user interface. The backed is written in Java and handles most of game logic, rendering objects, registering user input and much more. 235 | 236 | Since the early days of Project Zomboid there was only ever two ways of modding the game; with Lua using the official API or with Java by modifying and recompiling game classes. The following sections list the advantages and disadvantages of both approaches. 237 | 238 | ### Lua modding 239 | 240 | Official modding support is implemented with modified [Kahlua](https://code.google.com/archive/p/kahlua/), which is a Lua interpreter written in Java. It reads instructions written in Lua and executes them in the Java Virtual Machine. Lua interacts with Java using an [API](https://projectzomboid.com/modding/) defined in [`LuaManager`](https://projectzomboid.com/modding/zombie/Lua/LuaManager.html). Methods defined in [`LuaManager.GlobalObject`](https://projectzomboid.com/modding/zombie/Lua/LuaManager.GlobalObject.html) are exported as global Lua functions and classes exported by `LuaManager.Exposer` are available as global Lua tables. 241 | 242 | #### Advantages 243 | 244 | - Easy to learn and write mods with. 245 | - Has officially supported API. 246 | - Supported by the modding community. 247 | 248 | #### Disadvantages 249 | 250 | - Unable to access classes and members that are not directly exposed by API. 251 | - No type safety or on-the-fly compiler errors makes it more difficult to write code. 252 | - More difficult to debug due to lack of proper debugging tools. 253 | - No control over memory management. 254 | 255 | #### Limitations 256 | 257 | - Does not implement all standard Lua modules such as `io.*` and `os.*`. 258 | - Java classes that have not been directly exposed by `LuaManager.Exposer` are not accessible from Lua. 259 | - Java class fields are not accessible from Lua regardless of whether the owner class is directly exposed or not. 260 | - Numbers cannot be stored as any type other then `double` in `KahluaTable` which degrades performance and increases memory use. 261 | 262 | 263 | ### Java modding 264 | 265 | This way of modding is not officially supported and is generally frowned upon by the community. However it offers many advantages over the official way which is why this guide promotes it as the **recommended** way of mod development. 266 | 267 | Still, there are many examples where it makes more sense to use Lua over Java, such as when creating or modifying user interface elements. Keep in mind that your mod can mix both Lua and Java depending on the need. The golden rule here is that any mod implementation that is either impossible to implement in Lua or can be implemented easier in Java then in Lua should be written in Java. The rest should be written in Lua. 268 | 269 | #### Advantages 270 | 271 | - Nearly unlimited scope of modding. 272 | - Type safety and access to all IDE features. 273 | - Easy to inspect and debug your code during runtime. 274 | - Complete control over memory management. 275 | 276 | #### Disadvantages 277 | 278 | - More difficult to learn and use. 279 | - Does not have officially supported API. 280 | - Not supported by *most* of the modding community. 281 | 282 | #### Recompiling 283 | 284 | The old way of modding with Java is by modifying and recompiling game Java classes. 285 | 286 | Here are the steps that need to be repeated for each Java class: 287 | 288 | - Decompile the game class. 289 | - Build the class from decompiled sources. 290 | - Check if new and old class have matching bytecode. 291 | - If the bytecode does not match, modify the new class to match bytecode. 292 | - Apply custom modifications to new class and build it. 293 | 294 | There are three problems with this approach. The first one being that the process outlined above requires extensive knowledge of bytecode and is quite tedious to repeat for each class. The second problem is that every time we update the game to a new version we have to check if the game classes we are replacing have changed and then either repeat the aforementioned process or replace them with our custom classes. The last and most important problem is that there is no safe way to distribute our mods to the community. If we upload the recompiled classes anywhere online we are essentially distributing parts of Project Zomboid which is a proprietary product protected under law. This could easily result in you receiving a visit from judge Spiffo. 295 | 296 | This method of modding is **not recommended** since it is tedious and not useful to the community as a whole. 297 | 298 | #### The Storm Project 299 | 300 | [Zomboid Storm](https://github.com/pzstorm/storm) is the new and *sexy* way of modding Project Zomboid. 301 | 302 | It is a fully integrated Java **modding toolchain** that allows mod developers to easily create functional Java mods using a custom API. It is similar to [Fabric](https://fabricmc.net/) and [Forge](https://files.minecraftforge.net/net/minecraftforge/forge/) which both provide modding capabilities for Minecraft. The project is open source and licensed under [GNU GPL v3](https://www.gnu.org/licenses/gpl-3.0.en.html) license. It is currently in alpha stage of development and releases are publicly available on [Github](https://github.com/pzstorm/storm/releases). Everyone is encouraged to join the testing process by downloading and using the latest pre-release. More information about Storm, including installation instructions and testing procedures can be found in the project [`README`](https://github.com/pzstorm/storm/blob/master/README.md). 303 | 304 | ## Community 305 | 306 | The following is a list of communities where you can discuss and learn about modding: 307 | 308 | - Visit the [PZ Modding](https://theindiestone.com/forums/index.php?/forum/45-pz-modding/) section of the Project Zomboid forum. 309 | - Join the official Project Zomboid [Discord server](https://discord.gg/EjSqDd9x) and visit the `#modding` channel. 310 | - Join [Coco Labs](https://discord.gg/vCeydWCbd9) Discord server to meet the author of this guide and join community projects. 311 | 312 | ## Credits 313 | 314 | - [The Indie Stone](https://projectzomboid.com/blog/about-us/) for creating Project Zomboid and making it the best zombie survival game. 315 | - [FWolfe](https://github.com/FWolfe) for writing [Project Zomboid Modding Guide](https://github.com/FWolfe/Zomboid-Modding-Guide) and inspiring me to write this guide. 316 | - Project Zomboid modding community for helping me learn more about the game. 317 | 318 | ## License 319 | 320 | ``` 321 | Copyright (C) 2021 Matthew Cain. 322 | Permission is granted to copy, distribute and/or modify this document 323 | under the terms of the GNU Free Documentation License, Version 1.3 324 | or any later version published by the Free Software Foundation; 325 | with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. 326 | A copy of the license is included in the section entitled 327 | "GNU Free Documentation License". 328 | ``` 329 | --------------------------------------------------------------------------------