Creating gem windows using the planner don't add value to rooms

[LoXyO-lab]

As the title says. Creating gem windows using the DFHack planner interface won't add any value to the room it is built in, both when letting the program choose or using the filter. Whereas using the vanilla interface to use lastest materials, closest materials or manually select the gems will properly add value.

To replicate :

• Create two small guildhalls and assign a legendary broker to see the exact value
• Dig/create gems and cut them if needed
• Build gem windows in one using the DFHack planner and the vanilla interface in the other
• Read the values of both rooms

[quietust]

It sounds like the Buildings module is failing to place new buildings "under mastery" (i.e. making them parts of rooms).

[chdoc]

If that is indeed the issue, then I suppose this also warrants a fixup tool/routine. After all, this will probably mean that lots of forts that have been using DFHack for a while will have a lot of furniture that is not part of the respective rooms/zones, right?

[chdoc]

I managed to reproduce the problem, and I can confirm that for gem windows constructed using the planner overlay neither the building_window_gemst.relations entry nor the building_civzonest.contained_buildings entry in the zone are present. When the gem window is constructed using the vanilla interface, these point to the respective other. The same happens for other furniture, even if it is constructed using planneroverlay.

The root cause seems to be the following check in Buildings.cpp:

static bool is_suitable_building_for_zoning(df::building* bld)
{
    return bld->canMakeRoom();
}

because canMakeRoom() returns true for things like chairs but returns false for gem windows.

[quietust]

Based on the logic I see in version 52.05 (which I'm currently analyzing in depth), I suspect this is a bug in DF itself whereby the order matters - if you designate a room and then add a window to it, it will probably contribute to its value, but if you place the window and then designate the room around it, it probably won't.

[chdoc]

Based on the logic I see in version 52.05 (which I'm currently analyzing in depth), I suspect this is a bug in DF itself whereby the order matters - if you designate a room and then add a window to it, it will probably contribute to its value, but if you place the window and then designate the room around it, it probably won't.

I have tried this with guild halls, and I can confirm that this is exactly what happens

[ab9rf]

I've also noticed similar behavior with bedrooms and with tombs.

[Alistair-Afton]

@LoXyO-lab Fixed in #5926. Planned gem and glass windows are now linked in both directions with existing rooms and zones. The PR includes in engine coverage for both window types.