Print

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

[Bearskie]

Ugh, I'm really not proud of it, but if it gets to help someone, here it is . It's my first and only time writing a DFhack script, so expect errors and general fuckery.

The central logic - use Putnam's teleport.lua to teleport an adventurer 48 squares (ie. 1 embark) in one direction, simulate some adventurer movement key-presses to activate/generate the area, and rinse repeat.

The script would likely be too slow for your purposes, as mapping the world once takes long enough, not to mention 365 times in a year.

Anyway, it teleports a flying adventurer three embark tiles at a time, so in your case you'd bump that up to 16 which is the width of a world tile. Most of the code deals with enforced delays and timeouts, ie. waiting for isoworld to render a detailed tile. In your case it won't be necessary, which speeds up the teleports considerably.

[PatrikLundell]

Thank you very much, both of you.
I'll definitely take a look at it and try to adapt it to my situation.
It's fair to warn about shoddy quality (and I definitely won't hold anyone responsible for me using things that have warnings attached), but even unfinished and unpolished things can be more than sufficient to fill out technical holes and provide techniques not thought of.

Time isn't really a huge issue (depending on what "slow" is, of course), as it would be something I'd start and then let it run in the background (or, for that matter, foreground when going to bed).

[jecowa]

DFHack 64-bit GCC 7.3.0 seems to work fine in MacOS X 10.6, 10.7, and 10.12. I don't really know what to test or look for exactly. Createitem, Reveal, Unreveal, Mousequery, Autolabor, and Labormanager commands all seem to work. Then I tried installing TWBT on Lion and Sierra and the main feature and multilevel both seem to work.

Does GCC do anything cool for us? I think you told me before, but I forgot.

[Clément]

Is there a way to generate a random dwarf ex nihilo or force migration waves or something similar? I'd like to check preferences of a large number of dwarves as generated by the game.

[lethosor]

DFHack 64-bit GCC 7.3.0 seems to work fine in MacOS X 10.6, 10.7, and 10.12. I don't really know what to test or look for exactly. Createitem, Reveal, Unreveal, Mousequery, Autolabor, and Labormanager commands all seem to work. Then I tried installing TWBT on Lion and Sierra and the main feature and multilevel both seem to work.

Does GCC do anything cool for us? I think you told me before, but I forgot.

That's basically all I need to be confident that it works across OS X versions - thanks!

GCC is what we have to use (because DF uses it). The only really "cool" thing about GCC 7 in this case is that it's actually possible to get working on newer macOS versions without putting in excessive effort (including compiling from source if you're using Homebrew), and it was the newest GCC version when we added support for it.

Is there a way to generate a random dwarf ex nihilo or force migration waves or something similar? I'd like to check preferences of a large number of dwarves as generated by the game.

"force migrants" or maybe "migrants-now" (not sure why we have two...)
Note that the criteria for limiting migrants do apply, so you might only get 2 waves worth of migrants before no more arrive for the rest of the season.

[SlimeOfSteel]

I enjoy using DFHack and I know that development on it isn't easy, but DFHack needs support for other programming applications like Eclipse (which is what I have on my flash drive).

I can only access the C: drive of my home computer, so installing Visual Studio on a flash drive is something that would benefit me greatly in development of scripts. However, after some Google searches, even if you specify the install path to somewhere besides the C: drive, a ton of files are installed to the C: drive anyways!

Here's a quote from this thread (https://social.msdn.microsoft.com/Forums/en-US/3e7160ef-505e-4c48-a1aa-78e778c13ee0/install-visual-studio-2017-in-d-drive?forum=vssetup) on MSDN:

this won't change location of all files, but only of those which can be (by design) installed onto different location. Be warned that there is many shared components which will be installed into shared repositories on drive C: without any possibility to change their path.

Again, I'd love to contribute to DFHack (in fact, I'm sure a lot of people would), but I think that allowing support for something like Eclipse would make plugin development easier, in my opinion.

I'm not annoyed with the developers, I'm annoyed at Microsoft because apparently, if I want a portable Visual Studio, I just need to carry around my HDD and a SATA cable, then just connect my HDD to an empty SATA port of the computer I want to use.

TL;DR: I'd like DFHack to have support for something like Eclipse because I can't get VS to run on a flash drive no matter what I do.

[lethosor]

We have no choice as to what compiler to allow on Windows. You must use the Visual Studio 2015 compiler, because that's what DF uses, and if DFHack is built with a different compiler than DF, it will either fail to compile or crash on startup. Even if we wanted to allow other compilers, it's simply not possible.

We aren't opposed to other IDEs, though, and if you can get Eclipse to work with the VS2015 compiler, great. If there's a way we can adjust the CMake configuration to support that, or document the process somehow, that's even better. I don't know of anyone that has done that yet, but it might be possible.

[Saiko Kila]

The crazy system disk space requirements of Visual Studio is the only reason I don't have it currently installed. But this is a recurring theme in Microsoft applications - they are just bad programmers (which I'm certain after reading some of their blogs). Even if they allow to install any suite besides C: drive, it will be flooded anyway, sometimes with duplicate files, and a total mess will be created. Huge non-Microsoft applications usually handle such issues much better. Sorry for ranting, but I'm becoming very angry every time I'm reminded about this problem.

However, I came to this thread for completely unrelated reason. DFHack includes a script extra-gamelog.lua. This script, after slight modification, allows me to log when siege is present on gameload, which I need for SoundSense, and this part works great. But, if I see correctly, this script also should log events like workshop completion, mayor election (different than vanilla DF), and most importantly to me siege end. It seems it doesn't do it by default. Anyone knows how to trigger logging of these items?

