June 25 - Changing JSON Merging

OmnipotentEntity submitted a new blog post:

June 25 - Changing JSON Merging

Continue reading the Original Blog Post

 

I'll be watching this thread until Monday or so, and I'll take all comments under advisement.

I'd personally love to move to a new system, one with design and features. But I understand if it would be too much of a PITA.

Also for you StackOverflow bots, I have a question regarding this RFC that I posted here: http://stackoverflow.com/questions/24419391/understanding-tilde-escaping-in-this-rfc

 

I don't know a thing about programming, but the words "if it isn't broken, don't fix it". Breaking/removing this merge thing sounds like it would break dozens of mods (harder than adding a new system anyway). Wouldn't it be easier to just have future coding refer to the new means of doing things and not use "__merge" and have said future coding still call stuff back (ignoring merge but still calling it back) --- you'd still only focus on the latter system, with the code already in place just remaining for its own sake or something.

 

Even though it would cost potentially dozen of hours to fix across my various mods, I think its still early enough in the development process to be worth it. Short term pain for long term improvement and improved capabilities.

That's my vote.

 

It's better to break something now than have to screw around with workarounds and redundant code in the future.

 

I agree with the above two posts. Going back and nipping the problem in the bud is the way to go. I'm sure the long term and short term benefits far outweigh the temporary hindrance.

 

I'm still in dev of my own mod, so this doesn't affect me as terribly as say Djinn, but I think the more robust / flexible solution should be used. Count me in for the new system.

 

If a function is lacking functionality that you need, then it is effectively broken, as far as things the new functionality would allow are concerned. Also, old code makes things cluttered.
If it isn't broken, don't fix it, but if a bone is broken and heals wrong, it will stay crooked for the rest of your life until you rebreak it and fix it correctly.

My vote is for the new system. Break it until it is no longer broken.

 

Well as long as it remains simple enough to fix things that used that __merge.

I actually liked what I could do with the merge as it cuts down quite a bit of what would basically be a copy. I don't know much on the new one your suggesting, and I am not really all that knowledgeable in the modding side of things; however I do know how to read instructions and modify them accordingly.

Really if it keeps the mod size in mind down to the same size as they are now, that would be fine. As well not have too many redundancies or duplicate info. (What was done before the __merge command)

So as long as it can be explained simply or utilized simply I would be fine with it either way.

 

I'm also in favor of this change. It's not a good thing to be limited by the actual system.

There is just something bothering me : how to add a value to an array at the end ? They only give example to add at a defined position/index, but what if we just want to add it at the end and if we didn't know the array lenght ? In fact it would be cool to be able to say "add bar after foo", i.e. [a,b,c,d,e,foo,g] would become [a,b,c,d,e,foo,bar,g]. Same for before.

 

Someone should start developing a script to aid!

I agree the short term pains are worth better functionality! I find my self saying this a lot as well.

 

These 3 have said it all.

 

Add me in as another vote for the new system

 

Something definitely needs to be changed. As the system currently stands, you have to explicitly declare "overwrite" when a value already exists, and if you forget to do so, the mod doesn't work (and likely crashes the game). I mean, is there ever any reason to have a mod cause the game to fail to load when improperly declaring an overwrite? Is there ever a good reason to ignore that value? I assume that this behavior is because every line is parsed as the line is read into the game, and if something doesn't fit it immediately throws an exception.

There are many JSON implementations (particularly Java based ones) that first build up a tree of values, silently allow overwrites explicitly, and only parse the data after it is all loaded in. Doing something like this would eliminate the necessity of merge and overwrites, allow seamless changing of values, and even allow comments in mods!

How?

Code:

value = "This is a comment. This requires an integer value"
value = 1

If the final code is only parsed at the end of mod loading, the final type of "value" is an integer, not a string.

It would also be nice to be able to inject values into a list, modify or remove from a list, or what have you. This would be a great way to make it easy to add values to treasurepool files, for example, or modify values in celestial.config biome lists (currently a personal source of issues).

Also, some concept of "includes" or "parent files" would allow mods to explicitly modify a specific file, chose a specific mod to change the values of, for compatibility patches, make building that "tree" of values easier, and more.

 

I'm all in for a new system that not only works better than "__merge", but also follows RFC norms.

i like RFC norms. They make network and database management not so hellish.

 

I agree with Dijinn. The long-term improvement will pay off. This was actually one the limitations of someone I know who was working on a mod. I also have some ideas I would like to implement if you change the system to the new one you proposed.

Edit: Thanks for the update!

 

As far as i see it, any solution is beter then none. Im all in for new system.

 

i'v made and helped make a few mods with my brother (nothing uploaded) but not too much work and it should be quick to fix, i support the change if it fixes problems.

 

I am cool with a new system. Eliminate that sucka!

Thanks for the consideration.

 

not reallly much of a modder but i know the merge functionality is broken and as you are saying it might not be fixable, so essentially we would end up with a new system down the line anyway, i wouls say fix itnow.