Print

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

[lethosor]

Was that working in 0.43.05? What platform/architecture are you using? I can confirm that the size of the identity structure on 64-bit OS X is correct (176 bytes), so I'm not sure what changed.

Here are 11 identity instances from a world generated in 0.44.03. I could see "unk_4c" actually being a histfig ID for all of them, but after that, only one field is positive for some, and I don't think birth_second should be negative.

Spoiler (click to show/hide)

Code: [Select]

0 <identity: 0x121b31d10>
id                      = 0
name                    = <language_name: 0x121b31d18>
race                    = -1
caste                  = -1
histfig_id              = -1
unk_4c                  = 94
birth_year              = 2
birth_second            = -1000000001
anon_1                  = 0
anon_2                  = -1
anon_3                  = -1
anon_4                  = -1
anon_5                  = -1
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b31d90>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b31da8>
1 <identity: 0x121b31dd0>
id                      = 1
name                    = <language_name: 0x121b31dd8>
race                    = 574
caste                  = 1
histfig_id              = -1
unk_4c                  = 180
birth_year              = 3
birth_second            = -196
anon_1                  = -1
anon_2                  = -1
anon_3                  = 80
anon_4                  = 110
anon_5                  = 29
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b31e50>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b31e68>
2 <identity: 0x121b30c10>
id                      = 2
name                    = <language_name: 0x121b30c18>
race                    = 572
caste                  = 1
histfig_id              = -1
unk_4c                  = 154
birth_year              = 3
birth_second            = 5
anon_1                  = 370419
anon_2                  = -1
anon_3                  = 77
anon_4                  = 115
anon_5                  = 29
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b30c90>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b30ca8>
3 <identity: 0x121b31e90>
id                      = 3
name                    = <language_name: 0x121b31e98>
race                    = 574
caste                  = 1
histfig_id              = -1
unk_4c                  = 180
birth_year              = 3
birth_second            = -196
anon_1                  = -1
anon_2                  = -1
anon_3                  = 50
anon_4                  = 113
anon_5                  = 25
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b31f10>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b31f28>
4 <identity: 0x121b31f50>
id                      = 4
name                    = <language_name: 0x121b31f58>
race                    = 574
caste                  = 0
histfig_id              = -1
unk_4c                  = 360
birth_year              = 3
birth_second            = -153
anon_1                  = -1
anon_2                  = -1
anon_3                  = 83
anon_4                  = 108
anon_5                  = 29
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b31fd0>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b31fe8>
5 <identity: 0x121b32060>
id                      = 5
name                    = <language_name: 0x121b32068>
race                    = 574
caste                  = 1
histfig_id              = -1
unk_4c                  = 480
birth_year              = 3
birth_second            = -142
anon_1                  = -1
anon_2                  = -1
anon_3                  = 81
anon_4                  = 113
anon_5                  = 29
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b320e0>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b320f8>
6 <identity: 0x121b32120>
id                      = 6
name                    = <language_name: 0x121b32128>
race                    = 574
caste                  = 0
histfig_id              = -1
unk_4c                  = 585
birth_year              = 3
birth_second            = -243
anon_1                  = -1
anon_2                  = -1
anon_3                  = 79
anon_4                  = 130
anon_5                  = 29
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b321a0>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b321b8>
7 <identity: 0x121b321e0>
id                      = 7
name                    = <language_name: 0x121b321e8>
race                    = 573
caste                  = 1
histfig_id              = -1
unk_4c                  = 600
birth_year              = 3
birth_second            = 27
anon_1                  = -1
anon_2                  = -1
anon_3                  = 39
anon_4                  = 110
anon_5                  = 25
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b32260>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b32278>
8 <identity: 0x121b322a0>
id                      = 8
name                    = <language_name: 0x121b322a8>
race                    = 572
caste                  = 0
histfig_id              = -1
unk_4c                  = 641
birth_year              = 3
birth_second            = -11
anon_1                  = -1
anon_2                  = -1
anon_3                  = 83
anon_4                  = 113
anon_5                  = 29
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b32320>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b32338>
9 <identity: 0x121b32480>
id                      = 9
name                    = <language_name: 0x121b32488>
race                    = 574
caste                  = 0
histfig_id              = -1
unk_4c                  = 678
birth_year              = 3
birth_second            = -158
anon_1                  = -1
anon_2                  = -1
anon_3                  = 83
anon_4                  = 110
anon_5                  = 29
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b32500>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b32518>
10 <identity: 0x121b32540>
id                      = 10
name                    = <language_name: 0x121b32548>
race                    = 574
caste                  = 1
histfig_id              = -1
unk_4c                  = 706
birth_year              = 3
birth_second            = -202
anon_1                  = -1
anon_2                  = -1
anon_3                  = 80
anon_4                  = 106
anon_5                  = 29
anon_6                  = <vector<identity_unk_94*>[0]: 0x121b325c0>
anon_7                  = <vector<identity_unk_94*>[0]: 0x121b325d8>


Edit: I got some strange values in 0.43.05 too (different world, just one identity):

