Implement a DFHack tab

[Pidgeot]

As far as I can tell, this is the last feature of the current Windows GUI that isn't available in the PyLNP launcher. Once this is implemented the Starter Pack can move over.

DFHack can load a text file and run each line as a command. We take advantage of this to avoid rewriting one of the existing init files, and instead simply have it call a script PyLNP_dfhack_onload.init when a fort is loaded. This means that the launcher can wipe and rewrite the file each time a change is made, which is significantly easier than parsing.

The tab is formatted as a list with checkboxes - much like the utilities list. It draws on configuration which for this would go in PyLNP.json. Each list item has four fields; name, tooltip, command, and enabled_bool.

name is the name of the list item.

tooltip is the tooltip for the list item, and (if enabled_bool) is written to the PyLNP init with a prepended #, as a comment.

command is the dfhack command to run, and (if enabled_bool) is written to the PyLNP init in the line following the corresponding comment. '\n' can be appended for readability.

enabled_bool reflects the state of the checkbox for that item, and stores it between runs.

[Issue created by PeridexisErrant: 2014-08-18]
[Last updated on bitbucket: 2014-08-24]

[Comment created by Pidgeot: 2014-08-24]
Add hack management (fixes #8)

→ <<cset 9f6b29ec5c4b>>

[Comment created by Pidgeot: 2014-08-24]
Here's how this is going to work for the first implementation:

Hacks will be stored as a dictionary called "dfhack" in PyLNP.json. Each hack will use its title as the key and an object containing tooltip and command as the value. (By extension, titles have to be unique.)

Here's an example using hacks from the Starter Pack:

#!json
{
	...
	"dfhack": {
		"Partial Mouse Control": {
			"command": "mousequery edge enable",
			"tooltip": "allows scrolling by hovering near edge of map; conflicts with isometric view; may cause trouble with levers or macros"
		},
		"Performance Tweaks": {
			"command": "multicmd repeat -time 3 months -command cleanowned x; repeat -time 3 months -command clean all",
			"tooltip": "dfhack fixes to run regularly, changes the game a little but helps a lot on old or slow hardware (dump worn items, remove all contaminants)"
		},
		"Pure Bugfixes": {
			"command": "multicmd fix/blood-del; repeat -time 1 months -command fix/feeding-timers; repeat -time 1 months -command fix/stuckdoors; repeat -time 3 months -command fix/population-cap",
			"tooltip": "bugfixes to run regularly, strongly recomended (fix: feeding prisoners, stuckdoors, population cap)"
		}
	}
}

A hack is considered enabled if a line in PyLNP_dfhack_onload.init matches the command for that hack.

Here's the UI:

The tab only appears if the previously mentioned object actually exists in PyLNP.json.

Clicking toggles an item and immediately triggers a complete rewrite of PyLNP_dfhack_onload.init - any changes will be lost then (and only then).

I expect to push it to the repository later today.

[Comment created by Pidgeot: 2014-08-24]
Extending beyond a single, program-controlled file means you suddenly have to special-case for that one file, and it no longer becomes enough to wipe and rebuild. I'm not too happy about that, so it won't be part of the first release (but maybe it can be fitted in later).

The tab will only show if any hacks are defined in PyLNP.json. It won't attempt to detect if DFHack is installed in the DF folder, though.

[Comment created by PeridexisErrant: 2014-08-23]
To make this more general, there could be a fifth field to specify what file the command should be written to if enabled. The line would then have to be removed from that field if disabled from the launcher. It might also be useful to match multiple files, for example the OnLoad.init in each region folder for some functions. This would require some extra configuration on the part of the pack distributor, but make the implementation much more flexible across use cases and versions of DFHack.

It would also be nice to hide the dfhack tab if dfhack is not present in the pack.

[Comment created by Pidgeot: 2014-08-18]
I would rather not store modifiable settings in PyLNP.json, because that would mean it gets reset when migrating between revisions - so the enabled field will probably end up going in PyLNP.user instead (probably as a list of names - we'll see).

I could possibly use an enabled field in PyLNP.json as a default, though - I'll have to consider that.