Print

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

[Kurik Amudnil]

Sorry to bother you guys.
But i have used the exportmaps command, and I don't know WHERE it was exported or what is the name of those map files. I Have a working Isoworld (after FEW problems) but I don't know how to use it, it is probably so simple that they even don't write it in readme...

;___;
Help

I suppose that is some useful stuff to know that isn't quite as clear as it could be so I have updated the dffd description for exportmaps. 

[Ranalcus]

You area a SAINT person Dwarf!
Let the Armok bless you with his knowledge.
Even if I would be thanking you for a century, it still would be not enough to prise you.

EDIT:
When I upload the files extracted by DFhack into isoworld it CRASHes horribly.
Is there anyway to contact with the creator of that program? By Chat? IRC?

[Kurik Amudnil]

In an effort to figure out how to calculate the thickens body size, I have deciphered much about the unknowns in the body plan structure and am trying to put together a function for calculating the thickens body size.  However I run into a block where I can't determine in code if a layer's tissue has [THICKENS_ON_ENERGY_STORAGE] and/or [THICKENS_ON_STRENGTH].  I suppose I could get around this if I ignore the edge case of a tissue that has both since there are no vanilla tissues that do, but I would prefer to do it right just in case a mod uses the edge case.  Therefore, my question is, is it possible to read the binary form of the tissues "userdata" structure in raws.creatures.all[].tissues[] ? 

[Urist Da Vinci]

If unit.body.unk494 has an offset of 0x494 in the unit data, and therefore unit.body.blood_count has an offset of 0x490 because it is an int32, what is the offset to the members of unit.body.physical_attr_tissues? I am still trying to wrap my head around the compound, array, vector, and pointer differences.

See this for reference: https://github.com/angavrilov/df-structures/blob/master/df.units.xml#L551

[Kurik Amudnil]

If unit.body.unk494 has an offset of 0x494 in the unit data, and therefore unit.body.blood_count has an offset of 0x490 because it is an int32, what is the offset to the members of unit.body.physical_attr_tissues? I am still trying to wrap my head around the compound, array, vector, and pointer differences.

See this for reference: https://github.com/angavrilov/df-structures/blob/master/df.units.xml#L551

I think that physical_attr_tissues would start at 0x474

6 int32 from physical_attr_tissues, 1 int32 (blood_max), 1 int32 (blood_count) = 8 int32 = 32 bytes = 0x020
0x494 - 0x020 = 0x474

It has been a while since I learned about c/c++ and haven't used it much so I could be wrong about that.

[Telgin]

I got 0x474 too.  Each int 32 is 4 bytes, each pointer (for 32-bit memory addresses, which all inside DF will be) is 4 bytes and each STL pointer is 12 bytes (3 pointers grouped together, if memory serves).  Arrays can be viewed a few different ways, but for the static-arrays in the documentation just multiply the count by the size of its data type.  So an array of 6 int32s is 24 bytes.  For a dynamic array that only stored a pointer to the first element, it would just be like any other pointer, but I don't think that comes up anywhere in the DF structures since Toady uses STL vectors in place of them.

[Kurik Amudnil]

I guess I am ready to post my finding from investigating the body plan structure:

Spoiler: Wall of text (click to show/hide)

body_plan.body_parts[].layers[] (body_part_layer_raw)

layer.unk2 is percent of body part that is composed of this layer to 3 decimal places as an integer (percent * 1000)
   given a tissue layer definition with relative thickness 1 (hair) : 1 (skin) : 5 (fat) : 50 (muscle) ; total relative thickness = 57 ;
   then unk2 for the hair layer is 1000 * 1/57 = 34 ; for the fat layer 1000 * 5 / 57 = 87 ; for the muscle layer 1000 * 50 / 57 = 877

layer.flags[0] is true when tissue has [CONNECTS]
layer.unk10 is the index in the local layers[] to the tissue layer that this layer is subordinate to
layer.unk11 is the layer_id of the afore-mentioned suboridnate to layer
layer.unk15 is an assigned id for when the tissue is [STYLEABLE]


body_plan.body_parts[]   (body_part_raw)
body_part.unk2      sum of .unk3 .unk4 .unk5 ;
body_part.unk3      percent of body part that is not affected by [THICKENS_ON_ENERGY_STORAGE] or [THICKENS_ON_STRENGTH] ; (percent * 1000) ;
body_part.unk4      percent of body part that is affected by [THICKENS_ON_ENERGY_STORAGE] ;
      sum of layers[].unk2 whose tissues [THICKENS_ON_ENERGY_STORAGE] ;
      layer.unk2 / 2 if both [THICKENS_ON_ENERGY_STORAGE] and [THICKENS_ON_STRENGTH] ;
