Print

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

[Ianflow]

I really want a Gorlak dancer fulltime.

I love this out of context.  All the pictures I've seen of this species seem to be just 90% head  and spindly short legs.

[KittyTac]

So as I've posted elsewhere, I have a visitor to my current fortress, who is a gorlak dancer.  He's been hanging out for a bit over a year now, and the longer he's here, the more fond of him I've grown.  I really want him to stay, but have yet to see a petition from him.  His graceful dancing heals the souls of all who witness his gyrations and nuanced movements.  Or something.

I'm wondering if there's a way, probably through dfhack, to force him to petition or just outright claim him as a member of our civilization.  I tried "tweak makeown" based on the dfhack plugin documentation, but that doesn't really seem to have the effect described.  Does anybody know of a way to make this happen?

Simple. Build a bedroom, then press "assign location", select the tavern name, then wait. You'll get a petition.

[Thisfox]

So as I've posted elsewhere, I have a visitor to my current fortress, who is a gorlak dancer.  He's been hanging out for a bit over a year now, and the longer he's here, the more fond of him I've grown.  I really want him to stay, but have yet to see a petition from him.  His graceful dancing heals the souls of all who witness his gyrations and nuanced movements.  Or something.

I'm wondering if there's a way, probably through dfhack, to force him to petition or just outright claim him as a member of our civilization.  I tried "tweak makeown" based on the dfhack plugin documentation, but that doesn't really seem to have the effect described.  Does anybody know of a way to make this happen?

Simple. Build a bedroom, then press "assign location", select the tavern name, then wait. You'll get a petition.

It's not that there are no petitions: It's that the particular petition desired isn't happening. Similar visitors are petitioning, but not the gorlak dancer.

[oldmansutton]

It seems like flags4.unk2 and flags3.unk23 might have something to do with visitors, as I'm noticing differences there between fort dwarfs, and visitors


New visitor came in with flags4.unk2 set to false, and flags3.unk23 set to true.

Gorlak dancer had these reversed.

Fort dwarves seem to have these both set to false.

I flipped unk2 and unk23 to match the incoming visitor's flags.  Now, he still shows as a guest, because .visitor is still true, but he doesn't have the usual guest information when I "V"iew him.  Going to keep playing with unknown flags amongst visitors.  I'll probably have to manually set the gorlak dancer using the method described by nolimit, as I think I've kind of screwed him up now, but I'm going to keep doing visitor research, since there's hardly any dfhack info out there for them.

Edit: Redacting about my assumptions on unk23.  Fort dwarves use this too.

Edit2:  After further research, flags3.unk31 appears to determine if a visitor is a guest or not.  If I flip it off, the Gorlak Dancer shows in the other units screen as a "Visitor", and there is none of the guest information.  If I flip it back to true, he shows up as a guest/activity like most fortress visitors coming to check out a location.

[escondida]

oldmansutton, given that those are still listed as "unknown" by dfhack, it would probably help dfhack folks to tell them your discovery! Props for that research.

[oldmansutton]

Good call, posting about this now to dfhack, thanks!~

[oldmansutton]

Ok, I think I have more info now.

Anybody visiting your fort who doesn't plan on petitioning, will enter the map with unit.meetings.target_entity = -1 and unit.meetings.target_role = -1

Anybody who will eventually petition, will have the unit.meetings.target_entity = XXX, in my fort, this is set to 528, which some way identifies the mayor.  It's not the mayor's id, hist_figure_id or hist_figure_id2.  I know that much.  I don't know if 528 is the mayoral position or what, but every visitor to my fort that has petitioned has had the target_entity set to this number upon entering the map.

Next: unit.meetings.target_role = 3 
You can actually select this enum, which is MEET_WORKERS.

I had my civ's lord consort come onto the map.  I set his unit.meetings.state = 2 (attend meeting)

It would show up as his current activity briefly, then cancel.  However, I think somebody else was petitioning at the time.  After that person was done petitioning, the lord consort immediately tracked down the mayor, and petitioned.

About to test again with the gorlak dancer..... who, shit, is leaving.... his idle_area_type keeps changing to 27 (HeadForEdge)   (might be a better option than the .Forest flag, PatrikLundell, for your getlost script?)

....now to figure out what state is their "I wanna leave" state before he gets away.... ugh

His activity shows attend meeting, but the headforedge is overriding it. annnnd.... couldn't figure it out... but used Nolimit's method to force him into civ.

Tested my method above to force petitioning on a visiting baroness consort, she came right off the map edge, and headed immediately to attend meeting, and petitioned. 

Solved.

EDIT:

The 528 number is my local government id.  Super solved.

EDIT2:
----------------------------------
tl;dr

select unit
dfhack
gui/gm-editor
meeting
target_entity = local government id
target_role = 3
state = 2

[Nolimit]

select unit
dfhack
gui/gm-editor
meeting
target_entity = local government id
target_role = 3
state = 2

