Print

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

[Schmaven]

Hi!  I’ve been having a few problems with autochop.
...

Not real solutions, but you can toggle your wood stockpiles to take only from linked stockpiles.  That would stop dwarves from hauling the logs and the associated troubles with that.  If it's a combination stockpile, you can forbid wood.  Then change it back when you need more logs brought in.

I've also had the lag spike issue with the stocks screen.  Using shift to jump over that line item, or scrolling the other direction in the list can dodge it.

[PatrikLundell]

Reducing the size of the wood stockpile would result in hauling to it only until it gets full. If you're using quantum stockpiles you can have the feeder stockpile use wheelbarrows to restrict the number of haulers (and change it to take from links only when you want the buggers to do something important, as mentioned).

[lethosor]

Hi!  I’ve been having a few problems with autochop. 

The first problem is that it seems to designate way too many trees for felling.  On one of my previous forts, my stocks screen listed something like 25,000+ logs and my computer ground to a halt for at least five minutes when ever I cursored down to the line for logs.  I checked the autochop dashboard and it said that it was set to keep only a maximum of 100 logs on hand at a time.  Something is obviously going wrong here if autochop is ignoring it’s maximum limit.

I pulled up a test fort and set autochop to a maximum of 10 logs. Autochop did designate every tree for chopping, but as soon as my woodcutter had cut down enough trees, it undesignated every tree again. It seems to check every in-game day, so if you have a lot of woodcutters, this behavior might result in a few too many logs. I let it run for a couple more in-game days and it didn't designate any more trees, so it seems to be working on my end, at least over the short term.

There is a feature request here to limit the number of trees designated, but it hasn't been completed yet. There is also this one for an annual limit on trees chopped (to keep elves happy).

A couple questions:
- How old is this fort?
- What DFHack version are you using? (The version number from running "help" or in the options (Esc) menu is ideal.)
- Do you have enough logs that are accessible? (i.e. not forbidden, in jobs, etc). One possibility I can think of is that if a lot of logs are queued to be placed in a bin, autochop might not consider them as available, and could end up causing more trees to be cut down. The "z"-stocks screen would still show a lot of logs in this case.

[myk]

I'm thinking of implementing a military uniforms importer/exporter (as per issue #651). What other military-related functionality would be useful? That is, if I built a "military" plugin, what would you want it to do?

If the answer is "not much", I'll probably keep it simple and just write a "uniforms" plugin that just does uniform import/export like how the "orders" plugin works for manager orders.

[A_Curious_Cat]

Hi!  I’ve been having a few problems with autochop. 

The first problem is that it seems to designate way too many trees for felling.  On one of my previous forts, my stocks screen listed something like 25,000+ logs and my computer ground to a halt for at least five minutes when ever I cursored down to the line for logs.  I checked the autochop dashboard and it said that it was set to keep only a maximum of 100 logs on hand at a time.  Something is obviously going wrong here if autochop is ignoring it’s maximum limit.

I pulled up a test fort and set autochop to a maximum of 10 logs. Autochop did designate every tree for chopping, but as soon as my woodcutter had cut down enough trees, it undesignated every tree again. It seems to check every in-game day, so if you have a lot of woodcutters, this behavior might result in a few too many logs. I let it run for a couple more in-game days and it didn't designate any more trees, so it seems to be working on my end, at least over the short term.

There is a feature request here to limit the number of trees designated, but it hasn't been completed yet. There is also this one for an annual limit on trees chopped (to keep elves happy).

A couple questions:
- How old is this fort?
- What DFHack version are you using? (The version number from running "help" or in the options (Esc) menu is ideal.)
- Do you have enough logs that are accessible? (i.e. not forbidden, in jobs, etc). One possibility I can think of is that if a lot of logs are queued to be placed in a bin, autochop might not consider them as available, and could end up causing more trees to be cut down. The "z"-stocks screen would still show a lot of logs in this case.

It was less than 3 years old when it fell.
DFHack 0.47.05-r2
The fort’s been deleted to save space, so I can’t check any more.  I didn’t have any bins.

Edit:  I’m going to see what happens if I make sure that there’s only ever one woodcutter.

[DwarfStar]

I'm thinking of implementing a military uniforms importer/exporter (as per issue #651). What other military-related functionality would be useful? That is, if I built a "military" plugin, what would you want it to do?

If the answer is "not much", I'll probably keep it simple and just write a "uniforms" plugin that just does uniform import/export like how the "orders" plugin works for manager orders.

Not sure if this is the best way to express/handle this, but here's an idea. Could you modify the uniform application (or write an alternate one) so it optionally only changes armor and leaves the weapons alone? The reason is that I usually set the weapon for each unit manually, and applying a uniform erases all those choices. If I could leave the weapon choices in place, the uniform system would be a lot more useful.

[myk]

It is probably possible to apply a uniform while not touching weapons, but I want to understand a little more about what you're doing. I believe the usual flow is to assign uniforms first, and then specify weapon choices. How exactly are you accustomed to interacting with your military if you are assigning weapons first and then changing the uniform?