Spoiler (click to show/hide)

Code: [Select]

<identity: 0x11c931c70>
id                      = 0
name                    = <language_name: 0x11c931c78>
race                    = -1
caste                  = -1
histfig_id              = 62
unk_4c                  = 2
birth_year              = -1000000001
birth_second            = 0


[jecowa]

sounds similar to bug. http://www.bay12games.com/dwarves/mantisbt/print_bug_page.php?bug_id=1178

[lethosor]

That may be related to identities as well, but they're almost certainly not the same issue. The issue here is (probably) DFHack's layout/names being wrong somehow. On the other hand, Toady's names for everything are right, so it's unlikely that he's mixing up a histfig ID and a year somehow. Also, it looks like at least something got added in 0.44, but the issue you linked to is from 0.31.

[Clément]

I am using both windows and linux 64 bits (linux was used for the last post values, windows may be the 0.44.03-alpha version). I don't think it is a DF bug, the date displayed in game is coherent with birth_year = 118, birth_second = 363899.

Even your strange values moved between 0.43.05 and 0.44.03. It really looks like there is a new member before histfig_id.

About the strange value for birth_year, is it possible it is actually a union whose content depends on unk_4c value (0 for birth date)?

Edit: maybe not that simple: I have a valid birth date with unk_4c=3. On Windows 64 bits (updated to beta1), a non-vampire from this save, Rel Anoeslik is lying about his name but not about his age.

Code: [Select]

[lua]# ~df.identity.find(2541)
<identity: 000000003AC6ECD0>
id                       = 2541
name                     = <language_name: 000000003AC6ECD8>
race                     = 495
caste                    = 1
histfig_id               = -1
unk_4c                   = 38030
birth_year               = 3
birth_second             = 131
anon_1                   = 127964
anon_2                   = -1
anon_3                   = 1889
anon_4                   = 132
anon_5                   = 828
anon_6                   = <vector<identity_unk_94*>[0]: 000000003AC6ED80>
anon_7                   = <vector<identity_unk_94*>[0]: 000000003AC6ED98>
[lua]# ~df.historical_figure.find(38030)
<historical_figure: 000000006C14DA90>
profession               = 79
race                     = 495
caste                    = 1
sex                      = 1
orientation_flags        = <orientation_flags: 000000006C14DA98>
appeared_year            = 131
born_year                = 131
born_seconds             = 127964
curse_year               = -1
curse_seconds            = -1
birth_year_bias          = 0
birth_time_bias          = 0
old_year                 = -1
old_seconds              = -1
died_year                = -1
died_seconds             = -1
name                     = <language_name: 000000006C14DAC8>
civ_id                   = 894
population_id            = 844
breed_id                 = -1
cultural_identity        = -1
anon_1                   = 6597
flags                    = <BitArray<>: 000000006C14DB58>
unit_id                  = 5126
unit_id2                 = 5126
id                       = 38030
unk4                     = 0
entity_links             = <vector<histfig_entity_link*>[6]: 000000006C14DB78>
site_links               = <vector<histfig_site_link*>[0]: 000000006C14DB90>
histfig_links            = <vector<histfig_hf_link*>[6]: 000000006C14DBA8>
info                     = <historical_figure_info: 000000006C302ED0>
unk_f0                   = nil
unk_f4                   = nil
unk_f8                   = nil
unk_fc                   = nil
unk_100                  = 0
unk_v4019_1              = -1

[martinuzz]

I have a visitor goblin animal caretaker, part of a visiting troop of performers. He has been running from location to location with a constant 'no job' for a few years now, and I think he is both blocking his troupe from leaving, as well as blocking any visiting troops from applying for semi-resident status.

I downloaded DT in hopes of fixing him somehow, only to find out DT doesn't deal with visitors.

Is there any way I can use DFHack to get rid of this goblin? Preferably just snap him out of it, but if all else fails, how do kill?

EDIT: nvm, found out how exterminate works

[PatrikLundell]

@martinuzz:
I've used this script in the past:

Spoiler (click to show/hide)

Code: [Select]

--  Causes units to leave the map when they're no longer occupied. Can be used to get rid of
--  bugged overstaying visitors that no longer socialize. Those still socializing seem to take
--  up new socialization activities before considering to act on this prompt, though. You'd have
--  to close the facilities they visit for it to take effect.
--[====[

getlost
=======
--
]====]
function getlost ()
   local unit = dfhack.gui.getSelectedUnit (true)
   unit.flags1.forest = true
end

getlost ()


[Max™]

Looks like anon_2 and anon_3 under nemesis[k].figure.info.relationships[v] in a given unit are the same as the reputation.wanted[k].type and .level with the same values/effects on fame when edited:

I just figured it out, and I will provide insight on what I think happened.
How I got it unstuck: I pressed the enter key in the DFHack menu.

What I think happened: I had earlier typed "ls" so i could see the command list. The command list was printed, and the line immediately after was blinking _, as what I would normally expect.
When i tried saving, the game got stuck in not-responding, and DF was using no processor resources. I was a bit confused, so I waited a long while with no progress.
I then pressed enter in the DFHack window. This caused the display to change as so:

