Page 1 of 3

Modding Tutorials: World Data Overrides

Posted: Mon Oct 14, 2019 2:38 pm
by Hazelnut
Overriding Daggerfall World Data

The World Data Override system has been built so that mods can alter and add to the Daggerfall world data after it's streamed from the original data files, but before it's used by the DFU engine. This allows modifications of the gameworld without needing to change the original data files. The override files are json format and much easier to edit than the original binary files, and targetted sections of world data can be changed, while the remainder is unaltered. This also avoids the issue of these files being copyrighted by Bethseda, and the DFU model is to require the original files without modifications.

I know this tutorial is more of an info dump and is not easy to read & comprehend, but please do read it. I've tried to write down what I know in the best way I can and have spent hours doing this when I would much rather have been coding and solving problems. Making overrides will require effort, time and understanding. The more you're pushing the boundaries of what's already been done before, the more you will need to understand the data structures and the code that uses them - so you are aware of the various constraints and can problem solve to reach a solution. I'll help as much as i can, but I don't know everything and my answers will often involve me reading through code and figuring stuff out so you may need to be patient. (Hint: queries with all relevant detail and context provided, and demonstrating the effort taken to understand and solve yourself will always get a response :geek: )

What is World Data?
By world data I'm referring to the data that defines the locations of the Daggerfall game world. All the coloured pixels that you see on the games travel map and select as destinations to fast travel to. Basically towns, villages, dungeons etc. These locations are merged into the world terrain, which is a completely different system where a TerrainSampler uses the classic heightmap data to generate the terrain of the world. This terrain is not something that can be altered by the world data system discussed here. DFU basically flattens the terrain to place a locations' exterior and paints over the texture tiles of the terrain with texture tiles defined in the world data.

Much of the DFU code relies on the world data being as expected. There are constraints on what you can change without breaking DFU, so care needs to be taken to change the world data only in ways that DFU expects. Following existing patterns in the classic data is the safest way to ensure this. For newcomers I would recommend starting with building overrides as they're the easiest to work with and the most useful. (see the last section of this guide "Altering an existing town building")

Background info (must read and understand!)
The world of Daggerfall is specified in several bsa data files from the original game that DFU streams data from at runtime. These files define the overworld map, locations (towns & dungeons), buildings, dungeons etc that make up the gameworld. The world data override system allows selective parts of the location data to be overridden and changed.

There are over 15 thousand locations across the regions of the Iliac bay, constructed from reusable blocks. World blocks for the outside world (RMB - Record Map Block), which includes building interiors, and dungeon blocks for large interior spaces (RDB - Record Dungeon Block). Dungeons interiors are constructed from RDB blocks and towns & dungeon exteriors are constructed from RMB blocks. The locations are merged into the streaming world at the map pixel coordinates specified.

The hierarchy is illustrated in this diagram.
DFworldData.png (13.48 KiB) Viewed 4157 times
Each map pixel is mapped to a region, and each region has a bunch of locations within it. Each location then has an overworld exterior constructed from reusable RMB blocks. As you can see from the illustration blocks can be used in multiple locations, so changing a block will potentially change many locations across the world and in different regions since all places the block is used will change. Locations can also optionally define a dungeon from RDB blocks, again the blocks can be shared between different locations.

