v3.3-misc-functionality: Implement JValue.toString - serializes the object into a JSON-formatt…

• Misc. functionality on top of previous changes: JValue.toString to serialize an object into a string
• Bugfixes:
  • Lua: fix an issue with form value being invalid
  • Fix a hang caused by interacting with JC via C API

v3.3-domains-feature-testing

NSFW version

Any mod author may have one or few JContainers domains, containing only the author's data. Which in return allows us to remove domain-specific data completely and automatically when a mod gets uninstalled. It's important, as it allows to remove the objects you forgot to release, i.e. absolutely everything.
Every domain is virtual, self-sufficient copy of JContainers. You can't transport your data across domains (unless use writeToFile/readFromFile).

Basically, every user-created domain is a copy of compiled JContainers_DomainsExample.psc file and just a new, empty folder inside SKSE/Plugins/JCData/Domains/

Q: How do I create my own domain?
A: Rename JContainers_DomainsExample.psc into AnyFilename.psc (change script name also), compile it and distribute with your mod. Put empty AnyFilename folder into SKSE/Plugins/JCData/Domains/. Import AnyFilename script into your scripts. Find and replace JXXX.yyyy with JXXX_yyyy. Some of the functions do not belong to any domain, and JContainers_DomainsExample.psc won't declare them.

Q: Any example of use?
A: SilverIce/PosePicker@38d0940

Q: Drawbacks?
A: You can't easily transport a data across domains. Lack of Sublime highlighting and having to invoke domain-specific functions via Class_method instead of Class.method. Though it's possible to develop a mod using default context, use normal scripts and etc and then perform mass find & replace on your scripts

Q: What happens when a folder in /JCData/Domains/ doesn't exist anymore?
A: Domain with similar name won't be loaded from a save file.

Yet another v3.3

Form observing:

• Remove extra strict test when loading forms' identifiers from JSON files. In previous alpha version the test marks a form's identifier as invalid if the form is not loaded in game. For now it assumes that the form exists, even if it's not possible to test that.
• Retain and observe EVERY form that gets passed into JContainers which prevents a form from being unloaded. This also involves persistent forms. Still, the forms imported from JSON files, especially object-reference forms may not be retained if those forms belong to some unloaded cells and are unloaded.
• Form observing code: make it really thread safe, almost lock free, use concurrent hashmap collections.

Cosmetic API changes, on hold:

• JValue: string getTag(int object), setTag(int object, string tag) functions. Mostly for debugging purposes. Note that it the functions will share the same tag with JValue.retain function

• JValue.toJSONString

• JString: FormId|Form <-> "__formData|'pluginName'|'lowFormId'" conversion functions

• Set of new JMap|JFormMap|JIntMap.allKeysPArray functions

• JLua interface for convenient Papyrus -> Lua parameter transporting. Example:

  -- replace all non-letter, non-number characters with empty space
  string function normalizeString(string value) global
   return JLua.evalLuaStr("return string.gsub(args.str, ' ', '%W')", JLua.setStr("str",value))
  endfunction

• JDB.autoremoveKeyIfPluginMissing(string rootKey, string pluginFileName). IMO it's best to replace rootKey with path

• Feel free to suggest better function naming etc.

Other changes:

• Improve nextKey functions. Note that the JFormMap.nextKey function is not much reliable (unlike allKeys & allKeysPArray). It is not very much reliable to use it on JFormMap containing object-reference form keys, because Skyrim may unload some of the forms and in the result iteration will be interrupted as nextKey will return None form. Note that v3.3 retains all forms including object-reference forms, thus it's likely impossible to unload such form anymore. Still, the forms imported from JSON files, especially object-reference forms may not be retained if those forms belong to some unloaded cells and are unloaded. For now JFormMap.nextKey will not return unloaded (None) forms, except if it's end of iteration.
  • The functions will not return, skip the keys equal to endKey parameter (that would interrupt iteration when key == endKey).
  • If map container gets modified during iteration process, some container's keys may not be visited. It is valid behavior. See https://groups.google.com/forum/#!topic/jcontainers-users/fy9jmgDplRA
• Log attempts to access deleted JContainers' objects. Useful for debugging, troubleshooting, etc. Note that the logging feature is not disable-able (yet?)

Diagnostics version. Logs access attempts to already destroyed objects, function timing

diagnostics-v3.3

yet another upgrade of python scripts