Print

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

[lethosor]

Hmmm, I just checked one of my active reclaimed forts, df.global.world.world_data.active_site.entity_links and looked at the bottom of the list, numbers list the site id and relevant entity, usually player created/claimed site groups are near or at the end, went to that entity and grabbed this shot:

Spoiler (click to show/hide)

Isn't that it?

Yeah. Is that in assignments? I couldn't find it in assignments_by_type.

Oh yeah! Is there a simple way to recenter a screen on a unit or whatnot that I'm just a moron and overlooked? I couldn't figure out dfhack.screen.zoom() syntax at all though I tried feeding it my unit position, cursor position, unit id, and a couple other things.

dfhack.gui.revealInDwarfmodeMap() (it takes a df.coord, I believe). dfhack.screen.zoom() zooms the screen in and out.

Hmmm, there's an update screen check too isn't there? Was annoying trying out a "teleport to the cursor" hotkeyable script because if you have the cursor out of view you have to move before it will refresh your screen fully. Even tried having it just straight up list that tile as revealed through the dfhack.maps.getTileBlock(blah).designations[xmath][ymath] stuff with no luck.

Some tools that need that just feed CURSOR_DOWN_Z and CURSOR_UP_Z to the dwarfmode screen, although that doesn't work at the lowest z-level. I've been meaning to add something to the Gui module to handle that appropriately.

Yes it was... I couldn't find it anywhere online... but its just a basic repeating script... It works, its set to 2000 ticks if I understand it correctly, and in fortress mode that's just about perfect timing, I couldn't tell you how "optimized" it is.  Here you go:

Is there a reason why MDF needs it? I'm fine with including it, but I don't want to enable it by default unless it fixes something that comes up in vanilla often.

Edit: also, I don't see anything particularly wrong with the formatting...

yeah I had, and on abandon, it reset the counter when I claimed a new site on the same map.  I can try and do some more testing but It may be next week and I'll get back to you.  I've got a load of things I'm trying to accomplish between today and monday, so when I can, its back on my list.  I don't want to have to fix that set of scripts anymore...

Weird. I don't see an obvious reason why it would be doing that. I'll look into it, though.

[Amostubal]

Yes it was... I couldn't find it anywhere online... but its just a basic repeating script... It works, its set to 2000 ticks if I understand it correctly, and in fortress mode that's just about perfect timing, I couldn't tell you how "optimized" it is.  Here you go:

Is there a reason why MDF needs it? I'm fine with including it, but I don't want to enable it by default unless it fixes something that comes up in vanilla often.

Edit: also, I don't see anything particularly wrong with the formatting...

simply put its not a vanilla issue as much as its a modder issue.  Basically any time you produce gloves from reactions they are unhanded.  so if you mod a lot of reactions in as MDF has, multiple times (craft full armor sets, mass productions, custom shops, specialty glove sets, etc.), this fixes that without having to add a reaction-trigger for every reaction that has gloves to run a correction.  I was just surprised, it wasn't a part of the repo, and I yeah I wouldn't have it enabled by default.

really it just needs some documentation added to it on the second part... thats what I meant for about not being DFHack-esque.

[Max™]

Hmmm, I just checked one of my active reclaimed forts, df.global.world.world_data.active_site.entity_links and looked at the bottom of the list, numbers list the site id and relevant entity, usually player created/claimed site groups are near or at the end, went to that entity and grabbed this shot:

Spoiler (click to show/hide)

Isn't that it?

Yeah. Is that in assignments? I couldn't find it in assignments_by_type.

entities[k].positions.own had that, .assignments just lists the histfig that it's linked to, never even thought to check assignments_by_type actually.

Oh yeah! Is there a simple way to recenter a screen on a unit or whatnot that I'm just a moron and overlooked? I couldn't figure out dfhack.screen.zoom() syntax at all though I tried feeding it my unit position, cursor position, unit id, and a couple other things.

dfhack.gui.revealInDwarfmodeMap() (it takes a df.coord, I believe). dfhack.screen.zoom() zooms the screen in and out.

That'll work even if not in dwarf mode?

Hmmm, there's an update screen check too isn't there? Was annoying trying out a "teleport to the cursor" hotkeyable script because if you have the cursor out of view you have to move before it will refresh your screen fully. Even tried having it just straight up list that tile as revealed through the dfhack.maps.getTileBlock(blah).designations[xmath][ymath] stuff with no luck.

Some tools that need that just feed CURSOR_DOWN_Z and CURSOR_UP_Z to the dwarfmode screen, although that doesn't work at the lowest z-level. I've been meaning to add something to the Gui module to handle that appropriately.

Yeah, I was trying to work out if I was just missing something or what, but then the lua api didn't mention anything remotely like what I was after.

[lethosor]

dfhack.gui.revealInDwarfmodeMap() (it takes a df.coord, I believe). dfhack.screen.zoom() zooms the screen in and out.

That'll work even if not in dwarf mode?

I wouldn't expect it to work in adventure mode, but I haven't checked.

I got the CURSOR_UP_Z / CURSOR_DOWN_Z idea from gui/liquids.lua. There are a couple plugins that use it too (mousequery?).

[expwnent]

Old thread locked to avoid confusion.

[necros]

Hello, wasn't sure where to put this and I haven't see anyone talk about this, but can someone explain why doors, tables and I guess other furniture are built with coke when they are put down in planning mode?
By coke, I mean they haul bars of coke to the location and then create a door or table from scratch!  I can deconstruct it and I get bars of coke back...  I've never seen this behaviour before.

