Fallout 4

This is perhaps the very use-case I had in mind when creating JP (albeit working with JSON is much better than with ESP for a whole lot of other reasons as well)

When Does This Apply?

The premise here is: you downloaded a mod and it "almost fits the bill", but not quite. So you decide to adjust it a bit .. or not just a bit to your liking. Please notice here, that I'm not encouraging any publishing of this without consent of the original mod author, but so long as you keep it only for yourself - all is well.

Next, you modified the mod to your liking - which maybe took you couple of hours (or days in my case). It would be the end of the story if not for the fact the mods are updated, hopefully often. And the moment you realize that you need to update the mod, you understand that your work will need to be redone again.

Alternatives?

Well, ok, maybe not completely redone, because there are two ways to approach the issues:

1. Indeed, reimplement whatever you've done to the mod in the new version.
Pro: Likely to work disregarding anything that changed from version to version assuming you know what you're doing
Con: Repetition of work. Chance to miss something that you already had in your modification before. Not future-proof. Here comes next version, and..? Rinse and repeat.

2. Create a local overriding module. So you can update the module with new version and your local edit will override it
Pro: You don't actually need to repeat your work because your edits will still override the updated mod
Con: Is only safe for minor adjustments that came with the versions. If some links changed, something was removed or some structure / logic changed - you risk completely breaking it since your local override bases on older version. This will completely not work for major versions updates. As such, this is a bit more future-proof since it is likely to withstand a couple of updates, but ultimately it's unreliable and even more dangerous than option 1. On top of that, with heavily modded games it's an issue because you want every mod slot out of 253 available. Reserving 2 for 1 mod isn't great.

"The Way"

As you can see, both approaches are flawed. Therefore, if there was a way to "version" your locally edited file and then selectively restore only the stuff you edited - it would be a good solution. But as ESP files are binary, you can't do that. And here's where JP can be useful. The way I can recommend using it is:

  • Before updating, export your locally edited module to a ESP (don't forget to specify the name when prompted to not accidentally rewrite it)
  • Backup your locally edited ESP just in case
  • Update the mod. This will overwrite your locally edited module, but it's fine - you have it backed up and you have already exported it into JSON
  • Export the JSON from the updated version of the mod. Again, specify some name to not overwrite the JSON from your module exported on the first step
  • Compare the two resulting JSONs. You can do it in many ways, but the best way is to set up a local VCS repository, I prefer git (also because this allows me to keep files having the same name from update to update), but just about any tool that supports text comparison will do. Especially great if that can compare data structures since then you will get the maximum out of JSON potential here. The very basic way of doing this you can look up in the web.
  • Check if any of the data structures have been majorly changed. For instance, if there is just a new item added in the collection - that's not a major change. But if a record now references something else - you might want to pay attention to that.
  • Edit your old JSON to match the new version. In many cases it can be done automatically if you're using git - just by merging stuff. IDEs like Inteliji IDEA do miracles here (though this one isn't free, mind me, but it has evaluation)
  • After you're sure everything is set, import your edited old JSON into new ESP. This will restore your edits with pinpoint precision.

Alternatively
If you know you did not edit any fields in records that are responsible for linking and structural binding, you can use JPImportFiltered to restore your JSON on a new version. For instance, you only edited some dialogue texts (use-case: removing profanity which is also much easier from JSON text file with replacement or regex rather than in FO4Edit). In this case running JPImportFiltered and selecting only 'NAM1 - Response Text' as the field to import will safely restore your JSON since, obviously, this field is not responsible for any references.

Summary Pro/Con
Is it easier? Well, in most cases, JSON edits will be minor. You can even just skip the comparison steps and try to restore your old JSON as is on a new version and then see what was changed (FO4Edit will highlight that in bold). If you see that nothing major was changed and your edits were correctly restored - you're good to go. This is likely to work since JP maps records by their FormIDs (i.e. it represents module as a map "FormID" => "Record")

Is it harder to set up? Yes, yes it is. You'll need to deal with VCS or at least comparison tool if you want to make it right, but the good thing is - it only needs to be done once. I edit mods locally as a habit, I have constantly at least 10 modified ESPs at the same time, so maintaining this manually would be a nightmare.

Article information

Added on

Edited on

Written by

ID8879488948574

0 comments