The main focus on this update was overhauling the generation of indicators from a single template set on the building system based on the rules that are set in the placement validator (Resource defined on building system) and Placeable specific rules optionally defined in each Placeable resource file. No longer do each rule that deals with collisions have to have their own indicator template. You simply define a mask to find the collision objects for indicator generation and then a mask to evaluate the rules using the indicators. Where rules overlap positions, tile indicators are shared but each rule is evaluated seperately (for instance, an indicator can check for collisions and also that it is above a valid tilemap tile as seperate rules but for the same indicator space. In such a case, the indicator would check both rules to determine if it is valid when all rules set are valid first)

To have extra fail textures to represent different rules having a failing result, you can define IndicatorVisualSettings in each rule and set a priority to determine which settings show in case of multiple failures (Highest failing priority number shows). This means there is no real need for multiple indicator templates and hopefully simplifies setting up rules for now and the future.

Breaking Changes

• TileCollisionIndicator class and templates are now RuleCheckIndicator.
• You assign a RuleCheckIndicator template to the building system instead of individual rules. Be sure to reassign the template.
• Rules used in the system must be reconfigured. For TileCheckRules, You need to define a Match Collision Shape Mask to find collision objects on the preview scenes based on their physics layer. Then for the rules to check properly, define the Rule Mask for which layers to look for collisions or other objects in the indicators when checking rule validity.
• CollisionsCheckRule combines NoCollisionsRule and IndicatorsMustCollideRule into one. Reassign as necessary.
• Custom rules setup method now uses RuleValidationsParameters instead of BuildingSystem as parameters
• /demo/ui folder moved to /ui. Any path references to scripts inside will need to be updated.
• BuildingSystem requires adding a BuildingSignalBus resource in the inspector to emit signals. Connect any scripts to the signal bus resource to connect signals to callable methods.

Other Changes

• To create visual RuleCheckIndicators to show passing and failing rules, you now assign a single RuleCheckIndicator template which will be used for all generated indicators.
• Instead of assigning templates to each rule, you can add optional fail visual settings resource for a texture and modulate color to show when a specific rule fails. Which texture gets displayed on the indicator is based on the Visual Priority ordering. For now, successful validation always uses the default success visual settings (Set on the rule check indicator template)
• Any rule that needs to check against the tile map or collision objects that may be in the way of placement inherit from TileCheckRule now which defines a Rule Mask for what rules to evaluate the rule against for each indicator.
• NoCollisionsRule and IndicatorTilesMustCollideRule were merged into one rule CollisionsCheckRule. Set pass_on_collision to get the desired result.
• Removed toggle_visible_button.gd script and the template .tscn for it from the plugin because it was unrelated to the plugin functionality itself. (Just a button that calls show or hide on the export control node target). You can still find it in the demo project where it was being used before.
• Rewrote the internal functions on how RuleCheckIndicators are generated based on Rules, rules are assigned to the indicators, and how rules evaluate.
• BuildingRules now use RuleValidationParameters as their setup parameter which currently passes a placer, preview_instance, placeable, and building_signal_bus to the rules
• BuildingSystem now emits signals through a BuildingSignalBus resource. Added in the inspector, you can save it and reference it in any other script that needs to know when a build is attempted or an object was placed without needing a direct reference to the building system. You can also have separate BuildingSignalBus for multiple BuildingSystem if you have a need for that in your game. (To reference a BuildingSignalBus in a script, simply do an @export var building_signal_bus : BuildingSignalBus towards the top to add the inspector field)

New Classes

RuleCheckIndicator - Direct replacement to TileCollisionIndicator. A shape cast 2D that evaluates it's "valid" property based on evaluating the assigned rules. These rules are assigned automatically when the system creates indicators for rules when selecting a new placeable & preview instance (test object before the placement). In the template scene or your own RuleCheckIndicator scene, you will want to define success and fail IndicatorVisualSettings to set corresponding textures and modulate colors (By default this would be a green square for success and a red square for failure).

TileCheckRule - For any rule that needs to access collision shapes and RuleCheckIndicators to test the placement location against the tilemap and game world, a tile check rule lets you do that by defining a Match Collision Objects Mask. When the building system creates a preview instance, rules will be assigned to each collision object (Physics Objects, Area 2Ds, etc) based on matching their physics layers.

RuleValidationParameters - The details to test placement rules against for validating whether a Placeable object can place into the scene at the target location. Currently used to pass placer, preview_instance, placeable, and building_signal_bus into the placement validator and any rules setup in that validator (Base Rules of the validation + placeable specific rules you define on each Placeable resource). If you define a BuildingRule, you can use these fields in setup(params) to have more information in evaluating your rule logic at validate_condition() time.

When the rule evaluates (either for individual indicators or all of the found and assigned indicators for the build, it will do so using the rule mask. For instance, if you have a CollisionCheckRule that has the Rule Mask on layer 1, then the rule will check collisions against layer 1 for each RuleCheckIndicator, then it will be able to evaluate the rule true or false for the indicators depending on if pass_on_collision is set true or false (With this property, you can use a CollisionCheckRule to expect there to be collisions or not to be collisions for the final RuleResult to be successful.

Did a fair bit of unit testing against the system to knock out some bugs and improve the code. There could be more to find so if you happen to run into any problems. Let me know and I'll be happy to add futher tests to find them.

Now that I have the plugin again in a good state I'm happy with, I can turn to tutorials for Grid Builder, World Time, Item Drops plugins and general Godot GameDev tutorials again.