Dev-Kit Devs: Small change, big impact for us

So I’ve been working for a week or so now with the dev-kit and something I would really like to see would be separation of the “Additional” fields in the PrimalGameData into a separate file and blueprint, PrimalGameAdditionalData.

The value behind this is that the core game would rarely need to touch the PrimalGameAdditionalData, other than to add new fields. The real value, is that with a total conversion, you can add spawns for new dinos, add the dino entries into Additional Dino Entries, and currently the only thing preventing core updates from working is that the dino entries get overridden by the TC, or vice versa.

If the TC could maintain it’s additional entries in a file that the core won’t often change, then while the dev-kit is out of sync (such as now with the Doedicurus), the main dino list from the core update would ensure the dino is loaded and spawning, while the TC could add it’s own dinos in the PrimalGameAdditionalData which would continue to add entries without any overriding of the core PrimalGameData.

As a related note, Color Definitions is lacking an “Additional Color Definitions” to take advantage of current (and suggested) isolation from core additions (like when bigfoot was added).

Thanks for reading, hope this or some sort of solution for this comes soon so we don’t have to choose between core content or TC/mod variants.

That’s a good idea Astaelan! We’ll definitely do that early this coming week, cheers :slight_smile:

i just fell in love

Much appreciated. Everyone is excited to hear the potential debut of my TC on my server sometime early next week now that they won’t impact core patches. Please don’t forget to include an Additional Color Definitions! :slight_smile:

Would you please add Extra Resources and anything additionalish there? It would also be really really great if you could take another look into Additional Structure Blueprints. You need to craft a new Structure for the blueprints to appear in the structure. But if you change the InventoryBP manually it appears in every structure.

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.

Well, in my tc i need the Extra Resources to add a weapon which should not be possible to be learned or crafted by the player. This weapon would else be not cooked within the tc. So the files are missing and you could not cheat the weapon.