Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PatrikLundell]

Given my experience, I'd say some raw changes only affect new creatures, but I'd suspect others affect all of them. The difference ought to be whether the info is copied into the unit on creation (in which case it ought to be possible to modify individually) or not. Note that this is speculation only: I haven't tried it out.
I wouldn't be surprised if changing the adult size of a creature would cause maturing (but already existing) creatures to take on the new size while those already mature would remain unchanged, i.e. raw changes affect only creatures that refer to the changed data for some processing.

[PatrikLundell]

Issues with DFHack documentation on Github (They're stored separately where I can't find any way to raise Issues):
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).
- 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?

[Roses]

Given my experience, I'd say some raw changes only affect new creatures, but I'd suspect others affect all of them. The difference ought to be whether the info is copied into the unit on creation (in which case it ought to be possible to modify individually) or not. Note that this is speculation only: I haven't tried it out.
I wouldn't be surprised if changing the adult size of a creature would cause maturing (but already existing) creatures to take on the new size while those already mature would remain unchanged, i.e. raw changes affect only creatures that refer to the changed data for some processing.

As far as I know modifying the creature information in global.world.raws.creatures.all (or something like that) will effect all existing and new creatures, since the information found in the unit (seen through something like gm-editor) is more or less a link to the creature raws, not stored per unit. There are exceptions to this since, like you said, some of the information in the creatures raws is just used as a basis for the unit (attribute information for instance, changing the range of a certain attribute wouldn't effect an existing unit, except for it's description), however most of the good stuff is linked to (like materials and tissues, and most of the tokens) and can not be changed on a per unit basis.

[Max™]

Having done my own embarrassing trying to poke around with the current dfhack github on the scripts side; you don't need to make a travis account, shouldn't link your github to it because it will spam build notifications in the dfhack irc, and the easy way to pass which I haven't actually seen the full list written together directly is as follows:

*--Put a short description for the ls/help/etc up here.
*--[====[
*
*scriptname
*======== <- same length as scriptname or longer I think
*some info
*about your script use
*also help/args and such
*
*]====]
*find and replace all tabs in your code with 4 spaces each
*kill trailing whitespace
*put a return at the end of lua scripts, I assume ruby is the same

[PatrikLundell]

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).

[Uzu Bash]

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.

[Roses]

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.

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.

[lethosor]

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).

[PatrikLundell]

Thanks lethosor, good answers as always.

I'm not exactly complaining about the documentation, as what's there is way more than we have reason to demand (which, I think, is nothing, by the way).  My comments were mostly meant as feedback to improve it, should someone wish to do so. However, I'll write an Issue for it.

The documentation links I've found are at https://dfhack.readthedocs.io/en/stable/, which is where I ended up searching for documentation.

Thanks for the description of the process. It's also good to hear that the Github documentation I've tried to read has failed to point out that there's actually a request/accept stage involved (or maybe the DFHack structure of it uses an organization way down the list after my brained had shut down).

Good to hear I was wrong about script indentation. I have more trouble with breaking lines in C where the development environment decides that the broken line should be placed so it ends up in a hard to read mess. With scripts I'm in control, but if half the page is lost to indentation there isn't much left for the actual script/code without it being broken over a silly number of lines.

Edit:
Trying to understand the pull request logic, my impression is that a pull request contains all the differences between the base and the head (terms used by web pages describing it). If that's the case, don't you need a separate branch for each item = (future) pull request? If you create plugin 1 and plugin 2 (or bug fix 1 and 2) they ought to be accepted/rejected separately?

[Rose]

Generally, yeah, each separate thing you're working on would be a separate branch, unless they're supposed to be together, in which case a single branch and PR would be fine.

[Max™]

Ah, yeah the 4 spaces was indeed from the C++ part, just remembered seeing that while checking for style info in dfhack, and once I did one script I just went around spamming find/replace with the same tab > 4space cache and didn't catch that travis only cared about tabs.

[Fleeting Frames]

Why no tabs requirement, anyway? Problems on *guessing* Mac systems?

[Max™]

Might just be a style preference, they can end up being excessive too.

Code: [Select]

I feel like this
    helps keep a groove
    when I'm scripting
        because it reminds me
            which blocks to check for closure
            by visually
        delineating
            the relevant
        nesting
    and lack thereof
    in my
subsections.

Code: [Select]

While this
        causes the lines to skew
                way over to the side
                        after just a couple of
                chunks
                which ends up
                        losing the vertical
                                component
                                        of the visual
                                relationships
                                        and can
                                make it harder
                        to catch errors
                or even just
        clean up
                sloppy
        and cluttered
bits of code.


[PatrikLundell]

Thanks for the answer, Japa.

One problem with tabs is that the horizontal space they take up varies, so you can create a file and format it using 4 space long tabs and then load it elsewhere where e.g. 8 or 3 spaces are using as the visual translation.

[Roses]

Edit:
Trying to understand the pull request logic, my impression is that a pull request contains all the differences between the base and the head (terms used by web pages describing it). If that's the case, don't you need a separate branch for each item = (future) pull request? If you create plugin 1 and plugin 2 (or bug fix 1 and 2) they ought to be accepted/rejected separately?

I'm not sure about in GitHub, but just using git you are able to commit specific file changes and do pull requests on those specific changes, so if you are working on two separate things you can keep their commits and pulls separate. I don't think GitHub allows you to merge specific commits with the web interface, but if you use a terminal you can.