June 25 - Changing JSON Merging

I'm no modder, but for reasons unknown this post/thread makes me want to try out modding. After the decision about changing this system is done, of course.

My two cents: go for it.

 

Assuming someone hasn't asked before (and I don't feel like looking to find out) in plain Engrish will this make it easier or harder for people who don't know anything at all about programming to mod the game? If the former, then I'm in. If the latter, then no thanks, it's bad enough you need java knowledge to mod minecraft.

 

Difficulty-wise, here's another example: how to add an object to the default blueprint list. In this case, we'll make the Shroom Table craftable by default. This involves one file, player.config.

__merge style:

Code:

{
  "__merge" : [],
  "defaultBlueprints" : {
    "tier1" : [
      { "item" : "shroomtable" }
    ]
  }
}

Patch style:

Code:

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

As always, http://json-schema-validator.herokuapp.com/jsonpatch.jsp is your friend

 

@Kawa , are you writing a tutorial, here?

 

I'm helping

 

Im a web dev myself and just wanted to throw out here that I love that you guys even opened this discussion up to the community. A lot of developers in many fields could learn from being open about the direction of projects. Keep up the good work folks, the game is quite enjoyable!

 

If you do switch it, PLEASE give us a tutorial on how to use it. I'm dumb enough that I had trouble with the current stuff, so this new one really needs a "for dummies" guide if it's implemented.

 

[Insert a dumb crack about reading comprehension here]

 

That doesn't have anything to do with what I asked. I asked if this will change how it's modded in the future, not how to do it now. Specifically if it'll be easier. I don't understand either of those examples.

 

I dunno. Do you feel the bottom one looks easier than the top?

 

Honestly, no it looks about the same. Probably even less descriptive since it just redirects to what I assume is another file. My guess is probably that all the files will be reordered and therefore everything will break and everyone will have to learn a whole new system that probably does something good on the programming side but would just be really frustrating for anyone who just learned it through a steam tutorial or something.

I don't mean to be touchy on the subject but if they're going to practically break every mod at once, they could at least add comment lines to the text files before every function so people are clearer on what they do and how to use them. Having everything be named in plain english is nice but it really doesn't tell you how you're supposed to handle an object or what it visually effects. (Example would be the undy color, if you look at the sprites for the apex or the avians you aren't going to know that's the red color unless you edit the species file anyway and happen to notice the difference.

 

@KazeSkyfox
To a person better versed in programming (ie, modders), the patch form looks much more descriptive than the __merge form. It tells where the change occurs in the tree of values of the file you're modifying, not which file you will be modifying. Additionally, it tells WHAT is occuring, whether your are adding, or moving, or deleting, or merging, or what have you.

This kind of stuff is important to modding.

Now, as to the issue that it might "practically break every mod at once". It would do that, but the amount of work that would need to be done to change most mods is pretty trivial. As you can see from Kawa's example, it won't take very long to convert most mods to this format, usually taking far fewer lines to achieve the same result. In some cases, it will even allow things that weren't possible before, like installing 4 or 5 mods which all alter Biome settings, all without having to have cross-compatibility patches.

Now, as to the mods that DON'T get fixed. So what? If the creators have left Starbound and/or can't be arsed to update their mods, then they have been abandoned. If they aren't going to update their mods to work with newer versions of Starbound, they deserve to be left behind!

 

I'd say several things about current and about future system.
My vote is that they both aren't well.
1. __merge would break recipes list if you forget to add that keyword. Silent overwrite isn't a good idea.
2. RFC JSON patching is too generic. You're trying to use oh-that-omnipotent JSON manipulation instead of solving your task.
My opinion is that files like player.config should not allow access to other mods' configs at all. What Minecraft Forge guys did really good is that they isolated each of the mods as much as they could.
My proposition is as follows:
1. Each mod can only add separate, independent entries via configs.
2. Override mechanic should be explicit and separated from addition mechanic. Either a Lua mod init script, or a separate config, or a separate section in config.
Thus, we separate operations on one mod's space from operations on other mods' spaces.

 

For species, I've already done half the work for you all.

In fact, here's a work in progress that includes templates.

Nope, it's the same file. Only the content's formatted differently.

"Function"? This is data, not code. There's no "functions" here. I'm just going to assume you meant "key", in which case nothing actually changes between formats, and there's already at least one source of information on what certain keys do.

Code:

"undyColor" : [
  { "dc1f00" : "4d76ad", "be1b00" : "395187", "951500" : "20325b" },
  ...

Yeah, those'd be color values. If you've ever done things with webpages, or most messageboards, you'd recognize the ones to the left of each colon as distinctly red. Plus, you said "apex or avians" but the key name refers to underwear. The only species with underwear are the humans. The human spritesheet has red underwear. Thus, the only real issue with undyColor is that it's a silly name.

The task: let mods manipulate config files. How are __merge and patch not ways to solve the task?

 

JSON patching doesn't solve that task because it provides you full-scale JSON manipulation. But the problem is, JSON configs in your case represent some entities, like recipe lists or item configs. I'd vote for solving that kind of merging in the terms of those entities.

 

There is an additional benefit to using RFC JSON patching standards: People can easily find help in books, forums, and other such sources of information. It won't be something specific, unique, and idiosyncratic. It would be a standard format that people can find help with, and not have to puzzle over and try to decipher. Ever tried to make a mod for an old video game that didn't initially support modding? It's complicated and hackish. This would make it really easy to pick up, if you can only get past the initial hump of learning how to do it, in the first place.

 

A practical (if not wholly hypothetical) example would be much appreciated.

A hump that was already here to boot!

 

Not an example, but kinda explanation.
Most modders, let's say 80%, just wanna add their items/blocks/etc.A smaller group wants to modify existing elements.
That RFC isn't bad, it just doesn't provide them ways to do so. It provides ways to patch JSON, which in turn allows to get desired funcs.
You're essentially leveraging both groups.
You're essentially proposing a low-level generic instrument for a very specific task.

Why does the most common operation need to be as verbose as the less common ones?
Why does the safe operation require the same amount of coding as the unsafe ones? Because adding entity is safe. It doesn't affect anyone. But modifying/deleting is unsafe.

 

I really would appreciate an example, and I'm sure Jeoshua would too.

So you have to learn only one way to write any supported action. This seemed obvious enough to me.