I left out listing all the specific fields this would affect, I think they got the idea pretty quick, but I expect you’ll find a lot of stuff move this way over time, even if the dev-kit starts to be in sync with client and server released, it’s still nice to be able to patch and continue without recooking a TC/Mod. Maybe we will even get the ability to alter existing actors in levels, and define additional entries for things like spawner blueprints on an NPCManager. Such as for mods to add to existing spawn managers in a clean way that basically stacks the mods “additional” values into one at runtime, without affecting the core spawner blueprint. This might be pushing it, but hopefully they will isolate more of the empty “additional” arrays throughout, and leave them exclusively for TC/Mod uses in those isolated files. This will also assist in less to deal with when a dev-kit update occurs (if it doesn’t need to update the structure of the file for new entries then yours should remain intact through dev-kit updates).
However, to be more specific I hope you’ll see any of the additional/extra arrays from the PrimalGameData moved to a new isolated file. ExtraResources is in there so it is a candidate for moving as well, but as I understand it that is for emotes? I hesitate to say “it will be moved”, but this was the intention of my post beyond just dinos, but ExtraResources isn’t like the additional fields which are effectively a mergable and isolatable section of a singular array. Still, if I’m correct about the result, it should affect the following fields which already exist in the PrimalGameData, continue past to see some suggested changes related to this area for new fields:
Additional Engram Blueprints
Additional Dino Entries
Additional Structure Engrams
Additional Structures to Place
Now, there are candidates listed below for the fields that should have new Additional X fields added:
Status Value Definition, Status State Definition, Status Value Modifier Descriptions
These may require further examination, some of these values are baked in code-wise, but still apply here all the same to get additional isolated fields.
Item Stat Definition, Item Type Definition, Equipment Type Definition
Again, a lot code related here, but good forward thinking to have additional fields for these.
Master Item List
Not even sure this is really extensively used anymore, everything is stacked and numbering gets mostly ignored, and should use class names going forward, so not really necessary for this anymore.
Item Quality Definitions
This should probably have an additional isolated field, aside from scaling horizontally with more items, it’s nice to scale vertically with more qualities eventually.
Player Spawn Regions
This should probably have an additional isolated field too, so people can add more spawns in the center of the map if they so desire (or with some other tricks, spawns in “connected” maps using the tricks like caves).
App IDItems
Okay, no idea why it’s called this, but these are the items that should spawn with a player when they first create or respawn from a death. For sanity sake, let’s call them the respawn loot. This one should get an additional field as well, already a lot of mods that are popular for adding new loot when spawning (like a torch for those dreaded respawns at night).
Primary Resources
Most definitely a candidate to get an additional isolated field, about half of the dev-kit users who are serious are working on new resources (sand is common, a few people are adding that, clearly people want glass tiles…)
Buff Post Processing Effects
Yup. Additional isolated field here, because this is where you can manipulate effects that may be applied with new buffs (RE: dilo poison and scuba).
Tutorial Definitions
Up in the air, once total conversions can do more, it’d be nice to have this for new player introduction, but it’s not something that I feel is too important right now. That said, future thinking and all presents it as a possible candidate.
Color Definitions
Yep, this is a must, the color definitions are used extensively with dino colorization and I suspect (and hope) this will move into other areas well. New random colorful dinos are a smash hit with players, even when it’s the same models. Just a side note here, the link between color definitions and colorset (among other things?) being purely textual was a little confusing at first, while I felt stupid when I figured it out, it did take a while to find that link. Might be nice to just avoid “color definitions” altogether, and simply allow color selection where you’d enter the text but I do understand why it uses the definitions to be more consistent. Open to any ideas to make this a little cleaner though, and maybe even avoid this needing to exist altogether from a TC perspective.
Extra Resources
This applies to a set number of emotes that are available in the menu, might be somewhat misleading, but I don’t believe this needs an additional fields, there would not be more emotes added, you’d need to remap the existing ones if that is your intent (unless the emote wheel accomadates when more are added? I assumed it was a set number UI).
Player Gender Definitions
Y…eah. Don’t think we need it here, but I’m not going down that rabbit hole.
Level Experience Ramps
Sure, future proofing, these could use an isolated additional field, might want to create your own tamables with a different levelling curve.
Named Team Definitions
Yep, these define which dinos play nice together, pretty important if we want to create our own teams for new NPCs.
Player Level Engram Points
Touchy subject, this one is going to cause overlap either way, and there is no real way to handle it gracefully, and I’m not one to go messing with adding levels to a game not yet designed for the levels to be added at any given point. No comment here, but future proofing doesn’t really come into play until the max “official” level stops going up. I’m sure someone out there will go “But I want my level 500 infigrind!”.
Remap X
These are all exclusively tied to mods remapping existing elements, I suspect some of these should actually disappear as they would no longer be needed, but I may be overlooking some of the specifics in their reason for being. That said, they are in their very nature controversial because they will always imply preventing the dev-kit from being out of sync from the core release, you’ll suffer remapping a list excluding core content. It would be better to see these as “additional” fields that merge with the existing content without collisions like that.
Master Dye List
I think this is still utilized, needs an additional list to allow more dyes to be added (when more sources of pigments are created, most obviously new types/colors of berries).
That about completes the list, of course a few of them are more important than the rest, for those I bolded them.