June 25 - Changing JSON Merging

found an explanation for "/~01" at http://tools.ietf.org/html/rfc6901#section-3

JSON:

Code:

{
    "/": 9,
    "~1": 10
}

PATCH

Code:

[
    {"op": "test", "path": "/~1", "value": 9},
    {"op": "test", "path": "/~01", "value": 10}
]

this would test both values, and match both, resulting in a successful patch that doesn't change anything.

 

Well, sometimes it's better to make your own, simplier stuff, but when it comes to something, that will be used frequently, it may be better to use something already existing and complex.
I also think, the more complex things you can do as a modder, the better. Although the new system will break existing mods, you will be surely kind enough, to give us a guide to how to fix old mods for the new system, won't you? =D

 

Mods are already broken in nightlies and will need to be updated anyway. This seems like a good time for the change.

 

Trying to maybe fix the old system running, with less limitations would be worth a try before going to replace the whole system.
Yet, i prefer a more functional system with more features over a half-broken half-rescued one, even if it means a whole lot of mods got to be fixed afterwards!

 

I'm no modder, but great job with the updates!

 

I have only made a couple of simple mods, so I haven't found any need for more advanced merge tools, but I can appreciate the fact that new tools would be a great asset to those who know how to use them.

However, I suggest we all brace ourselves for the gargantuan outcry that will result from a thousand simultaneously broken mods.

 

Anyone who would be unhappy about something like this wouldn't have made a mod for a game in beta in the first place! Of course our work gets screwed up every update, that's what we signed up for. My vote is yes, do it.

 

As a few people have pointed out, the game is still in very early beta and completely doing away with the current system in favor of a better one is a better decision than trying to rework the current one when it decided to stop working. I think it will not only be better for the people creating the mods, but for those implementing them in their game (as pointed out that the current way the mods are loaded can easily crash the game).

I vote yes

 

I'm not a modder, but if the new system would improve everything further down the line than surely it's a good idea to implement it now, and cause issues whilst still in beta rather than realising you need to, and doing it after launch

 

it is Beta, so Modders like me expect to have these changes, Out with the Old and in with the New i say!

 

id say fix the merge system
starting over again will break almost every mod
and that kinda sucks for the ones that arnt updated anymore

 

I'd say throw in the new system, at least if you can verify that it itself does not have any other limiting factors that you'd later on need to replace it again.

Obviously this may not be possible to know in advance, but I'm not a modder here and my programming skills are quaint so maybe this is nonsense. The only reason I'd see to keep something you KNOW is limited is if the solutions arent perfect so you may as well keep refining the wheel you've got instead of getting a new one.

That said, thanks for including the community in your development actively! I look forward to attempting to make mods once the game is at a later stage of development - to avoid things like this

 

Someone else already countered this.

Also see what Enraged Koala did to somewhere around 200 mods that were never updated for it, and that adding in the other ... like 60% of the game will supersede or render obsolete a whole bunch of existing mods regardless of whether the mod integration system is compatible with the old work.

I'm not a modder, but if what Rainbow Dash said is to be taken at face value, she would have us hold back the game and everyone playing it for the sake of a relatively small fraction of the existing modbase, that would never work again anyway, from people who apparently no longer care about the game, or at least their work. Does that seem right to you?

 

Damn, Omni. You were not kidding.

Just to check, are these functionally the same? If so, most __merges will convert to patches easily:

Code:

{
  "__merge" : [],
  "defaultBlueprints" : {
    "tier1" : [
      { "item" : "kawa_hotpants" },
      { "item" : "felinbeanbagchair" }
    ]
  }
}

Code:

[
  { "op" : "add",
    "path" : "/defaultBlueprints/tier1/-",
    "value" : [
      { "item" : "kawa_hotpants" },
      { "item" : "felinbeanbagchair" }
    ]
  }
]

Belated plot twist: it is.

 

found a place to test json patching: http://json-schema-validator.herokuapp.com/jsonpatch.jsp (json data+patch gets sent to server, patched on server, and then sent back to browser)

with this, I tried recreating a zoom mod and checked how the json is modified (the json file to modify: packed.pak/interface/optionsmenu/optionsmenu.config)

__merge method:

Code:

{
    "__merge" : [
        [ "overwrite", "zoomList" ]
    ],
    "zoomList" : [
        0.25,
        0.5,
        1,
        2,
        3,
        4,
        8
    ]
}

patch, replacing the whole array:

Code:

[
    {
        "op": "replace",
        "path": "/zoomList",
        "value": [
            0.25,
            0.5,
            1,
            2,
            3,
            4,
            8
        ]
    }
]

"add" can be used instead of "replace" above. "add" will overwrite zoomList if it already exists, or create zoomList if it does not exist. the "replace" operation will be unsuccessful if zoomList does not exist.

alternate patch, inserting values into an array one by one:

Code:

[
    { "op": "add", "path": "/zoomList/0", "value": 1 },
    { "op": "add", "path": "/zoomList/0", "value": 0.5 },
    { "op": "add", "path": "/zoomList/0", "value": 0.25 },
    { "op": "add", "path": "/zoomList/-", "value": 8 }
]

the "add" operation here will be unsuccessful if zoomList does not exist

I don't know if Starbound will be accepting json patch files exactly like this. better wait and see before creating more json patch files

 

My vote is add the new system now while it's still early in the cycle and if it adds more tools for modders than the old way that's all the more reason to do it. The benefits longterm outweight the temporary inconvenience

 

xxswatelitexx has a point, but I'd like to ask about surfaceBiomeParameters/.../dungeonSelection instead. I've been messing with the tool NanoPi linked (it's great) and can't get felinvillage to appear in the right spot.

Never mind, I figured it out! Answer in new reply.

 

the way to add multiple values to an array in one operation, based on that site, seems to have an undesirable result. http://i.imgur.com/Mqohg84.png

it would be nice if there was a way to join an array from a patch into an existing array

Code:

[
  { "op" : "add",
    "path" : "/defaultBlueprints/tier1/0",
    "value" : [
      { "item" : "kawa_hotpants" },
      { "item" : "felinbeanbagchair" }
    ]
  },
{"op":"move","from":"/defaultBlueprints/tier1/0/0","path":"/defaultBlueprints/tier1/-"},
{"op":"move","from":"/defaultBlueprints/tier1/0/0","path":"/defaultBlueprints/tier1/-"},
{"op":"remove","path":"/defaultBlueprints/tier1/0"}
]

first this adds an array to the top of the tier1 array, then it moves kawa_hotpants out of the sub-array, then it moves felinbeanbagchair out of the sub-array, leaving it empty, then it deletes the empty sub-array.

this is madness, but it would get this result: http://i.imgur.com/OX75xdw.png