Print

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

[Amostubal]

Continuing from my previous conversation.....

Okay so here I am again.  So I moved the New version of create-unit.lua to the raw\scripts folder that had fixed my earlier problem allowing me to run this onLoad.init command with no issues:

Code: [Select]

modtools/reaction-trigger -reactionName KILL_CAPTIVE_DWARF -command [ create-unit -race FAKE_SAPIENT -caste MALE_DWARF -location [ \\LOCATION ] -age 20 -flagSet [ scuttle ] ]
:
And yes a dead dwarf appears at the feet of the one who operates this command, from the reaction... well its a fake dwarf... but it gets the job done of getting dwarf skulls (and other commands for humans, elves, goblins, kobolds, etc skulls and meat for everyone!).

well we had a different script that when reviewed was the new version of create-unit.lua renamed to create-unit-friendly.lua with a few minor changes.... I was shocked at how similar it was, and decided that because I couldn't get it to do anything right(moved it etc like I did with create-unit.lua), I removed it, retried these lines with create-unit...

Code: [Select]

modtools/reaction-trigger -reactionName RELEASE_DWARF_MIGRANTS -command [ create-unit -race DWARF -caste MALE -civId a -groupId a -location [ \\LOCATION ] -name MOUNTAIN -age 20 ]
modtools/reaction-trigger -reactionName RELEASE_DWARF_MIGRANTS -command [ create-unit -race DWARF -caste MALE -civId \\LOCAL -groupId \\LOCAL -location [ \\LOCATION ] -name MOUNTAIN -age 20 ]
The first line is the original line from the original onLoad.init, modified to access create-unit, we got a dwarf, but it was just set to friendly, and not a part of the fort civ/group at all.   It eventually wandered around the tavern then disembarked to who knows where....

The second line is the line written based on the information in the first part of "create-unit.lua" that says to use \\LOCAL to make the created unit a member of the local civ and group.... and well this dwarf did the same as the first one.  It appeared but was set to friendly, not a member of the civ/group, hung out roamed a statue garden then left to points unknown.  so now we have 2 free roaming dwarves just enjoying themselves free from the politics of any civ (and not forced into slave labor in my deep mines)...

The only thing I have to say is I'm glad it pops up in the right location?  but how do I force the dwarf to be a member of the fort?

[KillzEmAllGod]

Still getting the odd crash when zooming to units.

Mind linking me to where this was reported before? I don't remember seeing it recently. Have you verified that it doesn't occur without DFHack (assuming it occurs consistently with DFHack)?

Edit: found it:

Getting a crash now and then when going to some units through to unit menu as well as when pressing v to inspect or examining creatures. Mostly seems to happen to creatures on different z levels, think it might be with some of the DFHack options on some of these things.

This is from quite a while ago. I can't think of many DFHack tools that have anything to do with that screen. What DFHack version are you using? Are you using Truetype? TwbT? You could try disabling the search and manipulator plugins, I guess.

I was just using the default on the pre release, just seems to happen when I use z: Go to Unit. no idea what the cause could be but that's the thing that I last did when it happens. 64 bit this time last one would have been 32 bit from ages back.

edit: Just to be clear that it doesn't happen what so ever without DFhack. So it might be something on one of the screens that causes it for me or could it be one of the settings in init?

[lethosor]

What version, precisely, of DFHack are you using? "the pre release" isn't specific enough for me to tell. Something like "0.43.05-alpha3" would be, and that should be displayed on the title screen (and in the DFHack console).

just seems to happen when I use z: Go to Unit

By "seems to", are you saying that it crashes some time later, or that you can't get anything else to cause the crash?

[Amostubal]

Continuing from my previous conversation.....

Okay so here I am again.  So I moved the New version of create-unit.lua to the raw\scripts folder that had fixed my earlier problem allowing me to run this onLoad.init command with no issues:

Code: [Select]

modtools/reaction-trigger -reactionName KILL_CAPTIVE_DWARF -command [ create-unit -race FAKE_SAPIENT -caste MALE_DWARF -location [ \\LOCATION ] -age 20 -flagSet [ scuttle ] ]
:
And yes a dead dwarf appears at the feet of the one who operates this command, from the reaction... well its a fake dwarf... but it gets the job done of getting dwarf skulls (and other commands for humans, elves, goblins, kobolds, etc skulls and meat for everyone!).

well we had a different script that when reviewed was the new version of create-unit.lua renamed to create-unit-friendly.lua with a few minor changes.... I was shocked at how similar it was, and decided that because I couldn't get it to do anything right(moved it etc like I did with create-unit.lua), I removed it, retried these lines with create-unit...

