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.
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.
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.
Author
Topic: DFHack 50.13-r2 (Read 820261 times)