View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009262 | Dwarf Fortress | Dwarf Mode -- Diplomacy | public | 2015-12-06 21:16 | 2020-02-04 17:46 |
| Reporter | Kaelem Gaen | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| OS | Windows Vista Home Premium 32bit | OS Version | SP 2 | ||
| Product Version | 0.42.02 | ||||
| Summary | 0009262: Outpost Liason Spends all time in Tavern | ||||
| Description | Basically, it seems my outpost liason never set up a meeting in the last merchant visit and he's still chilling with no job/socialize at my Tavern and it's midwinter. That by itself isn't to bad, but they haven't made an agreement yet and he doesn't even look interested in setting up a meeting. | ||||
| Additional Information | This is a save from 42.01 in 42.02 | ||||
| Tags | No tags attached. | ||||
|
|
A save file would be helpful. :) Are you certain that your expedition leader isn't busy doing something else? Toady mostly fixed the priorities, but there are still some things (like military duty) that can take priority over setting up a meeting with a diplomat. |
|
|
Alright here's the save file http://dffd.bay12games.com/file.php?id=11410 |
|
|
Same thing happened to me, after the first visit he just stayed. I can't recall if I ever set up a trade agreement, but he still eventually offers you the position of duke, so I don't believe it breaks progression. |
|
|
If you don't have tavern but you have temple, he stays there, as shown in 0009303, "Liaison conducts the meeting but then stays in temple as a visitor after merchants leave, doing nothing". |
|
|
http://dffd.bay12games.com/file.php?id=11620 Here's another save where this is happening. Retiring all locations and deleting meeting areas does nothing, neither does disabling all of my mayor's labours. I think this is probably more than a minor bug, since you can never ask anything of the merchants and neither can you ever be promoted to barony. |
|
|
What about a minor incident involving spilled magma? If nothing else works, store your save and then try to get a new liaison. This current !!liaison!! seems to not do his/her job properly. |
|
|
I have tried using DFHack to just kill the liaison, but the same thing happens with the one that appears next year. I might try deleting all my meeting areas, killing the liaison and then seeing what the one next year does. |
|
|
http://dffd.bay12games.com/file.php?id=11627 Here is a save where this has happened. There are no liaisons in the fortress currently. All locations have been deleted. It is autumn. The liaison which arrives with the next caravan STILL does nothing forever. |
|
|
I can also note that liaisons will leave at some point during the year (no idea when), irrespective of whether or not there are any locations in the fortress. However, when they appear next year they simply idle about with either "no job" or "socialise" until they leave again. |
|
|
I got this bug at some point after I made my library and tavern citizen/longterm only. The liaison would appear and never try to conduct meeting, because apparently those visitor scribes and whatnot would linger there forever and not leave after their respective meeting areas were now "forbidden" for them. Apparently this somehow affects the liaison, because he went from idling/socializing to conduct meeting immediately after I had killed all those "stuck" performers, mercenaries and scribes that were loitering around. (And no, changing those locations to everyone welcome again did not help with this issue.) |
|
|
Also having this bug in 43.05. |
|
|
Here is a save showing this http://dffd.bay12games.com/file.php?id=12784 |
|
|
I had a similar issue, I "only" had to send in the military to kill every visitor who wanted a meeting, including the liaison (though I probably missed a few). But, that fixed it, as the next liaison who visited my fort, as well as bards/mercenaries/scholars, all went to the meeting properly. |
|
|
mrmagolor, that's pretty dangerous to do as it can trigger a loyalty cascade. |
|
|
At least some instances of this problem has been found to be due to buggy scheduling. <WRONG>Meetings are scheduled with the individual who holds the office at the time the decision to meet is made </WRONG>. If the holder of the office is replaced (accidents, elections, etc.), those scheduled for a meeting with the office remains scheduled for a meeting with the former office holder individual (who don't conduct any meetings anymore), but still stalls the office queue from moving forward. Removing those scheduled to meet the wrong person is one way to resolve the issue. Another one that has been used successfully is to manually reinstate the former mayor until those scheduled to meet the former one have been processed, and then re-instate the "current" mayor. Obviously hard to do when the previous office holder is unavailable. Edit: Some of the above is incorrect. Units are scheduled with the site entity, not the position holder. The error thus seems to be in the office replacement process where some kind of queue seems to be individual based. |
|
|
I will confirm at least in my recent Fortress I had this issue crop up. that reinstating the previous mayor has toggled the Liason back to Attend Meeting. (I got lucky only had one other mayor, and they had a unique name in my fortress.) (This was in .43.05) |
|
|
This seems to still occur in 0.47.01. EDIT: Never mind, the liasion did leave of their own will eventually. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-12-06 21:16 | Kaelem Gaen | New Issue | |
| 2015-12-07 06:16 | Talvieno | Note Added: 0033573 | |
| 2015-12-07 07:06 | Kaelem Gaen | Note Added: 0033575 | |
| 2015-12-14 06:45 | NolanSyKinsley | Note Added: 0033876 | |
| 2015-12-14 07:23 |
|
Note Added: 0033878 | |
| 2016-01-06 14:42 | ediblesideburns | Note Added: 0034343 | |
| 2016-01-06 16:16 |
|
Note Added: 0034344 | |
| 2016-01-06 16:17 |
|
Note Edited: 0034344 | |
| 2016-01-06 19:03 | ediblesideburns | Note Added: 0034345 | |
| 2016-01-07 22:19 | ediblesideburns | Note Added: 0034355 | |
| 2016-01-09 15:05 | ediblesideburns | Note Added: 0034384 | |
| 2016-02-26 00:23 | Muumeh | Note Added: 0034753 | |
| 2016-02-26 00:24 | Muumeh | Note Edited: 0034753 | |
| 2016-02-26 01:04 | Muumeh | Note Edited: 0034753 | |
| 2017-03-24 12:53 | TV4Fun | Note Added: 0036363 | |
| 2017-03-24 13:14 | TV4Fun | Note Added: 0036365 | |
| 2017-03-25 10:51 | mrmagolor | Note Added: 0036368 | |
| 2017-03-26 20:48 | TV4Fun | Note Added: 0036376 | |
| 2017-03-27 02:07 | PatrikLundell | Note Added: 0036377 | |
| 2017-04-05 08:03 | PatrikLundell | Note Edited: 0036377 | |
| 2017-04-15 16:29 | Kaelem Gaen | Note Added: 0036418 | |
| 2017-04-15 16:29 | Kaelem Gaen | Note Edited: 0036418 | |
| 2020-02-04 17:46 | mrmagolor | Note Added: 0039879 | |
| 2020-02-05 12:31 | mrmagolor | Note Edited: 0039879 |