I actually tried it before (but i probably set state to 1) and it didn't work as intendent for me, that's why I didn't post it here. In my case visitor showed 'attend meeting' activity, but stayed in a tavern and mayor was doing nothing. I guess it was because I set state value to 1 and not to 2.

Edit: It still doesn't work for me. There is more stuff going on than just unit.meeting. For a visitor who's going to petition in my case unit.meeting.state is 2, unit.meeting.target_entity - my local gov id, unit.meeting.target_role - 3. Also unit.idle_area_type is 18, which is MeetingLocation. And unit.specific_refs contains specific_ref vector

specific_ref vector:
type - 4 (activity)
object - nothing
unit - nothing
activity - activity_info vector
vermin - nothing
effect - effect_info vector
job - nothing
arg2.wrestle - nil

activity_info vector:
id - some id
unit_actor - unit vector of a visitor
unit_noble - unit vector of a mayor
place - at the beginning it was nil, when mayor got job 'conduct meeting' it changed to  a place with reference to a chair in his office
flags - add delay is true everything else is false
unk3 - 3
delay - 0
tree_quota - -1

For mayor unit.idle_area_type is 19 (meetingLocationBuilding) and specific_ref vector is pretty much the same
Thats my findings for now

[PatrikLundell]

I'm afraid I don't think the case is solved. When you have multiple petitioners waiting (e.g. because of a stalled meeting "queue") none of them show they're heading for a meeting. This information is set up only at the time a meeting is actually scheduled, so it's set only for the one currently active. I've looked at this on visitors appearing at the edge (to see if petitioners could be identified), and they've shown up without this info even if they may get it later.

It may be oldmansutton's lord consort actually intended to petition "naturally", so to call it a success would require several successful cases (or better still, cases where visitors known NOT to intend to petition (i.e. claiming to visit to relax/perform/research) being nudged to change their mind).
Nolimit's experience indicates there's more to it than just playing with the meeting stuff, and it matches my experience.

A bit late now, but for the gorlak case I would have made a copy of the save and played around with things to restore the save to implement the solution (provided lost general fortress progress was worth less than the capture of a head banging Gorlak dancer).

I think I've tried HeadForEdge to get rid of camping visitors, but I'll try it again.

[Nolimit]

There are definitely some unknown triggers that causes visitors to change their meeting state. I thought about forcing them to go for a meeting by changing all of the parameters involved. That also means at least adding specific_ref to a visitor and a mayor, and, maybe, there are some other things.

[oldmansutton]

Interesting, my baroness consort didn't have the meeting already set when he appeared on the edge of the map to visit, and manually setting it worked for me.  And somebody else was already petitioning at the time I set it, so the consort just waited until they were done, made his way to the tavern first, then immediately left the tavern to get the mayor and drag him to the mayor's study to attend meeting.

I didn't mess with the pathing or idle area, but I have noticed that the attend meeting seems to use idle location 28, rather than 18, and the threshold usually seems to be 2.

I'll keep going, as more interesting experiments visitors appear.

Edit:  I agree there's hidden stuff, but I'd say the hidden stuff takes care of flipping the meeting.state, and the meeting type is preset when they enter the map if they'll petition or not.  There still are definitely flags hiding pertaining to what the visitor is doing and what initiates the meeting state to flip.  I couldn't find the flag that convinces the guest it's time to leave, for instance.

Edit2:  I do have a prior save before the gorlak tried to leave as well.

[Nolimit]

If your visitor entered with everything in the meeting set up except state, then i would assume that everything else required for petitioning was also set up. Look for specific_refs with type 4 (activity), if it is there when your visitor entered, then it seems like he had been set up for petitioning by a game. I tried adding same specific_refs for both mayor and visitor and it still didn't work. But i'll post my script anyway:

Spoiler (click to show/hide)

Code: [Select]

local utils = require 'gui'

function petition()
local newcitizen
newcitizen=dfhack.gui.getSelectedUnit()
if newcitizen==nil then
qerror("No unit selected")
end
local govId=df.global.ui.group_id
newcitizen.meeting.target_entity=govId
newcitizen.meeting.state=1
newcitizen.meeting.target_role=3
newcitizen.idle_area_type=18
local govEntity=df.historical_entity.find(govId)
local mayorHistfigId
for i,j in pairs(govEntity.positions.own) do
if j.responsibilities.MEET_WORKERS==true then
for k,l in pairs(govEntity.positions.assignments) do
if l.position_id==j.id then
if l.histfig~=-1 then
mayorHistfigId=l.histfig
break
else
break
end
end
end
if mayorHistfigId~=nil then
break
end
end
end
local mayorHistfig=df.historical_figure.find(mayorHistfigId)
local mayorUnitId=mayorHistfig.unit_id
local mayorUnit=df.unit.find(mayorUnitId)
local actId=df.global.activity_next_id
df.global.activity_next_id=df.global.activity_next_id+1
df.global.ui.activities:insert("#",{new=true,id=actId,unit_actor=newcitizen,unit_noble=mayorUnit,flags={add_delay=true},unk3=3,delay=0,tree_quota=-1})
local actNum=#df.global.ui.activities-1
newcitizen.specific_refs:insert("#",{new=true,type=4,activity=df.global.ui.activities[actNum]})
local specNum=#newcitizen.specific_refs-1
mayorUnit.specific_refs:insert("#",newcitizen.specific_refs[specNum])
mayorUnit.idle_area_type=19
end
petition()

