Print

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

[Clément]

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

Nothing better than that? thistleknot used attribute data from 5000 dwarves. I would be interested for something on this scale, but I don't know how it was done.

Nothing happens when I type these commands after a fresh embark. Does it need time or a minimum wealth before migrants appear?

[lethosor]

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.

What does "changed event_loop() to global" mean? I didn't say anything about that, and event_loop() having the local keyword doesn't have anything to do with the issues I mentioned.

There's no easy and good way to avoid logging mayor changes when the fort loads, unfortunately. I guess there could be a special case for the first run after a world loads.

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

You should absolutely be able to change the build scripts and avoid committing them without Git complaining. The only time Git would complain is if the build scripts also change in DFHack's repo, and that happens rarely and can be worked around without you having to get rid of (or commit) your local changes.

What stonesense build script are you referring to? The only things that contain "C:" in the build folder are build/win64/package-debug.bat and build/win64/package-release.bat, and they don't deal with stonesense. plugins/stonesense/CMakeLists.txt does not contain "C:".

Nothing better than that? thistleknot used attribute data from 5000 dwarves. I would be interested for something on this scale, but I don't know how it was done.

Nothing happens when I type these commands after a fresh embark. Does it need time or a minimum wealth before migrants appear?

You didn't say you wanted 5000 of them - the normal criteria for migrants apply to those scripts, so they won't work if it's too early (as well as if you have too many recent migrants). Thistleknot says he used 5000 "generated" dwarves, which could be from the arena or using spawnunit or modtools/create-unit (which use the arena unit-creation code). I don't know if the variety distribution of migrants is any different, but I can't think of a way to come up with 5000 dwarves otherwise without ~100+ fortresses.

[Atomic Chicken]

Nothing better than that? thistleknot used attribute data from 5000 dwarves. I would be interested for something on this scale, but I don't know how it was done.

The script "modtools/create-unit" lets the game handle preference generation (alongside a bunch of other stuff) for the units it spawns. As such, you could use something like this for your research:

Code: [Select]

local spawnNumber = 10 -- replace this with the number of dwarves you want to spawn

local x,y,z = pos2xyz(df.global.cursor)
if not z then
  qerror('First place your cursor on the screen to choose a spawn location!')
end


for n = 1,spawnNumber do
  dfhack.run_command("modtools/create-unit -race DWARF -caste MALE -name MOUNTAIN -setUnitToFort -location [ "..x.." "..y.." "..z.." ]")
end
Specify the number of dwarves you want to spawn where indicated in the script before running it. Note that it's entirely possible to generate and observe 5000 dwarves at a go with this, but your FPS will be absolutely murdered if you attempt to unpause.

Come to think of it, perhaps it'd be a good idea to add this functionality to the actual script.

[Saiko Kila]

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.

What does "changed event_loop() to global" mean? I didn't say anything about that, and event_loop() having the local keyword doesn't have anything to do with the issues I mentioned.

I had to remove "local" from line

Code: [Select]

local function event_loop()
Otherwise I get DFHack error:

...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:67: attempt to call a nil value (global 'event_loop')
stack traceback:
   ...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:67: in function <...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:13>

[lethosor]

I had to remove "local" from line

Code: [Select]

local function event_loop()
Otherwise I get DFHack error:

...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:67: attempt to call a nil value (global 'event_loop')
stack traceback:
   ...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:67: in function <...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:13>

Oh, okay, that's because of Lua's scoping rules - inside functions, you can only access things that are global (without the "local" keyword), or things that are local and defined before the current function. event_loop is defined near the end of the script, so that makes sense. Thanks - that'll be good to keep in mind for whoever fixes the script.

Atomic Chicken: use "for n = 1, spawnNumber", not the stuff with the while loop. I agree that a quantity flag would be useful (like modtools/create-item), and was thinking of adding one but never got around to it.

[Atomic Chicken]

Atomic Chicken: use "for n = 1, spawnNumber", not the stuff with the while loop. I agree that a quantity flag would be useful (like modtools/create-item), and was thinking of adding one but never got around to it.

Oh wow, brain fart right there. Edited accordingly. I'll get a PR for that quantity arg in place shortly.

[userpay]

Is there a way/script to use DFhack to change a dwarf's emotions to counteract the current 'bug' of sorts that's leading to emotion runaway? Or perhaps another utility? I updated from 9 to 10 because I'd heard the stability was better but didn't realize 10 was where the emotion issue was occurring.

[lethosor]

Atomic Chicken: use "for n = 1, spawnNumber", not the stuff with the while loop. I agree that a quantity flag would be useful (like modtools/create-item), and was thinking of adding one but never got around to it.

Oh wow, brain fart right there. Edited accordingly. I'll get a PR for that quantity arg in place shortly.

To be fair, while loops aren't always bad, of course - I'm a bit paranoid after https://github.com/DFHack/dfhack/issues/1285. Thanks for the soon-to-be-PR.

Is there a way/script to use DFhack to change a dwarf's emotions to counteract the current 'bug' of sorts that's leading to emotion runaway? Or perhaps another utility? I updated from 9 to 10 because I'd heard the stability was better but didn't realize 10 was where the emotion issue was occurring.

