Print

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

[Putnam]

That is the intended usage, yes. It may or may not be broken. I forget if that was one of the broken things or not.

It's not.

[Dirst]

Second Bug: I also notice in the autolabor plugin that woodcutting is snubbed completely if dwarves have any experience in mining. If you embark with seven picks and assign all your dwarves the "Mining" labor having all your dwarves dig and become dabblers, if you then enable the autolabor plugin and then assign some trees to be cut down your dwarves will refuse. Forcing one to disable autolabor and assign the woodcutting profession manually.

I run dwarf fortress and dfhack on a min install of debian linux jessie. If you need any other information just ask and I'll try to get the information to you as clearly as possible.

Just a quick thought, both the miner and the woodcutter have an invisible "uniform" that goes along with their labors (edit: Hunting does too).  Turning on both in Dwarf Therapist or the vanilla interface would also lead to problems.  These invisible "uniforms" also conflict with real military uniforms.

So this may not be an autolabor bug, though detecting these conflicts might be a nice feature for autolabor to have.

[lethosor]

First off, I love dfhack and I don't know what I would do without it. It is a powerful and awesome tool. Thank you so much!

Second off, I have run into some bugs and I am hoping this is the right place to report them. If not, kindly point me in the right direction.

First Bug: I've noticed that the workflow plugin seems to have a limited number of entries that it can take before hanging? You can duplicate this error by running a bash script with multiple (~320) entries of "./dfhack-run workflow amount X 2 1" Where X # # is a new and different item to be produced. Exiting the game with the "die" command or the conventional way results with repetitions of the following error for each workflow command that didn't execute:

Code: [Select]

Could not connect to localhost: 5000

It's possible that that's a problem with dfhack-run, not workflow. Does the problem still occur if you place the commands in a file (without "./dfhack-run") and run "script (filename)" in the DFHack console?

[breadman]

Second off, I have run into some bugs and I am hoping this is the right place to report them. If not, kindly point me in the right direction.

This is probably the best place to ensure your bug report will be seen, but the issues list on GitHub has a longer memory, and the IRC channel can be better for a deep discussion if you catch the right person at the right time.

Second Bug: I also notice in the autolabor plugin that woodcutting is snubbed completely if dwarves have any experience in mining.

Yeah, autolabor tries to deal with the three uniformed professions (mining, woodcutting, and hunting), but isn't exactly optimal for them.  It helps to reduce their maximum numbers to less than the number of civilians in your fort.  For this case:

Code: [Select]

autolabor MINE 2 6
autolabor CUTWOOD 1 2
autolabor HUNT 0 1
That will probably give you six miners and one woodcutter, but might switch them to five and two.

I've considered improving the plugin for this case, but haven't done much yet.  It would also be interesting to incorporate some of the improved algorithms from Dwarf Therapist.

[walberg]

First off, I love dfhack and I don't know what I would do without it. It is a powerful and awesome tool. Thank you so much!

Second off, I have run into some bugs and I am hoping this is the right place to report them. If not, kindly point me in the right direction.

First Bug: I've noticed that the workflow plugin seems to have a limited number of entries that it can take before hanging? You can duplicate this error by running a bash script with multiple (~320) entries of "./dfhack-run workflow amount X 2 1" Where X # # is a new and different item to be produced. Exiting the game with the "die" command or the conventional way results with repetitions of the following error for each workflow command that didn't execute:

Code: [Select]

Could not connect to localhost: 5000

It's possible that that's a problem with dfhack-run, not workflow. Does the problem still occur if you place the commands in a file (without "./dfhack-run") and run "script (filename)" in the DFHack console?

Or better yet, put them in an appropriately placed onLoad.init file...

[Roses]

That is the intended usage, yes. It may or may not be broken. I forget if that was one of the broken things or not.

It's not.

Code: [Select]

