Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 143 144 [145] 146 147 ... 244

Author Topic: DFHack 50.14-r1.1  (Read 889046 times)

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2160 on: March 01, 2020, 05:14:53 pm »

Relocating a temple might be considered razing it, though.

No, an entity is an organization, such as a civ, site government, or religion. A HF (historical figure) is a creature, such as an elf.
Entities are actually rather simple, as they're never culled, so they're in df.global.world.entities.all
  • , where * is the number (4746, in this case).

The save after retiring is likely rather useless, unfortunately, as the unit (and its thoughts) are no longer present (a unit is a creature that's involved somewhat immediately with what happens in a fortress [and, I would assume, adventure mode]. HF's can also be units, but a lot of units are not, but rather faceless entities, such as wild animals and most members of invading forces. Non HF creatures become HFs when they make notable kills, though, such as an invader goblin killing one of your citizens).
Logged

Alatun

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2161 on: March 01, 2020, 05:47:18 pm »

Ok, got it: entity 4746 is called "The hall of Rock" - the "Guild of Farmers" of my dwarven community.
Logged

Roses

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2162 on: March 01, 2020, 07:09:43 pm »

- There's been a lot of mapping of the "shape" of structures, i.e. introduction of new, unidentified, fields to align structures so that fields previously known again contain the known contents, as well as new unidentified fields at the end of structures.
- Similarly, a lot of enum values have been located, and a fair number identified.
- A number of new fields and structures have been (partially) identified.
- There's been a fair bit of at least identification of new derived types, although the identification of the contents may be lagging behind.

If you've got an interest in a particular area, such as e.g. syndromes, you ought to be better suited than most to help in the identification of the fields within it. Things that those active in field identification are interested in ought to be more likely to be identified than things peripheral to their interests. The syndrome and interaction complex is a particularly messy area that I, personally, avoid unless I need to deal with it.

That's great, I was mainly concerned about the first part. As long as there are the correct alignments finding out what the unknown fields are can be kind of fun. I remember doing it for some of the army stuff last release. I will definitely start poking around in various places in a week or two. Syndromes and interactions are definitely more of a mess than some of the other stuff, but I'm hoping I'll be able to make some sense of them.

Edit: Here is a more specific question. The syndrom utility plugin that is used to add and remove syndromes, is that something that is going to need updating with the various new effects? Just wondering if I should start my research there or assume that it works and start research from there?
« Last Edit: March 01, 2020, 07:26:32 pm by Roses »
Logged

Atkana

  • Bay Watcher
  • [CURIOUSBEAST]
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2163 on: March 04, 2020, 04:32:01 am »

I've kept meaning to ask, is there a plugin or script available that disables the indoors requirement for furniture placement in fort mode? It's not fair that adventurers get to easily build all those nice outdoor rooms without having to temporarily build scaffolding over it / use tiletypes to set the areas as indoors for a frame so you can designate the placements :P

jecowa

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2164 on: March 04, 2020, 05:15:21 am »

I'm pretty sure I've built an altar outdoors when testing out graphics for the new items. I didn't realize an indoor requirement existed.
Logged

Atkana

  • Bay Watcher
  • [CURIOUSBEAST]
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2165 on: March 04, 2020, 06:25:31 am »

I'm pretty sure I've built an altar outdoors when testing out graphics for the new items. I didn't realize an indoor requirement existed.
Certain furniture (namely beds, tables, and chairs) are coded to not allow designating to build outside in fort mode. Most other furniture can be - and all can in adventure mode, as far as I know - it's just some weird restriction on a certain few :c

iceball3

  • Bay Watcher
  • Miaou~
    • View Profile
    • My DA
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2166 on: March 04, 2020, 06:51:26 am »

Do bridges count for roofing? If so that can help speed up your scaffolding setup before taking it down.
Logged

luisedgm

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2167 on: March 04, 2020, 08:41:55 am »

Hello, is there an ETA for the 47.04 version?
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2168 on: March 04, 2020, 10:59:59 am »

Hello, is there an ETA for the 47.04 version?
No. It's done when it's done.
Logged

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2169 on: March 04, 2020, 11:09:18 am »

If you'd like it to be ready faster, feel free to download one of the nightly builds linked in the first post and let us know if you run into any issues (just don't count on it being stable for actual gameplay!)
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

feelotraveller

  • Bay Watcher
  • (y-sqrt{|x|})^2+x^2=1
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2170 on: March 04, 2020, 01:18:54 pm »

Just as a point of interest I used the dfhack-0.47.03-beta1-200301001-Linux-64-gcc-7 build for a few days with 47.04 and had no problems - although I didn't use any of the dfhack 'hacking' functions (outside of the core) only information providers like prospect etc. and more or less the default dfhack-init  Which is not so say that I was expecting long term stability!