Console data dump commands
To assist with overriding world data I've added several data dump console commands to DFU that dump various world data into JSON files. The files go into the folder where you can find the DFU settings file and do nothing at all if left there. They are simply put there for you to look at, copy from, move and edit etc. Just be aware that the contents will include any override data the game has loaded from mods and loose assets, these will need to be disabled to get a file with just the vanilla data.
  • dumpregion - Dump the current DFRegion to JSON file. (for example data only)
  • dumplocation - Dump the current DFLocation to JSON file. (can be used for location overrides)
  • dumpblock - Dump a set of RMB & RDB blocks to JSON files. e.g. "dumpblock RESIAM10.RMB M0000004.RDB" (can be used for RMB & RDB overrides) If no block names specified, will dump a block index to "BlockIndex.txt" containing all of the blocknames indexed as they are from the original data.
  • dumplocblocks - Dump the names of blocks for each location, or locations for a block, to JSON file. With no argument you get a list of blocks for all locations in the game which will take a while so be patient. Providing a blockname gives a list of all locations split by region that contain that block. e.g. "dumplocblocks RESIAM10.RMB" (useful for finding everywhere a block you're modifying is used) Giving the argument "locindex" dumps a location index to "LocationIndex.txt" with regionIndex, locationIndex, location name.
  • dumpbuilding - Dump the RmbSubRecord of current building player is inside to JSON file. e.g. "dumpbuilding"
Comparison with the 'New Locations' mod
Uncanny Valley has created a new locations modding resource already, and it's been used to create new things in the Daggerfall gameworld, so why is overriding world data of any use you may ask? The location loader and other resources in 'new locations' are fantastic, but they serve a different purpose. It enables new content made in Unity to be layered on top of the gameworld, allowing new decorations and places to appear in the exterior overworld. It doesn't enable new locations that can be fast travelled to or used in quest scripts however. I think the name locations is a bit misleading, since they're not daggerfall locations and are not integrated into the gameworld. Brilliant for adding small places of interest around the map, but not for a new town or dungeon.

Do I have to edit the raw json files?
Currently yes you do. Although Uncanny Valley has already made an building editor, and I believe has plans for a dungeon editor. Hopefully these will be released to the modding community and allow the json files for blocks to be editable using the Unity 3D editor. There will probably still be some json editing required, for locations for instance unless UV does an editor for that as well, but RMB and RDB edits where models and flats are being positioned will be a lot easier with a 3D editor.

What can I use to edit the raw json files?
Any text editor you like, but I would recommend one that can interpret json and allow section folding. This is incredibly helpful for navigating and focussing on specific parts of the data. My recommendation is to use VSCode which is free, provides json folding, and very good. Atom is another good option.

Development of override files.
When developing override files, the best way is to run the game in the Unity editor and put the files as loose files into StreamingAssets/WorldData/. This will allow changes to those files to be reflected in-game without requiring a restart. When not running in the editor, the override data will be loaded and cached for the rest of the session, so changes will not be seen in game until it's restarted.

Test files.
I've attached a zip file with the test files I've used when developing this feature. The new dungeon block references a custom model from the Archaeologists mod, so you will need that installed or you will need to change the model id to one from the original data otherwise the block layout will fail. You can also see all the source files for my mods in github here:
(7.05 KiB) Downloaded 104 times

Using Variants for a more dynamic Daggerfall world!

The world data variant system allows different overrides to be used once a trigger happens. The triggers can set variant blocks (or location / buildings) to be used just for a specific location, or every location using that block like the base system does. A variant is simply a string that selects a specific world data override file, for example in the Roleplay & Realism mod I use the variant "_master" to select a file called ARMRAM03.RMB-765-building14_master.json that changes building number 14 in the ARMRAM03.RMB block. I used the underscore prefix to make variant separate from the rest of the filename, but it's not required. The building is actually an armorer shop that was not given the right data to be a real shop, and the override file changes it into a very fancy & decorated shop with a special NPC.

The class that controls this is WorldDataVariants and has 4 methods for adding & changing variants as listed below. For blocks and buildings, a locationKey can be specified if you want the variant to only appear in a specific location. A location key is simply the location index combined with its region index and you should use WorldDataReplacement.MakeLocationKey(int regionIndex, int locationIndex) to create one. If you want a variant block or building to be used for all locations, don't supply a locationKey or use -8 (chosen because it looks like an infinity standing up, and I'm bored of using -1, do refer to the constant AnyLocationKey :P )
  • SetLocationVariant(int regionIndex, int locationIndex, string variant)
  • SetNewLocationVariant(int regionIndex, string locationName, string variant) - Need a different method for new locations as the index is only allocated at runtime.
  • SetBlockVariant(string blockName, string variant, int locationKey = -8)
  • SetBuildingVariant(string blockName, int recordIndex, string variant, int locationKey = -8)
Removing a variant is simply done by setting a blank variant string, by using NoVariant constant. Setting a variant for the same parameters overwrites any already set.

There's a quest action for triggering variants called worldupdate and can take the following forms:
  • worldupdate location at <locationIndex> in region <regionIndex> variant <variant>
  • worldupdate locationnew named <locationName> in region <regionIndex> variant <variant>
  • worldupdate block <blockName> at <locationIndex> in region <regionIndex> variant <variant>
  • worldupdate blockAll <blockName> variant <variant>
  • worldupdate building <blockName> <recordIndex> at <locationIndex> in region <regionIndex> variant <variant>
  • worldupdate buildingAll <blockName> <recordIndex> variant <variant>
