[New Feature] Extended component tower and gates logic

[vinifera-developers]

[New Feature] Extended component tower and gates logic

[CCHyper]

How could this be implemented?

RULES.INI already contains keys to handle the Component tower and Gate logics;

GDIGateOne=<BuildingType>
GDIGateTwo=<BuildingType>
WallTower=<BuildingType>
NodGateOne=<BuildingType>
NodGateTwo=<BuildingType>

Add new entries here might be over-engineering it, so perhaps add them directly to HouseTypes? For example;

[NewSide]
GateOne=<BuildingType>
GateTwo=<BuildingType>
WallTower=<BuildingType>

Would be good to some discussion on this.

[MikillRosen]

I guess HouseTypes will do

[Crimsonum]

This behaviour is also hardcoded to certain OverlayType indexes, for example index 0 (GASAND), and I believe 2 (GAWALL) and 26 (NAWALL) too. Other indexes do not allow any building to be placed on them, even if the overlay is a wall-type.

[CCHyper]

@Crimsonum

This behaviour is also hardcoded to certain OverlayType indexes, for example index 0 (GASAND), and I believe 2 (GAWALL) and 26 (NAWALL) too. Other indexes do not allow any building to be placed on them, even if the overlay is a wall-type.

What would be an ideal solution for handling this logic? A new key on the OverlayType to decide if a building can be placed on-top?

[Crimsonum]

@Crimsonum

This behaviour is also hardcoded to certain OverlayType indexes, for example index 0 (GASAND), and I believe 2 (GAWALL) and 26 (NAWALL) too. Other indexes do not allow any building to be placed on them, even if the overlay is a wall-type.

What would be an ideal solution for handling this logic? A new key on the OverlayType to decide if a building can be placed on-top?

Walls don't have their own OverlayType sections, even though they are listed in [OverlayTypes]. So the flag would probably have to go to the BuildingType, which governs all other aspects of the wall (Cost, Strength, etc.) anyway. But yes, a new key would probably be the best option. I might also make this the default behavior for walls with Wall=yes or LaserFence=yes to mimic/support the vanilla game.

[CCHyper]

Walls don't have their own OverlayType sections, even though they are listed in [OverlayTypes]. So the flag would probably have to go to the BuildingType, which governs all other aspects of the wall (Cost, Strength, etc.) anyway. But yes, a new key would probably be the best option. I might also make this the default behaviour for walls with Wall=yes or LaserFence=yes to mimic/support the vanilla game.

I have yet to look into how the system is linked, but the buildable walls get converted to OverlayTypes on placement, and do not contain a link back to the BuildingType instance they were once (if placed manually by the player). So I think adding a new OverlaType key to define this behaviour for new wall types would be ideal rather than implementing a link back to the BuildingType, which could be redundant and costly.