Planning mode was working normally a while ago where it would wait until I'd build the funiture item and then a dwarf would go haul the constructed item to the spot and install it.  But suddenly (and I'm not sure exactly when as 'coke bar' furniture looks like gabbro) any planned furniture immediately gets made out of coke bars...  and it's always coke bars.  Any ideas?

[lethosor]

I haven't seen that happen before. What DFHack version are you using?
Edit: I can't reproduce it in DFHack 0.43.05-r1, even if there aren't any tables available (and coke bars are available).

[necros]

Right, sorry I should have said all the technical stuff

I'm using the LNP (PeridexisErrant's Starter Pack 0.43.05-r03) which has DF 43.05 along with DFHack 0.43.05-r1 (thread: http://www.bay12forums.com/smf/index.php?topic=126076.0)

To be clear, I have the min quality set to ordinary and filter set to *any.  I have say 4 beds prebuilt.  I place 1 bed down in planning mode and a dwarf hauls a bar of coke over.

I don't think this happens on a new game.  I feel like I did something at some point that triggered this behaviour because it reliably does this as soon as I load up the save (even if I already have the furniture constructed).  But when I load an earlier save, it doesn't happen and dwarfs will wait until I construct a bed even if there is coke bars available.

I tried forbidding all my coke bars from the stocks screen.  When they are forbidden, dwarfs properly use normal constructed beds.   After unforbidding, it seems this has fixed the behaviour...  Very strange!!!  I'll post again if anything interesting happens...

[lethosor]

Right, sorry I should have said all the technical stuff

I'm using the LNP (PeridexisErrant's Starter Pack 0.43.05-r03) which has DF 43.05 along with DFHack 0.43.05-r1 (thread: http://www.bay12forums.com/smf/index.php?topic=126076.0)

Thanks
I asked because DFHack 0.43.05-alpha3 had several bugs related to planning mode (and other things) - planned buildings disappearing instantly or being unbuildable, for example.

To be clear, I have the min quality set to ordinary and filter set to *any.  I have say 4 beds prebuilt.  I place 1 bed down in planning mode and a dwarf hauls a bar of coke over.

I don't think this happens on a new game.  I feel like I did something at some point that triggered this behaviour because it reliably does this as soon as I load up the save (even if I already have the furniture constructed).  But when I load an earlier save, it doesn't happen and dwarfs will wait until I construct a bed even if there is coke bars available.

I tried forbidding all my coke bars from the stocks screen.  When they are forbidden, dwarfs properly use normal constructed beds.   After unforbidding, it seems this has fixed the behaviour...  Very strange!!!  I'll post again if anything interesting happens...

Yeah, that is weird. Let us know if you can reproduce it again, and upload the save if you can.

[MLP Pandemic]

Absolutely fantastic. Please accept a gift of hundreds of sacrificed elf buttocks encircled with a useless mineral.

[krisslanza]

If you use the autoassign DFHack thing from LNP, how does it actually decide when to let things Fish? If I try to manually assign labors, it naturally unassigns them, and I'm not sure how to make it turn someone to fishing.

Or should I just turn that hack off and do it the old fashion, manual way?

[lethosor]

If you use the autoassign DFHack thing from LNP, how does it actually decide when to let things Fish? If I try to manually assign labors, it naturally unassigns them, and I'm not sure how to make it turn someone to fishing.

Or should I just turn that hack off and do it the old fashion, manual way?

"The autoassign DFHack thing" is vague, although since you mentioned labors, I assume you mean labormanager (which is similar to autolabor, but different). I think if you mouse over that option in PyLNP, you'll get a tooltip with a more descriptive name, but I haven't tried.

From the labormanager docs, it sounds like there are a couple things you need to do:
- Have a fishery
- Run "labormanager allow-fishing" in the DFHack console (and pay attention to the warning: "This tends to result in most of the fort going fishing")

[krisslanza]

If you use the autoassign DFHack thing from LNP, how does it actually decide when to let things Fish? If I try to manually assign labors, it naturally unassigns them, and I'm not sure how to make it turn someone to fishing.

Or should I just turn that hack off and do it the old fashion, manual way?

"The autoassign DFHack thing" is vague, although since you mentioned labors, I assume you mean labormanager (which is similar to autolabor, but different). I think if you mouse over that option in PyLNP, you'll get a tooltip with a more descriptive name, but I haven't tried.

From the labormanager docs, it sounds like there are a couple things you need to do:
- Have a fishery
- Run "labormanager allow-fishing" in the DFHack console (and pay attention to the warning: "This tends to result in most of the fort going fishing")

On LNP it specifically calls it "Automatic Job Assignments", which seems to just automate labor assignments.
Thanks though. Guess I'll just need to stop being lazy and actually manually assign things instead of just having it on automatic...

[Snafu]

If you don't have a fishery no dwarves will autofish..

[Moonshine Fox]

I can't find anything about this in any bug tracker or thread about DFHack, but planning mode seem to be utterly broken.

Steps to reproduce:

Start a new fort.
Dig in/down to be inside.
b-b to build a bed.
P to switch to planning mode.
Place bed, instant segfault.

Code: [Select]

dfhack: line 66: 16014 Segmentation fault      (core dumped) setarch i386 -R env LD_PRELOAD="$PRELOAD_LIB" ./libs/Dwarf_Fortress "$@"
Any ideas? Is it something I'm missing to install, or is this a DFHack bug? I'm running 64 bit Arch Linux with multilib libraries installed.
DFHack version 0.43.05-alpha4 (release) on x86_64
DF is version 0.43.05-4 on x86_64