For example, from RRMSTARM1.txt in my mod:

Code: Select all

worldupdate building ARMRAM03.RMB 14 at 240 in region 52 variant _master

Re: Modding Tutorials: World Data Overrides

Posted: Mon Oct 14, 2019 2:39 pm
by Hazelnut

To be able to target a building within a location, the sector field of the building data records can be used to index the block name in the exterior data array. The correct block containing the building must be known so the building key can be calculated when referencing the building & location from the place definition in a quest script. This is not what the field was for, but as it's unused I re-used it to allow this.

Altering an existing location

To alter an existing location, travel there and run the dumplocation command to get the current data for that location. The json file will be called location-RR-NNNN.json where RR is the region index (e.g. 17 for daggerfall) and NNNN is the location index within that region. The json in this file can be edited to change the location in the same ways as shown for adding new locations. Region Ids can be found here:

At present, all that can be visibly changed for a location exterior is the RMB blocks used and their layout. This is done by changing the list of block names and the width / height elements. Only existing blocks can be used at this time until the 2D array serialization issue is resolved to allow entire RMB blocks to be changed or added. Individual buildings can have their interior and exteriors replaced, see later on in this tutorial for more detail. Building data is also at the location level and this is combined with the block building data at runtime to give the buildings (which are otherwise the same for every location the block is used) location specific data for nameSeed, factionId, and quality.

Altering a dungeon location dungeon block layout

Altering a dungeon location dungeon block layout is a case of specifying the RDB blocks in a list and defining the x,y coordinates they should be at. Only one block can be marked as the entrance block, and even though the crypt locations in original data all seem to define an '+' shape of 5 blocks with only the central one actually accessible by players, there's no need to do this for DFU and, as shown in my examples, just the single block seen by players needs to be defined. See ... ck_Element for more details.

Adding a new location

New locations should be named 'locationnew-LOCNAME-RR.json' where RR is the region index the new location will be in, and LOCNAME is your file name for this location. e.g. 'locationnew-archcrypt1-17.json' When adding a new location, I suggest finding a similar existing location and use the dumplocation command to get the data for it, then rename the file and edit it to become your new location as shown below. A unique location index will be assigned internally when loaded in the game, and this could be different each time depending on other mods, so you cannot rely on it being a particular value and should set the corresponding data elements to zero as shown below. You must restart the game when adding a new location replacement file regardless of running in the editor, as the index will not get assigned correctly. Once the new location file is there, you can make changes while the game is running as normal.

Now you will need to decide is where to put your new location on the map, first choosing a region, and then the specific map pixel in that region. As far as I know you can't have two locations in one map pixel. (utility to assist is coming... be patient: The easiest way to find the coordinates you want is to use the in-game travel map with the WorldDataUtilities.dfmod installed. This will display the map pixel coords the mouse is over enabling easy selection of a suitable map pixel.) Once you have the map pixel x,y coords then you can calculate the mapId and the other coordinates required for the header. These must be consistent otherwise errors will occur. I will refer to the map pixel x,y coords as mappx.x and mappx.y in all of the instructions below and I will use the example numbers 123,456 for mappx.x,y below.

Code: Select all

1) MapId = (mappx.y * 1000) + mappx.x = 456123
2) ExteriorData.MapId = MapId 
    (In original data, the MapId & 0xfffff = ExteriorData.MapId with the upper bits contain the LocationIndex but 
     these upper bits are unused by DFU so you can simply set both MapId's the same)
3) Latitude = (499 - mappx.y) * 128 = 5504
4) Longitude = mappx.x * 128 = 15744

Annotated example: a new crypt location

This is an annotated example of a new crypt location from the test files zip. The filename is: "locationnew-archcrypt1-17.json" and the 17 is the region index of Daggerfall. It's a copy of the Gaerhart Vaults and is placed one map pixel to the east, and uses a new added block ARCHC001.RDB for the crypt interior. It also uses a different existing RMB block for the exterior.

Location-crypt.jpg (354.96 KiB) Viewed 4040 times

Annotated example: existing shack location

This is an annotated example of an existing shack location from dumplocation command. The filename is: "location-17-1268.json" and the 17 is the region index of Daggerfall, and the 1268 is the location index. It shows a location with building data, and no dungeon.

Location-shack.jpg (186.47 KiB) Viewed 4936 times

Re: Modding Tutorials: World Data Overrides

