Announcement

Collapse
No announcement yet.

Child or Copy - When do you want to use Child?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Child or Copy - When do you want to use Child?

    Hey guys,
    The question is when creating a mod and basing another item off something that already exists (eg. Tranq dart for to create a separate stronger tranq dart) which do you want to do copy or child the blueprint relevant to the tranq dart?

    What are the right times to use child and what are the right times to use straight out copy?

    #2
    Originally posted by shinooni View Post
    Hey guys,
    The question is when creating a mod and basing another item off something that already exists (eg. Tranq dart for to create a separate stronger tranq dart) which do you want to do copy or child the blueprint relevant to the tranq dart?

    What are the right times to use child and what are the right times to use straight out copy?
    Generally if the specific use or item you are making is very similar to an item in game you just want to COPY that item and alter it. Each item in ark that can be crafted is already a child of a generic class that gives it the basic functionality while the instance of the class (I.E. tranq dart is an instance of projectile) is where you edit the specific values and effects. So most times you will want be making a COPY of an existing item. When you CHILD an item that new item references all of the values found in the parent item (which you just made a child of). This can lead to you not seeing any new effects when you edit the new one since the new item is also pulling the old values from the parent class. I have yet to personally use a child version in anything other than when dealing with new resource instances, but I have since found a better way at dealing with those that makes child unnecessary. This explanation may change between modders and someone else might have more insight when a child is necessary dealing with more complex graph/code systems, but if you are just making a tweaked version of an existing item you should be fine using a Copy in my experience.

    EDIT: I have yet to deal with custom ammo, so I'm not sure if child is needed to recognize as valid, but if you reference everything correctly it should be fine.
    Kronos' Trade Center | http://steamcommunity.com/sharedfile.../?id=603370998

    Comment


      #3
      Originally posted by IONIC_OVRDOSE View Post
      I have yet to deal with custom ammo, so I'm not sure if child is needed to recognize as valid, but if you reference everything correctly it should be fine.
      Not needed for ammo, works fine as a copy.

      And to add to what Ionic said:
      Another thing with children is some things are just not editable. A good example is making a storage container where you would change the inventory component. If it's a child you can not delete the existing inventory component. On a copy you can.


      My Mods | P0k3r's Workshop

      Comment


        #4
        What P0ker and IONIC have stated is true, but another thing to keep in mind is compatibility.

        It can be rather important to create BPs as children if you are ever going to be remapping the assets. (Like swapping out the vanilla dinos for your own versions in the PrimalGameData BP). The reason is this, if you want it to be stackable in any regard with any mods that depend on the vanilla assets then those mods need a way to recognize your new remapped versions. If your new versions are children of the originals then they will match on "Child is class of" and the other mod can cast it to the parent type to do what they need to with it. But if it is a copy then other mods can't operate with it making your version non-stacking.
        My Mods: ArkFrame | Antinode

        Comment


          #5
          I have a question to the remapping of children stuff. Say I make a Child of a Trike. Then I would basically remap the parent with the child right? (I assume the way it works it somehow doesn't lead to a grandfather paradox when building the files or whatever it is that happens when the PrimalGameData is executed ) How can this prevent stackability issues or how is this different from remapping a copy exactly? What kind of mods could be stacked onto that? Probably not one that remapps the same dino, right?

          "If your new versions are children of the originals then they will match on "Child is class of" and the other mod can cast it to the parent type to do what they need to with it."

          Does that mean only mods that do some specific thing can stack ontop of a remapping mod? So confused.

          Comment


            #6
            When remapping data, you are simply telling the game to look at class B when it request data from class A. So remapping to a child has no cyclical issues as.

            With a remap, it doesn't effect the other Mods you have installed.

            If Mod A uses Vanilla Oil, and Mod B replaces Vanilla Oil with Crude Oil and is not a child, Mod A will not access or recognise Crude Oil, because Mod A doesn't know about the remap.
            IF Crude Oil is a child of Oil, then Mod A can use Crude Oil, ONLY because Crude oil is a Child of Oil, and is accessed in the exact same way.

            Comment


              #7
              Okay, so I followed this tutorial:
              https://forums.unrealengine.com/show...osaur-variants
              Instead I based my NewDino off of the BigFoot dino. I made my spawning entry be a child of the main grassland spawning entry. I registered this child with the PrimalGamedata_BP (which is a copy of the version in the GenericMod PrimalGamedata_BP. So is that going to make my spawning new dinos stackable? I am not seeing my Dino in game, but the mod does show and does load. How does one go about making spawning new dinos stackable? It would help so much if someone could walk through this step by step. Once I learn this I plan on putting together some tutorials to help me remember and help other people.

              Comment

              Working...
              X