Room designation- unretiring fortress issue

[Orange sucre]

The room designation feature is something that greatly improves the gameplay of retiring and unretiring fortresses for continuous gameplay! The feature works as intended until unretiring a fortress.
Unretiring a fortress causes the nobility to lose their rooms. The dfhack feature keeps the dwarves to their assigned rooms, but the game still forgets the connections (when looking at the nobility window, they re all red) and must be reassigned manually (for them to turn at least yellow). Manual reassign with the feature on is more difficult than without the feature (more inputs required: unassign dfhack room, delete dwarf from room, add dwarf; I often try to delete dwarf from room firstly and forget to set designation to none, resulting in blocked command).
Not only, unretiring a fortress (with a designated room, example: mayor room) that has gone a mayor election (resulting in a different dwarf as mayor) does not change the dwarf assigned to the mayor room (the old dwarf keeps the room, despite feature being on).

Maybe a room designatiom reiteration could work? Maybe a refresh of feature at the start of unretired fortress?

Thanks for making the game enjoyable

[myk002]

I was able to track down what is happening here. I believe this is a vanilla bug, but we can fix it in DFHack. The zone remembers which unit owns it, but the unit forgets that they own the room. That is why the room still shows the correct unit as the owner but the nobles screen is still red.

This is going to affect all units in the fort. DFHack can likely run a fixup tool when it detect a fort has just been unretired.

[myk002]

Ok, fixed in https://github.com/DFHack/scripts/pull/1304 Thank you for bringing this to my attention!

Note that this fixes much more than just the part that impacted preserve-rooms when unretiring. All room assignment links will be checked and fixed in all fort situations. This effectively fixes DF bug 6578: https://dwarffortressbugtracker.com/view.php?id=6578

[Orange sucre]

That is great news! I will check it out and report on it! Thank you for action!

[amade]

I just want to chime in and say thanks for this improvement. I no longer have to reassign rooms to my expeditionary squad members when they return from a mission!

[amade]

Whoops, I just had something unexpected happen. A visitor baroness from my civ spawned right into a siege, got killed, which immediately promoted her son who was in my militia as the new baron of a distant fortress. This means he now needs his own room, office, etc…

However, I already have a duchess, so I wondered how the room reservation would work. Surprisingly, even though the DFHack UI lumps baron/count/duke as one reservation setting, it still assigns the new zones to the new baron instead of the existing duchess, and the previous zones reserved for the duchess remained under her name.

I'm not sure if this was something you guys anticipated and made allowances for or things just happened to work out fine, either way it's great!

[myk002]

Yes, this is working as designed. preserve-rooms will distribute your registered rooms among multiple landholding nobles if you have more than one (and many people do)

[amade]

Cool! What kind of logic is used for distribution? Let's say I have multiple nobles who have yet to be assigned rooms, does it distribute them according to highest rank first? Does it try to match room quality to the noble? Also in my case, the new Baron already had a regular quarters before he got promoted, so although the quality is not up to scratch, the bedroom assignments for both nobles were already assigned yet it correctly assigned the new bedroom (which was higher quality, but not yet Baron quality) to the new Baron.

[myk002]

I considered taking room value into account when assigning rooms, but it is very non-trivial to calculate room value, so I put that off for a future version (while hoping that someday we can ask Bay 12 for an exported function that we can call to calculate room value so we don't have to write all that logic ourselves).

Overall, the algorithm for assigning role-associated rooms is:

iterate through all rooms that the player has marked as associated with a role

if the room is currently owned:

- if the room is currently owned by someone who does not have the assigned role (or set of roles), then unassign them
- if the room is owned by someone who has the assigned role (or any of the set of roles), don't change the assignment

if the room is not currently owned:

- iterate through the set of roles that the room is associated with in reverse promotion order (in this case, that would be Count, Duke, then Baron)
- find units that hold that role that belong to your fort and are present at your fort
- find the first of those units that does not already have a role-assigned room of the current room type (e.g. bedroom) and assign this room to them

If you're interested, the code for this is here: https://github.com/DFHack/dfhack/blob/develop/plugins/preserve-rooms.cpp#L311

and the code that detects and prepares the groups of promotion chains is here: https://github.com/DFHack/dfhack/blob/develop/plugins/lua/preserve-rooms.lua#L315 (noble positions and promotion chains are entirely determined by the raws, so there are no static assumptions about what the noble roles look like in the current game).

[amade]

Originally posted by myk002:

- find the first of those units that does not already have a role-assigned room of the current room type (e.g. bedroom) and assign this room to them

Ah, that explains why my Baron got the room, since his previous room was not role-assigned. Thank you very much for the detailed explanation!