body_part.unk5      percent of body part that is affected by [THICKENS_ON_STRENGTH] ;
      sum of layers[].unk2 whose tissues have [THICKENS_ON_STRENGTH] ;
      layer.unk2 / 2 if both [THICKENS_ON_ENERGY_STORAGE] and [THICKENS_ON_STRENGTH] ;

Even though unk4 and unk5 split the layer.unk2 in half when both thickens are set, the thickened size uses the full layer.unk2 for both thickness adjustments.  Thus I suspect that the game doesn't really use bodypart unk2-5 except for the insulation below.

body_part.insulation_muscle   (fat)    sum of layers[].unk2 * tissue insulation value / 1000 when has [THICKENS_ON_ENERGY_STORAGE]
body_part.insulation_fat   (muscle)   sum of layers[].unk2 * tissue insulation value / 1000 when has thicken on strength
body_part.insulation_base   (hair)   sum of layers[].unk2 * tissue insulation value / 1000 when neither thickens flags are set

I found that insulation_muscle and insulation_fat are backwards.

body_plan (caste_body_info)

body_plan.unk8      sum of body_parts[].relsize if body_part.flags not INTERNAL and not EMBEDDED (not affected by body_parts[].number > 1)
body_plan.unk15a   sum of body_parts[].unk2 (total)
body_plan.unk15b   sum of body_parts[].unk3 (neither)
body_plan.unk15c   sum of body_parts[].unk4 (fat)
body_plan.unk15d   sum of body_parts[].unk5 (muscle)

None of the unk15 are affected by body_parts[].number > 1.  Also, these unk15 values make no mathematical sense to me since the body_part.unk2 through unk5 are relative to that part and not all parts are of the same relative size.  It is similar to saying 2x + 3y = 5something , it doesn't work.

[Urist Da Vinci]

unit.appearance.unk_4c8  is the effective body appearance modifier (percent), default is 100.  This effective body modifier is the result of combining the body size modifiers in unit.appearance.body_modifiers[] .
...

unit.flags3.unk1=false causes unk_4c8 to be "calibrated/calculated" and sets itself to true when complete.

The part of the game that makes changes to unit.body.physical_attr_tissues draws on info from the race's creature_raw, specifically 0x128 and 0x12c. Here are links to the creature_raw part that I am talking about, but I don't know what info is being targeted because the offsets aren't labelled in df.creature-raws.xml.
https://github.com/angavrilov/df-structures/blob/master/df.units.xml#L339
https://github.com/angavrilov/df-structures/blob/master/df.creature-raws.xml#L954

The part of the game that makes changes to unit.body.physical_attr_tissues also draws on some sort of time number (I know this only because 403200 appears in there), the effective body appearance modifier unk_4c8, and unit.counters2.stored_fat. It also appears to have some kind of default size and blood count of 7000 to initialize variables.

EDIT: I think it also looks at the body_plan info that Kurik found, at the unit.body.body_plan offsets 0xa0, 0x94, 0x98, and 0x9c, whatever those are.

[ag]

You cannot assume that "unk494" means it starts at 0x494 - that's just a name. For one, it is different between linux and windows. The address is just a convenient way to initially assign a name that doesn't conflict with anything else, rather than manually counting what number is next when using the unk1,unk2,unk3... etc pattern.

For actual offsets see the csv files: https://github.com/angavrilov/df-structures/tree/master/windows

[Kurik Amudnil]

unit.appearance.unk_4c8  is the effective body appearance modifier (percent), default is 100.  This effective body modifier is the result of combining the body size modifiers in unit.appearance.body_modifiers[] .
...

unit.flags3.unk1=false causes unk_4c8 to be "calibrated/calculated" and sets itself to true when complete.

The part of the game that makes changes to unit.body.physical_attr_tissues draws on info from the race's creature_raw, specifically 0x128 and 0x12c. Here are links to the creature_raw part that I am talking about, but I don't know what info is being targeted because the offsets aren't labelled in df.creature-raws.xml.
https://github.com/angavrilov/df-structures/blob/master/df.units.xml#L339
https://github.com/angavrilov/df-structures/blob/master/df.creature-raws.xml#L954

The part of the game that makes changes to unit.body.physical_attr_tissues also draws on some sort of time number (I know this only because 403200 appears in there), the effective body appearance modifier unk_4c8, and unit.counters2.stored_fat. It also appears to have some kind of default size and blood count of 7000 to initialize variables.

EDIT: I think it also looks at the body_plan info that Kurik found, at the unit.body.body_plan offsets 0xa0, 0x94, 0x98, and 0x9c, whatever those are.

