Print

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

[Dangield]

Soo, a strange thing I encountered. Apparently there is a human among my dwarves. I was scrolling through my unit list ('u') and among my citizens I spotted an entry of 'Human (Tame)'. And it's extremely strange as I have not accepted anyone on a long term stay and afaik you can't get any race other than dwarf in a caravan. So i started snooping around and it looks really strange.

• It has a status of 'Tame', but it doesn't come up at animal list. I can only see him in 'Citizens' tab, so it's definitely a part of my fortress.
• He is 63, so it was definitely not born in my fortress.
• He has a personality and thoughts as any other citizen.
• He doesn't have a name! At first I thought it is a human named 'Human'. But I accessed his customization and his name is actually empty. His profession name is 'Human'. I can change his nickname, but it doesn't affect him not having a name when I reverse a change. I can change his profession too, but it goes back to 'Human' when I erase it. The '(Tamed)' tag is always present, not matter what i call him.
• He has literally no relationships despite sitting in a tavern all day.
• He has a single entry in health tab: '22nd Hematite 1082: Brought to rest in Bed - Sibrek Rithobok Mason'.
• I can't assign him any job through any meanings (including dfhack and dwarf therapist).
• I can't assign him to military.
• I can't make him a noble.
• I can't interrogate him through justice system. He is on a list, but my sheriff seems to ignore the order.
• The only thing he does is sitting at the tavern and listening to songs and stories. I am yet to see him do anything else.
• I checked him with dwarf therapist and he has almost no work/military/social skills other than being Dabbling in Discipline and Observer. He does have regular attributes like e.g. Strength, Focus, Memory, Aglility.
• Dwarf therapist actually seems to be unaware of his '(Tame)' tag as it can't be seen there.

I am deeply confused. Does somebody had similar situation? What may be the cause and what do I do with him?

EDIT: I will add anything i discovered after creating this post:

• I can assign him a bed.
• He does sleep and drink.
• I can assign him a function inside a location, like Performer or Scholar.

[Dangield]

I have not raided anyone with that fortress, but I have been attacked many times by undead, goblins and elves.

I can assign him a function of Performer/Scholar/Scribe/Tavern keeper/Messenger in locations.

[PatrikLundell]

He might have migrated spontaneously from a holding. I've had a case in the past when a (tame) goblin and a (tame) troll or ogre (don't remember which) arrived together with the message that they'd returned to the fortress. I believe those case from a conquered goblin site, but I don't see why your human couldn't have come from a site economically linked to you.

It's a bug, of course.

[Dangield]

I believe those case from a conquered goblin site, but I don't see why your human couldn't have come from a site economically linked to you.

I'm afraid that's not really possible. The first holding economically linked to my fort was founded after I discovered him. I only had regular migrant waves and traders before.

[orius]

Mebbe he was raised by wolves.   

[feelotraveller]

Pure speculation on my part... but here's a possible scenario:

One of the hostile parties (probably goblins) arrived at your fortress after capturing a non-historical figure in a raid.  After defeating the 'attack' - guessing it could be that goblins stumbled upon your fortress whilst returning from a raid elsewhere and the attack happened because they are permanently hostile rather than your fortress being the target of an attack - the non-hostile, and now free, non-historical human remained, but because of the unexpected chain of events the triggers for the creation of a historical figure id were not met. 

You could check this (the non-historical figure part, not the story about how this came about...) by using dfhack 'gui/gm-editor' after selecting the human and checking if their hist_figure_id is -1 or not.  If this is the case giving them an appropriate* hist_figure_id may well fix the 'bug'. (Do advise keeping a before-save if trying the latter in case it breaks something...  )


* Not sure what 'appropriate' consists of here, but pretty certain that the id needs to be unique?

[PatrikLundell]

Hist fig ids should be unique, yes. They probably also should be the next one in the number allocation sequence, and that number should probably have to be increased to account for the newly allocated number. In addition to that a hist fig entry should probably be allocated and filled out in the hist fig vector (and, again, probably update a "last used" counter, which may or may not be the same one). Any other related structures should probably have to be allocated as well (nemesis?, ...).

[feelotraveller]

Beyond the uniqueness - could well be.  On the other hand maybe the allocation system is more flexible?  (Thinking about how the 'cull unimportant historical figures' option in worldgen might work it is possible that historical id's can be reallocated. or at least that the number active need not be strictly equivalent to the next id(value) to be allocated -1, or whatever.)  Still if it was my save I'd probably try a sufficiently large number like 999999 just to see if it 'solved' the problem for a reload without unpause, but yeah it's a longshot given that other fields may also need alteration. Indeed probably a messy and complicated process to alter them and definitely in possible saving-breaking territory.  An alternative would be to select a fortress unit with a known hist_figure_id and swap it to non-historical then use that id for the Human (Tame).  Not that that doesn't have problems of its own... 

(And in fact I would not have gone here but for a lead-on from investigating whether the unit is classed as non-historical, something entirely safe and that provides/confirms relevant information.)
Probably a better way to allocate a new historical figure id would be to trigger a relevant/appropriate event (getting a kill, being trained - spring to mind) for the unit in question.  Barring a script  that leaves open the question of 'how' to get the event to happen.

On the other side of the issue I'd be looking at historical records (first fortress then legends) in the days/weeks prior to 22nd Hematite 1082 to see if it was the tail end of siege and if the hostile site/civilization had been involved in an attack on another site (human probably) in the immediate past.  Of course the historical records could lead elsewhere.

[PatrikLundell]

It's true the hist fig vector is shorter when hist figs are culled and contains holes in the (sorted) vector, but DF contains "last number used" or "next number to use" elements in a lot of places (including ones that are never culled), so it would be odd if the same system wasn't used for hist figs (I'm too lazy to check at the moment). Thus, if you allocated a number higher than the one DF "think" is the highest, it may well end up being double allocated, overwritten, or result in a crash when that number is eventually allocated by the normal process. A hole, however, ought not to be a problem for hist figs (and probably not for a number of other vectors either, as long as the elements are sorted properly so the "find" functions work as they should).

Edit:
It can also be noted that culled hist figs aren't completely erased from history. The hist figs themselves are removed, but all references to them aren't, so you can have a villain who recruited an unknown hist fig, and that entry will contain the hist fig id of that hist fig, but there's no entry with that number in the vector, so the "find" function will return a null pointer. Thus, trying to take the place of someone else may have some side effects (quite likely they'd be noted as being related to the culled hist fig if any close, non culled, relatives were examined, for instance).