Other GFF Derivatives

[LaneDibello]

Due to the heavily varied, and numerous variants of GFF files, it would be best to allow GFF to serve as a super class to a number of derivatives as Contained in GFF_Derivatives.cs.

Aside from Blueprints there are several other GFF file types as listed (NOTE: It remains to be seen whether all of these file types will be integrated):

• [ ] ARE - Module Area File
• [ ] IFO - Module Info File
• [ ] GIT - Game Instance File
• [ ] DLG - Dialogue File
• [ ] FAC - Faction File
• [ ] GUI - General User Interface File
• [ ] JRL - Journal (mission log) File.

[LaneDibello]

• I've come back around to this idea again more recently. I created essentially what is described here for the rando item generation feature I have been developing for the randomizer. That is the KItem class, and its accompanying item property class. Currently they are all packed together, but I feel they could be relocated in a form that is more manageable.

So my idea would be as follows: Create a nested Namespace within KOTOR_IO (called GFFTypes, or something similar) Within it we create these "derived" classes who's only member is just a private GFF, and the public facing side will be a set of properties that allow logical access to all of the fields for that file. I don't see the need for true inheritance anymore. In the event need to pass these to some other method that takes GFFs, we can just use a method that grants access to the private member (or maybe make the member public?).

The way I propose these different types be laid out are as follows. For all file types the Top-Level fields will just be granted properties of the same name/type that access them. Lower level fields will be handled on a class by class basis:

• ARE - We'll need to define a struct for 'Rooms', and work out a clever interface for the Map
• DLG - See about putting together some sort of intuitive tree data structure for this, with some struct to represent the entiries and replies
• FAC - Structs for Factions and Reputes
• GIT - Structs for Smeras, Creatures, Doors, Encounters, Merchants, Placeables, Sounds, Triggers, and waypoints.
• GUI - This might be beyond the scope of this project
• IFO - Differentiate between Module IFOs and Player IFOs. Since they're fundamentally different structures it may be worth putting into a separate class.
• RES - Differentiate between this formats many uses.
• UTC - Structs for classes and spells, Structs for inventory items
• UTE - Structs for creatures
• UTI - See Random Item generation implementation
• UTP - Structs for inventory items