Interesting.  403200 is one year.  7000 as an init is probably related to humans, I think I remember some place saying that humans were used as a base line.  At the moment, my thickens size calculation is using body_plan.unk8 (body relative size without embedded and/or internal) which I think is at offset 0x40, store_fat, STRENGTH.value, body_part.relsize, body_part.unk4 and unk5 in the absence of accessing the tissue data, and the body size.  I calculate the body size (physical_attr_tissues[1]) with the creature raws .caste.body_size_1 and body_size_2, and the unit.appearnce.unk_4c8.  My thickens calc is coming along.  I have it giving a valid result for thickens on strength, and almost have it right for thickens on energy.  I seem to be missing a ratio.

body plan 0x94 should refer to anon_1 ; 0x98, 0x9c, and 0xa0 should refer to the materials.mat_type vector.
I think that creature_raw 0x128, 0x12c, and 0x130 is the caste vector (type caste_raw).

You cannot assume that "unk494" means it starts at 0x494 - that's just a name. For one, it is different between linux and windows. The address is just a convenient way to initially assign a name that doesn't conflict with anything else, rather than manually counting what number is next when using the unk1,unk2,unk3... etc pattern.

For actual offsets see the csv files: https://github.com/angavrilov/df-structures/tree/master/windows

I suppose my offset interpretations might not line up then, struck em out (if anyone cares, i am using the windows version).

[Urist Da Vinci]

Did more testing with some liposuction and force-feeding by altering unit.counters2.stored_fat between 1000 and 1000000. Also tried altering the (actual) strength attribute value.

Turns out that creatures with unit.flags3.unk1=false (old or young) also happen to be immune to size (physical_attr_tissues[0]) changes from alteration to muscle or fat. They can also walk around with an incorrect hacked unit.appearance.unk_4c8 and it doesn't change or matter.

Creatures with unit.flags3.unk1=true, which happen to grow properly, will change size within a few ticks, and their unit.appearance.unk_4c8 will recalculate to a correct value.

However, the flag is NOT the cause of the problem but rather another symptom. The evidence indicates that the size calculation function is being bypassed completely for some creatures, regardless of if they are growing or not. If the bug was fixed, all your old lazy corpulent dwarves would suddenly gain a few belt notches and move slower due to their increased size.

On another topic, the game appears to use unit.body.body_plan.unk15c and unit.body.body_plan.unk15d to determine if a creature has ANY fat or muscle in its body - it checks if the numbers are greater than zero.

[Meph]

I have a question, or more of an idea:

A way to make only a specific mat digable by a specific item. Example:

ITEM_SHOVEL only digs inorganics with [REACTION_CLASS:SHOVEL]
ITEM_PICK only digs inorganic with [REACTION_CLASS:SHOVEL] and [REACTION_CLASS:PICK]
ITEM_DRILL only digs inorganics with [REACTION_CLASS:SHOVEL] and [REACTION_CLASS:PICK] and [REACTION_CLASS:DRILL]

This would make mining a lot more interesting, with cheap shovels (wood), expensive picks (metal), and custom made drills (ore/slade). Also nice for other races, Kobolds only get shovels, can only dig soil...

How feasable is this?

[foop]

Does workflow understand making clay bricks yet?  About halfway through this thread, back in June 2012, someone tracked the problem down to workflow not knowing how to handle the FIRED_MAT mask on the input to the reaction. 

Is this still the case or is there now some clever way of including brick making into workflow?

[Warmist]

I have a question, or more of an idea:

A way to make only a specific mat digable by a specific item. Example:

ITEM_SHOVEL only digs inorganics with [REACTION_CLASS:SHOVEL]
ITEM_PICK only digs inorganic with [REACTION_CLASS:SHOVEL] and [REACTION_CLASS:PICK]
ITEM_DRILL only digs inorganics with [REACTION_CLASS:SHOVEL] and [REACTION_CLASS:PICK] and [REACTION_CLASS:DRILL]

This would make mining a lot more interesting, with cheap shovels (wood), expensive picks (metal), and custom made drills (ore/slade). Also nice for other races, Kobolds only get shovels, can only dig soil...

How feasable is this?

Hardish: you could cancel active dig jobs if worker does not have correct item (and issue a message). That would be annoying as mining under lava to some extent. Also because there is limited way to select who does what you will have problems with mining equipment. That said there is already a system that detects new jobs, although it is not accessible through lua so i can't help you there.

[Meph]

Thanks warmist. I still hope for some sort of solution. I want to merge all my playable races into one world-gen, but the kobolds can only dig soil. I did this by adding UNDIGGABLE to the stone-template when playing as kobolds. But you need a new worldgen to remove it, so I cant play kobolds, retire the camp, then play dwarves...

I would even be ok with removing digging in its entirety from one race, if possible.

Another idea: Can a screwpump by copied, just without the need for water underneath it? Essentially a pump-workshop that just spawns the water/magma on one end. It would be so much better then the current system for water/magma spawning.