Print

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

[lethosor]

http://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html might help. I'm not entirely sure what you're asking for, though, or what you've come up with already.

[Ashtaroth]

Possibly a daft question, so I apologise in advance;

I'm trying to use Misery to balance out happiness a little bit, but it just causes endless job cancellation spam and makes the fortress grind to a halt; there are other negative emotions besides "miserable" that don't cause job cancellations and should have the same effect on overall stress, so I want to change it. But since misery, as far as I can see, is a .dll, not a script, I don't have the slightest clue how to go about changing it? What would be the easiest way of doing that?

[lethosor]

It's compiled from https://github.com/DFHack/dfhack/blob/master/plugins/misery.cpp, so you'll have to change it and recompile it to have changes take effect.
If you're interested in compiling DFHack, see https://dfhack.readthedocs.io/en/latest/docs/Compile.html. Otherwise, you can submit an issue and someone might get to it eventually. (I'm mostly responsible for making it use miserable thoughts, since I rewrote it some time after it broke around 0.40, but I'm also fairly busy with other things at the moment.)

[YetAnotherLurker]

So, tweak cage-butcher apparently does not check anything about the occupants of a cage before setting the slaughter flag. Thus, anything that winds up in a cage can be butchered, including sapient citizens.

Spoiler: The initial, accidental, discovery by someone else (click to show/hide)

Spoiler: Later experiment with a petitioned full citizen (click to show/hide)

I also tried flagging assorted captured invaders for butchering, but didn't manage to get one dragged to the Butcher's Shop due to immediate recaging upon release.

[thefriendlyhacker]

I am having a few problems with modtools/create-unit.  I am trying to use it in an old mod I am updating to the latest DF version, but I have reproduced the problems in a vanilla .05 save moved to both DF .07/DFHack .07-alpha1 and DF .09/DFhack .09-alpha1.   I could *not* reproduce some of them in a fresh embark on a fresh .09 install, but all I did there was create a 5 year pocket world and spawn dogs next to the starting wagon.  All of this is 64bit win 7, by the way.

Spoiler: details (click to show/hide)

Sometimes when an animal is spawned with the -setUnitToFort arg, it attacks and is attacked by my other units indiscriminately, despite showing up in the units screen as a fort pet.  This happens to animals but I just tried to spawn a pony in .09 (MLP FO:E) and they seemed to work just fine (inc. changing/performing labors).  Animals without the -setUnitToFort arg are friendly and do not attack/get attacked (which is afaik expected). 

