Print

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

Blah

10 (100%)

Bluh

0 (0%)

Total Members Voted: 10

[Harem-Rose]

Sounds good.


I appreciate you looking into this. I am guessing that since the issue lies with the scripts themselves and not any of the raws that whatever fix is generated would be applicable to current and new worlds? It would be great to be able to convert Stampy and his friends into functioning members of society.

Were you able to determine why the two that were converted properly ended up getting into fights with everyone and everything around them?

[Amostubal]

so far I'm at an impass...

what was unit.relation.anon_2 and unit.relations.anon_3 referring to?  I've been searching the DFHack repository, and can't find any references to these.

The others are all now unit. instead of unit.relations. so I'm going to delete relations and run it and see if it 'breaks' at anon_2.... if it does, then I'm going to try something else.

they may have been renamed, if they were discovered, because it looks like all anons were removed from unit in dfhack...

[Harem-Rose]

I am not certain what those are referring to.

I made no changes to the script files other than replacing the existing ones with what were in the succupatch file. I have a small bit of scripting experience but none of it is in LUA. I opened the files to see if I could find what line was causing an issue and saw the unit.relations references but I had no idea what they were referencing or pointing to.

[Boltgun]

so far I'm at an impass...

what was unit.relation.anon_2 and unit.relations.anon_3 referring to?  I've been searching the DFHack repository, and can't find any references to these.

The others are all now unit. instead of unit.relations. so I'm going to delete relations and run it and see if it 'breaks' at anon_2.... if it does, then I'm going to try something else.

they may have been renamed, if they were discovered, because it looks like all anons were removed from unit in dfhack...

Afaik those values has something to do with hostility, not changing these lead to infighting and fps death.

I'll check with gui/gm-editor and see what data you can find inside relations. It is probable that these anons has been identified and renamed into something better.

[Amostubal]

Maybe lastattacker?  that's a relationship_id now.

I'm just confused... after removing the other 'relations' they all work... I don't know when those were committed out, I've searching the github structure trying to figure out when they were removed, then I can see what replaced them.

oh @ harem-rose:
when you have an error, in dfhack, exit the embark(or tell dfhack to die... it kills the game without saving, great when your testing a save point of interesting data), and then check stderr.log ; that's where everything that DFhack did is output at and the last set of lines will look like this.

Code: [Select]

...1.24c (43.05) - TEST\Dwarf Fortress\hack\lua\makeown.lua:151: Cannot write field historical_figure.anon_1: not found.
stack traceback:
[C]: in metamethod '__newindex'
...1.24c (43.05) - TEST\Dwarf Fortress\hack\lua\makeown.lua:151: in function 'makeown.make_citizen'
...on1 - Before Corruption/raw/scripts/succubus/corrupt.lua:266: in global 'corrupt'
...on1 - Before Corruption/raw/scripts/succubus/corrupt.lua:111: in local 'findLos'
...on1 - Before Corruption/raw/scripts/succubus/corrupt.lua:351: in local 'script_code'
...V1.24c (43.05) - TEST\Dwarf Fortress\hack\lua\dfhack.lua:562: in function 'dfhack.run_script_with_env'
(...tail calls...)
[C]: in field 'runCommand'
...V1.24c (43.05) - TEST\Dwarf Fortress\hack\lua\dfhack.lua:580: in upvalue '_run_command'
...V1.24c (43.05) - TEST\Dwarf Fortress\hack\lua\dfhack.lua:595: in function 'dfhack.run_command'
...warf Fortress/hack/scripts/modtools/reaction-trigger.lua:146: in local 'doAction'
...warf Fortress/hack/scripts/modtools/reaction-trigger.lua:186: in function <...warf Fortress/hack/scripts/modtools/reaction-trigger.lua:115>
Invoking: die

anyways boltgun its definitely a deprecated script all together from DFHack, its not in their current pack.  looks like it was dropped after 42.06 along with most of tweak.

possibly some other way to perform it may be through calling transform.  not sure how well that works, but its pretty cool command, as it allows duration time and saving of previous race data so you can detransform lol... I could see a super saiyan script using that..  but that doesn't switch ownership.... back to what I was doing hunting down when those anons disappeared...

[Harem-Rose]

