Overriding and merging config files in mods. (DEPRECATED)

Tabula Rasa was a good Entry point for this to be avoided. Player.config files are going to get big

 

To just add, I think it would be:

Code:

{
     "__merge" : [],
     "defaultBlueprints" : {
          "__merge" : [], // still necessary when no additional parameters?
         "tier1" : 
          [
               { "item" : "new_item1" },
               { "item" : "new_item2" },
               { "item" : "new_item3" }
          ]
     }
}

is __merge still needed in every object if no additional parameters are supplied after initially stating it at the top?

 

looking back at my code it seems meh.. xD
I believe you would need to put in

"tier1" : [ { "item" : "new_item" } ],

the part we all know well { "item" : "new_item" }
is most likely still feed into the config file

we'll see how this works, if it works like I think it will then
yay for never having to update a mod purly for compatibility again

 

This is the system as I take it:

http://mod.gib.me/starbound/merge.html

I am unsure about object member deletion is handled, can you clarify?

 

This, is it retroactive too? Nothing clear on that apparently.

 

Something like this, from what I gathered, would work:

Code:

{
  "__merge" : [],
  "defaultBlueprints" : {
    "__merge" : [
      ["overwrite", "tier1"],
      ["delete", "tier2"]
    ],
    "tier1" :
    [
      { "item1" : "new_item1" },
      { "item2" : "new_item2" },
      { "item3" : "new_item3" }
    ], 
    "tier2" :
    [
      { "item1" },
      { "item2" },
      { "item3" }
    ]
  }
}

item1/2/3 will be overwritten in tier1, but item1/2/3 will be deleted from tier2.

 

As much as I'd like this function to be available, there is only one gripe that might cause problems for us using and making race mods (such as my Kangaru race).

Every race has it's own unique ID code that has to be set manually. Since Starbound doesn't do this automatically, if any of the .species config files have the same ID code, the game will choose priority of who's is highest on the list. This needs to be changed so people can freely drop in a race mod without conflictions coming from other race mods.

On another note, there's also an issue where if you set any race to an ID code that isn't in sequence to the last (eg = default races are set to 0 through 5 and I'm using ID 7 or above without a race being set as 6) the game will also flip to another race. This is defiantly a bug that needs to be corrected.

 

In the example:

Code:

{
// "__merge" : "nil", // sets file to nil, for some configs this will be treated asif the file was deleted
"__merge" : [],
"defaultBlueprints" : {
"__merge" : [
// ["delete", "tier1" ]
[ "overwrite", "tier2" ]
],
"tier1" : [ { "item" : "grapplinghook" } ],
"tier2" : []
}
}

He uses delete to add an item? Is this how we have to do it soon?

 

Your example for deletions is not valid JSON.

 

The delete bit is commented out.

 

Sorry, I popped into LUA mode there.
Should have been: { "item1" : [] }
But looking back at it, it doesn't feel right. Couldn't we use the same syntax he used here:

Overwrite or default merge the objects, using "nil"?

 

Two pages of speculation with no clarification. Come on! We're still confused!

 

Anybody have a video I can't get this to work when I have more than one mod in my folder..they should conflict they worked fine before the patch. But after patch even editing the bootstrap and player cfg more than one = doesn't work for anything.

 

Code:

"__merge" = []  

mean merge simply

Code:

"__merge" : ["overwrite", "tier1"],

mean you will provide a completely new array

Code:

"__merge" : ["delete", "tier2"]

mean you will delete corresponding elements in this array

concretely :

adding a new item :

Code:

{
  "__merge" : [],
  "defaultBlueprints" : {
    "__merge" : [],
    "tier1" : [
      { "item" : "new_item1" },
      { "item" : "new_item2" },
    ],
    "tier2" : [
      { "item" : "new_item3" }
    ]
  }
}

deleting a new item :

Code:

{
  "__merge" : [],
  "defaultBlueprints" : {
    "__merge" : ["delete" : "tier1"],
    "tier1" : [
      { "item" : "stoneaxe" }
    ]
  }
}

replacing a complete tier :

Code:

{
  "__merge" : [],
  "defaultBlueprints" : {
    "__merge" : ["override" : "tier1"],
    "tier1" : [
      { "item" : "copperarmorchest" },
      { "item" : "copperarmorpants" },
      { "item" : "darkwoodmaterial" },
      { "item" : "yarnspinner" },
      { "item" : "campfire" },
      { "item" : "platform" },
      { "item" : "torch" },
      { "item" : "woodencraftingtable1" },
      { "item" : "fence" }
    ]
  }
}

the __merge element provide the parser the way you want to handle specific cases in the same level, otherwise it will just merge elements.
For example, the first occurrence of "__merge : []" mean keep the original root as it is, and then, you modify "defaultBlueprints".

 

This will be so helpful not just for modder but for mod users. Mad props to Bart and the rest of the crew for working alongside the modding community from such an early point.

 

^ goes in the modinfo file or recipes? I still cant get more than one mod working at same time. Its only one mod that works regardless of what mod it is lol.

 

As far as I know this feature isn't implimented in Offended Koala. I setup a config to merge some stuff from my mod into the base player.config and it didn't seem to work.

Also message me the mods you're using and I'll see if I can help

 

no, in the .config file you are editing, player.config for exemple

 

indeed, and can we all just take a second to admire how well laid
out the entire code of the game is? I mean really.. mad props for sure

if you make a folder in the mods folder and put only a player.config with
all the added entries needed for every mod and then not put player.configs in
the separate mod folders it should work.

the issue right now is that only one player.config is being picked up
the new mod system will fix this tho it seems

 

This implimentation of a merging function is something that is coming next update or so correct? Not currently in?