[Schmaven]

It is probably possible to apply a uniform while not touching weapons, but I want to understand a little more about what you're doing. I believe the usual flow is to assign uniforms first, and then specify weapon choices. How exactly are you accustomed to interacting with your military if you are assigning weapons first and then changing the uniform?

I too would find that useful.  I often assign members a weapon of their preferred type, then later being able to change everyone's cloaks around, or add / remove hoods, maybe force downgrade them from steel to bronze to kit out a higher priority squad... All those changes are independent of the weapon I want them to have.

[A_Curious_Cat]

Whelp!  I tried limiting my most recent fort to only one woodcutter.  I set autochop to a minimum of 100 logs, and a maximum of 120 logs (enough to fill up my four 5x6 wood stockpiles).  The fort fell to a major mining disaster, but the logs never went above 130.

[ldog]

Generally the idea is to create uniforms and then assign them to squads and then tweak individuals.
What other flow is there? I think people are misunderstanding (or maybe I am)
Myk is talking about making a utility so you can define the uniforms by config files instead of having to do them in game every time.
I used to do a steel uniform for every weapon, then I paired it down to 2, individual choice-melee & crossbow.
Right now I'm doing metal instead of steel.
Now I'm leaning towards going back to leather for crossbow.
If I didn't have to make all these uniforms by hand every new embark (enter utility) then I'd likely experiment with all that and more.

I can't see any need to ever have said utility actually try and touch live soldiers in a squad so the requests to ignore weapons seem pointless.

[ab9rf]

- Do you have enough logs that are accessible? (i.e. not forbidden, in jobs, etc). One possibility I can think of is that if a lot of logs are queued to be placed in a bin, autochop might not consider them as available, and could end up causing more trees to be cut down. The "z"-stocks screen would still show a lot of logs in this case.

I'm pretty sure that logs cannot be placed in bins.

It's possible that the job cancel bug I discovered the other day is involved here. My current test fort, which is running using the new job cancel method, does not exhibit the behavior that is being reported here; rather, it works as expected, autodesignating every tree on the map, and then undesignating them as soon as enough trees are cut down, as expected. But if the jobs are not cancelling properly (as I was seeing in my prior test fort), then it might continue to chop even though autochop tried (but failed) to cancel the jobs.

[ldog]

- Do you have enough logs that are accessible? (i.e. not forbidden, in jobs, etc). One possibility I can think of is that if a lot of logs are queued to be placed in a bin, autochop might not consider them as available, and could end up causing more trees to be cut down. The "z"-stocks screen would still show a lot of logs in this case.

I'm pretty sure that logs cannot be placed in bins.

It's possible that the job cancel bug I discovered the other day is involved here. My current test fort, which is running using the new job cancel method, does not exhibit the behavior that is being reported here; rather, it works as expected, autodesignating every tree on the map, and then undesignating them as soon as enough trees are cut down, as expected. But if the jobs are not cancelling properly (as I was seeing in my prior test fort), then it might continue to chop even though autochop tried (but failed) to cancel the jobs.

Please tell me it still leaves manually designated trees alone.

[lethosor]

Please tell me it still leaves manually designated trees alone.

As far as I can tell, autochop has never left manually designated trees alone. The point of the plugin is that it controls when trees get cut down, so it will designate or undesignate them as appropriate. ab9rf's work isn't changing that.

However, you can configure trees to be ignored (via burrows or disabling e.g. fruit trees in autochop settings), and those restrictions apply to both designating and undesignating trees.

[ldog]

Please tell me it still leaves manually designated trees alone.

As far as I can tell, autochop has never left manually designated trees alone. The point of the plugin is that it controls when trees get cut down, so it will designate or undesignate them as appropriate. ab9rf's work isn't changing that.

However, you can configure trees to be ignored (via burrows or disabling e.g. fruit trees in autochop settings), and those restrictions apply to both designating and undesignating trees.

Hmmm...I coulda swore it still left them. Dreamfort designates some trees for cutting, and then I usually throw in a few extra's I want done, and I tend to have autochop on. Possibly because I usually have more than the threshold at that point autochop doesn't activate?

Consider it a feature request then

[Bumber]

What's the deal with this syntax?

Code: [Select]

movzx   eax, ds:(byte_7FF67649E388 - 7FF676350000h)[rdx+rax]
mov     ecx, ds:(off_7FF67649E380 - 7FF676350000h)[rdx+rax*4]
Using IDA disassembler, where 7FF676350000h (and value in rdx) is the address of hInstance, byte_7FF67649E388 is the indirect table, and off_7FF67649E380 is the jump table.

I know "ds" is "data segment", but not why that expression is in the parentheses.

Is it starting at address 14E380h, then offsetting by rdx (7FF676350000h, resulting in byte_7FF67649E388 again,) then adding rax to that and moving the value there into eax? (With that value being an index for off_7FF67649E380?) Are my assumptions correct?

Why wouldn't it be something like "movzx eax, ds:(byte_7FF67649E388)[rax]" instead?