Notes on Forge Model Docs

/models/introduction.md

- Old Models/New Models - While technically accurate, these subheaders have a double meaning.  In this context, model refers to the literal model, rather than a "model for doing things".  I'd use "method" or "approach" instead.
  eg. The Old Method / The New Method

- ISBRHs and IIR should be defined after the word is used.
  eg. "You'd hardcode your shape into a class that implements ISimpleBlockRenderingHandler (ISBRHs) or IItemRenderer (IIR), and register that class."

- This may be overly technical.  Is explaining implementation detail necessary for the old method?

/models/files.md

- "Domain" isn't defined.  A brief explanation and example path using one would help.

- Second paragraph could use restructuring.  It first talks about paths, then immediate segues into item overrides.  Split these up into separate paragraphs and elaborate if necessary.

- Third paragraph goes back to talking paths.  Can be joined with paragraph 2.

- Third paragraph jumps into discussing uv without explaining what they are (xy coords on texture mapping).  Again, move to own paragraph and elaborate.

- This line is unclear: "Most things do not care about what loaded the model or what format it's in".  Would make more sense immediately after introducing WaveFront/Blitz3D object files, or in the context of alternate loaders below.

- Typo: "its SIDE must be a power of two"

/models/blockstates/introduction.md

- I think the introduction should give more of an overview of what a blockstate actually does.
  eg. "Blockstates are used to represent all the possible states of blocks in the world.  They largely replace metadata for storing information about a block, and are used for everything from representing if a door is open to which way a jack o' lantern is looking."
I'd then show the oak log example and then get into how "variant strings" work.

- Uses "properties" without defining.

- There should be a paragraph split when discussing Mojang vs Forge's model formats.

/models/blockstates/forgeBlockstates.md

- Uses "normal" (as in 'normal blockstate') without defining.

- This text:
    "!!! Attention"
And the block quote tag breaks convention.  It also seems an inappropriate place for this info.  Would fit in better in files.md when explaining how paths work.

- Another rule:
    "Notice here that the string used in the json is lowercase, however. It has to be lowercase or it wont be found."
Are these rules common enough to be put into a big list, rather than strewn throughout the document?  A "please note" syntax may be ideal in any case.

/models/docs/models/using.md

- Defined what an MRL is, but not RL.  So this is unclear:
    "Set said name as the ResourceLocation part of the MRL."

- Typo: "IStateMappers are REGISERED per block"

- Typo (arguably): "for some of the most common USECASES of custom IStateMappers" - Reads easier as two words.

- setName subheader is an h5.  The others are h4s.

- "!!! note" and "!!! important" again.  I'd suggest alternate emphasis.

- "When you call ModelLoader.setCustomMRL".  You should use the full method name.

- The bottom section here on ItemMeshDefinition and setCustomMeshDefinition might be better as a proper tutorial (how to render items dynamically), rather than as a footnote on this page.  Essentially make it clear that setCustomMRL does the work for you, but using these two lets you have more control over rendering.

/models/overrides.md

- Second paragraph, starts explaining binding MRLs to metadata, then immediately moves into the downside with the bow example.  It's fine to explain why overrides are useful, but it should be separate from explaining how the other method.  Along with the last page, I think a separate page devoted to "getting your items rendering using different methods" would be useful.