I've been fairly busy (and will be more busy shortly), and haven't had much time to respond to posts here, so sorry for the delayed responses.
Regarding documentation: it's not great, I know. There's an open issue for improving the docs about the build process and Travis tests, I think.
Issues with DFHack documentation on Github (They're stored separately where I can't find any way to raise Issues):
Not sure where you were looking, but it's definitely on Github in the docs folder of
https://github.com/dfhack/dfhack/I've tried to create a DFHack plugin and have encountered a number of issues with the documentation on how to do this (the documentation is rather helpful, so this is a set of smaller issues). I'd also need help actually understanding how the process works.
- The Compile document https://dfhack.readthedocs.io/en/stable/docs/Compile.html claims Python is needed only for documentation. This isn't quite correct as the How to Contribute document https://dfhack.readthedocs.io/en/stable/Contributing.html#contributing-code says you have to pass a Python script test before submitting code (which not all the DFHack copied from Github passed did, by the way).
I suppose that's a fair point, although you don't need it to
build DFHack - it just enforces a few checks. All of the code in the DFHack repo passes it currently:
https://travis-ci.org/DFHack/dfhack- The latter document above assumes the reader has far too much knowledge of both Github and DFHack's use of Github for me to make sense of the process (which might be due to my lack of understanding, and it doesn't help that I have no prior experience of Github). It seems Github repos can be set up in several ways, and it isn't clear how DFHack is set up.
A guess:
- Create a fork of the development branch (based on the second point plus some of the first one).
- Do work in branches of your fork, pull request (weird terminology for pushing something back without anyone actually being involved in accepting it?) the work back to your development branch and then pull request that back to your master branch and then pull request that back to the DFHack development branch. Look like overkill for a simple plugin, though.
- Presumably, the last step should be done only after some sanity checking and actual acceptance by a trusted DFHack maintainer, but it seems this is based only on trust?
Basic process:
- create a fork of dfhack/dfhack (e.g. your-username/dfhack)
- make a new branch based on the develop branch
- work on your stuff there
- make a pull request
- someone on the DFHack team comments on / accepts the pull request (that's what the "request" part means - you'd be requesting that someone takes a look at your changes and merges them in)
Thanks Max. I haven't done anything with any travis linking: I've just run the script (once I managed to find it). Since it's a matter of code in my case the description etc. script stuff doesn't apply to me. Finding how to get the small soft compiler environment to stop using tabs took a few search passes to find the setting, but I've finally gotten rid of the tabs. The script pointed out where trailing spaces were, so it was a matter of going through that list to eliminate them.
If I get the hang of how Github is supposed to be used I'll consider placing my scripts there, in which case your script summary will come in handy (although I'll have to find out how to get Notepad++ to stop using tabs). Come to think of it, no, I won't put my script there, because of the stupid demand for 4 character indentation, which wastes far too much space (I use 2 in my scripts, but have resigned myself to suffering lines being pushed off the page with the code).
There's no demand for 4-space indentation for scripts:
Four space indents for C++. Never use tabs for indentation in any language.
(Now, I do have objections to 1-space indentation, because it's hard to read, but 2-space indentation is fine if you really want to do that. If you're running into issues with lines being too long, either you have things nested too far or you should break lines up at some point.)
I think twbt bears too much investigation into its stability to be so intractably integrated with dfhack that it can't be unloaded or disabled. It seems to me there's a level of denial about its responsibility for dfhack's crashprone reputation.
To add on what Roses said, these are some reasons why it's
not included in DFHack. Plugins that refuse to be disabled/unloaded are hard to deal with. I'm not up-to-date with how stable recent TWBT builds are, but having seen several crashes linked to it in the past, I'm a bit wary of using it much myself.
TWBT doesn't come with DFHack, it's a separate thing. And as far as I know, even if you have it installed it can be disabled by changing the print mode.
I'm pretty sure Uzu Bash was talking about disabling it in-game with "disable twbt" or "unload twbt", both of which are impossible (it enables itself if it detects PRINT_MODE:TWBT in init.txt, and cannot be unloaded, ever).