Data organizing/structuring

[th3w1zard1]

I notice everything seems to be thrown into the KotorDotNET.Data namespace. Perhaps a good place to start is to construct a flow chart of how you intend to define the data types using the wisdom gained from PyKotor. I've been thinking of the following organization schema:

KotorDotNET │ ├── Common │ ├── BaseArchive │ ├── BaseTexture │ ├── BaseScript │ ├── BaseTemplate │ ├── BinaryReaderExtensions │ └── BinaryWriterExtensions │ ├── ArchivesAndContainers │ ├── ERF: Dictionary<string, byte[]> │ │ ├── ERFReader │ │ └── ERFWriter │ │ │ ├── MOD: Inherits from ERF │ │ ├── MODReader -- maybe just the header instead of the whole reader? │ │ └── MODWriter │ │ │ ├── RIM: Dictionary<string, byte[]> │ │ ├── RIMReader │ │ └── RIMWriter │ │ │ └── BIF: Dictionary<string, byte[]> │ ├── GraphicsAndVisuals │ ├── Textures │ │ ├── TPC: Image │ │ │ ├── TPCParser │ │ │ └── TPCConverter │ │ │ │ │ ├── TGA: Image │ │ │ ├── TGAParser │ │ │ └── TGAConverter │ │ │ │ │ └── TXI: Dictionary<string, string> │ │ ├── TXIParser │ │ └── TXIWriter │ │ │ └── Models │ ├── MDL: HelixToolkit.SharpDX.Model3D │ │ ├── MDLParser │ │ └── MDLBuilder │ │ │ └── MDX: HelixToolkit.SharpDX.Model3D │ ├── MDXParser │ └── MDXBuilder │ ├── GameLogicAndScripts │ ├── NSS: string │ │ ├── NSSParser │ │ └── NSSCompiler │ │ │ └── NCS: byte[] │ ├── NCSReader │ └── NCSExecutor │ ├── GameData │ └── 2DA: Dictionary<int, string> │ ├── 2DAParser │ └── 2DABuilder │ │ ├── Conversations │ ├── StrRef │ │ ├── StrRefClass │ │ └── StrRefMethods │ │ │ ├── DLG: Dictionary<int, DialogueNode> │ │ ├── DLGParser │ │ └── DLGBuilder │ │ │ └── TLK: Dictionary<int, string> │ ├── TLKReader │ └── TLKWriter │ ├── AreasAndEnvironment │ ├── ARE: List │ │ ├── AREReader │ │ └── AREWriter │ │ │ ├── VIS: Dictionary<string, HashSet> │ │ ├── VISParser │ │ └── VISBuilder │ │ │ └── WOK: HelixToolkit.SharpDX.Geometry3D │ ├── WOKParser │ └── WOKBuilder │ └── SoundAndMusic ├── WAV: Sound parsing library class here │ ├── WAVReader │ └── WAVWriter └── BIK: RAD video parsing library class here Key points: Models: Using Helix Toolkit, you can represent MDL/MDX with the HelixToolkit.SharpDX.Model3D library class. This might not directly support the MDL/MDX format, but it offers a flexible structure to build upon and is compatible with .net standard 2.0 WOK: Walk meshes might be a collection of 3D vertices and triangles, so HelixToolkit.SharpDX.Geometry3D can be a starting point.

Thoughts?

[NickHugi]

• I would perfer to keep the 3D renderering code separated, the same way I did with PyKotor, with it being a layer that sits on top of KotorDotNET. Additionally HelixToolkit and SharpDX are not crossplatform.
• I appreciate the input regarding organizing the namespaces. While I do think my approach can be improved upon, I would still rather keep everything organized by technical purpose, rather functional purpose, atleast on the top level. Here is a revision of the structure I am planning on implementing:

- FileFormats		- 2DA		- GFF		- TLK
- GenericTemplates
	- ARE
	- IFO
	- UTC
	- UTD
- Tables
	- Appearances
	- BaseItems
- Patching
- Extensions
	- BinaryReaderExtension
- Common
	- Creature
		- Class
		- ForcePower
	- Dialog
		- StringRef
		- LocalizedString
	- Data
		- ResRef
		- ResourceType
		- Resource
- ResourceContainer
	- FolderResourceContainer
	- ERFResourceContainer
	- RIMResourceContainer