Just downloaded dfhack-0.47.04-alpha0-200303002-Linux-64-gcc-7 so that experiment ('histories of impatience and recklessness') has come to an end...
Logged

Alatun

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2171 on: March 05, 2020, 06:08:33 pm »

I've got a question regarding programming LUA scripts for dfhack. I hope this is the right place to ask.

First a rather specific one:
If you view the "Stocks" and press TAB the item list gets expanded. Items there are colored and according to the wiki, red items are "Not owned by the fort".
I'm interested in items in the category "Bars" or "Cloth"
In the list I see some white (traded items), a lot of dark yellow (created by the fort) and some red (not owned by the fort - e.g. if a caravan is currently at the depot). If you have opened a cavern already, uncollected spider silk cloth is also marked red.

How do I test an item, if is owned by the fort (which is NOT red) in the stocks list. Here is a small script I was using, to find all items that can be used for crafting.
Code: [Select]
local utils = require('utils')

for i,item in ipairs(df.global.world.items.all) do
if not item.flags.rotten and not item.flags.dump and not item.flags.forbid and not item.flags.construction then
if item:getMaterial() == df.builtin_mats.INORGANIC and item:getType() == df.item_type.BAR then
print(utils.getItemDescription(item,0))
end
end
end

I saw that there should be a flag "item.flags.owned". If I add this flag to the other flag checks, NO item will be printed. As I'm currently seeing items in dark yellow and red, there should always be printing something.
Code: [Select]
if item.flags.owned and not item.flags.rotten and not item.flags.dump and not item.flags.forbid and not item.flags.construction then

It seems, this flag is false for all items. Is this a bug? Does this flag represent something else? Is there another way to check the "owned" status? (I'm using DF 0.43.03 with DFHack 0.47.03-beta1).

Then a more general question. Is there a "useful resource" when looking for documentation regarding programming LUA in connection with DFHack.
I was looking at: https://dfhack.readthedocs.io/en/stable/docs/Lua API.html
and I'm currently browsing the available scripts already provided by DFhack. But this is quite cumbersome and may not always be lead to success.

some examples, where I was struggling to find a solution:

Code: [Select]
item:getMaterial() == df.builtin_mats.INORGANIC
What are other material types, I could check? I found "df.builtin_mats.COAL", but there should be much more.
I was looking for wood, leather, cloth, bone, glass, ....
 
I found a function
Code: [Select]
df.inorganic_raw.find(matIndex).material.state_name.Solid to get the material name for an inorganic item, if I have the materialIndex.

There are other "resources types" (cloth, thread, leather, bones,...) and was looking for a similar function to get the material name for "organic" materials, if I have the material index.
I found a global "df.material_common" which seems to get exported for DT, but I failed to get more information, what methods may be sent.


Any help is appreciated. Thanks in advance.
« Last Edit: March 05, 2020, 06:14:03 pm by Alatun »
Logged

HungThir

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2172 on: March 06, 2020, 03:05:36 am »

I saw that there should be a flag "item.flags.owned". If I add this flag to the other flag checks, NO item will be printed. As I'm currently seeing items in dark yellow and red, there should always be printing something.

...

It seems, this flag is false for all items. Is this a bug? Does this flag represent something else? Is there another way to check the "owned" status? (I'm using DF 0.43.03 with DFHack 0.47.03-beta1).

i don't know, but i believe, that the owned flag refers to whether some dwarf "owns" the item (as in, the clothes and trinkets they wear/carry around or stash in their bedroom), not whether it belongs to the fort.  if i'm right, i wouldn't expect to see this flag on craft materials like bars or cloth, so it would make sense that your script prints no items
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2173 on: March 06, 2020, 03:40:43 am »

Look at the item flags to try to figure out which ones you need.
in_job: already allocated, and so shouldn't be allocated again.
spider_web: Would include all the one in the caverns.
construction: used in construction, and thus not available.
encased: in magma. Obviously not available.
foreign: not made in the fortress.
trader: "owned" by traders. Sometimes set buggily on items that belonged to visitors that have ceased to be.
owned: belongs to someone, as HungTir said, and thus not available. I believe items carried/worn by visitors are owned by them as well.
artifact_mood: I assume this means in_job, but specifically for an artifact.

There are other flags that may be applicable for various purposes.
Logged

Alatun

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r3 | 0.47.03-beta1
« Reply #2174 on: March 06, 2020, 10:02:22 am »

Thanks for your response.

So it seems there is no item flag that has the information whether the item is owned by the fort (as being indicated by the stockpile color red) and I must check other states that might block access.

Look at the item flags to try to figure out which ones you need.
That's part of the general question above. Where should I look up such an information?

Logged
Pages: 1 ... 143 144 [145] 146 147 ... 244