Posted: Mon Oct 14, 2019 2:41 pm
by Hazelnut

Altering an existing dungeon block

To alter an existing dungeon block, first dump the original using the dumpblock command. Do ensure you don't accidentally get the data from installed mods, unless that's what you want to start with. The file will be called BLOCKNAME.RDB.json and can be edited then moved into WorldData. See the annotated examples for details of how to change the data, but in summary there's a list of model references and a list of lists of rdbObject's. These objects can be flats, lights or models that make up the block. It's unclear why this is a list of lists, and I've not spotted any pattern yet. I suggest that any new objects are added to one of the empty lists to make it easier to keep track of new stuff, but it doesn't really matter. The model refs are used by model objects by the model ref list index, so any models you want to use need to have a reference with a numeric model id. New models provided via the asset injection system can have references added, but only if the model has a numeric name. (try to avoid collisions between mods)

In addition, model objects can have action resources attached to enable the model to trigger an action when clicked by the player. I've not figured out how this all works, but these can be added. It's unnecessary for any models that don't have actions, so feel free to delete it.

Adding a new dungeon block

To create a new dungeon block you will need a name for it, e.g. ARCHC001.RDB from my examples. I don't think it has to follow the 8.3 format of classic block names, but I've not tested that. Feel free to try and report back if you want. Next either start with an existing block dump and delete everything you don't need. The dungeon block will need constructing from existing and new models, and each will need a single entry in the model ref list regeardless of how many times the model is used. Then create object list entries for each placement of the model, following up with entries for flats and lights. Currently there's no taxonomy of the existing models in Daggerfall so it can be hard to find what you are looking for, but they can be browsed using the modelling utility availiable here.

Note that you cannot use a new model for the entrance part of the block without creating a related instance of CustomDoor.cs, otherwise it has to be an existing model with a static exit door definition. Also worth mentioning that a good way to look at complete blocks is to run DFU in the Unity editor and navigate to a dungeon the block is used in, pause the game, then switch to the scene view. Click on the interior dungeon tree on the left panel and select the block entry you're interested in. Rendered blocks have all the models combined so the entire 'finished' block can be inspected and rotated etc.

Annotated example: a new crypt block

This is an annotated example of a new crypt block from the test files zip. The filename is: "ARCHC001.RDB.json" and is referenced from the new location data as shown above.

RDBblock.jpg (195.28 KiB) Viewed 4851 times
RDBblockObjectLists.jpg (74.37 KiB) Viewed 4851 times
RDBblockObjects.jpg (298.93 KiB) Viewed 4849 times

Re: Modding Tutorials: World Data Overrides

Posted: Mon Oct 14, 2019 2:46 pm
by Hazelnut

RMB blocks used for overworld locations like towns can now be overridden.Individual buildings in an RMB block can be altered independently (see next section), so for existing blocks, it's probably best to override specific buildings as only one override for each thing (block, location, building) can be used at a time. So two mods could change different building in the same block, but if one changes the whole block then it would conflict. I think mostly RMB block overrides will be used to add new blocks to the game because the building data lists of each location using the block would need to be changed if any new named buildings are added, whereas building overrides do not require this, and can modify exterior and interior. Recommendation is only use block overrides if modifying all/most the buildings, the layout, ground textures, or you're creating an entirely new block. Otherwise use building overrides. Even if you want to have the name vary by location you can still do that with building overrides by having a FactionId of zero and altering location building lists, but at that point consider a full block override.

UESP has a useful set of pages showing the existing blocks of the game here: ... apPItem.29

When creating a new RMB, the best way to start is to find an existing block that's as similar to what you want from the classic data, then dump the block data and use that as a starting point. Ground tile data and automap data have editors written by BadLuckBurt that I will link here once they are released. Most other data elements are described in the example below.

Annotated example: a new map block

This is an annotated example of a new map block for the fort from my upcoming FG master quest with a few minor changes so it's a better example.
RMBblock.jpg (261.76 KiB) Viewed 4038 times

Altering an existing town building (Building Overrides - use these first!)