I wasn't sure if you wanted me to go ahead and do that now, but I did so just because.
I uploaded the stderr.txt file because the stderr.log file did not seem to have any useful information.

What command did you use to tell dfhack to "die"? I tried simply 'die' but it didn't seem to want to work.

Please let me know if you need more information.

[Amostubal]

@ Harem Rose

yeah die is the command in dfhack to kill dwarf fortress takes a minute sometimes, you can't be in any menus or it just hangs.

nah stderr.log is a full list of "errors" in the last game session that was pushed by DFHack.  Its readable in txt, so you don't have to make images of the dfhack console, as most of what it has going on is shown in stderr.log.  makes it easier to just copy and paste errors, instead of screenshot.  Its rewritten every time dfhack reloads.

@ boltgun:

OMG I hate this issue... we break this thing every 6 months, lol.

so I was going through corrupt I came across the mo.xxxx commands and I added these lines around it:

Code: [Select]

   
if unit.race == df.global.ui.race_id and debug then print('it should run make_citizen prior to exiting make_own') end
mo.make_own(unit)
if debug then print('we made it past make_own') end
if unit.race == df.global.ui.race_id and debug then print('it should of already ran make_citizen') end
mo.make_citizen(unit)
if debug then print('we made it past make_citizen') end

The interesting result is that the only line that printed was:
we made it past make_own

which is interesting to me as this line is in make_own:
    if unit.race == df.global.ui.race_id then

followed by a call to make_citizen.... so I ran code to see what the two are at that point, so I changed the earlier code to:

Code: [Select]

   
if unit.race == df.global.ui.race_id and debug then print('it should run make_citizen prior to exiting make_own')
elseif debug then print('unit.race: '..df.global.world.raws.creatures.all[df.global.ui.race_id].creature_id..", df.global.ui.race_id: "..df.global.world.raws.creatures.all[df.global.ui.race_id].creature_id) end

to see what those 2 races are at that point... which I thought should be both SUCCUBUS... which they are and they are not...


as you can see in 2 different lines I have it pulling the numbers and the creature_id... and in both they are succubus, but they are different numbers....

that's more confusing then ever....

in makeown.lua they seem to have the confidence that the 2 should have the same number... but since they don't that's an error in makeown.  it should be checking all the way down to the creature_id.... but the other end is why is SUCCUBUS in 2 creature_ids... I've checked a couple of times there is only one succubus definition in the folder.  I can only think that its picking up something else like the entity file being labeled SUCCUBUS... I tried a few other variables and either hit error or got the same answer on that one.... so I'm not sure what it is doing or why... but I returned to the previous issue of anon....

I couldn't find out what they was from the dfhack github, etc.... so I first tried the script without the anon lines and... hit more errors...  this time inside of corrupt.lua
here's the lines to change all related to the relations.....

Code: [Select]

function clearMerchant(unit)
local draggee

-- Free the draggee as well and makeown + tame it
if -1 ~= unit.relationship_ids.draggee_id then
dragee = utils.binsearch(df.global.world.units.active, unit.relationship_ids.draggee_id, 'id')

if dragee then
mo.make_own(dragee)
dragee.relationship_ids.dragger_id = -1
dragee.flags1.tame = true
dragee.training_level = df.animal_training_level.Domesticated
end
end

unit.relationship_ids.draggee_id = -1
unit.relationship_ids.rider_mount_id = -1
unit.relationship_ids.mount_type = 0
unit.flags1.rider = 0
end

-- Take the creature out of its cage
function clearCage(unit)
local cage = dfhack.units.getContainer(unit)

if -1 ~= cage then
teleport.teleport(unit, xyz2pos(dfhack.units.getPosition(unit)))
end

unit.flags1.caged = false
end

-- Takes down any hostility flags that mo didn't handle
function clearHostile(unit)
unit.population_id = popId
unit.cultural_identity = -1

unit.flags1.marauder = false
unit.flags1.active_invader = false
unit.flags1.hidden_in_ambush = false
unit.flags1.hidden_ambusher = false
unit.flags1.invades = false
unit.flags1.coward = false
unit.flags1.invader_origin = false