Some people have had luck with the remove-stress command, although it only works for the short term (you'll have to run it repeatedly). Thoughts can definitely be modified/removed (the misery plugin does the opposite) but I haven't looked at the issues in 0.44.10 much. You could look at what misery does and see if there's a way to modify thoughts (maybe with gui/gm-editor?).

[userpay]

Atomic Chicken: use "for n = 1, spawnNumber", not the stuff with the while loop. I agree that a quantity flag would be useful (like modtools/create-item), and was thinking of adding one but never got around to it.

Oh wow, brain fart right there. Edited accordingly. I'll get a PR for that quantity arg in place shortly.

To be fair, while loops aren't always bad, of course - I'm a bit paranoid after https://github.com/DFHack/dfhack/issues/1285. Thanks for the soon-to-be-PR.

Is there a way/script to use DFhack to change a dwarf's emotions to counteract the current 'bug' of sorts that's leading to emotion runaway? Or perhaps another utility? I updated from 9 to 10 because I'd heard the stability was better but didn't realize 10 was where the emotion issue was occurring.

Some people have had luck with the remove-stress command, although it only works for the short term (you'll have to run it repeatedly). Thoughts can definitely be modified/removed (the misery plugin does the opposite) but I haven't looked at the issues in 0.44.10 much. You could look at what misery does and see if there's a way to modify thoughts (maybe with gui/gm-editor?).

Hmm... Sounds promising. While my programming is rusty (much less I've never programmed for DF) it should be relatively simple to swap out the added negative thought for a positive one no? I'll have to look into it if issues start arising in my fort. Kinda surprised the opposite hasn't been made already but I guess since the negative emotion thing is relatively recent that would explain it.

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

You should absolutely be able to change the build scripts and avoid committing them without Git complaining. The only time Git would complain is if the build scripts also change in DFHack's repo, and that happens rarely and can be worked around without you having to get rid of (or commit) your local changes.

What stonesense build script are you referring to? The only things that contain "C:" in the build folder are build/win64/package-debug.bat and build/win64/package-release.bat, and they don't deal with stonesense. plugins/stonesense/CMakeLists.txt does not contain "C:".
:

When I tried to push things with the scripts changed but not added and commited git complained. It was a while ago as I've given up (as is typically the case with git...) and copy the blasted install-debug.bat script back and forth (and git didn't like a working copy of the script with a different name either).
Stonesense:The annoying thing there is that it's not even a build script, but the generate-MSVC-gui.bat script, which starts to download stuff and then barf when the stonesense checkbox has been checked, so it blows up during configuration of what to build eventually. It's probably due to the %XXX% symbol having to point to the C drive for old stuff (like the web browser) to continue to work.

[lethosor]

When I tried to push things with the scripts changed but not added and commited git complained.

That's not a situation where Git can complain.

Stonesense:The annoying thing there is that it's not even a build script, but the generate-MSVC-gui.bat script, which starts to download stuff and then barf when the stonesense checkbox has been checked, so it blows up during configuration of what to build eventually. It's probably due to the %XXX% symbol having to point to the C drive for old stuff (like the web browser) to continue to work.

Is this just an assumption, or did you see an error message pertaining to the C drive? I checked again, and "C:\" and "%XXX%" don't appear in stonesense (and if the latter was just a placeholder, there aren't any batch files in stonesense that could be using a symbol like that). An error message would help us figure out what's going wrong.

Anyway, I'm sorry you're having trouble with Git. Are you using the command line or some graphical Git client? I recommend the former as it has more documentation available. I can try to find some good tutorials if it would help - DFHack's workflow is based on "git flow", so searching for that might help with the DFHack-specific Git workflow.

[PatrikLundell]

%XXX% is a placeholder for %program files (86)% or something along those lines.

I believe I did see an error message saying that something or other couldn't be found at the C: drive, and I think it pointed down the program file guff path to where VS would have been placed if it had been on the C: drive.

I'm using the the command line (git xxx <guess at parameters here>). "git help" provides a dozen commands, most of which I've never used, and most of the ones I need aren't listed. The "documentation" is horrible, resulting in a web page that only provides overall syntax, but not any parameters, nor any description of the commands. Web searches are needed to find commands, and sub repo juggling was found in a comment somewhere half way through a discussion of failed attempts.
As it currently stands, I can stumble by with git and a frequent "remove everything and download from scratch" approach. For instance, I won't create a new pull request in a (sub) repo before the previous one is done as I don't want to try to juggle several instances of it (and the complete DFHack surrounding it that's required for the sub repo stuff to be tested), as pull requests are frequently requested to be changed, so the local copy needs to be prepared for making changes to be pushed up.

[Rose]

There's a dozen or so gui frontends for git that make it a lot easier.

[jecowa]

Git front ends do not seem to make git easier to understand. The ones I've seen just add buttons for the different commands. Still have to wrap your head around how it works.

Here's how I use github most of the time:

Note: If you're not on the group for the GitHub project, you'll probably want to fork the project first from the UI on GitHub.com so that you can upload your edits back to your fork.
Key: Terminal commands are in light blue. Text that you should edit for your case are in italics.

• git clone yourproject.git - downloads the project from github the first time (you theoretical only need to do this once)
• cd yourproject - change the directory to the root of your project
• git pull - this downloads new content from the github server (it will be up-to-date, though if you just cloned)
• make your changes to the project
• git status - checks which files you changed and which will be sent to github. (red files wont get sent)
• git add filename.file - adds a file to the list of files getting sent. (or git add . to add all the red untracked files)
• git status - do this once more to make sure it all looks right
• git commit -am "change description" - this makes a save point or something with a comment of what you just changed.
• git push this sends all your commits back to github
• Go to github.com and make a new release.

If you have any problems, backup the project to another folder and reclone it from the github.

[Clément]

The script "modtools/create-unit" lets the game handle preference generation (alongside a bunch of other stuff) for the units it spawns. As such, you could use something like this for your research:

[...]

Thanks for the script.