Building overrides just affect a single building within a block, and allow multiple buildings in a block to be modified by different mods without conflicts. (except for the automap, as a block can only have one and there's no merging logic) They also allow residences to be turned into named (shop/tavern/guild) without needing the building list of every single location using the block having to be modified. Recommended method to modify existing buildings.

The way it works is that you create a JSON file containing data for the BuildingReplacementData struct in the WorldDataReplacement class and place it in StreamingAssets/WorldData. It needs to be named like this:

Code: Select all

string.Format("{0}-{1}-building{2}.json", blockName, blockIndex, recordIndex)    
e.g. blockName-blockIndex-building#.json
For example, the file I created for the Archaeologists mod is called RESIAM10.RMB-543-building10.json and overrides building 10 of RMB block RESIAM10. (refer to it as an example, and compare it with the default data dumped by command to see what I changed) This example doesn't contain a NameSeed since it's a guild, another example from Mountain Rumors does since it's a shop. Note that the block name & index in the filename are redundant, either one could have been used alone, but I put both are in the filename becuase I find it useful.

To create a JSON BuildingReplacementData file simply start with the JSON file produced by the dumpbuilding command like the example detailed below and edit the values. You will need to put the top level faction id and the building type (e.g. 11 which is for a guild hall) which can be any of DFLocation.BuildingTypes. Quality is only important for shops as far as I know. When location & block building data is being matched, overridden building NameSeed's are added to the location index so the shop/tavern names will vary and not be the same for every place the block with the building is used.

Note: You must set FactionId if this is a new 'named' building (see RMBLayout.IsNamedBuilding()) unless you modify the building list of every location using the block. So leave it zero when either not a named building or changing an existing named building which will already have a record. This is so that the location building matching doesn't get out of sync. NameSeed & Quality values are only used if FactionId is non-zero, otherwise all are taken from the matched building data of the location if found. BuildingType is always overridden regardless. NameSeed is not used for guilds, the faction data is used instead.

The remaining two members of the structure are RmbSubRecord which is where the specific building data goes and AutoMapData which is optional but allows the map data for the block to be adjusted to be consistent with the updated building. Note that if two buildings in the same block are overridden, only one can override the map data for that block. Currently there's no solution for this. FactionId of zero will allow DFU location building data matching to run, be careful with this as you can use up pool items and change other buildings in the location.

Code: Select all

    "FactionId": 1010,
    "BuildingType": 11,
    "Quality": 11,
    "NameSeed": 1234
    "RmbSubRecord": {
        ... Rmb block dump in here ...
    "AutoMapData": [
        ... paste automap byte array dump in here (optional) ...

The subrecord has 2 sections 'Exterior' and 'Interior'. The interior is split into following: Header, Block3dObjectRecords, BockFlatObjectRecords, BlockSection3Records, BlockPeopleRecords, and BlockDoorRecords. To add new things to the building (i.e. npc's, furniture etc), add json blocks to the following sections.
  • Block3dObjectRecords - 3d models, including the walls etc. Add new furniture like beds, shelves, chairs, tables in here. I found AlexanderSig's list of models he's replacing was really helpful to find the model id's, and you can also use the DF modeling tool as well.
  • BockFlatObjectRecords - Flat sprites used for decorations etc.
  • BlockPeopleRecords - Flat sprites used for npcs. The position field is filled from the position within the blocks file, just set it to a unique number within the list for the name seeding code. (start with 1 and count up...)
From here it's simply a case of adding all of the models, flats and npcs one by one. Getting them all in the right place is a case of trial an error or using an edior.

For automap data, use BadLuckBurt's tool to edit, then copy and pasted the output JSON into the relevant part of the building JSON file.

Re: Modding Tutorials: World Data Overrides

Posted: Wed Oct 16, 2019 8:15 pm
by BadLuckBurt
I could follow most of the annotated example for a dungeon. I just have a few questions :oops:

Exterior > RecordElement > Header
Unknown2 is used to overwrite an existing location when you copy from LocationIndex right?
How do we know what the current max number is for LocationId and how far up is the number allowed to go?

Dungeon > Blocks

Code: Select all

Ex: Privateer's Hold
 B0000009 @S0000999  B0000003
The ARCHCH001.RDB file that's in your example would just be one of the B0000012, 03, 06, 09 or @S0000999 (when set as starting block in the above setup right, the position depending on their X-Y coordinate?

I don't understand what the '5 blocks defined but only the center one is used so they can be cut down to just that block' means exactly. Does the ARCHCH001.RDB offer different models but only 1 is usable?

Re: Modding Tutorials: World Data Overrides

Posted: Wed Oct 16, 2019 8:32 pm
by Hazelnut
BadLuckBurt wrote: Wed Oct 16, 2019 8:15 pm I could follow most of the annotated example for a dungeon. I just have a few questions :oops:

Exterior > RecordElement > Header
Unknown2 is used to overwrite an existing location when you copy from LocationIndex right?
How do we know what the current max number is for LocationId and how far up is the number allowed to go?
Unknown2 should simply have the value that LocationIndex at the end of the file has. This will be defined and fixed if you're changing an existing location and should be set to 0 for new locations since the value will be auto-assigned. Guess my explanation text was a bit cryptic.

LocationId is a 16 bit unsigned int, but you could find that out from the DFLocation class if you needed to know.

Regarding the single dungeon block, I was just pointing out that a dungeon with 1 block only needs that block in the list, whereas DF data has 4 additional blocks for these cases as you will see when dumping the data for a crypt.

Re: Modding Tutorials: World Data Overrides

Posted: Wed Oct 16, 2019 9:02 pm
by BadLuckBurt
Hazelnut wrote: Wed Oct 16, 2019 8:32 pm Unknown2 should simply have the value that LocationIndex at the end of the file has. This will be defined and fixed if you're changing an existing location and should be set to 0 for new locations since the value will be auto-assigned. Guess my explanation text was a bit cryptic.

LocationId is a 16 bit unsigned int, but you could find that out from the DFLocation class if you needed to know.

Regarding the single dungeon block, I was just pointing out that a dungeon with 1 block only needs that block in the list, whereas DF data has 4 additional blocks for these cases as you will see when dumping the data for a crypt.
Thank you, I should've guessed 0 would make the LocationIndex auto-assigned, makes sense.

I know the LocationId is only used when you specifically target a location in a quest but I was just wondering what would happen when two people pick the same location id for different locations?

Sorry for bugging you with these questions, I'm going to give setting up a new dungeon a shot this Saturday and I like to understand the 'why' of things I'm doing, helps to troubleshoot too.

Re: Modding Tutorials: World Data Overrides

Posted: Wed Dec 04, 2019 8:30 pm
by Hazelnut
Have now finished the basic documentation. It's now possible to develop mods with data overrides and variants etc as demo'ed by my two mods using this info. It's not easy, but it is possible. I've done the best I can to make this info accurate to the best of my knowledge but it's really a primer and starting point. Feedback is welcome, as long as it's constructive. It may not look like it but I've spent 15 odd hours doing just the documentation in this thread.

Re: Modding Tutorials: World Data Overrides

Posted: Thu Dec 05, 2019 5:25 am
by pango
Hazelnut wrote: Wed Dec 04, 2019 8:30 pm It may not look like it but I've spent 15 odd hours doing just the documentation in this thread.
On the contrary, as I was reading this thread it was obvious it took time to write. I know how hard it is to write good documentation.

I don't know if I'll use it directly since I'm not really into writing mods, but I salute the effort.
Actually I salute all the documentation efforts done in those forums, I'm so glad they exist.

Re: Modding Tutorials: World Data Overrides

Posted: Mon Feb 10, 2020 5:33 am
by communityus
This is perfect. I started creating my own visual version of this. But there is a ton in here I didn't even know. Huge time save! Thanks. I'd be happy to contribute to and help establish a wiki of sorts on GitHub or UESP somewhere. the convo. Here is a horrible visual aid (shows some of how I have mapped the engine/framework workflow) - its super polished! :P

pic 1: -> How MAPS.BSA plays a role. This may not be right but the next one about blockData was getting closer to what I think is going on data flow wise. I will leave this pic here for now so someone can correct me. If anyone can follow it that is.

pic 2: -> blockData -> I think I nailed this.

pic 3 (similar to pic 1) and 4 (begin to see how one might sort this all out): -> As one plays around with removing all Daggerfall IP from the arena2 files and replacing the content, things break. Here is one..."what happens if". Note the ARCH3D.BSA file size at 463 kb and maps.bsa smaller too. From this we can infer, our BLOCKS.BSA (now 4 MB and stripped down) does not have the right RDB but we can fix that or using this document (above) perhaps fill the slot with random values and override it with JSON to have the work be less tedious when developing.Image
Playing in a iHex for now. With the documention provided above I am beginning to wonder if I can just replace the model data in the RDB/RMB files (etc) with random values and then using the override feature above replace all IP faster with this JSON approach.

Lots to think on. Thanks again for taking the time. I will use it for sure!