[SlimeOfSteel]

We have no choice as to what compiler to allow on Windows. You must use the Visual Studio 2015 compiler, because that's what DF uses, and if DFHack is built with a different compiler than DF, it will either fail to compile or crash on startup. Even if we wanted to allow other compilers, it's simply not possible.

We aren't opposed to other IDEs, though, and if you can get Eclipse to work with the VS2015 compiler, great. If there's a way we can adjust the CMake configuration to support that, or document the process somehow, that's even better. I don't know of anyone that has done that yet, but it might be possible.

Eclipse does support C++, but I don't know how to get it to use the VS2015 compiler. Or where to find said compiler. As you said, it might be possible, but I have no idea how to do it.

[lethosor]

Eclipse does support C++, but I don't know how to get it to use the VS2015 compiler. Or where to find said compiler. As you said, it might be possible, but I have no idea how to do it.

I linked to it in your last thread: https://www.visualstudio.com/vs/older-downloads/#microsoft-build-tools-2015-update-3
Note that I don't actually know if it will work, but BenLubar thinks it would. I also don't know if it can be installed on an external drive.

However, I came to this thread for completely unrelated reason. DFHack includes a script extra-gamelog.lua. This script, after slight modification, allows me to log when siege is present on gameload, which I need for SoundSense, and this part works great. But, if I see correctly, this script also should log events like workshop completion, mayor election (different than vanilla DF), and most importantly to me siege end. It seems it doesn't do it by default. Anyone knows how to trigger logging of these items?

Not sure why it would only log sieges. You're only running the script once, right?

[SlimeOfSteel]

I linked to it in your last thread

...Okay, I'll be honest, I feel a bit stupid. I wasn't absolutely sure what the compiler files were, so I wasn't sure if that VS Build Tools was what I was looking for. I'll take your word for it, though.

[Saiko Kila]

However, I came to this thread for completely unrelated reason. DFHack includes a script extra-gamelog.lua. This script, after slight modification, allows me to log when siege is present on gameload, which I need for SoundSense, and this part works great. But, if I see correctly, this script also should log events like workshop completion, mayor election (different than vanilla DF), and most importantly to me siege end. It seems it doesn't do it by default. Anyone knows how to trigger logging of these items?

Not sure why it would only log sieges. You're only running the script once, right?

I assumed that if it is enabled in the *.init, it runs in loop, constantly. But I get only the "onload" part of the logs from the srcipt (like season info), not the "loop" part (like workshop completion). Maybe my assumption was wrong. Does it have to be enabled in special way to get the loop/repeated part?

[lethosor]

Well, again, I don't know for sure if that's enough. BenLubar has had luck compiling for Windows on Linux, though, so I assume he knows what works. Not sure how closely he follows this thread, but if you have questions, he's usually around on IRC/GitHub.

I assumed that if it is enabled in the *.init, it runs in loop, constantly. But I get only the "onload" part of the logs from the srcipt (like season info), not the "loop" part (like workshop completion). Maybe my assumption was wrong. Does it have to be enabled in special way to get the loop/repeated part?

Which "*.init" exactly is it enabled in? Is it running "modtools/extra-gamelog enable"? (The "enable" part is important.) Have you unloaded and loaded a world before noticing this issue?

Edit: reported several issues I identified at https://github.com/DFHack/dfhack/issues/1287

[Saiko Kila]

Well, again, I don't know for sure if that's enough. BenLubar has had luck compiling for Windows on Linux, though, so I assume he knows what works. Not sure how closely he follows this thread, but if you have questions, he's usually around on IRC/GitHub.

I assumed that if it is enabled in the *.init, it runs in loop, constantly. But I get only the "onload" part of the logs from the srcipt (like season info), not the "loop" part (like workshop completion). Maybe my assumption was wrong. Does it have to be enabled in special way to get the loop/repeated part?

Which "*.init" exactly is it enabled in? Is it running "modtools/extra-gamelog enable"? (The "enable" part is important.) Have you unloaded and loaded a world before noticing this issue?

Edit: reported several issues I identified at https://github.com/DFHack/dfhack/issues/1287

dfhack.init has this:

Code: [Select]

modtools/extra-gamelog enable
I have been using it for days, so loaded the world many times, but never was interested in the "loop" part till recently. Only then I checked gamelog.txt and noticed, that there's no information about mayor election or siege breaks. Only these things which are logged on load are present.

EDIT: Oh, I see, these are issues I'm talking about.

EDIT2: I moved call of event_loop() to log_on_load(), and changed event_loop() to global (after looking up how to do it, I didn't know LUA conventions). This causes the siege info to work as intended (I think), causes mayor info to work (though I'm not sure if as intended, because it is logged every time the fort is loaded), and the building info still doesn't work. But honestly, the only thing I personally needed was siege info for SoundSense, so I'm OK. Thanks for help.

[PatrikLundell]

If you install VS on a drive different from C: you can't use a number of the scripts as the are, as they're hard coded to C:, and if you change them to work you have to copy them out and replace them with the original for the blasted git to allow you to upload anything (it won't accept your local modifications staying local: you either have to commit them [which trashes the original if accepted], or delete the remove).
I've also found that I can't set up stonesense for compilation because the setup gui script uses a symbol that still points to C: (which I can't change without old stuff installed there breaking). A clean install of the computer and applications where everything goes to D: might work, unless you have stuff that's still hard coded for C:. Fortunately, I don't really care about compiling stonesense (Only tried it because of issues that turned out to be due it internal DF git setup upgrades at the same time).