CloudModding:Policy
From CloudModding OoT Wiki
Here's my personal goals for the Cloudmodding wiki, at least the Z64 stuff Mzxrules (talk) 05:52, 20 June 2017 (CEST)
Objectives
Our goal here is to document everything code/data wise with the Zelda64 games in the most sane way possible. As such, I have the following guidelines
- Cloudmodding should not be bogged down by poorly written tutorials, especially ones in the mainspace
- Editors should assume that readers have a reasonable understanding of basic concepts shared by most computer programming languages. As such, there is no place tutorials on basic concepts like "hex", "pointers", "data structs"
- Tutorials with an extremely narrow focus (e.g. Custom Tunic Colors in MM, How to remodel Link's Sword, etc.) are also better posted elsewhere
- Complex subjects that aren't necessarily Zelda64 specific (i.e. MIPS assembly) are better learned elsewhere as well.
- Documentation should attempt to be version agnostic whenever sensible to do so, since many data structures appear/have the same structure across all versions.
- When dealing with large tables that are structurally the same, but contain different values across versions is to create a main page that documents the structure, followed by subpages that contain the individual. Furthermore, the following version codes should be used when creating such pages:
- Ocarina of Time: NTSC 1.0, NTSC 1.1, NTSC 1.2, PAL 1.0, PAL 1.1, Debug
- Majora's Mask: J 1.0, J 1.1, U 1.0, PAL 1.0, PAL 1.1, Debug, Demo
- When dealing with large tables that are structurally the same, but contain different values across versions is to create a main page that documents the structure, followed by subpages that contain the individual. Furthermore, the following version codes should be used when creating such pages:
- Cheat code documentation is frowned upon. There is some useful information to be gained through cheat codes, and some "basic" codes useful to some for testing, which is why the Cheat namespace still exists. In the mainspace however, cheats should be converted into a form that explains a variable, documented in a way where that variable's domain (i.e. vrom/vram), type (e.g. ptr/int/short), and scope/location (lives in an actor instance? part of "code" file?) is as clear as one can figure out.