Print

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

[Isngrim]

PTW

[Roses]

Full breakdown of the attack action. Note that the unk_4.unk_10 and unk_4.unk_14 fields are the only two things I have no ideas about. The seem to be nonesense, but I doubt that is the case. They could possibly be related to very specific circumstances.

• target_unit_id = Target unit id
• unk_4 -> Wrestling Vector
  • wrestle_type = -1 if not a wrestling attack, 1 if a grab, 0 if anything else (throw, break, slam)
  • unk_4 -> Attackers body part id (-1 if wrestling with an item)
  • unk_6 -> Defenders body part id (-1 if targeting an item with wrestling)
  • unk_8 -> Attackers item id (-1 if wrestling with a body part)
  • unk_c -> Defenders item id (-1 if targeting a body part with wrestling)
  • unk_10 -> No freaking clue, possibly related to breaks
  • unk_14 -> Again, no clue
• attack_item_id = Attack item id (-1 if attacking with a body part)
• target_body_part_id = Target body part id
• attack_body_part_id = Attack body part id (-1 if attacking with an item)
• attack_id = Attack id
• unk_28 -> Ease of strike (e.g. Fairly Easy, etc...)
• unk_2c -> Level of connection (e.g. Connects Squarely, etc...)
• unk_30 -> Attack velocity
• flags = Based off of attack_id, attack_body_part_id, target_body_part_id, and type of attack (Wild, Heavy, etc...). Comes in groups of numbers, exact meaning of the number and it's effect is unknown.
• unk_38 -> Body part attack skill
• unk_3c -> Attack hit chance
• timer1 = Preparation timer
• timer2 = Recovery timer

[Putnam]

I'm reasonably sure the flags were fully mapped out by IIRC me and Quietust about a year ago (earliest stuff relating to ki in Sparking was April 2015, and that's when I figured out unk_30 and the flags IIRC)

[Roses]

I'm reasonably sure the flags were fully mapped out by IIRC me and Quietust about a year ago (earliest stuff relating to ki in Sparking was April 2015, and that's when I figured out unk_30 and the flags IIRC)

Well, from my little work you get things like flags = 4 is a normal bite attack against body parts <= 15, flags = 5 is a normal bite attack against body parts > 15, flags = 6 is a normal grasp attack against body parts <= 15 and flags = 7 is a normal grasp attack against body parts > 15. 1030 and 1031 are normal stance attacks against body parts <= 15 and > 15 respectively. This is true, at least, for dwarves, where 36, 37, 38, 39, 1062, and 1063 are the corresponding flag numbers for quick attacks. It's possible that all the numbers are filled in by different attack types from different units or that there are intentional gaps. I don't know. If you know more please do share. Right now I can't seem to find any difference in outcomes when I change the flags number from one thing to another without changing other values.

[Roses]

Just some final research to wrap up the attack research I have been doing. This will reference Urist DaVinci's (UDV) work which can be found here and here. Note that his work and this work has all been done in DF 40.xx. I am unsure how much has changed with combat in 42.xx, but will be doing similar research to double check everything when I start using 42.xx.

1. The velocity UDV found is not the same as the velocity input into attack_velocity(unk_30). Instead it is some factor of that velocity, capped at the velocity. This is dependent on skill, strike ease, level of connection, and random factors. With, on average, greater skill, greater striking ease and greater level of connection resulting in higher velocities.

2. UDV didn't post any results for hit chance from his dissasembly reading, but from what I have found, all of the factors that influence the velocity are the same as those that influence attack_accuracy (unk_3c). Even the randomness found in the attack_velocity is the same randomness found in attack_accuracy. This means that whatever random roll is made is applied to both, instead of a different roll for each. The main difference between attack_velocity and attack_accuracy is attack_accuracy does not seem to be capped, instead increasing linearly with skill.

3. Type of attack and multipliers

Code: [Select]

         velocity     accuracy
normal       x1          x1
quick        x0.5        x1
heavy        x1.5        x1
wild         x1.5        x0.75
precise      x1          x1.5
Ending Note:
The actual equation that determines attack_accuracy is still unknown, but suitable temporary value ranges can be found numerically. In the future I may attempt to find an actual equation like UDV has done for attack_velocity.

Next up for research:
With the inclusion of emotion changing syndromes I plan on using 42.xx to test the various numbers in unit.current_soul.personality.emotions and determine how they translate from the syndromes to the structures. In addition I hope to test the effects these emotions have on units. Possibly even seeing if the emotional state has any effect on combat (besides the extreme states where the unit "flees in terror" and such).

[Putnam]

attack_velocity is capped at 10000 IIRC

Sparking can bring it up to... I think I cap it off at 2000000000. It has proper effects there, too, sending even larger opponents flying.

