Print

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

[Roses]

I wasn't exactly sure where I should put this, so I decided to start a new thread, in hopes people will see it. This topic will concern the inner workings of DF as they relate to things we can change with DFHack and the research I have been doing/have done on them. (Others please feel free to post your own findings)

First up, tokens in the unit.counters and unit.counters2 vectors (e.g. pain, suffocation, stunned, winded, etc...)

• Pain - Altering this value directly in the counters vector will have no effect. If you wish to inflict pain on a unit with DFHack you need to create a wound with the pain in the wound itself. Note that the pain value in the wound will not directly translate to the pain value in the counters, it will be adjusted based on the pain receptors of the specific body part.
• Nausea - Same as Pain (minus pain receptors)
• Dizziness - Same as Pain (minus pain receptors)
• Winded - Winded can be set to whatever you want, but it seems to cap at 50 (at least for the creatures I tested on). It then decreases by between 4 and 10 each tick (again for the creatures I tested). For each tick that Winded > 0 Suffocation increases by one.
• Stunned - Stunned can be set directly in counters, it's value will decrease by one each tick. Note that no matter what you set Stunned too you can never make a unit unconscious with just setting this.
• Unconscious - Same as stunned, in addition when Unconscious reaches 0 it will set Stunned to ~75 and will set Unconscious to -1. While Unconscious is -1 the unit will ignore increases certain counters.
• Suffocation - Suffocation will automatically reset to 0 if Winded is 0 (or presumably if the lungs are damaged, more testing is needed for this).
• Webbed - Same as Stunned except that it decreases by 2 each tick instead of 1.
• Paralysis - Same as Pain (minus pain receptors)
• Numbness - Same as Pain (minus pain receptors)
• Fever - Same as Pain (minus pain receptors)
• Exhaustion - Same as Stunned with the caveat that certain threshold values will change the health display of the unit (e.g. Tired, Over-Exerted, etc...)

In general there are two types of counters, those that have an effect without adding a wound, and those that require a wound to function. Note that just having a wound is not enough. You can't, for instance, just increase the value of Pain in unit.counters, you must increase the Pain value in unit.body.wounds. The game will then automatically adjust the pain value in unit.counters.

Next Up;

I will try and get an idea of values for emotions, there effects, and the possible effects traits have on them.
Determine effect of density on spawned flows
More as I come across it

[Roses]

(Reserved just in case)

[Meph]

Not sure if this is what you are looking for, but adding NODRINK or NOEAT to creatures does not reset their hunger/thirst counters.

[Roses]

Not sure if this is what you are looking for, but adding NODRINK or NOEAT to creatures does not reset their hunger/thirst counters.

Good to know, for both DFHack modding and normal modding.

[Bearskie]

What about NOSLEEP?

[Max™]

Hmmm, I noticed with my retired adventurers that they had 0 on the counters for those, but [NOEXERT] permanently sets exhaustion to 3000 for some reason which drove me nuts in fort mode.

[Roses]

Preliminary research into attacks and the values in dfhack.

The attack action is currently filled with unknown variables. And currently looks like

Code: [Select]

target_unit_id           = 28
unk_4                    = <unit_action.T_data.T_attack.T_unk_4: 0x17234f0c>
attack_item_id           = 15
target_body_part_id      = 0
attack_body_part_id      = -1
attack_id                = 1
unk_28                   = 0
unk_2c                   = 1
unk_30                   = 57
flags                    = 66
unk_38                   = 0
unk_3c                   = 58
timer1                   = 3
timer2                   = 4
It has been "established" that unk_30 and unk_3c are attack_velocity and attack_hitchance (or somehow related to hit chance) and I believe the names have even been changed in the new DFHack. The following research tries to investigate the other components.

Tests done. By having several groups of dwarves with the same stats attack eachother with differing skills I have been analyzing their attack actions. Currently found results.

