Yes, I named it apexshipdetails.material.patch and put it in the /tiles/materials folder in the mod's directory. *facepalms* Yup, I was trying to change the name of it by patching apexshipdetails.material in the /tiles/materials folder instead of apexshipdetails.matitem in the /items/materials folder. Simple mistake on my part. Thanks for pointing that out. I just patched the apexshipdetails.matitem file and it works now.
Y'know... I like how everybody's helping everybody else over these little hurdles. Warms my cold, lonely heart.
You just summoned the evil spirits to this thread through jinx magic... whhyyy? *Plants evil-warding seals all over the thread*
i think that's a site people just found, @Kawa linked to it back on page 2 of this thread, however he also has a more starbound specific JSON page including a validator and patch tester of his own that he mentioned on page 3
That seems strange, I'm sure that someone at least tangentially related to the Starbound community wrote it, considering it's Starbound specific. So I'd want to properly credit them, if I'm showing their shit off.
the generic JSON Patch validator (the one at herokuapp.com) was written by Francis Galiegue who's email address shows up in mailing lists about JSON well before starbound announced it would be using the new patching system, examples: 2013 - http://mail-archives.apache.org/mod...Di-tWbt4v3ZhAAGCBYEiuvR4Pik0g@mail.gmail.com> 2012 - http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07022.html
If you want a starbound community created one to link to, use Kawa's... It has the benefit of supporting comments, and diff'ing
i know that kawa makde a lab for starbound modding json experiment. there is a vaidator, (it check your file to make sure that nothing is missing) a diff generator(pretty much a translator for the _merge to json patch), a patcher (for testing), and a linter here is the link http://helmet.kafuka.org/sbmods/json/
Now that I've been tinkering some more... 1) I may just be overlooking something, but when a test op fails, does it just not do the next line, or stop the whole patch dead right there? 2) json patching really needs the ability to combine testing for an array value and adding a *different* value conditional on that, if 1) turns out to terminate the patch. You know, so a mod can, say, check a label that another mod could leave to flag that it's present and modifying this file, and then do work depending on if said flag is present? Sort of a 'if this whatever is present in the JSON tree at a known place, add something that would totally not make sense if it weren't' command. 3) Some sort of 'if this value or item is in an array of unspecified size and unknown content, do this' command, so that IF 1) doesn't stop anything but the next line, you don't have to walk through with a buttload of test commands to 'search' an array manually for a value. ... and all this for something that's only important if you modify existing content, or optionally modify / use content patched in by another mod. ^^ (Edit: ... this is actually highly important if implementing a user race, so that race-specific messages can be added to existing items or conditionally added if that race is present or not, just as a big example. Unless... are the race specific description texts hard coded to the core races? If you made a "blabbityrace", would "blabbityraceDescription" be called for it? ... and this is straying out of patching territory now. >_<) ... which leads to a question about how mods are ordered as they're loaded... ^^''
This'd been discussed on ##starbound-modding.. The plan, IIRC, is to have alphabetical for starters, sneaking in dependencies. So if you have mods A B C and D, they load in that order. But if B depends on D, it goes A C DB instead. At the time of that discussion, it was in filesystem order instead of alphabetical, but otherwise the same.
For output in a more convenient, easier to copypaste format: http://helmet.kafuka.org/sbmods/json Gee, I wonder how often that link's been posted now.
According to RFC6902, if the test operation fails the WHOLE patch is not applied. --edit -- i was playing around with an idea, and it SEEMS to work... apparently player.config.patch doesn't really need to be in the root of the mod folder, so in theory (haven't fully tested this) you might be able to have multiple player.config.patch files for different test conditions
And i saw it the first time around and used it. Doesn't change the fact that the code is valid and fine, it just doesn't pop up as "learned new recipe" when picking up the spinning wheel...for some reason i couldn't figure out.