Help with understanding remap/child/subclass/copy

I’ve been seeing these terms fly around on the forums and it’s confusing as to what they really mean.
I’ve also been searching for explanation on them but i can’t find any.
Please help me to understand how they work.

  1. When people say remapping, do they mean copying into your mod folder? I watched all the tutorials and they only show copy command being used.
  2. Then some people say child and subclassing, do both mean the same thing? Is it different from remapping or copying?
  3. I saw someone say the child that inherits anything from the parent will override the parent, what considerations should i be careful of if this affects core parent files in any way?
  4. If i really want to make clean stackable mods, that will not dirty core files and are not TC, which above strategy should I use to build mods? Or what is the shortcomings of each strategy?

I hope someone knowledgeable and experienced would be willing to explain these. Also if you know where to find any wildcard documentation of the ark functions, please share me a link too, thank you! ^^

  1. Remapping means going to PrimalGameData and adding entries into one of the six “Remap” fields. This effectively overrides specific item A with specified item B. It does not edit core files, but only one remap can be made per class (meaning, mods changing the same class won’t stack).

  2. Yes, child and subclass are the same. Child classes will, by default, inherit of the parent’s parameters, with one difference from copying: any action that applies to the parent class also applies to the subclass. For example, chitin and keratin are subclasses to a material “chitinorkeratin” (which cannot be obtained normally), and are usable in any recipe that requires it.

  3. You can change most parameters of child/sub classes, and in case they are the opposite (or simply different) from that of the parent class, the child-specific values will be used. Editing subclasses will not affect the parent class in any way.

  4. Using child classes is useful for when you want to remap an existing item but only edit a few parameters. For example, if you wanted to change stack sizes for wood, you’d make a child class for wood, change its stack size, and then remap the main wood item to your custom one. The effect would be a different stack size w/o any other changes, meaning it would be harvested and used the exact same way. Unfortunately, this will make it non-stackable (or at least not fully) with any mod that also changes or remaps wood.

Subclassing is not worthwhile when speaking of assets with components (like dinos and structures), since they inherit all components from the parent class and said components cannot be edited. In this case, copying is the way to go.

The only way to make your mod fully stackable is to not edit or remap ANY core class at all. When adding new content, you can simplify your job by copying classes of the same type as your intended addition (pistol or rifle for new guns, pike for melee weapons etc). You’ll need to use the “Additional” fields in the PrimalGameData to properly add your items. However, this is limited to structures, crafting and dino dossiers - to add actual dinos or anything else, you will have to make some edits and/or remaps of core files.

Hope this helps!

Thanks for the kind response :slight_smile:
Right now i’ve gotten a little further, but stuck at a very strange thing. I made a child from the DeathItemCache that drops when players die, as well as child from playerpawntest_male and female, but the Death Cache keeps using the core one, although I’ve modified the child and trying many different ways. Everything else works fine in the other playerpawn childs and with the blueprint logic. This has got me baffled and i’m still hoping to make it fully stackable…

I found out the playerpawn inherits deathitemcache from the primalgamedata but changing it inside the pawn doesnt do anything only changing in primalgamedata works, but i need to do it in the playerpawn, is there a way to do this?

Honestly, I have noticed that trying to replace the PlayerPawn with a custom one doesn’t seem to work as intended. Not sure of a solution yet. However, there are very few instances where you would actually need to do so.