attack.flags
Flags is a specific number, meaning  you won't find just a random number between say 0 and 100. Instead it appears to be tied to the type of attack done (i.e. fast attack, wild attack, etc...). My reasoning behind this is that the attack.flag and attack.timer1/attack.timer2 is fixed, independent of attack preformed (with the exception of weapon vs non-weapon attacks). This means that if you were to tell me that the flags for a short sword attack was 66 I could tell you that the timer1 = 3 and timer4 = 4. In the couple dozen or so tests I ran with short swords, the flags values could be 2, 34, 66, 130, or 258. For the unnarmed attacks the flag values were 70, 134, or 262.

attack.unk_38
This number appears constant depending on if it is a weapon attack or creature attack. With all tested weapon attacks having unk_38 = 0 and all tested creature attacks having unk_38=102 or unk_38=103 (no idea why the difference all dwarves tested used 103, but some other animals used both, some only used 102, possibly other animals use other numbers?)

attack.unk_3c or hitchance
A highly variable number, as expected increase skill, on average, increases hit chance. The attack.flags also impacts hit chance greatly. With larger timer1 values and smaller timer2 values increasing hit chance (4,3 appearing to give the best increase for the tests done). Still need to do more work concerning varying agility, speed, and enemy dodge skills.

attack.unk_30 or velocity
Velocity values have been analyzed by Urist DaVinci in his disassemble work and appear to follow those values well.

attack.unk_28 and attack.unk_2c
No idea. Doesn't seem to be tied to anything I could think of, with unk_28 varying between 0 and 4 (usually 0, 1, or 2) and unk_2c varying between -2 and 5 (usually -2, -1, 0, or 1). Possibly related to the attack.unk_4 vector, as I have not studied the numbers in there yet.

That is my small update for now.

EDIT: After looking through about 50,000 attacks it appears that velocity and hit chance are related to eachother. For basic attacks (not fast, wild, hard, etc...) you have a higher velocity = higher hit chance (the particular equation I looked at was hit chance = velocity*0.8 - 40, but I haven't looked at the impact skills and attributes have yet). Now when you throw in different types of attacks the relationship changes, but it's a nice start.

EDIT2: Here are two simple graphs showing the velocity and hit chance of different types of attacks for dwarves with 1000 strength and 1000 agility at different skill levels.

Spoiler (click to show/hide)

You will notice that the hit chance increases linearly with skill level, but the velocity seems to plateau.
Other interesting notes
Quick and Heavy have the same hit chance as Normal attacks, with Precise having more and Wild having less
Normal and Precise have the same velocities, Wild and Heavy have the same velocities, and Quick has the lowest velocities
Next step will be to check the effect attributes have on this distribution. Presumably the general shape will remain the same, with just the absolute values changing.

EDIT3: Last update for now. The reason the velocity is plateauing is because the max velocity of all attacks doesn't increase as skill goes up, just the minimum and the average. I believe you can think of there being an optimum velocity that you can reach based on your attributes and weapon (this is the velocity Urist DaVinci calculates), then the game uses a fraction of that velocity depending on how skilled you are. The more skilled, the closer that fraction goes to reaching 1. This is different from hitchance, which doesn't seem to have an upper cap, and whose max just keeps increasing along with the average at each skill level.

[Hesperid]

attack.unk_28 and attack.unk_2c
No idea. Doesn't seem to be tied to anything I could think of, with unk_28 varying between 0 and 4 (usually 0, 1, or 2) and unk_2c varying between -2 and 5 (usually -2, -1, 0, or 1). Possibly related to the attack.unk_4 vector, as I have not studied the numbers in there yet.

I can answer as I did this same research a few versions ago. These numbers represent how easy the hit is to land and how well it can connect. Hence they vary between -3 and 3. (-3, -3) is an impossibly difficult hit that cannot connect even if the hit roll succeeds. (3, 3) is a simple hit (hit roll automatically succeeds) that can connect squarely, i.e. will typically dismember the opponent if it hits.

[Roses]

attack.unk_28 and attack.unk_2c
No idea. Doesn't seem to be tied to anything I could think of, with unk_28 varying between 0 and 4 (usually 0, 1, or 2) and unk_2c varying between -2 and 5 (usually -2, -1, 0, or 1). Possibly related to the attack.unk_4 vector, as I have not studied the numbers in there yet.

I can answer as I did this same research a few versions ago. These numbers represent how easy the hit is to land and how well it can connect. Hence they vary between -3 and 3. (-3, -3) is an impossibly difficult hit that cannot connect even if the hit roll succeeds. (3, 3) is a simple hit (hit roll automatically succeeds) that can connect squarely, i.e. will typically dismember the opponent if it hits.

Ah perfect! I didn't even think about that.

[Atomic Chicken]

Quite unrelated to the research on attacks, but I haven't seen documentation on this anywhere, so here's my run-through on how to replicate the "true name" mechanics utilised by worldgen demon slabs:

Spoiler (click to show/hide)

Creating a "true name" and linking it to your target:

1) obtain your target unit's hist_figure_id
2) insert a new "identity" in df.global.world.identities.all and remember to increase the value of df.global.identity_next_id by +1
3) in the "identity" :

