Allow controlling autogems from dfhack *.init

[TymurGubayev]

I'd like a way to control autogems from my onMapLoad*.init file, the aim being able to write something like

on-new-fortress \
    autogems auto-cut; \
    autogems ignore CRYSTAL_GLASSABLE;

Because it's what I usually do (if I manage to remember it).

Fun fact: this lua-script toggles autocutting rock crystal.

-- pressing o-W-G-r-ENTER-ESC-ESC-ESC
local scr = dfhack.gui.getViewscreenByType(df.viewscreen_dwarfmodest)
scr:feed_key(df.interface_key.D_ORDERS)
scr:feed_key(df.interface_key.ORDERS_WORKSHOP)
scr:feed_key(df.interface_key.CUSTOM_SHIFT_G)
scr:feed_key(df.interface_key.CUSTOM_R)
scr:feed_key(df.interface_key.SELECT)
scr:feed_key(df.interface_key.LEAVESCREEN)
scr:feed_key(df.interface_key.LEAVESCREEN)
scr:feed_key(df.interface_key.LEAVESCREEN)

[lethosor]

If it helps, the autogems configuration is saved to data/save/*/autogems.json (but it isn't transferrable if raws are different between saves).

[TymurGubayev]

yeah, I thought about copying the file, but I don't like the idea.

[lethosor]

Are you concerned about the file format or config files in general? This is probably something I would put in a config file in any case, although maybe we should switch the format to be more useful across saves.

[TymurGubayev]

Actually, I didn't like the idea of creating config files from an .init file (as a concept), but now that I've actually taken a look at the file in question, {"blacklist":[90]} won't survive any changes in the game (and even mods could break it if I understand the concept of RAWs and CRYSTAL_GLASSABLE correctly)

[lethosor]

Yes, mods could change the numeric IDs, but adding materials to an existing save will cause DF to crash (at least without extra manual modification to the save beforehand, e.g. devel/inject-raws), so the current format works as long as config files are kept internal to a save, or saves with identical raws. I guess that's not necessarily useful for what you want, though. The current implementation was really just a minimal solution for #1027, and we'd be open to making it more flexible.