Code: [Select]

modtools/reaction-trigger -reactionName RELEASE_DWARF_MIGRANTS -command [ create-unit -race DWARF -caste MALE -civId a -groupId a -location [ \\LOCATION ] -name MOUNTAIN -age 20 ]
modtools/reaction-trigger -reactionName RELEASE_DWARF_MIGRANTS -command [ create-unit -race DWARF -caste MALE -civId \\LOCAL -groupId \\LOCAL -location [ \\LOCATION ] -name MOUNTAIN -age 20 ]
The first line is the original line from the original onLoad.init, modified to access create-unit, we got a dwarf, but it was just set to friendly, and not a part of the fort civ/group at all.   It eventually wandered around the tavern then disembarked to who knows where....

The second line is the line written based on the information in the first part of "create-unit.lua" that says to use \\LOCAL to make the created unit a member of the local civ and group.... and well this dwarf did the same as the first one.  It appeared but was set to friendly, not a member of the civ/group, hung out roamed a statue garden then left to points unknown.  so now we have 2 free roaming dwarves just enjoying themselves free from the politics of any civ (and not forced into slave labor in my deep mines)...

The only thing I have to say is I'm glad it pops up in the right location?  but how do I force the dwarf to be a member of the fort?

Okay I have crafted a fix...  After forcing the script to print out info on what it was receiving, I found that it wasn't getting \\LOCAL from the onLoad.init.  it was getting LOCAL instead.  Well no matter what I did to the onload.init, it never got \\LOCAL.... I tried [ \\LOCAL ], "\\LOCAL", '\\LOCAL', \\\LOCAL and \\\\LOCAL and it all went became just LOCAL at the script.  So I rewrote the lines in the script here's the lines I changed:

create-unit.lua:

Code: [Select]

481 if args.civId == 'LOCAL' then
482   civ_id = df.global.ui.civ_id
483 elseif args.civId and tonumber(args.civId) then
484   civ_id = tonumber(args.civId)
485 end
486
487 local group_id
488 if args.groupId == 'LOCAL' then
489   group_id = df.global.ui.group_id
490 elseif args.groupId and tonumber(args.groupId) then
491   group_id = tonumber(args.groupId)
492 end

so that edit, changing the '\\LOCAL' to 'LOCAL' ;
moving the create-unit.lua from hacks\scripts to raw\scripts;
and then changing the onLoad.init line:
modtools/reaction-trigger -reactionName RELEASE_DWARF_MIGRANTS -command [ create-unit -race DWARF -caste MALE -civId LOCAL -groupId LOCAL -location [ \\LOCATION ] -name MOUNTAIN -age 20 ]

gets the effect I want with zero errors. I'm leaving it that way unless someone else comes up with a better fix for it.

for anyone that didn't catch that this was on 43.05 beta 1.

[lethosor]

Did you try \LOCAL ?

Edit: no, that won't work. However, I have been using \\LOCAL in the console (with modtools/create-unit) for other tests in 0.43.05-beta1, and it has been working consistently. Perhaps you have an older version of the script still. Try replacing your hack/scripts/modtools/create-unit.lua with the original from 0.43.05-beta1, and get rid of the file you have in raw/scripts (e.g. move it somewhere outside of your DF folder if you don't want to delete it). Scripts in raw/scripts always take priority, so a broken script there will override a working script in hack/scripts.

Edit 2: oh, and you should probably be using modtools/create-unit.

[wuphonsreach]

Anyway, please be sure to report any issues you run into with 0.43.05-beta1. I'm hoping we can put up a stable release relatively soon.

Been running beta1 on 64-bit Linux for a week or two now with no issues.  Main things I use are prospect, showmood, cursecheck, autobutcher, seedwatch, zone, and cleanowned.

The only minor bug is that seedwatch does not auto-restart after loading (unlike autobutcher which works fine when loading up a save).

[KillzEmAllGod]

What version, precisely, of DFHack are you using? "the pre release" isn't specific enough for me to tell. Something like "0.43.05-alpha3" would be, and that should be displayed on the title screen (and in the DFHack console).

By "seems to", are you saying that it crashes some time later, or that you can't get anything else to cause the crash?

DFHack 0.43.05-beta1 though I have had it in the back in 42s ones as well. It's the last thing I do before the crash I get no other crash besides this one.

Started up DFHack and started going to units doesn't seem to be causing it at least not yet so something else must happen somewhere to cause it.

[lethosor]

