Print

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

[Rumrusher]

so poking around unit enemy 4406_1 flags I ended up finding out that the flag 57 is the toggle for if the unit can talk or not.
which means with a dfhack script you can give anyone the ability to fly, and talk.
but if the creature it self can't talk then you can't talk and this set up won't work.
though I did found out you can just bypass that block by looking at stuff in adventure mode and while looking use dfhack to switch the advmode_ui menu from look to conversationaddress which brings up the talk menu.

[Schmaven]

What do you mean by "exist"? Are you looking for the animals on the map, or animals that could appear on the map? Regular creatures or vermin? Is this before or after embarking?

My goal is to capture certain regular animals.  Before or after embarking would both be okay as I could simply abandon the fort and re-embark if those animals were not amongst the expected groups that wander in from time to time. 

[PatrikLundell]

@Schmaven: I would guess you're looking for region-pops. If I remember correctly, the script finds the populations of plants and creatures in a 7*7 world tile area centered at the embark, which means some of them area actually out of reach (you can e.g. get ocean creatures in the list because there's an ocean 3 world tiles away).

Schmaven posted while I wrote this:
I'm not aware of any script that shows what's actually available to an embark. You could use the Biome Manipulator http://www.bay12forums.com/smf/index.php?topic=164658.msg7495705#msg7495705 to find the information by looking at each of the regions that are present on your embark (prior to embarking you can't know whether biomes present in neighboring mid level tiles will spill over into your intended embark rectangle or not). You can also use the Biome Manipulator to add creatures/plants you'd like to have as potential visiting groups if they're missing.

[Rose]

Is there an issue with the build system currently?

Also, is there a way to tell if a copy of DFHack is compiled for GCC 4.8 or 7? (From within DFHack)

[lethosor]

An issue with what specifically?

I don't believe there's a way to tell those apart.

[Rose]

The last build on my PR failed on linux because of an unmet dependency of some sort. I didn't change anything that would effect that.

[lethosor]

If you mean buildmaster, looks like the last build failed on the older Linux because it's using python 3.4, which Sphinx doesn't support anymore.

[Rose]

That's exactly what I was meaning.

[DerMeister]

I need know hardcoded properties of ballista arrow and catapult rock.

[risusinf]

Someone with a tag I can't catch (ruisuif or something like that)

That would be me.

I expect those structures to exist only when viewed

Seems to be true. I was able to put a debugger breakpoint on the function that populates equip lists, but i don't really know how that memory mapping thing is done, what can i do from there?

[PatrikLundell]

Sorry for not getting your tag correctly, risusinf, but I have a problem with some tags just not sticking, and though it better to give imperfect credit than none at all.

If you've managed to put a breakpoint at the function, it ought to be possible to read the assembly code to locate (with the help of the debugger, of course) the addresses of the structures the code looks at (my first guess is that those structures would be vectors the code then iterates over). With that in hand I'd try to iterate over all DFHack mapped structures, e.g. with a DFHack script, to find a matching address. If such an address match is found, I'd then identify the DF structure path to the structure(s).
However, there's a significant risk the structures DF populates the UI from haven't been mapped by DFHack, but we may be lucky to get unk_X matches.

[risusinf]

Thanks, i might try to figure that out at some point. I'll go with other, much more feasible insights for now.

[Pvt. Pirate]

can someone finally fix the mousequery bug?
now with a 16:9 monitor, i can say the "mousequery edge" bug is not dependant on resolution.
it is well explained in its symptoms and exists ever since 44.9 (and there was a possible fix until 44.10, which got dropped)
all tilesets and mods move towards 44.12 and it's a pita (and most times impossible) making them work on 44.9.

[lethosor]

can someone finally fix the mousequery bug?
now with a 16:9 monitor, i can say the "mousequery edge" bug is not dependant on resolution.
it is well explained in its symptoms and exists ever since 44.9 (and there was a possible fix until 44.10, which got dropped)
all tilesets and mods move towards 44.12 and it's a pita (and most times impossible) making them work on 44.9.

Please link to a description of the bug. I've seen you mention it as if everyone knows about it several times, but I can't find a complete description of the problem you're having easily, and can't even attempt to fix it without one. The DFHack bug tracker (linked in the first post) would be the best place to report it in any case.
Some important information to include is what exact builds of mousequery you are using, both when you see the issue and when you don't. I know TWBT used to distribute its own. If you can give that information, I can try to compare the source code and look for any obvious causes, but I'm fairly confident that the merge back into DFHack was done correctly and there should be no functional differences.
And regarding "finally", it's not like we've been intentionally not fixing it to annoy you. We all work on DFHack in our free time, and I have had very little of that recently.

Edit: ok, some Googling turned up some posts. It sounds like mousequery edge "doesn't work" on the right or bottom side of the screen. Is this correct? If so, some follow-up questions:
(a) What exactly are you doing that works in some places and not in others? I have never used this feature, so I need to know exactly how to make it work. It's not entirely intuitive for me. Are you left/right/middle clicking/hovering over the edge of the window? Answer: hovering, but it needs "mousequery edge enable" to enable. "mousequery edge" isn't enough.
(b) Do you have intro movies turned off?
(c) Are you ever resizing the game window? If not, does resizing it fix the issue? (Exit fullscreen mode if you have to.)
(d) Can you provide links to the mousequery.plug.(dll/so/dylib) files that (i) work and (ii) don't work?
(e) What tileset are you using? Is it square or rectangular? If it's not a vanilla tileset (curses 8x12 or 16x16), can you try one of those and see if it works?
(f) Are you using TWBT? If so, does disabling TWBT entirely help?

[Pvt. Pirate]

sorry for having been rude.

you found the description before I started searching.
i can't link you to the old version, as i do not have a link myself.
i could upload the 44.09 version of mousequery that works, but i do not know if its the one from twbt or not.
a) it is enabled by that command and doesn't work correctly also if it weren't enabled, the scrolling on top and left side wouldn't work either, but those work.
b) movies off - always
c) i usually don't resize window. i never use fullscreen either.
d) (i) working one https://www.dropbox.com/s/v3gjhco764p28uw/mousequery.plug.so?dl=0 (ii) not working http://www.bay12forums.com/smf/index.php?topic=163211.0 and http://www.bay12forums.com/smf/index.php?topic=161047.0 (as tested both on my LINUX-PC and the Win8-Laptop of a friend)
e) Mephs lite + curses 800x600 font // Phoebus + curses 800x600 font
f) TWBT always on testing turning it off, but i think i remember it not changing a thing.