This script changes meeting state for visitor (and everything else in meeting), adds specific_ref and activity to both mayor and visitor. Visitor would be 'attending meeting', but wouldn't really do anything. On a side note, I used df.global.activity_next_id for next id when created activity for specific_ref, but i’m not sure if it’s right id, I think that one used for activity_entrys. Also I almost never coded and that’s my first attempt at lua, so I am open to hear what I’ve done wrong in this script.

Other things that I found: When visitor is looking for meeting, in df.global.ui.meeting_requests will appear some value (I think it's some sort of id for meeting request, though gm-editor doesn't have a list of meeting requests). When visitor and mayor met and petition appeared, in df.global.ui.petitions will appear another entry (again, I think it's an id for petition). It would be great if it was possible just to add petition itself, but at this point I don't think it's possible.
Some visitors also petition not just for themselves, but for a troup, and this information also have to be somewhere (my guess that it's stored in meeting requests and later in petitions, but df.global.ui only lists their ids).
So it’s easier just to add them by my first method, I’m pretty sure that stuff required to force visitors to petition is not indexed by dfhack yet.

[PatrikLundell]

No, the specific ref activity is set up as the meeting is set up. It's not present on visitors entering, but set up later. The stuff in df.global.ui.meeting_requests is likewise set up as the meeting is scheduled (and is messed up on blocked meetings). The df.global.ui.petitions list has been empty when I have looked at it, but I have assumed it is populated as a meeting has been conducted (i.e. contains the stuff that go into the P menu).
I think looking at the unblockmeetings script

Spoiler (click to show/hide)

Code: [Select]

--  Work around for blocked meetings where a change of position holder causes the meeting activities to
--  stall. The somewhat heavy handed approch wipes all meeting activities from the participants and the
--  internal store and relies on DF's ability to rebuild the ones that should actually be there.
--
function unblockmeetings ()
  if not dfhack.isWorldLoaded () or not dfhack.isMapLoaded () then
    dfhack.printerr ("Error: This script requires an embark to be loaded.")
return
  end

  dfhack.println ("Deleting " .. tostring (#df.global.ui.meeting_requests) .. " meeting requests")
  for i = #df.global.ui.meeting_requests - 1, 0, -1 do
    df.global.ui.meeting_requests:erase (i)
  end
 
  dfhack.println ("Deleting " .. tostring (#df.global.ui.activities) .. " activities")
  for i = #df.global.ui.activities - 1, 0, -1 do
    for k = #df.global.ui.activities [i].unit_actor.specific_refs - 1, 0, -1 do
  if df.global.ui.activities [i].unit_actor.specific_refs [k].type == 4 then  -- ACTIVITY
    dfhack.println ("Removing actor ACTIVITY from " .. dfhack.TranslateName (df.global.ui.activities [i].unit_actor.name, true))
    df.global.ui.activities [i].unit_actor.specific_refs:erase (k)
  end
end

    for k = #df.global.ui.activities [i].unit_noble.specific_refs - 1, 0, -1 do
  if df.global.ui.activities [i].unit_noble.specific_refs [k].type == 4 then  -- ACTIVITY
    dfhack.println ("Removing noble ACTIVITY from " .. dfhack.TranslateName (df.global.ui.activities [i].unit_noble.name, true))
    df.global.ui.activities [i].unit_noble.specific_refs:erase (k)
  end
end

df.global.ui.activities:erase (i)
  end
end

unblockmeetings ()

should give you an idea of the territory I've covered.

[Nolimit]

I looked at unblockmeetings before. That's where i got a feeling that only changing meeting state won't cause a proper meeting. What I was trying to say is that specific ref isn't set up because of meeting state change. They both change at the same time by some other triggers (in my previous post I just thought that those changes applied not at the same time, but I was wrong). And, yeah, you're right, meeting_request appears when visitor 'attends meeting', and petitions appear after meeting is conducted. I would really love to understand what role those entries are playing.
The best solution would be to find what triggers the change of meeting state and addition of specific_refs. Second best would be to find all of the changes those triggers cause, and try to apply them manually. Only changing meeting and adding specific_refs doesn't seem enough to cause petitioning unfortunately.

[PatrikLundell]

I agree there should be some lower level state that keeps track of why a visitor has come to the fortress, and on top of that there should be some flag that keeps track of whether the visitor has spoken with a fortress member yet (and thus made that info available for presentation when the visitor is examined).
I suspect trying to set up the secondary effects manually won't cut it, as my guess is that the primary condition is checked when evaluating the results of the secondaries, so telling someone their petition has been accepted when they haven't petitioned will just do nothing, but that's not based on any evidence: I wouldn't mind being proven wrong.