The only minor bug is that seedwatch does not auto-restart after loading (unlike autobutcher which works fine when loading up a save).

That's really more of a missing feature - seedwatch has never persisted across save/load cycles.

DFHack 0.43.05-beta1 though I have had it in the back in 42s ones as well. It's the last thing I do before the crash I get no other crash besides this one.

Started up DFHack and started going to units doesn't seem to be causing it at least not yet so something else must happen somewhere to cause it.

0.42, really? This is the first time I've heard of the issue, so I'm fairly surprised. Does it occur with specific units? In a specific save? If so, uploading the save would be helpful.

[Amostubal]

Okay I've been having an issue with item-trigger.lua

basically repeatedly it spits out the same error over and over that looks like this:

Code: [Select]

...ed\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:116: attempt to index a nil value
stack traceback:
...ed\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:116: in global 'getitemType'
...ed\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:126: in global 'handler'
...ed\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:166: in global 'equipHandler'
...ed\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:175: in function <...ed\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:170>

so I thought maybe I'm having something that isn't built right causing thee error.  I looked at it and looked at and added this to the script trying to detect the error:

Code: [Select]

function getitemType(item)
 print("item: ", item)
 if item:getSubtype() ~= -1 then
  itemType = dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()).id
 else
  itemType = df.item_type[item:getType()]
 end
 return itemType
end
the print ("item: ",item) line is nice it gives me some info... not enough, but it got me looking for an answer. here's what the code looks like in the console when an error hits:



so now the issue is... why are plant growths causing this error... I tried a couple other lines trying to get the name of the item and it just errors out on the line... anyone have a clue what the line is I need to get the name to appear, so then I can start checking these "growths" for why they are erroring out?

does anyone else have similar issues with this script?

[KillzEmAllGod]

0.42, really? This is the first time I've heard of the issue, so I'm fairly surprised. Does it occur with specific units? In a specific save? If so, uploading the save would be helpful.

No idea though doing it at the start of loading a save doesn't seem to cause it so it must require something else to have happened before it. Seems like it would be a pretty painful crash to hunt down.

[lethosor]

Okay I've been having an issue with item-trigger.lua

...

so now the issue is... why are plant growths causing this error... I tried a couple other lines trying to get the name of the item and it just errors out on the line... anyone have a clue what the line is I need to get the name to appear, so then I can start checking these "growths" for why they are erroring out?

Nice catch! My best guess is that it's a DFHack issue, with something not handling plant growths correctly. The error appears to be happening on this line:

Code: [Select]

  itemType = dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()).id
which implies that one of these things is nil.

Try this:

Code: [Select]

function getitemType(item)
 print("item: ", item)
 if item:getSubtype() ~= -1 then
  print(item:getType())
  print(item:getSubtype())
  print(dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()))
  print(dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()).id)
  itemType = dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()).id
 else
  itemType = df.item_type[item:getType()]
 end
 return itemType
end
I suspect that the third call to print under the "if" statement will print nil and the fourth will trigger an error for plant growths (the first two should be okay, since item has to be non-nil for "item:getSubtype()" in the "if" statement to work at all).

[Amostubal]

Okay I've been having an issue with item-trigger.lua

...

so now the issue is... why are plant growths causing this error... I tried a couple other lines trying to get the name of the item and it just errors out on the line... anyone have a clue what the line is I need to get the name to appear, so then I can start checking these "growths" for why they are erroring out?

Nice catch! My best guess is that it's a DFHack issue, with something not handling plant growths correctly. The error appears to be happening on this line:

Code: [Select]

  itemType = dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()).id
which implies that one of these things is nil.

Try this:

Code: [Select]

function getitemType(item)
 print("item: ", item)
 if item:getSubtype() ~= -1 then
  print(item:getType())
  print(item:getSubtype())
  print(dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()))
  print(dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()).id)
  itemType = dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()).id
 else
  itemType = df.item_type[item:getType()]
 end
 return itemType
end
I suspect that the third call to print under the "if" statement will print nil and the fourth will trigger an error for plant growths (the first two should be okay, since item has to be non-nil for "item:getSubtype()" in the "if" statement to work at all).

lol you read my mind.... this is what I coded:

Code: [Select]

function getitemType(item)
 if item:getSubtype() ~= -1 then
  if dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()) then
   itemType = dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()).id
  else
   print("getSubtypeDef has returned nil. type:",item,item:getType(),"subtype:",item:getSubtype())
  end
 else
  itemType = df.item_type[item:getType()]
 end
 return itemType
end

