I will defer to Tachytaenius for questions on custom-raw-tokens, but I can answer the others:
> are there any limitations in the new system that weren't in the previous?
Not that I know of. To my knowledge (which isn't complete) the syntax and capabilities of the raws have not changed
> Are subfolders still allowed, or does everything have to be flat in scripts_modactive and scripts_modactive/internal?
The folder structure under the scripts directories is up to you. DFHack essentially adds
scripts_modinstalled and
scripts_modactive to its script search path, and script modules can be organized however you like. Scripts in the
internal subdirectory won't clutter up the autocomplete list in
ls or
gui/launcher and cannot be run by the player, but they can still be reqscript'd from your top-level scripts.
> saved a lua table to a json file ... or used persist-table... Is this still the best way to handle persistant data storage and function callbacks?
Persisting data to json manually (for state not tied to a savegame) or with
persist-table (for savegame state) are still the best options. The biggest related change is how you reload on start. Before, the player had to manually invoke a script or you had to specifically start your script from an init file. Now, all (non-internal) scripts that declare themselves to be module loadable are parsed at game start (and again before the game is loaded). You can reload your state (including whether your script was enabled, if it can be enabled/disabled) in a callback hook attached to
dfhack.onStateChange. A good, simple example is emigration.lua, which stores state with the savegame via persist-table and restores its enabled state on game load:
https://github.com/DFHack/scripts/blob/master/emigration.lua> Syndromes
Syndromes haven't changed since 0.47. I don't have a lot of experience with using them for actual modding, but to my knowledge, they're still the best way to apply unit based modifications.
> I am wondering if there has been any work on the DFHack side of things to track things like custom DF structures.
Even if DFHack adds to the structures or extends the enum values, it's DF that will be interpreting them. Adding new enum values, for example, might cause DF to take unexpected paths through switch statements. I don't think this can be supported. I think a safer architecture would be to keep your own mapping of units to extended attributes and reference that map when you need to make a decision based on the value for a unit.
> Custom Files - Where should custom files that aren't technically raw objects or scripts go?
You can distribute whatever files you want in a mod, even when it is distributed via the Steam Workshop. You can look up your mod source path in df.global.world.object_loader.object_load_order_src_dir. You shouldn't write there, though. Dynamic data/configuration can be saved to dfhack-config/mods/yourmodid/somefile
