Print

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

[lethosor]

There appear to be issues with autochop not creating jobs correctly (described in this thread and on GitHub). I hope to get those fixed by r1, although I do still plan on putting up a beta2 release soon (for Stonesense and a couple other things), and I can't guarantee autochop will be fixed for that.

[Snafu]

See also http://www.bay12forums.com/smf/index.php?topic=139553.msg7411188#msg7411188 above..

[lethosor]

See also http://www.bay12forums.com/smf/index.php?topic=139553.msg7411188#msg7411188 above..

Sorry, I didn't reply to that because I'm really not familiar with autochop. I'm guessing the issues with designations and jobs targeting the wrong trees are related to the job creation issues, at least to an extent.

Does autochop currently have a feature to prioritize trees? I'm not seeing one on my end. Do you mean you designated some trees manually? That might not work because a lot of DFHack-created designations don't have priorities set properly, and can take precedence over DF-created ones.

[Snafu]

Does autochop currently have a feature to prioritize trees? [..] Do you mean you designated some trees manually?

Prioritising (mature) trees is a suggestion for a fix; AFAIK it's not currently implemented at all. However, prioritising manually selected trees over autochop's designation is a much-desired feature

While autochop was active I manually designated some trees (top (lvl 1) priority) to have them cleared ASAP, but nothing happened, even after a year or so My 10 idiot woodcutters still continued to chop saplings etc until I eventually turned off autochop & deselected the entire 5 z-lvls manually (turning off autochip didn't work just by itself), then reselected the priority trees

[Amostubal]

Hey lethosor or anyone else knows...
Whats the status of makeown and tweak, are they all the way out?  They still show up in the DFHack readthedocs...
http://dfhack.readthedocs.io/en/stable/docs/Plugins.html?highlight=makeown

The reason I'm asking is we were having issues with a few commands trying to convert an invader into a citizen.

apparently our previous script was using makeown but it apparently hasn't been updated in quite some time, and now we came across 2 lines that are giving us issues that we really aren't sure what they did to begin with.

makeown.lua:151: Cannot write field historical_figure.anon_1: not found.

we removed the .relations from these 2 lines, since relations is gone... what were anon_1, anon_2, anon_3 discovered to be looking at? or what are they trying to reference.
        hf.anon_1 = unit.anon_2
        hf.anon_2 = unit.anon_3


....
if its not a script that's going to get fixed and re-released, does anyone else have a method to accomplish what makeown did, convert a unit to a citizen of the fort?

[milo christiansen]

Interesting. I will definitely have to take a look at assigning tasks through reaction-trigger. If I could figure that all out then you could get rid of all vanilla buildings and have a total conversion.

My Underhive Settlement reboot removes all vanilla workshops. Well, all except the butcher shop, as the slaughter job will not work at any other workshop (but milking will, go figure).

To do hardcoded jobs that cannot be replaced with reactions I hack a button for that job into the workshop sidebar. Triggering the job from a reaction will probably work better though...

[Roses]

Interesting. I will definitely have to take a look at assigning tasks through reaction-trigger. If I could figure that all out then you could get rid of all vanilla buildings and have a total conversion.

My Underhive Settlement reboot removes all vanilla workshops. Well, all except the butcher shop, as the slaughter job will not work at any other workshop (but milking will, go figure).

To do hardcoded jobs that cannot be replaced with reactions I hack a button for that job into the workshop sidebar. Triggering the job from a reaction will probably work better though...

Hmm, I didn't even think about just putting the button into a different workshop sidebar. I think I am going to try to get the reaction trigger method working, it might even give more options that are script customizable for each job.

[milo christiansen]

The problem with hardcoded jobs in custom workshops is that jobs the normally queue automatically don't. Also when hacking in buttons you can't queue jobs with the manager...

Using reaction-trigger should solve the manager issues, so that is one major point in its favor.

[lethosor]

Hey lethosor or anyone else knows...
Whats the status of makeown and tweak, are they all the way out?  They still show up in the DFHack readthedocs...
http://dfhack.readthedocs.io/en/stable/docs/Plugins.html?highlight=makeown

The reason I'm asking is we were having issues with a few commands trying to convert an invader into a citizen.

apparently our previous script was using makeown but it apparently hasn't been updated in quite some time, and now we came across 2 lines that are giving us issues that we really aren't sure what they did to begin with.

makeown.lua:151: Cannot write field historical_figure.anon_1: not found.

we removed the .relations from these 2 lines, since relations is gone... what were anon_1, anon_2, anon_3 discovered to be looking at? or what are they trying to reference.
        hf.anon_1 = unit.anon_2
        hf.anon_2 = unit.anon_3


....
if its not a script that's going to get fixed and re-released, does anyone else have a method to accomplish what makeown did, convert a unit to a citizen of the fort?

A couple things: "tweak" is a plugin, and "tweak makeown" is a subcommand of that plugin that does what you expect (ideally). There's also a "makeown.lua" file in hack/lua that other scripts can use more easily, which I just found out about thanks to you. "tweak" also has a lot of other unrelated subcommands.

Just because it's broken doesn't mean we plan to remove it - this is the first time I've heard about this file being an issue. It's usually better to report these sorts of things on GitHub, because they can get buried here.

Anyway, the issue is almost certainly that "anon_1" and "anon_2" got renamed (well, named, since "anon_x" fields are placeholders for fields with no names). We strongly discourage using those without giving them proper names (in df-structures), but that file must have slipped through the cracks, presumably because it's old and in hack/lua instead of hack/scripts. I'll check on what the fields are named now.


Edit: try changing them to "birth_year_bias" and "birth_time_bias" respectively (keeping whatever relations-related changes you've made). If that works, could you make a pull request or post the fixed file?

[Amostubal]

sure I can post that lethosor.... I'm hacking it fast as I can trying to come up with something that works....

Here's our issue it seems there is a lot of stuff in there not working... I'm banging my head against it like a good little dwarf...

[lethosor]

Here's a new beta release: https://github.com/DFHack/dfhack/releases/tag/0.43.05-beta2. Still waiting on Windows for now, but this adds 64-bit Stonesense support on OS X and Linux (which was already available on Windows), so I didn't want to delay this further.

Apologies for the long wait. I wanted to get this out for people to make sure 64-bit Stonesense worked a while ago, but didn't have time.

Hopefully a stable release will happen soon. There are just a couple issues left, particularly with autochop.

Amostubal: let me know how you fixed that file (if it works) so that the changes can be included.

[Amostubal]

actually I just stopped trying on makeown... the issue I was facing wasn't going to be fixed by it... I went back to the other route, fixed create-unit issues.... the only thing I want more from create-unit is a way to actually designate a 'name' of another unit when calling it from another script... not sure how that would be accomplished...

the fixes I made to create-unit included:
1.  utilized arguments to get the location information to the createunit function so that it could properly place the cursor, over teleporting the unit from hell...  gets around the rare, but frustrating mapdata fail at 0,0,last z that I had a few weeks past.
2.  added an argument to setUnitToFort to clean up the verbose of other scripts that try to call it, left in the old \\LOCAL stuff to keep from breaking old scripts.
3.  fixed a bug in the part of the age script that would fail if the historical_figure went over ~32,000 switched it to the proper call to find the historical_figure instead of trying to index it.

Now if I can get past the bugs that crept into another script, masterwork/succubus related....
anyone have a good script that will kill a unit that is in an actual cage?  I've tried several unit.flags including scuttle, which is my favorite... I just love finding dead bodies... but the unit just stays in the box...  I've got a script that teleports the unit out of the box... but it leaves a funky remnant of a unit behind. 
nvm... apparently the teleport script I have followed by a scuttle does the job, the remnants in the cages disappear when their teleported versions die.  Its a beautiful work too... created new unit based off information of the old unit, new unit set to civ/group, created on top of the old unit's cage, the old unit teleports out of the cage and insta dies... the new unit has a nice bit of terror and horror the first few minutes, sits there for half a month till it get hungry or thirsty enough or someone else with more discipline comes and gets the body.  I giggled halfed the night about it...

[surazal]

Here's a new beta release: https://github.com/DFHack/dfhack/releases/tag/0.43.05-beta2. Still waiting on Windows for now, but this adds 64-bit Stonesense support on OS X and Linux (which was already available on Windows), so I didn't want to delay this further.

I logged on to my account on this site for the first time in months just to be able to say: Squeeeee!

[lethosor]

Windows builds are up now, thanks to ab9rf: https://github.com/DFHack/dfhack/releases/tag/0.43.05-beta2

[Bumber]

Has there been any work done into figuring out how to adjust the combat wear feature?

Haven't actually played since it was added, but from what I've gathered it's over-zealous. Especially considering there's no way to repair masterworks or named items. Really worried about candy, as well.