Numbering for units without a name given is broken.  Most of the time, the number that the creature displays is a very large, sometimes negative number. Further spawned units of that race increment the number as expected.  Occasionally, the number starts at 1 as expected. Given that one time I saw an opossum 5(the first of its kind spawned) immediately after I just spawned a coati 5 (the 5th of its kind), I would guess that the variable for unit numbering isn't being initialized and the code branch that deals with numbering/naming creatures who are the first of their kind isn't executing or is missing the code to assign it to 1. Either that or there is a bad pointer address/pointer math somewhere (don't know whether the code for it is in C or Lua).

The -domesticate flag throws an error, and units with it but not -setUnitToFort are friendly, not fort pets (the latter may be intended behavior, I'm not sure).  Here is the stack trace: 
...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:344: Cannot write field unit.T_enemy.anon_4: not found.
stack traceback:
   [C]: in metamethod '__newindex'
   ...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:344: in global 'domesticate'
   ...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:537: in local 'script_code'
   ...y\Desktop\games\DFFE temp\DFFE 14.04\hack\lua\dfhack.lua:562: in function 'dfhack.run_script_with_env'
   (...tail calls...)
There *was* also some other weirdness with units that had -setUnitToFort but not -domesticate being unbutcherable/ungeldable, but that went away when I went from .07 to .09. Otherwise -domesticate didn't make a difference at all in any of my tests.

I transferred a vanilla .05 fort to .07, installed dfhack .07 and did some testing.  This is what I found by spawning animals into the middle of a 10x20ish training area filled with about 60 dwarves:
- all the carnivores and bonecarns I tested were attacked immediately and killed (they often didn't make it past a single step(.)).  Occasionally the animal attacked first before being obliterated.  The only exception to this was cats, weirdly enough, who were left alone.  I also tried taking bonecarn out of dog and it made no difference.  I also tried taking a single step(.) when I spawned a lion, and I noticed that it was overcome by terror (while bolts were already in flight).
- non-carnivores/bonecarns were not immediately attacked, but would be constantly going in and out of overcome by terror (even dangerous ones, like elephants or rhinos).  The only exception to this was a Mandrill, which was attacked immediately (which may have something to do with curiousbeast eater/item). I tried putting bonecarn on a Horse but it still spawned safely.  Weirdly enough, if another animal that gets attacked was spawned immediately after the first was then the first would also get attacked, but this didn't seem to apply if the first animal was spawned some time ago.  Lastly, a couple of non-carnivores were attacked some time later, although I didn't actually see it happen.  A badger at the meeting hall went enraged, attacked someone and was then punched to death, while a donkey by the archery range was shot by a crossbow repeatedly without a report of it attacking anything first.
For reference, this is what I spawned:

Killed Immediately
several dogs, 1 after removing bonecarn from the save raws, 1 after adding at peace with wild
1 bobcat, jaguar, rattlesnake, saltwater croc, Vulture
2 dingos, Lions
6 Coatis, one of which was spawned next to other animals in a different area (the meeting hall, which had half a dozen armed dwarves in it)
1 Mandrill (the only killed animal without bonecarn/carnivore)

Not attacked immediately
1 giraffe, cat, skunk, warthog, hare, weasel, Gazelle, Sheep, Pig, Goat, Chicken, Cavy, Rhino
2 elephants
1 badger, later killed after enraging and attacking first according to the report, unknown exactly why
1 Ibex, killed immediately after when a dingo was spawned in
1 Opossum, killed immediately after when Coati was spawned in
1 Donkey, was killed later for unknown reasons without any report of attacking first
3 Horses, including 1 with bonecarn
5 Chimpanzees, including 4 at once in the same square

I tried spawning 6 dogs in a new world/embark, and only 1 of them was attacked (the newly drafted newbie axe wielding commander exchanged hits with it for a couple of pages and then left it alone, after which it crawled away a few squares and bled to death).   I then got DF/DFhack .09 and tried the same thing with another 20 dogs, but could not reproduce it again - all I managed was to get dogs to attack each other for a bit if I spawned them on top of each other.  I might have been unlucky though.  In any case, I unzipped a fresh .09 version and copied my mod raws over and the problem still persists there.

Oh, and failing to put the space between the -location z coord and the ending bracket puts you in the arena spawn menu.  Dunno how much people care about idiot-proof code, but there it is.

I am also having an issue with item-trigger. 

Spoiler: details (click to show/hide)

Here is an example of the onLoad code I am using
modtools/item-trigger -itemType ITEM_ARMOR_BATTLE_SADDLE_MINIGUN -onEquip [ Worn ] -command [ modtools/add-syndrome -syndrome "minigun battle saddle" -target \\UNIT_ID ]

modtools/item-trigger -itemType ITEM_ARMOR_BATTLE_SADDLE_MINIGUN -onUnequip [ Worn ] -command [ modtools/add-syndrome -erase -syndrome "minigun battle saddle" -target \\UNIT_ID ]

There are many different item/syndrome pairs with the same code, and all have the same issue.  Many units are walking around with as many as a dozen duplicates of each syndrome from their items despite only wearing 1 or 2 items of a type (or sometimes no items at all, if it has equipped and later dropped an item), while a few appear to be functioning correctly (I don't know how recently they have picked up their equipment though).   Many of the syndromes were listed by the show-unit-syndromes selected command in patterns, as if being repeatedly reapplied without the remove code going off in between (e.g. ...pipbuck, pipbuck, stealthbuck, gasmask, pipbuck, pipbuck, stealthbuck, gasmask...).  I tried taking about a dozen units (including some mercs) with syndrome stacks out of the military so they drop/stow their gear, and every time a single instance of appropriate syndrome per item was removed.  One of them had moved a gasmask from head to hauled and that also removed a single instance (don't know if the unit moved it straight from head to hauled or dropped it first). 
I also tested an item in the arena and the syndrome was added/removed as expected, so...  No idea what is happening.  [ Worn ] was put in specifically to try to stop this, but it made no difference afaict.

While I am here, is there a way to change intelligent pets to normal citizens through dfhack, or change long-term residents to citizens so they can take labors?  I tried reaction-trigger and syndrome transformations but those turn the pet into some weird kind of long-term resident that I could assign scholarships/scribing/performing but not the military or labors (not even through dwarf therapist). I might be able to skirt around this using a couple of reaction-triggers, create-unit, an instakilling syndrome and corpseitem (because intelligent pets can do skill-less reactions only for some reason), but it would be nice to not use such a hacky and limited method, especially since it won't allow intelligent pets to keep their skills.

[Boltgun]

I am having a few problems with modtools/create-unit.  I am trying to use it in an old mod I am updating to the latest DF version, but I have reproduced the problems in a vanilla .05 save moved to both DF .07/DFHack .07-alpha1 and DF .09/DFhack .09-alpha1.   I could *not* reproduce some of them in a fresh embark on a fresh .09 install, but all I did there was create a 5 year pocket world and spawn dogs next to the starting wagon.  All of this is 64bit win 7, by the way.

Spoiler: details (click to show/hide)

Sometimes when an animal is spawned with the -setUnitToFort arg, it attacks and is attacked by my other units indiscriminately, despite showing up in the units screen as a fort pet.  This happens to animals but I just tried to spawn a pony in .09 (MLP FO:E) and they seemed to work just fine (inc. changing/performing labors).  Animals without the -setUnitToFort arg are friendly and do not attack/get attacked (which is afaik expected). 

Numbering for units without a name given is broken.  Most of the time, the number that the creature displays is a very large, sometimes negative number. Further spawned units of that race increment the number as expected.  Occasionally, the number starts at 1 as expected. Given that one time I saw an opossum 5(the first of its kind spawned) immediately after I just spawned a coati 5 (the 5th of its kind), I would guess that the variable for unit numbering isn't being initialized and the code branch that deals with numbering/naming creatures who are the first of their kind isn't executing or is missing the code to assign it to 1. Either that or there is a bad pointer address/pointer math somewhere (don't know whether the code for it is in C or Lua).

The -domesticate flag throws an error, and units with it but not -setUnitToFort are friendly, not fort pets (the latter may be intended behavior, I'm not sure).  Here is the stack trace: 
...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:344: Cannot write field unit.T_enemy.anon_4: not found.
stack traceback:
   [C]: in metamethod '__newindex'
   ...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:344: in global 'domesticate'
   ...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:537: in local 'script_code'
   ...y\Desktop\games\DFFE temp\DFFE 14.04\hack\lua\dfhack.lua:562: in function 'dfhack.run_script_with_env'
   (...tail calls...)
There *was* also some other weirdness with units that had -setUnitToFort but not -domesticate being unbutcherable/ungeldable, but that went away when I went from .07 to .09. Otherwise -domesticate didn't make a difference at all in any of my tests.

I transferred a vanilla .05 fort to .07, installed dfhack .07 and did some testing.  This is what I found by spawning animals into the middle of a 10x20ish training area filled with about 60 dwarves:
- all the carnivores and bonecarns I tested were attacked immediately and killed (they often didn't make it past a single step(.)).  Occasionally the animal attacked first before being obliterated.  The only exception to this was cats, weirdly enough, who were left alone.  I also tried taking bonecarn out of dog and it made no difference.  I also tried taking a single step(.) when I spawned a lion, and I noticed that it was overcome by terror (while bolts were already in flight).
- non-carnivores/bonecarns were not immediately attacked, but would be constantly going in and out of overcome by terror (even dangerous ones, like elephants or rhinos).  The only exception to this was a Mandrill, which was attacked immediately (which may have something to do with curiousbeast eater/item). I tried putting bonecarn on a Horse but it still spawned safely.  Weirdly enough, if another animal that gets attacked was spawned immediately after the first was then the first would also get attacked, but this didn't seem to apply if the first animal was spawned some time ago.  Lastly, a couple of non-carnivores were attacked some time later, although I didn't actually see it happen.  A badger at the meeting hall went enraged, attacked someone and was then punched to death, while a donkey by the archery range was shot by a crossbow repeatedly without a report of it attacking anything first.
For reference, this is what I spawned:

Killed Immediately
several dogs, 1 after removing bonecarn from the save raws, 1 after adding at peace with wild
1 bobcat, jaguar, rattlesnake, saltwater croc, Vulture
2 dingos, Lions
6 Coatis, one of which was spawned next to other animals in a different area (the meeting hall, which had half a dozen armed dwarves in it)
1 Mandrill (the only killed animal without bonecarn/carnivore)

Not attacked immediately
1 giraffe, cat, skunk, warthog, hare, weasel, Gazelle, Sheep, Pig, Goat, Chicken, Cavy, Rhino
2 elephants
1 badger, later killed after enraging and attacking first according to the report, unknown exactly why
1 Ibex, killed immediately after when a dingo was spawned in
1 Opossum, killed immediately after when Coati was spawned in
1 Donkey, was killed later for unknown reasons without any report of attacking first
3 Horses, including 1 with bonecarn
5 Chimpanzees, including 4 at once in the same square

I tried spawning 6 dogs in a new world/embark, and only 1 of them was attacked (the newly drafted newbie axe wielding commander exchanged hits with it for a couple of pages and then left it alone, after which it crawled away a few squares and bled to death).   I then got DF/DFhack .09 and tried the same thing with another 20 dogs, but could not reproduce it again - all I managed was to get dogs to attack each other for a bit if I spawned them on top of each other.  I might have been unlucky though.  In any case, I unzipped a fresh .09 version and copied my mod raws over and the problem still persists there.

Oh, and failing to put the space between the -location z coord and the ending bracket puts you in the arena spawn menu.  Dunno how much people care about idiot-proof code, but there it is.

Thank you for the testing, this give me some new theories about what causes new units to be hostile for a few frames upon spawn. I believe that it was caused by DF's enemy cache but it seems that any units keep their wild behavior as a predator, prey or curious beast until DF goes and refresh their AI. Is there a "wild animal" cache somewhere?

I need to replace some hacks in create-unit. Meanwhile, if you open the script and remove the three anon_x lines at line 344, create-unit may work again but with strange effects.

[lethosor]

Numbering for units without a name given is broken.  Most of the time, the number that the creature displays is a very large, sometimes negative number. Further spawned units of that race increment the number as expected.  Occasionally, the number starts at 1 as expected. Given that one time I saw an opossum 5(the first of its kind spawned) immediately after I just spawned a coati 5 (the 5th of its kind), I would guess that the variable for unit numbering isn't being initialized and the code branch that deals with numbering/naming creatures who are the first of their kind isn't executing or is missing the code to assign it to 1. Either that or there is a bad pointer address/pointer math somewhere (don't know whether the code for it is in C or Lua).

What mode are you in (fortress, arena, adventure)? The initialization behavior varies between them. I thought I had fixed it in one, but it might have broken in another.

The -domesticate flag throws an error, and units with it but not -setUnitToFort are friendly, not fort pets (the latter may be intended behavior, I'm not sure).  Here is the stack trace: 
...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:344: Cannot write field unit.T_enemy.anon_4: not found.
stack traceback:
   [C]: in metamethod '__newindex'
   ...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:344: in global 'domesticate'
   ...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:537: in local 'script_code'
   ...y\Desktop\games\DFFE temp\DFFE 14.04\hack\lua\dfhack.lua:562: in function 'dfhack.run_script_with_env'
   (...tail calls...)

To script authors: this is why you NEVER use "anon" variables. Submit a PR to give them names!
Boltgun: either they were given names or some other unnamed fields were given names. I'll try to investigate what the right names should be.
Edit: fixed: https://github.com/DFHack/scripts/commit/96b118b2e7fe8d91b59e0cc1c7951bf27a5e6698

[thefriendlyhacker]

I am having a few problems with modtools/create-unit.  I am trying to use it in an old mod I am updating to the latest DF version, but I have reproduced the problems in a vanilla .05 save moved to both DF .07/DFHack .07-alpha1 and DF .09/DFhack .09-alpha1.   I could *not* reproduce some of them in a fresh embark on a fresh .09 install, but all I did there was create a 5 year pocket world and spawn dogs next to the starting wagon.  All of this is 64bit win 7, by the way.

Spoiler: details (click to show/hide)

Sometimes when an animal is spawned with the -setUnitToFort arg, it attacks and is attacked by my other units indiscriminately, despite showing up in the units screen as a fort pet.  This happens to animals but I just tried to spawn a pony in .09 (MLP FO:E) and they seemed to work just fine (inc. changing/performing labors).  Animals without the -setUnitToFort arg are friendly and do not attack/get attacked (which is afaik expected). 

Numbering for units without a name given is broken.  Most of the time, the number that the creature displays is a very large, sometimes negative number. Further spawned units of that race increment the number as expected.  Occasionally, the number starts at 1 as expected. Given that one time I saw an opossum 5(the first of its kind spawned) immediately after I just spawned a coati 5 (the 5th of its kind), I would guess that the variable for unit numbering isn't being initialized and the code branch that deals with numbering/naming creatures who are the first of their kind isn't executing or is missing the code to assign it to 1. Either that or there is a bad pointer address/pointer math somewhere (don't know whether the code for it is in C or Lua).

The -domesticate flag throws an error, and units with it but not -setUnitToFort are friendly, not fort pets (the latter may be intended behavior, I'm not sure).  Here is the stack trace: 
...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:344: Cannot write field unit.T_enemy.anon_4: not found.
stack traceback:
   [C]: in metamethod '__newindex'
   ...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:344: in global 'domesticate'
   ...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:537: in local 'script_code'
   ...y\Desktop\games\DFFE temp\DFFE 14.04\hack\lua\dfhack.lua:562: in function 'dfhack.run_script_with_env'
   (...tail calls...)
There *was* also some other weirdness with units that had -setUnitToFort but not -domesticate being unbutcherable/ungeldable, but that went away when I went from .07 to .09. Otherwise -domesticate didn't make a difference at all in any of my tests.

I transferred a vanilla .05 fort to .07, installed dfhack .07 and did some testing.  This is what I found by spawning animals into the middle of a 10x20ish training area filled with about 60 dwarves:
- all the carnivores and bonecarns I tested were attacked immediately and killed (they often didn't make it past a single step(.)).  Occasionally the animal attacked first before being obliterated.  The only exception to this was cats, weirdly enough, who were left alone.  I also tried taking bonecarn out of dog and it made no difference.  I also tried taking a single step(.) when I spawned a lion, and I noticed that it was overcome by terror (while bolts were already in flight).
- non-carnivores/bonecarns were not immediately attacked, but would be constantly going in and out of overcome by terror (even dangerous ones, like elephants or rhinos).  The only exception to this was a Mandrill, which was attacked immediately (which may have something to do with curiousbeast eater/item). I tried putting bonecarn on a Horse but it still spawned safely.  Weirdly enough, if another animal that gets attacked was spawned immediately after the first was then the first would also get attacked, but this didn't seem to apply if the first animal was spawned some time ago.  Lastly, a couple of non-carnivores were attacked some time later, although I didn't actually see it happen.  A badger at the meeting hall went enraged, attacked someone and was then punched to death, while a donkey by the archery range was shot by a crossbow repeatedly without a report of it attacking anything first.
For reference, this is what I spawned:

Killed Immediately
several dogs, 1 after removing bonecarn from the save raws, 1 after adding at peace with wild
1 bobcat, jaguar, rattlesnake, saltwater croc, Vulture
2 dingos, Lions
6 Coatis, one of which was spawned next to other animals in a different area (the meeting hall, which had half a dozen armed dwarves in it)
1 Mandrill (the only killed animal without bonecarn/carnivore)

Not attacked immediately
1 giraffe, cat, skunk, warthog, hare, weasel, Gazelle, Sheep, Pig, Goat, Chicken, Cavy, Rhino
2 elephants
1 badger, later killed after enraging and attacking first according to the report, unknown exactly why
1 Ibex, killed immediately after when a dingo was spawned in
1 Opossum, killed immediately after when Coati was spawned in
1 Donkey, was killed later for unknown reasons without any report of attacking first
3 Horses, including 1 with bonecarn
5 Chimpanzees, including 4 at once in the same square

I tried spawning 6 dogs in a new world/embark, and only 1 of them was attacked (the newly drafted newbie axe wielding commander exchanged hits with it for a couple of pages and then left it alone, after which it crawled away a few squares and bled to death).   I then got DF/DFhack .09 and tried the same thing with another 20 dogs, but could not reproduce it again - all I managed was to get dogs to attack each other for a bit if I spawned them on top of each other.  I might have been unlucky though.  In any case, I unzipped a fresh .09 version and copied my mod raws over and the problem still persists there.

Oh, and failing to put the space between the -location z coord and the ending bracket puts you in the arena spawn menu.  Dunno how much people care about idiot-proof code, but there it is.

Thank you for the testing, this give me some new theories about what causes new units to be hostile for a few frames upon spawn. I believe that it was caused by DF's enemy cache but it seems that any units keep their wild behavior as a predator, prey or curious beast until DF goes and refresh their AI. Is there a "wild animal" cache somewhere?

I need to replace some hacks in create-unit. Meanwhile, if you open the script and remove the three anon_x lines at line 344, create-unit may work again but with strange effects.

As a quick test, I removed those 3 lines and tried spawning a few units in my modded .09/.09-alpha1 game that would fight previously on spawn. The short of it is that while some things are still broken, unless weird problems crop up later then I have a workable command I can use now to spawn pets from a workshop (thanks!).

Spoiler: results of quick test (click to show/hide)

Both -domesticate and -setUnitToFort produced a Stray animal with it's name+number displayed (number still broken) that fought with other fort units.  They did wander past a few units before going to the fort central stairwell and getting attacked (which I have seen happen before, so it appears to be behaving identically). 

-Domesticate and no -setUnitToFort produced a Stray fort controlled animal that was not attacked.  It's number was not visible. I didn't test for very long, but the creatures managed to wander around while I was testing other create-unit commands and they did *not* fight once, and didn't appear to behave differently to normally acquired pets afaict.  Unless some "unusual" behavior crops up later then this is fine for my purposes (thanks once again).

No -Domesticate and -setUnitToFort produced a fort controlled creature (no Stray Tag) that fought similarly to the above -setUnitToFort creature.

Having neither produced a wild animal.

As before the fix, spawning an intelligent non-pet with -setUnitToFort resulted in an initially laborless peasant that had the same broken numbering but otherwise functioned correctly.

What mode are you in (fortress, arena, adventure)? The initialization behavior varies between them. I thought I had fixed it in one, but it might have broken in another.

All the create-unit stuff I have been doing is in fortress mode.

[lethosor]

Can you try replacing the 3 lines with the fixed ones I linked instead of deleting them? I doubt they have much to do with your issue, but I want to be safe.

"spawnunit CAT MALE" (which uses modtools/create-unit) produced a cat called "Cat 1" in fortress mode for me, and I'm using a tool that initializes all memory to 0xAA, so if the ID weren't initialized, it should have been a large negative number. Can you provide a specific command that produces a badly-numbered unit?

[Boltgun]

To script authors: this is why you NEVER use "anon" variables. Submit a PR to give them names!
Boltgun: either they were given names or some other unnamed fields were given names. I'll try to investigate what the right names should be.
Edit: fixed: https://github.com/DFHack/scripts/commit/96b118b2e7fe8d91b59e0cc1c7951bf27a5e6698

For info, create-unit broke creatures with special loyalty such as underworld or residents and long trials and errors revealed that those three anons needed to be set. Perhaps we can drop the two unks if those creatures do not turn weird, if not... we found a clown AI flag.

[lethosor]

The point is that if you determine that something needs "anon" fields, you need to give them names. Even "unk" names, like two of them have now, are better than no names ("anon" names are automatically generated).

[thefriendlyhacker]

Can you try replacing the 3 lines with the fixed ones I linked instead of deleting them? I doubt they have much to do with your issue, but I want to be safe.

"spawnunit CAT MALE" (which uses modtools/create-unit) produced a cat called "Cat 1" in fortress mode for me, and I'm using a tool that initializes all memory to 0xAA, so if the ID weren't initialized, it should have been a large negative number. Can you provide a specific command that produces a badly-numbered unit?

Ok, getting out the fresh vanilla 5 year pocket embark and testing this a bit (.09+dfhack .09, 64 bit win7).

For reference, what I get without deleting or replacing any code

Spoiler: control run (click to show/hide)

I ran the following command after using teleport -showpos to get some coords:
modtools/create-unit -race DOG -caste MALE -setUnitToFort -domesticate -location [ 95 94 174 ]
This spawned a pet dog called Dog -467715215, Dog (as listed in unit list under pet/livestock). An error was thrown when running the command, same as in my first post.

I then ran spawnunit DOG MALE.  This produced a wild dog.

I then ran:
modtools/create-unit -race DOG -caste MALE -setUnitToFort -location [ 95 94 174 ]
This created a dog listed Dog in the units screen with a name of Dog -467715213 when looking at it with (v) (incremented by 2 from first spawned dog).  Or, to be more specific, it looks like this:
Dog
"Dog -467715213"

I then tried:
modtools/create-unit -race CAT -caste MALE -setUnitToFort -location [ 95 94 174 ]
I got a Cat listed Cat, with a name of Cat 2047 in (v) screen.

After typing die in dfhack console, I then replaced the old 3 lines in the script with the ones from your link and loaded up the same fresh embark.

Spoiler: results (click to show/hide)

Using the same commands:
modtools/create-unit -race DOG -caste MALE -setUnitToFort -domesticate -location [ 95 94 174 ]
Spawned a dog listed Dog in unit list.  (v) showed a name of Dog 1276912175. No error thrown.

Then tried spawnunit DOG MALE.  Same again, wild dog.

Then tried the same dog command without -domesticate.  As before, Dog in unit list, "Dog 1276912177" in (v) (incremented by 2).

Then the cat.  Cat in unit list, "Cat -1946156959" in (v)

EDIT: I wasn't getting units attacking each other either before or after except for the wild dog, so I am going to transfer that .05 fortress over and spawn some dogs in the packed training room. 

EDIT 2: Ok, getting coords with teleport and spawning dogs in the middle of a packed training room of a large fortress.  Still have new code.

Spoiler (click to show/hide)

With -domesticate: Stray Dog in unit list (weird, it wasn't stray on the fresh embark),  "Dog 517843281" in (v).  Attacked upon unpausing.

spawn unit again created a wild Dog.  Attacked and killed.

Without -domesticate: Dog in unit list, Dog 517843285 (I derped a couple of times and spawned dogs in the wrong spot twice before aiming at the right spot for spawnunit/put new coords in for create-unit, so the number incremented correctly)

I also realized I forgot to test -domesticate alone, so...
In copied .05 fort, new code:
Stray Dog, no name, not attacked, wandered off to meeting area like a normal dog.

After booting up fresh embark again, new code:
Same again, Stray Dog, no name, hovered around wagon as expected.

[Bumber]

What's the deal with all the "exterminate" command's pronouns? Options include "him", "her", and "it" / "that". The script will print a message if you choose wrongly.
Seems like unnecessary confusion for something that isn't at all relevant to the function. Why not just "exterminate target" or "exterminate selected"?

[lethosor]

Agreed. I'll add those and get rid of the message.

[PatrikLundell]

What's the deal with all the "exterminate" command's pronouns? Options include "him", "her", and "it" / "that". The script will print a message if you choose wrongly.
Seems like unnecessary confusion for something that isn't at all relevant to the function. Why not just "exterminate target" or "exterminate selected"?

The only reason I can see for the rejection is if it's the wrong target (e.g. two units at the same tile). However, there's only a 50% chance of it catching an error at the cost of annoyance when you just want to get rid of a bugger without examine it's gender first.