modtools/interaction-trigger -onAttackStr "casts burn" -command [ wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -script [ modtools/add-syndrome -unit !TARGET -syndrome BURN ] -reflect [ REFELECT_ALL REFLECT_ELEMENTAL REFLECT_FIRE ] -silence [ SILENCE_ALL SILENCE_ELEMENTAL SILENCE_FIRE ] -iclass [ FIRE_1 FIRE_2 FIRE_3 FIRE_4 MAGIC_IMMUNE MAGIC_RESIST ] -isyndrome [ FIRE_WARD RESIST_MAGIC IMMUNE_MAGIC ] ]
modtools/interaction-trigger -onAttackStr "casts burn" -command [ wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -script [ unit/attribute-change -unit !TARGET -physical [ ENDURANCE TOUGHNESS ] -fixed [ !VALUE !VALUE ] -dur 1000 ] -value self:willpower:-10:100 -reflect [ REFELECT_ALL REFLECT_ELEMENTAL REFLECT_FIRE ] -silence [ SILENCE_ALL SILENCE_ELEMENTAL SILENCE_FIRE ] -iclass [ FIRE_1 FIRE_2 FIRE_3 FIRE_4 MAGIC_IMMUNE MAGIC_RESIST ] -isyndrome [ FIRE_WARD RESIST_MAGIC IMMUNE_MAGIC ] -aclass [ ICE_1 ICE_2 ICE_3 ICE_4 ] ]
modtools/interaction-trigger -onAttackStr "casts burn" -command [ wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -script [ modtools/add-syndrome -unit !TARGET -syndrome ICE_WARD -eraseAll ] -reflect [ REFELECT_ALL REFLECT_ELEMENTAL REFLECT_FIRE ] -silence [ SILENCE_ALL SILENCE_ELEMENTAL SILENCE_FIRE ] -iclass [ FIRE_1 FIRE_2 FIRE_3 FIRE_4 MAGIC_IMMUNE MAGIC_RESIST ] -isyndrome [ FIRE_WARD RESIST_MAGIC IMMUNE_MAGIC ] -asyndrome [ ICE_WARD ] ]
modtools/interaction-trigger -onAttackStr "casts burn" -command [ wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -script [ modtools/add-syndrome -unit !TARGET -syndrome SOAKED -eraseAll ] -reflect [ REFELECT_ALL REFLECT_ELEMENTAL REFLECT_FIRE ] -silence [ SILENCE_ALL SILENCE_ELEMENTAL SILENCE_FIRE ] -iclass [ FIRE_1 FIRE_2 FIRE_3 FIRE_4 MAGIC_IMMUNE MAGIC_RESIST ] -isyndrome [ FIRE_WARD RESIST_MAGIC IMMUNE_MAGIC ] -asyndrome [ SOAKED ] ]

Well here is an example of what I am thinking, the break down is;
Burn is a level 1 Fire spell, all fire creatures are immune to it, if not a fire creature the syndrome is applied
If the target is an ice creature, it will loose some amount of endurance and toughness, based on the casters willpower (100 at 2000, 400 at 5000)
If the target has an Ice Ward on it will remove the Ice Ward
If the target is soaked from a Water spell, it will remove the soaking

So basically all spells will have multiple effects based on strengths and weaknesses of schools versus each other. And each sphere of magic is associated with a different mental attribute, so that your spells are more powerful with a given attribute (Willpower for Elemental, Focus for Arcane, Creativity for Mental, Intuition for Divine, and Patience for Nature).

[lethosor]

First off, I love dfhack and I don't know what I would do without it. It is a powerful and awesome tool. Thank you so much!

Second off, I have run into some bugs and I am hoping this is the right place to report them. If not, kindly point me in the right direction.

First Bug: I've noticed that the workflow plugin seems to have a limited number of entries that it can take before hanging? You can duplicate this error by running a bash script with multiple (~320) entries of "./dfhack-run workflow amount X 2 1" Where X # # is a new and different item to be produced. Exiting the game with the "die" command or the conventional way results with repetitions of the following error for each workflow command that didn't execute:

Code: [Select]

Could not connect to localhost: 5000

It's possible that that's a problem with dfhack-run, not workflow. Does the problem still occur if you place the commands in a file (without "./dfhack-run") and run "script (filename)" in the DFHack console?

Or better yet, put them in an appropriately placed onLoad.init file...

That's only useful if you want the commands to be run when a specific world loads (or any world, in the case of onLoadWorld.init). Some plugins save their state, so commands involving them only need to be run once per world.

[mifki]

I'm planning on a release very soon. It will be missing most of the things on my todo list. I'll do an r2 later for those.

Aaand.. 0.40.15 is here:)

[expwnent]

I'm planning on a release very soon. It will be missing most of the things on my todo list. I'll do an r2 later for those.

Aaand.. 0.40.15 is here:)

Haha yeah. Sorry guys. 0.40.14-r1 will be up soon. Hopefully 0.40.15-r1 will be up within a few days.

[Spacebat]

So, what needs updating to make this compatible with 0.40.15? I have the source, but every time I look too deeply I can feel it staring back.

[expwnent]

Release done.

[lethosor]

OS X build (0.40.14-r1)
Edit:
Linux build (GCC 4.5.4)

[Max™]

Argh, what was the fix for the graphics either not working or working with messed up keybinds? I've tried various ways from scratch, used the linux tar.bz2 from here, used the native arch one, but I still get the l announcements, f3 pause, etc weirdness if I use the native arch libgraphics.so, or nothing but png errors if I try to use the one that comes with the df_linux install.

Hmmm, not directly related to a fix, but anyone got an idea why the arch one would be 6.9 mb while the bay12games download gives a 1.4 mb libgraphics.so?

[AshenGrey]

I hate to complain, but I just downloaded the new version and I found several issues. First off, it says that 'plugin dwarfmoniter not built for this version of DF hack', as well as the dfhack.int config file is missing. Care to fix/Find out what is with that, please?

[Max™]

The dfhack.init missing is normal, rename the one present from .init.example or substitute your own if you have one.

Still stumped on the keybinds thing, I checked the symbols.xml and it's fine, but that would be involved in dfhack not working (which it does, by the way) not the weird keybinds. I'm missing something here.