[Roses]

attack_velocity is capped at 10000 IIRC

Sparking can bring it up to... I think I cap it off at 2000000000. It has proper effects there, too, sending even larger opponents flying.

Ah yes, that is important to note. The game caps the attack_velocity at 10000 when calculating it, but larger numbers (if put in manually or via script) do have an effect. As far as I can tell it is a linear effect, although to figure that out exactly it would require many more tests than I have done.

[expwnent]

Great work!

[Max™]

In case anyone knows more about working with offsets, when you pull up the world_data screen in gm-editor there is a region_map entry but it never changes and doesn't have a list so I can't manually make it open region_id[k] or whatnot, but playing with the offsets option (thank you for putting that in, whoever added it, it's exactly the kind of derpy vaguely dangerous thing I like to play with!) I was able to determine that 1 through 30 (probably 33 as it is a 33x33 map) changed the map opened to the regions along the west edge of the world.

That map has the fields for evil, savagery, volcanism, drainage, etc, and directly editing the values in there is enough to reliably change a serene site to a terrifying one which for some reason has bubble bulbs and unicorns. There's also stuff related to weather so that should be tweakable through there.

[Roses]

If you instead just open up the lua command line by typing 'lua' in the DFHack command line, you can access all the different region_map_entry values with df.global.world.world_data.region_map[n].

[Max™]

>.>

Naturally, I was trying to open it up through the region map entry nesting because the value line screwed me up. That string works with gm-editor too, so yeah, you can change region evilness fine then.

[Roses]

I'm bumping this thread, both to bring interest back to it and in preparation of a new DF release. I've noticed a lot of threads with people performing their own !SCIENCE! and I am planning on starting to gather those all together and provide links to it from here. If you have any research you would like to post, or any links to research feel free to post them.

As for me, I am starting back up my research into syndromes and how they are transferred to units. Currently a CE_NAUSEA:SEV:100 syndrome doesn't necessarily mean an increase in 100 in the unit.counter.nausea counter. Similarly some syndromes actually work by applying a wound to unit.body.wounds, this is why some syndromes applied via modtools/add-syndrome don't work correctly. The syndrome is added but the wound is not.

Also, I am wondering if anyone knows what tool(s) Urist DaVinci used here to obtain the equations he did. I know he mentions disassembly reading and DFHack, but my knowledge of the former is rather limited.

[Quietust]

In reply to your rather old research about attack flags, you were incorrectly looking at them as a number when you should have been looking at them as a bitfield (as nearly all "flags" values are), and had you looked directly at the df-structures XML files, you would have seen that bits 5-9 mean "quick attack", "heavy attack", "wild attack", "precise attack", and "charge attack" (with bit 10 being related to multi-attacks), while the lower 5 bits were never properly identified.

[Roses]

In reply to your rather old research about attack flags, you were incorrectly looking at them as a number when you should have been looking at them as a bitfield (as nearly all "flags" values are), and had you looked directly at the df-structures XML files, you would have seen that bits 5-9 mean "quick attack", "heavy attack", "wild attack", "precise attack", and "charge attack" (with bit 10 being related to multi-attacks), while the lower 5 bits were never properly identified.

Interesting, so why do values change based on type of attack (bite, grasp, stance, etc...) and targeted body part? Sorry, my knowledge of bitfields is lacking.

[Quietust]

Interesting, so why do values change based on type of attack (bite, grasp, stance, etc...) and targeted body part? Sorry, my knowledge of bitfields is lacking.

A bitfield is a single number used to store multiple "on/off" values, distinguished by position - if you convert the number to binary, you can see each individual value as a 0 or 1.

For example:

Code: [Select]

  2 = 0000000010 -> bit 1 set
 34 = 0000100010 -> bits 1 and 5 set
 66 = 0001000010 -> bits 1 and 6 set
130 = 0010000010 -> bits 1 and 7 set
258 = 0100000010 -> bits 1 and 8 set
In this particular case, bits 5-9 were already identified (as I mentioned previously, "quick", "heavy", "wild", "precise", and "charge"), but bits 0-4 also have some special meaning which I wasn't able to determine at the time (and of those, bit 1 is being actively used).

In other parts of Dwarf Fortress, multiple bits might be combined together to form a numeric value - for example, the Tile Designation flags use 3 consecutive bits to store the Liquid Level (i.e. 0-7) as well as another 3 bits to specify one of up to 8 types of Dig designations present in a given tile (none, tunnel, up/down stair, channel, ramp, down stair, or up stair - the 8th type isn't used). In most other places, though, they're just used to store individual on/off values, since it uses much less memory than storing them in separate variables (and memory usage has historically been a big problem in Dwarf Fortress, at least until Toady started making 64-bit builds).

See this article for more information.