I was still trying to get the item name... but I was at a loss...  its the dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()) that is returning nil for some reason.  here's the image of what it output....


 nice thing was its not a thousand things and pages of errors, I just get this quick nice list right about 200 ticks from when I load the save, but rarely get anything else let it run for most of a season (I wanted to 'die' before a new save occured)... I was about to try and figure out what type 55 is, then slapped myself on the head it has to be plantgrowths lol.... but I saw you had replied, so came back to remark on my progress.    The other error shown there, I was about to write a similar wrap around it and see if I couldn't identify what it was complaining about.  My biggest problem though is that I wish I understood the code well enough to get a name for what was causing the error.  there are many modified raws and I was concerned something had been a bad code.

separate note/issue: was there a change to unit.relations.{xxxxx}? I have one script that uses that and it now constantly spits out that relations is not found.  Think there must of been a change in dfhack to that, too.

[PatrikLundell]

Amostubal separate note/issue: If I'm not mistaken, units.relations stuff has been shifted up one level into the units structure itself (try gui/gm-editor on a unit and search for what you're looking for). I think that happened from 0.40.X to 0.42.X.

[lethosor]

Okay, it looks like the issue is a combination of several things:
- Plant growths can have subtypes that aren't -1
- item-trigger assumes that anything with a subtype that isn't -1 has an entry in world.raws.itemdefs
- There isn't anything in world.raws.itemdefs for plant growths (and there doesn't appear to be anything there we haven't identified yet, either)

I think changing the "if" statement to this would work:

Code: [Select]

if item:getSubtype() ~= -1 and dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()) then


separate note/issue: was there a change to unit.relations.{xxxxx}? I have one script that uses that and it now constantly spits out that relations is not found.  Think there must of been a change in dfhack to that, too.

Yes. Most stuff that was in "relations" was moved out into the main "unit" struct - e.g. "unit.relations.pregnancy_timer" is now "unit.pregnancy_timer". This was done because the old layout was wrong, and it had to be fixed to work properly with 64-bit DF.

Ninja edit:

Amostubal separate note/issue: If I'm not mistaken, units.relations stuff has been shifted up one level into the units structure itself (try gui/gm-editor on a unit and search for what you're looking for). I think that happened from 0.40.X to 0.42.X.

0.43.05, not 0.42

[Amostubal]

Okay, it looks like the issue is a combination of several things:
- Plant growths can have subtypes that aren't -1
- item-trigger assumes that anything with a subtype that isn't -1 has an entry in world.raws.itemdefs
- There isn't anything in world.raws.itemdefs for plant growths (and there doesn't appear to be anything there we haven't identified yet, either)

I think changing the "if" statement to this would work:

Code: [Select]

if item:getSubtype() ~= -1 and dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()) then


separate note/issue: was there a change to unit.relations.{xxxxx}? I have one script that uses that and it now constantly spits out that relations is not found.  Think there must of been a change in dfhack to that, too.

Yes. Most stuff that was in "relations" was moved out into the main "unit" struct - e.g. "unit.relations.pregnancy_timer" is now "unit.pregnancy_timer". This was done because the old layout was wrong, and it had to be fixed to work properly with 64-bit DF.

Ninja edit:

Amostubal separate note/issue: If I'm not mistaken, units.relations stuff has been shifted up one level into the units structure itself (try gui/gm-editor on a unit and search for what you're looking for). I think that happened from 0.40.X to 0.42.X.

0.43.05, not 0.42

Awesome! and I just fixed my other item-trigger issue....

Items used up in reactions with zero skill, are gone before item-trigger.lua can operate on them.  I have an exchanger that is flipping coins from silvers to gold... the last coin in triggers a nil error, as the interaction is instantly complete in the next step and the dropped item is suddenly gone in 1 tick.  any other reaction of such nature would cause the same error. Here's the fix to stop the error from occuring:

Code: [Select]

function equipHandler(unit, item, isEquip)
 local mode = (isEquip and 'onEquip') or (not isEquip and 'onUnequip')

 local table = {}
 table.mode = mode
 table.item = df.item.find(item)
 table.unit = df.unit.find(unit)
 if table.item and table.unit then -- they must both be not nil or errors will occur after this point with instant reactions.
  handler(table)
 end
end
leave it up to me to do something that would cause errors to occur....

relation issue:  how to get lastattacker ID lol.... on-death.lua script from roses.... was going to contact them next on that one.  its under relationship_ids in the gm-editor.  but unit.relationship_id.lastAttacker, unit.relationship_ids.lastAttacker, and unit.lastAttacker all do not work.