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 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?
I edit around 400+ vanilla files. But if the new system offers much more direct control of what can be changed. I vote for the new system. Even if that means I would have to redo anything, it would be better in the long run. ======= One Question - I have been trying for days to see if I could create a system where you could become "temporarily" immune to "poison" ( though I would prefer to make it - just reduce the effectiveness of the poision instead of immunity )but nothing seems to work. I tried changing the mode to sum, in hopes of making a negative value decrease the given value per tick. But I never have been able to make it go down. Though when switching it to a positive number it does add to the damage given per tick. I moved the damage amount out of the tick child into the parent - which allowed a bit more control over the damage applied. But still not being able to "Reduce" damage, only add to it. So I am at a real loss. Though I think it would add a lot more options of potions - if it were possible to create "debuffs" for status effects. The advantage of such a feature would of course be monumental. As alien species would have specific resistances to different type of damage. An new debuffs for certain types of damage for the player. But from my experimentation, it doesn't seem to be anyway to decrease the damage of a particular type through another source.
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
Awesome post - link should be added to Omni's post if this is what is being implemented. I see one issue - I don't see how something like this can still be edited. Answered: http://community.playstarbound.com/...anging-json-merging.81014/page-3#post-2085816 Code: { "undergroundLayers" : [ { "biomes" : [ "claylayer", "drydirtlayer", "drysandlayer", "gravellayer", "mudlayer", "sandlayer", "sandstonelayer" ], "detachedBiomes" : [ "crystalcave", "cellcave", "wilderness", "tarpit", "colorfulcave", "abandonedmines", "village", "bonecaves", "fleshcave", "slimecaves", "mushrooms", "coralcave", "heck", "zen", "hive" ], "terrain" : [ "undergroundCaves" ] }, { "biomes" : [ "rock01layer", "rock02layer", "rock03layer", "rock19layer", "rock20layer", "icecaves" ], "detachedBiomes" : [ "crystalcave", "cellcave", "wilderness", "tarpit", "colorfulcave", "abandonedmines", "village", "bonecaves", "fleshcave", "slimecaves", "mushrooms", "coralcave", "heck", "zen", "hive" ], "terrain" : [ "undergroundCaves" ] }, { "biomes" : [ "rock04layer", "rock12layer", "rock14layer", "rock15layer", "rock17layer", "icecaves" ], "detachedBiomes" : [ "crystalcave", "cellcave", "wilderness", "tarpit", "colorfulcave", "abandonedmines", "village", "bonecaves", "fleshcave", "slimecaves", "mushrooms", "coralcave", "heck", "zen", "hive" ], "terrain" : [ "undergroundCaves" ] } ] } Its these kind of snippets of the code which pose most problems.
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