About this mod
Export your plugins to JSON or import your JSON back to plugin
- Requirements
- Permissions and credits
- Changelogs
This mod is a utility script for FO4Edit that allows import and export of the plugins from/to JSON. In essence these are just two scripts with assigned hotkeys that you will need to use from FO4Edit.
Why Use It
Regex replacement? Validation? Batch update? Major tweaks? Programmatic creation of patches? You name it. You can do a lot with JSON. The idea is:
- Export the plugin to JSON
- Do your work on it - change your values, update your module
- Import it back to plugin
- Save, done
Wait, but FO4Edit scripts!
Yes. And no. There are severe limitations on what they can do and adding absolute lack of guidance regarding those and a castrate version of the built-in Delphi compiler and it can become very frustrating to use scripting (eh, no offense to the authors, I did spend a lot of time on user scripts and it's a great feature). JSON, on the other hand.. it's hard to imagine any solid tech that does not support it. This mod is an attempt to bridge plugin scripting to other tech you might want to use.
Installation
Install to your FO4Edit/Edit Scripts folder. You must put it there or else it will do nothing. If you don't know what that is - you probably aren't a target audience (no offense)
Usage
You can R-Click in the FO4Edit in the left side and then Apply Script and select JPImport or JPExport. Alternatively, Ctrl+J will launch exporter and Ctrl+Alt+J will launch importer.
Exporter will write your files into your FO4Edit directory (and importer will read from there). You can change the name of the file, but that is optional. If you just leave the field empty then the name to write to / read from will be assumed as PluginName.esp.json
You can select a record at any level, including the file itself (in this case everything underneath will be included). You cannot select multiple records, the root of the tree must be one thing.
If you are importing from JSON, you must select the record that was the root for the exporter, otherwise it will do nothing. This is a safety precaution.
Since version 0.1.0 there is also a new way of importing files. JPImportFiltered will offer the fields you want to import (i.e. whatever was not selected will be ignored). Hotkey Ctrl+Shift+J. Be carefull though as it is much, much slower that the regular import.
Limitations
Unfortunately, xEdit isn't the definition of consistency. There are many issues such as element type determination. Therefore it is possible that exporter will generate inaccurate JSON (most likely data will be missing). Good news are - I created ways to fix this, you will need to look into JPUtils. If you don't know what it is - then just report the missing field and I will try to fix it.
Other issues can be with memory limitations. It is not a fast thing to traverse the whole plugin with thousands of records. It may take minutes or tens of minutes on larger files. And this isn't intended way of using JP - in these cases I would recommend selecting a smaller subtree of the module and working with it since chances are - you don't really need the whole thing.
Last, but not least - this is not thoroughly tested in any way. It can be buggy, the internal JSON library is inconsistent with the very specs it is pointing to (some of the calls I had to really look up in the HEX editor on the executable of the program)
Known Issues
Due to the limitations above as well as some quirks of the built-in JSON library and xEdit in general, there are some known issues with the way JP works:
- Sometimes the FO4Edit will mark the item as modified after importing the JSON even if the value and the structure were not changed. Most notably on "Conditions" sub-structures and values. It is unknown whether that's a flaw in SetEditValue / GetEditValue or the xEdit modification flag (there's simply no way to check it). In other words: if something is appearing "in bold" after running the importer, it does not necessarily mean some changes happened there.
- Ordered collections might end up out of order. It usually does not matter, however for cases when you rely on the order of the structure this may be an issue (I've yet to find such a use-case though)