Nicknaming vampires doesn't work correctly

[PatrikLundell]

The script/plugin ("names"?) [edit: it's actually gui/rename] allowing you to assign (nick)names to units and things have largely, but not completely, been made obsolete by native naming support. One of the things DFHack is needed for is to nickname units not belonging to you (such as keeping track of quester groups to easier locate infiltrators when one of them tries to sneak attack, and the whole fortress erupts in chaos). Another usage is to name vampires identified by the arrival message (or identified otherwise). However, if they operate under a false identity, the nickname is attacked to their real name rather than the false one used.
Interestingly, when updating the nickname, the interface shows a blank nickname, indicating it was retrieved from the false identity, not the real one it's stored to.
Presumably, this doesn't only affect vampires, but any units operating under a false identity (including, your own migrants if you're unlucky and I've read the bug reports correctly).

[lethosor]

Is it possible that this was fixed with #1279?

[PatrikLundell]

If #1279 is included in the current DFHack release (0.44.12-r1), as it seems to have been, it wasn't. I'm using the r03 LNP which includes the only 0.44.12 DFHack release made.
I'll see if I can look into it further, as I've currently got the vampire locked up (in one of the entrance tunnels, so I can kill it once it quester buddies have left).

Edit: I've looked a little further. The script I used turned out to be "gui/rename", and the issue is not resolved by #1279 (although that probably solved a problem that would have shown up).
Units::getVisibleName goes through identities to select the name to display, while Units::setNickName probably hasn't been updated to look at those, so the correct (i.e. the visible) name is retrieved for editing, but the entered nickname is saved to other places.
I suspect a correction would need to take different cases into consideration, as a nickname of a false identity shouldn't show when/if the unit shows up under a different one (which may be the real one), but a nickname for a real name should reflect back to the hist fig (as is currently the case) as well as the unit.
I don't yet know if the presence of an identity is a sufficient reason to just update that one and skip the rest, or if units using false identities also have its real identity as one of them, in which case you'd have to detect if an identity is the real one (and update the other entries as well) or a false one (in which case I would expect only that identity should be updated.

Edit 2: My vampire has only a single "extra" identity, so there's not a copy of a real one in that case, at least. However, the current code does handle identities later, when dealing with demons, but that code seems to update a (presumably assumed false) hist fig id rather than the identity in the false identity, and my vampire's false identity refers to his real hist fig id, so the real hist fig nickname gets set twice.

If I'm guessing correctly, you'd need to first check for a false identity. If you find one you should probably set its nickname regardless (but that's not done by the current demon handling code, which indicates that guess is wrong). You'd then check if the false identities hfid is the same as the hf's id. If it is, you're done and can return. If it isn't, it's a demon that presumably should have its false hist fig updated, but I don't see why you'd want its real hf or unit to be updated in that case, so I'd suggest you'd quit updating the demon after updating the false histfig (and possibly its unit).
If there wasn't a false identity involved, the current code would be invoked to update the unit, current soul, and the histfig (if any).
However, this would need to be fixed by someone who actually knows how demons behave with the current DF code.

[JackOfSpade]

Also, nicknaming a dwarf in fortress mode pre-embark will cause that dwarf to not enage in any work, and be idle all the time when using autolabor/automanager.

[lethosor]

I doubt that's the cause, unless you were doing something really strange to rename the dwarf.

[myk002]

Fixed by DFHack/scripts#1368