unit.flags2.underworld = false
unit.flags2.visitor_uninvited = false
unit.flags2.visitor = false
unit.flags2.resident = false
unit.flags2.calculated_nerves = false
unit.flags2.calculated_bodyparts = false

unit.invasion_id = -1
     --It acts like these 2 don't exist....
--if unit.relationship_ids.group_leader then unit.relationship_ids.group_leader = -1 end
--if unit.relationship_ids.last_attacker then unit.relationship_ids.last_attacker = -1 end

unit.flags3.body_part_relsize_computed = false
unit.flags3.body_temp_in_range = true
unit.flags3.size_modifier_computed = false
unit.flags3.compute_health = true
unit.flags3.weight_computed = false

    unit.counters.soldier_mood_countdown = -1
    unit.counters.death_cause = -1

    unit.animal.population.region_x = -1
    unit.animal.population.region_y = -1
    unit.animal.population.unk_28 = -1
    unit.animal.population.population_idx = -1
    unit.animal.population.depth = -1

    unit.counters.soldier_mood_countdown = -1
    unit.counters.death_cause = -1

    -- weird, unknown territory
    unit.enemy.anon_4 = -1
    unit.enemy.anon_5 = -1
    unit.enemy.anon_6 = -1
    --unit.enemy.anon_7 = 0
    --unit.status2.unk_7c0 = -1
    --unit.enemy.unk_v40_2_count = 11
    --unit.unk_100 = 3
end

and that got me past several more errors....

but I already see that the issue with ids earlier is coming back to bite... I've got it to a "friendly tame elephant in a cage...." as best I can describe it... It crashed on something in the merchant removal script... which will probably have to be trashed.  I think all the errors are because its not switching the race for some reason I think its something to do with those ID difference or its not getting the caste call or race call correctly, currently its a succubus war elephant which doesn't make sense.....

I've got to get to RL for a bit, I'll look into it later.

[Harem-Rose]

Sorry for the confusion. The screenshot of stderr.log was of notepad.exe, not the console. I forgot to include the window bar over the top.

Also, I was wondering if the corruption task is supposed to affect all nearby enemies, or just 1 at a time. It only seemed to affect a single one when I was trying to use it.

[Amostubal]

While looking at it, I spotted that, I really didn't think it would do it any other way but basically it checks for line of site over a distance of 10 squares circular starting along the line going south, as best I can tell from the script.  the first target discovered along that line is tested for validity, and if it is valid, it then performs the rest of the transformation commands in the following order.

transformation-> make own -> make civilian -> remove hostility -> remove merchant (which seems excessive as its very unlikely you will ever have merchants to capture, unless you place it beside a trade outpost) -> remove from cage... the issue is this is just WAY too much work and WAY too many things that could go wrong.

@ boltgun:  I have an idea....  lets just find the unit... save its name, figure out the caste to replace it, teleport it out of the cage, and scuttle it (set a flag, simple enough, you end up with a corpse on the ground), then use create-unit to create the new unit according to caste, give it the same name, and set its civ/group ids and have it teleport on top of the corpse. And your done.  Create-unit is operating correctly, now, other than the occasional fail, if 0,0,0 is a blank map tile, but other than that its 90% operating....

I'm going to write a quick script on that idea, chop the rest of this script up to accomplish it, and see if that works.

[Amostubal]

hold on to that thought, you got to see these images:




I went back to the script... thinking about my issues and saying to myself something wasn't right... it wasn't... I looked at the script and seen a reoccuring error where 1 term was used in place of another... I fixed it... kicked out the merchant script, and wala the elephants are elephants! and suddenly they transform into Oni, mace dames, and they pop out their cage and charge into the fort thirsty as hell for a drink.... but I think I was pushing my limits with all the restarts..... my game insta died while trying to tag them all as nickname elephant X and checking their thoughts.... they are all afraid, traumatized, and angry about being confined.  they need a real brain wash.... I've got to retest and see how far they get before they go beserk or get into a fight...

basically I'm out of the thicket into the rainforest, give me another hour or so of testing see if I can't brainwash them real good... If I remember right there is already a happy thought generator. somewhere.

