August 19 - The day when all your mods died.

OmnipotentEntity submitted a new blog post:

August 19 - The day when all your mods died.

Continue reading the Original Blog Post

 

No, Omni! Not bad news! Nooooooooo! Not the mods I don't have!! Take my eyes but not my mods!

Thank you for the update

 

Well then...

 

Haha, im guessing this means one of two things. Either or, glad I didn't install mods.

 

RIP mods

well they were fun when they lasted

 

Wait, so is this somehow removing all our mods with no hope of ever getting them back?
I'm a little confused. This seems very strange....

 

I think what the OP was trying to state is that with the updates to the game coming in and what not, Mods will break and in turn have to be remade for the game again. I mean I just jumped into the Nightly Builds and man there is a crap ton more stuff then there was in the original builds, which im pretty happy about.

All in all don't fret!

 

Aah, okay. That makes sense. ^.^
Thats what I figured, but I just wasn't entirely sure...
(That was a fail on my part. xP )

 

is this just in nightly for now?

 

Yeah just nightly.

 

Looks like you missed the "a" before href!
In any case thank you for the blog post!

 

Glad to hear. The JSON patching system seems much more robust than the current merge system.

For those of you confused by this post and who haven't read the original discussion it's not like mods are permenantly broken. I'm not a Dev so my understanding may be a little off but I'll do my best to sum it up simply.

Currently (in stable) mods use a special "merge" line to make changes to existing files. With the new system in place mods that use that system will no longer work, but they can, relatively easily, be upgraded to the new system which is much more versatile.

I doubt mod developers will adopt the new system right away with the constant and massive changes to nightlies so it might take some time after the next stable update before all the mods get updated to the new system. But it'll allow compatibility between a lot of currently incompatible mods.

 

Still, some working examples would be useful to just clarify, those docs are pretty dense and I'm not certain all of the stuff it contains is actually relevant

 

Here's a short example.

Let's say you have a file named... oh I don't know, "player.config" And let's say you want to change the hitbox of the player by changing around the standing poly.

You would create a file called "player.config.patch" and it could contain, for example, the following:

Code:

[
  { "op" : "replace", "path" : "/techControllerSettings/baseMovementParameters/standingPoly/2", "value" : [ 1.35, -2.5] }
  { "op" : "replace", "path" : "/techControllerSettings/baseMovementParameters/standingPoly/3", "value" : [ 1.75, -2.0] }
  { "op" : "replace", "path" : "/techControllerSettings/baseMovementParameters/standingPoly/4", "value" : [ 1.75, 0.65] }
  { "op" : "replace", "path" : "/techControllerSettings/baseMovementParameters/standingPoly/5", "value" : [ 1.35, 1.22] }
]

What that will do is change the values in the file from:

Code:

  "techControllerSettings" : {
  "baseMovementParameters" : {
  "standingPoly" : [ [-0.75, -2.0], [-0.35, -2.5], [0.35, -2.5], [0.75, -2.0], [0.75, 0.65], [0.35, 1.22], [-0.35, 1.22], [-0.75, 0.65] ],
  "crouchingPoly" : [ [-0.75, -2.0], [-0.35, -2.5], [0.35, -2.5], [0.75, -2.0], [0.75, -1], [0.35, -0.5], [-0.35, -0.5], [-0.75, -1] ],
  "airFriction" : 0.2,
  "mass" : 0.6,

  // should keep the player from teleporting through walls
  "maximumCorrection" : 1,
  "maxMovementPerStep" : 0.4
  }
  },

to

Code:

  "techControllerSettings" : {
  "baseMovementParameters" : {
  "standingPoly" : [ [-0.75, -2.0], [-0.35, -2.5], [1.35, -2.5], [1.75, -2.0], [1.75, 0.65], [1.35, 1.22], [-0.35, 1.22], [-0.75, 0.65] ],
  "crouchingPoly" : [ [-0.75, -2.0], [-0.35, -2.5], [0.35, -2.5], [0.75, -2.0], [0.75, -1], [0.35, -0.5], [-0.35, -0.5], [-0.75, -1] ],
  "airFriction" : 0.2,
  "mass" : 0.6,

  // should keep the player from teleporting through walls
  "maximumCorrection" : 1,
  "maxMovementPerStep" : 0.4
  }
  },

Possible values for "op" are: "test", "add", "remove", "move", "copy", and "replace". They do what it says on the tin. The only one potentially confusing is "test" which simply tests the path for some value, and if it's not correct it aborts the patch.

"test", "add", and "replace" take "path" and "value"
"remove" just takes "path"
"move" and "copy" take "from" and "path"

There's other stuff like "-" for end of list and using ~1 and ~0 to reference "/" and "~" respectively. But that's pretty much it.

 

Yep, that seems appropriate.

 

Thanks, that makes a lot more sense now, I'd never figured out how that 'path' system worked without seeing that. Doesn't that mean that adding new entries requires a vastly new format? - Functionally the merge system allowed you to include entire new blocks of JSON practically verbatim, which made it very easy to edit and figure out, ie:

Code:

{
    "__merge" : [],
    "species" : ["avali"],
    "defaultBlueprints" : {
        "tier1" : [
            { "item" : "blah1" },
            { "item" : "blah2" },
        ]
    }
}

The new system would now take the form of... uh:

Code:

{ "op": "add", "path": "/species", "value" : "Avali"},
{ "op": "add", "path": "/defaultBlueprints/tier1/item", "value" : "blah1"},
{ "op": "add", "path": "/defaultBlueprints/tier1/item", "value" : "blah2"}

Or, something close to that?

 

Close but not quite.

Code:

{ "op": "add", "path": "/species/-", "value" : "Avali"},
{ "op": "add", "path": "/defaultBlueprints/tier1/-", "value" : { "item" : "blah1" } },
{ "op": "add", "path": "/defaultBlueprints/tier1/-", "value" : {"item" : "blah2" } }

Because tier1 is a list, and you're appending to it, you can use "-" to say "end of the list". And you can tack on arbitrary json values.

 

Thanks a lot @OmnipotentEntity .... now i cant even use mods by inactive devs who still use _merge......

 

Now the future can commence! The death of an era and the birth of another brighter one!