My deduction here is this: the "ls" script continues running until after enter is pressed again. This prevents "clearing animal hospitals" or any other number of "it's time to save" subroutines from going through. This stalls Dwarf Fortress itself from performing any saving.
Luckily, I didn't close DF before I figured this out, so my save is safe!

Question though, can I safely paste the new DFHack version over my DF Folder that has the alpha version on it? This experience has made me crave some of those new bugfixes.

Dwarvet drives me nuts in adventure mode so I just delete it when I do a new dfhack version, I wonder if it wasn't the source of the hang as it runs at times when it never needs (travel mode changes?), and yeah it'll just drop into the relevant folders fine, I copy over my scripts since I've got personal projects/variations in there but other than that it's easy as that.

[Rumrusher]

what does Dwarvet do anyway? was there a bug that consistently spawn animal hospitals in DF that never to this day got patched out?
other than that
 I take it if folks want fame they have to build a personal relationship? this might make solving the issue of getting folks to become your hearthperson alot eaiser or moving up in noble ranks.

[Max™]

Yeah, but the personal store of rep doesn't seem to track everything properly either, and people don't seem to care about the entity linked fame since I previously tried making myself a legendary hero/hunter/bandit slayer/artifact finder and all via the reputation fields for shit effect, but doing it to a direct relationship field worked as seen above.

[Kat]

what does Dwarvet do anyway?

allows your medics to treat injured animals, in a zone marked as hospital & animal training zone iirc.

otherwise, your animals only heal very slowly on their own.

[Rumrusher]

Yeah, but the personal store of rep doesn't seem to track everything properly either, and people don't seem to care about the entity linked fame since I previously tried making myself a legendary hero/hunter/bandit slayer/artifact finder and all via the reputation fields for shit effect, but doing it to a direct relationship field worked as seen above.

so in a odd way adventurers can get into a relationship, it kinda tied to your fame.
so the game plan isn't to do a bunch of quests for a bunch of random folks but to instead to a bunch of quest for a Really really important person to butter them up and gain favors like your wooing them with your feats.
wait doesn't that mean since it's a relationship affair you could get an adventurer to be someone's hero/hunter/bandit slayer/artifact finder in the relationship tab? like how if you trade with a player fort citizen they will add the adventurer down as "good for business" in their relationship list.

[Roses]

Question time!

1. I know that the equip-item script can be used to put pretty much any item on any unit, but does it actually have an effect? If I put a helmet on a dog will it actually help protect it's head? Will the dog even keep it equipped, or will it just unequip it right away?

2. Does the equip-script and item-trigger play well with each other?

3. With the addition of the SYN_CONCENTRATION_ADDED and SYN_IDENTIFIER and such, does the add-syndrome script correctly add concentrations and respect the dilution factors?

4. I'm not sure add-syndrome is working correctly for syndromes that add effects like bleeding, or for syndromes that have targeted body parts. It seems that a syndrome applied normally from in-game comes with a wound that actually does the targeting/bleeding/etc... Has anyone else noticed this or am I just doing something wrong?

[Boltgun]

Question time!

1. I know that the equip-item script can be used to put pretty much any item on any unit, but does it actually have an effect? If I put a helmet on a dog will it actually help protect it's head? Will the dog even keep it equipped, or will it just unequip it right away?

2. Does the equip-script and item-trigger play well with each other?

3. With the addition of the SYN_CONCENTRATION_ADDED and SYN_IDENTIFIER and such, does the add-syndrome script correctly add concentrations and respect the dilution factors?

4. I'm not sure add-syndrome is working correctly for syndromes that add effects like bleeding, or for syndromes that have targeted body parts. It seems that a syndrome applied normally from in-game comes with a wound that actually does the targeting/bleeding/etc... Has anyone else noticed this or am I just doing something wrong?

I'm on the same issue with add-syndrome. Syndrome-util is setting wound_id to -1 and I guess that it prevent a lot of symptoms from working. We had the same issue in 0.34 and is was fixed by creating a fresh wound (as far as my memory goes).

Interactions are not working either when added with add-syndrome. Perhaps there is more to insert that the list of symptoms. I need to compare in gm-editor a naturally infected creature with a dfhack infected one to check this.

[buuface]

Hi guys is there a way to force a siege to end?

I have a bug whereby I was besieged by goblins who immediately seem to have left the map (I searched everywhere for them including using the 'reveal' hack) but the *SIEGE* tag remains.

Is there a way I can use DFhack to force this status to end? Looked in the commands list but couldn't see anything.

[Kat]

Hi guys is there a way to force a siege to end?

I have a bug whereby I was besieged by goblins who immediately seem to have left the map (I searched everywhere for them including using the 'reveal' hack) but the *SIEGE* tag remains.

Is there a way I can use DFhack to force this status to end? Looked in the commands list but couldn't see anything.

Try fix/retrieve-units

this might clear the siege, or force the goblins to enter.