Code: [Select]

id: insert the "identity" index value
name: edit as desired and set "has_name" to true (this shall be the hidden "true name" of your target unit)
histfig_id: insert the target unit's hist_figure_id
unk_4c: not sure what this does, but apparently must be set to "2" for this to work

all other fields can be set to -1   
4)

Code: [Select]

df.historical_figure.find(histfigId).info.reputation.all_identities:insert("#", newidentityId)where histfigId = the hist_figure_id of your target unit
and newidentityId = the id of your previously created identity

Note that df.historical_figure.find(histfigId).info.reputation and possibly even df.historical_figure.find(histfigId).info may need to be newly created in some cases.
Of course, an entirely new histfig will need to be created for non-historical figures.

Creating a functional "true name" slab:

5) obtain or create a slab
6) in your target slab item:

Code: [Select]

engraving_type: set to "25" (DemonIdentity)
topic: insert your target unit's hist_figure_id
At this point, any unit who reads the slab will gain knowledge of the target's secret identity, and the invoke/banish conversation options will become available when talking to the target.

The effect of reading a "true name" slab:

Upon reading the slab, the following occurs:

Code: [Select]

df.historical_figure.find(x).info.secret.anon_2:insert("#", y)where 'x' is the hist_figure_id of the reader
and 'y' is the id of the identity linked to the hist_figure_id on the slab

Incidentally, this means that the slab can be entirely omitted from the procedure if so desired, by directly modifying the histfig info of the unit who is to learn the target's identity.

[Putnam]

unk_38 is attack_bp AFAIK... I thought that was already found, at least I posted it alongside the attack_velocity findings.

[Roses]

unk_38 is attack_bp AFAIK... I thought that was already found, at least I posted it alongside the attack_velocity findings.

unk_38 is definitely not attack_bp, as it varies from 102 to 104 for body part attacks and is 0 for item attacks for dwarves. There is already a field attack_body_part_id that is seperate from unk_38.

From my tests on dwarves it appears unk_38 has to do with a relation between attack_body_part_id, target_body_part_id, flags and attack_id. Not quite sure what the exact number means, but in over 100,000 dwarf attacks it is only ever 102, 103, and 104, where as a dwarf only has ~80 body parts.

From what I can tell, for dwarves and ignoring wrestling attacks, 102 is used for bites, 103 is used for punchs and scratches, and 104 is used for kicks. Meaning 102 is for attack # 6, 103 is for attack # 0, 1, 4, and 5, and 104 is for attack # 2 and 3. This break down when the attack is a wrestling attack.

[scamtank]

Not quite sure what the exact number means, but in over 100,000 dwarf attacks it is only ever 102, 103, and 104, where as a dwarf only has ~80 body parts.

Hey, peep the skill index.

[Roses]

Not quite sure what the exact number means, but in over 100,000 dwarf attacks it is only ever 102, 103, and 104, where as a dwarf only has ~80 body parts.

Hey, peep the skill index.

Well then, that's that. Get's weird with wrestling attacks, and for some reason is always 0 for weapon attacks, but that solves that puzzle. That solves all the puzzles for non-wrestling based attacks. Go us!

[expwnent]

Posting to watch.