Print

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

[lethosor]

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

No, it's not platform specific at all. Mostly consistency and issues with tabs displaying differently in different environments.

[PatrikLundell]

Further DFHack contribution questions:
Would it be a good idea to make pull requests for updated DFHack structures when fields have been identified rather than generating issues? I'm particularly thinking about some rather lengthy description (in acomment) to describe how rivers work (there's an issued for the raw info).
If that is a good idea, does Travis (or something else) theck the XML syntax to verify it's legal? I currently have no tool for XML editing to it would be raw text editing. None of the things I've seen are complicated, but it's easy to make mistakes.
Obviously, any field identification should be verified by at least one additional person to make reasonably sure it was actually a correct identification.

[lethosor]

Yeah, make pull requests if you can. We haven't set up any Travis stuff in df-structures yet. Are you able to build DFHack? If so, you can build just the "generate_headers" target to make sure the XML is valid, or "dfhack" to make sure the generated headers actually compile. (Usually people will double-check stuff and make sure it compiles, though, but it's nice to check before making PRs if you can, and if it's not trivial.)

[PatrikLundell]

Thanks lethosor. Yes, I can build DF. I didn't know the headers were generated "locally" (but was puzzled about where they came from, as I haven't been able to find them on github), but that makes the syntactic check a lot easier.
Should I "convert" the other issues I've raised that are complete enough into pull requests as well?

Edit: I think the "generate_headers" you refer to is actually the Perl script "codegen.pl"? Running it generated a codegen directory containing a whole lot of .h files, and the one generated from my changes looks well formed (and Visual Studio doesn't complain about it).

[lethosor]

"generate_headers" is the name of the CMake target, which should show up in Visual Studio somehow if you're using that. Yes, it does run codegen.pl, but it gives it certain arguments that cause it to put headers in the right places (so you can actually compile DFHack with them), which I don't think you did. "make generate_headers" would run the same thing on Linux/macOS, but I haven't tried this in Visual Studio, so I'm not sure exactly how it would work there.

Anyway, pull requests generally tend to get looked at faster than issues, so yeah, feel free to make more.

[PatrikLundell]

With a marginal amount of additional experience, I conclude it's probably not possible to just magically get the header generation script to run from Visual Studio without the addition of some glue. The reason for this is that DFHack and df-structures are separate repos and separate entities, and separate directories (on my machine), so something would have to tell Visual Studio in my DFHack fork->branch->clone where to look for the df-structures fork->branch->clone. Adding this glue is probably trivial when you know how...

Also, I'm not too keen on pushing the new headers into my current DFHack fork->branch->repo, as that will break the plugin I have there, so it would have to be a separate clone (which shouldn't be too hard to create). It can also be mentioned that df-structures
is ahead of the development branch of DFHack, as of my last check (a small bug Quietust fixed within 15 minutes of it being reported wasn't present in DFHack develop a few days later when I cloned my stuff, and I don't know what other things are ahead).

My current plan is to transform my issues into  pull requests once I've gotten somewhere with the current one, so I won't have to repeat all process corrections in parallel.

[Nahere]

Is it possible to get modtools like projectile-trigger and spawn-flow to work in the arena? If so how?

[Rose]

PatrikLundell, it's probably easiest just to keep different copies of the dfhack repo for different things. That's what I do anyway.

Just have one just for DF-structures research. Then you can change the DF-structures branch for separating pull requests.

[lethosor]

With a marginal amount of additional experience, I conclude it's probably not possible to just magically get the header generation script to run from Visual Studio without the addition of some glue. The reason for this is that DFHack and df-structures are separate repos and separate entities, and separate directories (on my machine), so something would have to tell Visual Studio in my DFHack fork->branch->clone where to look for the df-structures fork->branch->clone. Adding this glue is probably trivial when you know how..

df-structures should be a submodule and cloned in your DFHack/library/xml folder. You can make changes there and push them to your fork as with any other repo, although you may need to run "git checkout master" first.

[PatrikLundell]

Ah, so that's where the XML files are hiding (and evading my eyes while looking for missing stuff). Sub modules haven't been my friends so far, as my attempt to push things back to my master (with DFHack scripts) failed, probably because the sub module did not respect my mastery, but somehow retained the one I forked from. I ended up with a "naked " scripts repo, and it's a lot less work to use the web interface to just drop my files there (from the folder inside DF), so I don't even need a local git copy of the repo.

Edit:
I've now managed to get the modified .XML file to generate h. files that have been used to build the Win 32 DFHack solution.

[Uzu Bash]

Documentation isn't clear on  what df.units.flags2 cleanup vars do. What do the kill function and forget function do exactly?

From testing I found that cleanup_1 will remove a unit from active, but not units.all, but I don't see any other effect it has on the unit, nor the unit's nemesis or figure records if they have one. Reloading the map doesn't return unit to active, not even leaving the region and returning.

cleanup_2 will clear the unit from active and all, and the associated nemesis record, if it exists. This corrupts the save because every nemesis# now refers to different histfigs. If non-notable units are cleared, they never return to the region tile.

I haven't seen any effects from cleanup_3, cleanup_4, or killed. cleanup_3 set to true will revert to false on next tick, the others will remain true.

[Quietust]

The identities of those "cleanup" vars were provided by Toady himself - we don't know exactly what they do, and we'd have to study a disassembly to figure out.

[PatrikLundell]

I'm trying to use the EventManager plugin's onJobCompleted callback from a Lua script. However, it doesn't seem to trigger on either StoreItemInStockpile or StoreItemInVehicle.
I've set the callback up both with a frequency of 0 and 1 (on different runs) with no apparent difference in the results. It's not that the callback isn't triggered: I've added a printout that prints df.job_type[job.job_type], and other stuff appears, such as drink2, eat, sleep, gather plants, and construct tool. Hauling a mine cart to a route stop did not register, however, so it might filter out all kinds of hauling jobs, which is unfortunate in my case, as I'm trying to make it possible to both transport booze using mine carts, and store it in (mine cart) quantum stockpiles. The intention was to strip any stockpile designation from booze barrels hauled to (food) stockpiles, but I haven't come further than trying to get a trigger when it would be time to look for booze barrels to strip for stockpile allocation...

Edit:
Well, the oddity above still remains, but my attempt to make it possible to transport booze failed as removing the references from barrels and stockpiles are immediately undone by DF restoring them. Otherwise it turned out INVENTORY_CHANGE can be used as a hauling trigger.

[Roses]

Did something change with table.unpack in the latest DFHack release? A script of mine that used to work no longer does, returning nil whenever I try to unpack a table. Not a big deal since I changed the way the script works, just wondering for curiosity.

[lethosor]

What table are you trying to unpack (and what are its contents)? These seem to be working for me:

Code: [Select]

[lua]# ~table.unpack{1,2,3}
1 2 3
[lua]# ~table.unpack{nil,1,2,3}
nil 1 2 3

We had to switch to Lua 5.3 (from 5.2) for 0.43.05, but that was several releases ago. That could've changed some behavior of built-in Lua functions.