Document custom Qodot Nodes and custom Qodot Resources

[RisingThumb]

It may be worthwhile documenting the following for completeness(If only to point out for some that they are internal and not relevant to the majority of users). Documenting their fields, methods, signals and inheritance tree.

Resources

• QodotFGDClass
• QodotFGDBaseClass
• QodotFGDPointClass
• QodotFGDSolidClass
• QodotFGDFile
• QodotWorldspawnLayer
• QuakeMapFile
• QuakePaletteFile
• QuakeWadFile

Nodes

• QodotPlugin
• QodotSpatial
• QodotMap
• QodotEntity
• QodotLight
• QodotRotateEntity

An example of this, is that for QodotMap, the signal outputs aren't documented(something I've used for knowing when to generate navmeshes at runtime after generating a map at runtime) and then using the verify_and_build() method available on QodotMap(should make more programmatic use of QodotMap easier to find out about).

As for the resources, the BaseClass, PointClass and SolidClass resources are already documented under the Entities section, but I don't know if we want exhaustive documentation on their fields there. It may be better to present the most useful fields there, and link to the complete reference for the resources.

In my head for this, I have in mind something akin to javadocs or the Godot Docs class Reference https://docs.godotengine.org/en/stable/classes/index.html

BaseClass, PointClass, SolidClass and QodotMap are the particular resources and nodes I imagine being something to prioritise with this ticket as these are the most frequently used in projects using Qodot. The others listed above, I'm aware they exist, but haven't used them or looked much into them(I expect they are mostly internally used).

[DeerTears]

This issue's been really useful, thanks for that.

I've been working my way through documenting the resources a bit better, but the nodes definitely could use something more concrete.

Should there be a separate class reference from the usage guide? I've been keeping them close together in hopes that everything about FGDs can be found on one page, similar for Entity Definitions, CFGs, etc.

[RisingThumb]

I think it should be documented as it's stuff the plugin leaves exposed for the developer to use. As for whether there should be a separate class reference, I'm not opposed to that- though I'd suggest keeping them under a single site/repository for documentation and splitting it out into a Usage section, and a Reference section. Where you are comprehensive in the current usage pages, consider pulling that out into the reference section to improve readability.