oh and harem-rose, thanks, it was your question that was making me think about it.... I saw were it made the list and the direction it started in... but I was wondering what it had done with all the other units it should of seen too.... that along with the reply about the merchants, and me being upset about the transformation not working and it all came together in my head.... now then a full restart of my computer, come back and try again, then see if they go beserk killing people.... if so... I'm going to armok bless them (I think that was it...).

[Harem-Rose]

That's incredible.

I did build a den near the trade depot and I have been dying to try it on goblins but I have only ever succeeded at getting them in to trade once. I was nowhere near where I needed to be to try to corrupt them at the time. All the other times, they run away right after they get to the depot because one of the wagons scuttles out of fear from the nauseating filth rain.
The trade depot that is supposed to be used is one one level below top z level. Ignore the one that's on the surface. That was an emergency one because of a rude guest that destroyed my main depot.

On the save I provided there is a happy thought generator room. It should be directly to the left of the central staircase on the same floor as the workshops. The workshops are right above the floor with the magma and water stream underground. If you have gone down to bedrooms, you have gone too far.

[Amostubal]

okay I got to step away from this one.....  I've got them as far as appearing....  I don't know what to do with them then.. I'm going to package the 2 scripts that changed and send them to bolt gun, see if he can figure it out...   I think its the teleporting out of the cage... it leaves behind what I call the after thought soul....  If you had them still in the cages you could move them to a lockdown area where food and water is stored for them, enough for say a year, and a few game rooms and a pile of toys... leave them in for a year and see what happens... I tried it again... with only 1 left ( i exterminated the others ) ran a stepford wife level brainwash on the last one when he popped out and they still mauled him at the top of the stairs...  I dont know what's going on.... I think I'd rather go back to my other idea and just scuttle the caged units and create new units...  less issues.

[Harem-Rose]

As I mentioned in an earlier post; I know a little bit about scripting, just not LUA, so anything I say in this post should be taken as a loose suggestion.

It seems to me that the issue that's happening doesn't really lie with the new converts so much as it lies with the other fort member's impressions of them. I thought I saw Boltgun mention something earlier in this thread where the game only re-checks aggression every so often. If you look at the combat (r)eports after one gets released from conversion, it always seems to be that they want to mind their own business when suddenly they get attacked by something or or someone else in the fort. They don't even seem to try to fight back. More or less they just seem to want to get away.

I personally think that deleting the old unit and creating a new one isn't a bad idea. It would be a lot easier to make a bunch of changes to a newly created blank unit than trying to change the attitude of 200+ other units on the map. It would probably be easy to copy all of the unit information from the old unit to the new one.
I noticed they didn't have anything in their relationship tab other than a deity, however their personality tab had just as much in it as any other fort unit.
Another thing that I noticed is that the War Elephants that had kills and actually got converted properly would have "kills" listed on their info sheet.
You might be able to copy everything that the old unit has into the new unit. If they are still getting attacked despite being a "new unit", you could take away all the personality/relations/history copying and add them in 1 at a time to see what causes the previous fort members to attack their new friends.

If you can, it might also be prudent to make sure that the removed old unit is not listed under the missing/deceased tab. It would be a little confusing to have two units with the same name listed on two different tabs. Hell, if it's possible you could even add a tab for "converted" and have the new units listed there as well as citizens. It could be like a trophy case for stolen rescued units.

I am not sure how much of this helps but I figure that any ideas are better than none.
Please let me know what you think.

Thank you

[Amostubal]

yeah I really think that's it... the base is just still aggroed on them.  okay I'm home for a bit today.. I'm going with my scuttle the old unit/craeate new unit idea... the basics are that I can create all the units you ever wanted.... but it has 1 bug.... if the lowest point at 0,0 has no mapdata there is about a 10% chance of insta crash....  killing units is easy... you just set them to scuttle and they die on the spot.  so I grab the data on their position, name, chosen caste, send that to create-unit, and set the old unit to scuttle.  job done.... I'll go work on it now.

[Harem-Rose]

I've read a bit about that the lowest map point with no metadata being a problem although I am not 100% sure what it means.
That being said, is there any way to artificially add metadata to 0,0 at the lowest map point when an embark point is embarked upon. Alternatively, to have the game check, and add it every time the game is loaded?

As for scuttling units:
Do they show up in missing/deceased?
Do they drop their gear first?