[Highly Customized] Building placing and deploying logic enhancement

[CrimRecya]

• In vanilla games, buildings are always cannot placing or deploying on the cells that other infantries or units on. Now this can be changed by setting ExpandBuildingPlace to true, when you try to place the building on these cells, it will check whether the occupiers can be scatter by yourself (include your own technos and allies non-player technos) and whether there are enough spaces to scatter. If can, it will record which building you are placing and show a preview to you and your allies, then start a timer to record this placement and order the occupiers to leave this building area. When the area is cleared, the building will be truly place down and the production queue will be restored to original state. But when the timer expires or an unexpected situation has occurred which make the building impossible be constructed here anymore, it will stop the action and play "cannot deploy here", then you should re-place or re-deploy the building in a valid space. Note that when the building has been recorded and is trying to place, unless the production queue has vanished (such as construction yard is no longer exist), it will continue to function normally until the conditions are not met.
• AutoBuilding controls whether building can be automatically placed.
  • AutoBuilding.Gap controls the gap of automatically placed buildings.
• LimboBuild controls whether building can be automatically placed like LimboDelivery.
  • LimboBuildID defines the numeric ID of the building placed by LimboBuild.
• PlaceBuilding.OnLand controls building with Naval=yes will become which building when placed on land.
• PlaceBuilding.OnWater controls building with Naval=no will become which building when placed on water.

In rulesmd.ini:

[General]
ExpandBuildingPlace=false   ; boolean

[SOMEBUILDING]              ; BuildingType
AutoBuilding=false          ; boolean
AutoBuilding.Gap=0          ; integer
LimboBuild=false            ; boolean
LimboBuildID=-1             ; integer
PlaceBuilding.OnLand=       ; BuildingType
PlaceBuilding.OnWater=      ; BuildingType

• Now LaserFence can be customized by setting LaserFencePost.Fence on LaserFencePost=true buildings.
  • LaserFencePost.Fence defines which kind of laser fence can connect this kind of laser fence post. If they have different LaserFencePost.Fence, they will not be connected.

In rulesmd.ini:

[SOMEBUILDING]              ; BuildingType, `LaserFencePost=yes`
LaserFencePost.Fence=       ; BuildingType

• Now technos have CanBeBuiltOn=true can simply removed when building is placed on them.

In rulesmd.ini:

[SOMETECHNO]         ; TechnoType
CanBeBuiltOn=false   ; boolean

Splits from #1335 .

[github-actions[bot]]

Nightly build for this pull request:

• compiled-dll-e79420400f2e4902bab50498319bf606131d9c6c.zip These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[TaranDahl]

我觉得AutoBuilding可能需要一个ingame的快捷键来决定是否整体地开启它。 I think AutoBuilding may need an in-game shortcut key to determine whether to turn it on globally. 一个具体的需求：在游戏初期我对于战争工厂的位置没有什么需求，所以自动放置它是好的；而在游戏后期我可能会修建前线阵地以确保生产出的单位能快速加入战斗，这时候我希望能手动决定它的位置。 A specific requirement: In the early stage of the game, I have no specific need for the location of the war factory, so it is good to place it automatically. In the later stage of the game, I may build a frontline position to ensure that the produced units can quickly join the battle. At this time, I hope to manually determine its location.

[brckhan88]

Hello,

I've been following this PR for a long time which allows AI to use its available foundation area efficiently, I even pull the relevant branch as it is updated and test it after rebuilding. First of all, I would like to thank you for all your efforts. I have observed a small bug with the flow of the 'ExtendedBuildingPlacing' tag on the AI side for a long time. If the AI fails to clean the space of the LimboBuilding it is placed within the time specified in the 'pHouseExt->CurrentBuildingTimer.Start()' statement in the function and cannot replace the real building instead, the AI permanently bypasses that building and never builds it again. Any other functions seem to be working flawlessly.

[CrimRecya]

Hello,

I've been following this PR for a long time which allows AI to use its available foundation area efficiently, I even pull the relevant branch as it is updated and test it after rebuilding. First of all, I would like to thank you for all your efforts. I have observed a small bug with the flow of the 'ExtendedBuildingPlacing' tag on the AI side for a long time. If the AI fails to clean the space of the LimboBuilding it is placed within the time specified in the 'pHouseExt->CurrentBuildingTimer.Start()' statement in the function and cannot replace the real building instead, the AI permanently bypasses that building and never builds it again. Any other functions seem to be working flawlessly.

Thank you for your feedback. I will try to fix it later (but it will take some time as Chinese New Year is coming).

At present, I have also encountered a problem, which is that for buildings with areas such as 4x3 and 2x5, the automatically calculated FoundationOutside is incorrect, and it is needed to customize this parameter to evacuate units within the construction area correctly in some special situations. I'm not sure if it can be fixed afterwards. At least for now, if you encounter such problems, you can solve them by Foundation=Custom with customizing FoundationOutline.

[CrimRecya]

Hello,

I've been following this PR for a long time which allows AI to use its available foundation area efficiently, I even pull the relevant branch as it is updated and test it after rebuilding. First of all, I would like to thank you for all your efforts. I have observed a small bug with the flow of the 'ExtendedBuildingPlacing' tag on the AI side for a long time. If the AI fails to clean the space of the LimboBuilding it is placed within the time specified in the 'pHouseExt->CurrentBuildingTimer.Start()' statement in the function and cannot replace the real building instead, the AI permanently bypasses that building and never builds it again. Any other functions seem to be working flawlessly.

I checked the code, buildings with LimboBuild=true should actually be completely separate from the placement logic of ordinary buildings and should not enter into the placement waiting logic. In other words, regardless, it should have been successfully placed. Can you provide a detailed description of how your problem was produced? Considering that my English is not very good, it would be very helpful if you could explain it in short sentences as much as possible. Thank you so much.

[brckhan88]

Hello, I've been following this PR for a long time which allows AI to use its available foundation area efficiently, I even pull the relevant branch as it is updated and test it after rebuilding. First of all, I would like to thank you for all your efforts. I have observed a small bug with the flow of the 'ExtendedBuildingPlacing' tag on the AI side for a long time. If the AI fails to clean the space of the LimboBuilding it is placed within the time specified in the 'pHouseExt->CurrentBuildingTimer.Start()' statement in the function and cannot replace the real building instead, the AI permanently bypasses that building and never builds it again. Any other functions seem to be working flawlessly.

I checked the code, buildings with LimboBuild=true should actually be completely separate from the placement logic of ordinary buildings and should not enter into the placement waiting logic. In other words, regardless, it should have been successfully placed. Can you provide a detailed description of how your problem was produced? Considering that my English is not very good, it would be very helpful if you could explain it in short sentences as much as possible. Thank you so much.

No problem, maybe I described the state a bit misunderstanding. When a player tries to build a structure on an area occupied with some units and "ExtendedBuildingPlacing" tag is activated, the actual behavior will be like this: First Placement Preview has been attached on this node where we wanted to place, after that area checking and cleaning process, removing units from there and the actual structure will be built on this area. This will happen in almost 8 sec, the value defined in the parenthesis of this func: pHouseExt->CurrentBuildingTimer.Start(8) , or else building operation will be aborted, EVA announced "Cannot be build in here" and returned to the ready state so player should select another place to build. But for AI it works a bit different. When AI becomes ready to build, it will pick up suitable place to be build, area filled with units also considered as suitable. Everything works just like the same as players but a small difference. On your codes pHouseExt->CurrentBuildingTimer.Start() value for AI is defined 40 and it will decrease by -5 for each cycle so it equals almost 8 secs. If AI will transformed placement preview into the real structure before the time ends, AI considers it as a Succesfull built; but If AI only make a placement preview but cannot complete to construct actual structure due to obstacles, moving units etc. at the same period, AI also considers it as a succesful built and never tries to build it again (Rare case happening on the battlefield). The Expected behavior AI should try to rebuild it. Maybe you can observe this bug by decreasing BuildingTimer to half for AI. Thnx anyway, hope this time the issue becomes clear for u :)

[CrimRecya]

No problem, maybe I described the state a bit misunderstanding. When a player tries to build a structure on an area occupied with some units and "ExtendedBuildingPlacing" tag is activated, the actual behavior will be like this: First Placement Preview has been attached on this node where we wanted to place, after that area checking and cleaning process, removing units from there and the actual structure will be built on this area. This will happen in almost 8 sec, the value defined in the parenthesis of this func: pHouseExt->CurrentBuildingTimer.Start(8) , or else building operation will be aborted, EVA announced "Cannot be build in here" and returned to the ready state so player should select another place to build. But for AI it works a bit different. When AI becomes ready to build, it will pick up suitable place to be build, area filled with units also considered as suitable. Everything works just like the same as players but a small difference. On your codes pHouseExt->CurrentBuildingTimer.Start() value for AI is defined 40 and it will decrease by -5 for each cycle so it equals almost 8 secs. If AI will transformed placement preview into the real structure before the time ends, AI considers it as a Succesfull built; but If AI only make a placement preview but cannot complete to construct actual structure due to obstacles, moving units etc. at the same period, AI also considers it as a succesful built and never tries to build it again (Rare case happening on the battlefield). The Expected behavior AI should try to rebuild it. Maybe you can observe this bug by decreasing BuildingTimer to half for AI. Thnx anyway, hope this time the issue becomes clear for u :)

Oh, thank you very much. The description was quite clear this time. I understand the problem now. This issue should not arise during the Campaign. Due to my modification of this behavior during the Skirmish, the AI was willing to wait much shorter than the original MaximumBuildingPlacementFailures, resulting in the deletion of the base node. As a result, the AI will not attempt to build it again. Afterwards, I will come up with a better way to handle it.

[TaranDahl]

两个有关AutoBuilding的需求： 1.将科技建筑和防御建筑的AutoBuilding分开。 2.设计某种方法指定AutoBuilding投放的大致位置。最理想的方式就像SC2中虫族基地的集结点，一个集结点指定科技建筑，另一个指定防御建筑。当前这可能不容易实现，我们可以寻找其它优雅的方式。 这个功能非常实用，我希望能把它变得更好😊 Two requirements related to AutoBuilding:

1. Separate the AutoBuilding of technology buildings and defensive buildings.
2. Design a way to specify the approximate location of the AutoBuilding placement. The ideal way would be like the rally point of the Zerg base in SC2, with one rally point designated for the technology building and another for the defense building. This may not be easy to achieve at the moment, we can find other elegant ways. This feature is very useful, I hope to make it better😊

[Aephiex]

This PR can cause a crash in an unusual case. If a building with CanBeBuiltOn=true is overlapped with a building with CanBeOccupied=yes, the former will be removed from the game when the latter becomes garrisoned, which somehow crashes the game.

How to replicate: There is a garrisonable structure overlapped with 2 pipes ([CAMISC05]) in the bottom right corner of the map (6) Stars and Stripes in Mental Omega. Give the pipes with CanBeBuiltOn=true and garrison the structure to replicate the crash.

[mevitar]

This PR can cause a crash in an unusual case. If a building with CanBeBuiltOn=true is overlapped with a building with CanBeOccupied=yes, the former will be removed from the game when the latter becomes garrisoned, which somehow crashes the game.

CanBeBuiltOn=yes is a TerrainTypes tag. Unless something got changed and i'm not aware of it, it should not be used on buildings. Also, buildings should never be made to overlap, because the game crashes if one of them is destroyed/removed. If one of MO maps has overlapping buildins, that's a map bug.

[TaranDahl]

This PR can cause a crash in an unusual case. If a building with CanBeBuiltOn=true is overlapped with a building with CanBeOccupied=yes, the former will be removed from the game when the latter becomes garrisoned, which somehow crashes the game.

CanBeBuiltOn=yes is a TerrainTypes tag. Unless something got changed and i'm not aware of it, it should not be used on buildings. Also, buildings should never be made to overlap, because the game crashes if one of them is destroyed/removed. If one of MO maps has overlapping buildins, that's a map bug.-----------谷歌翻译-----------canbebuilton =是的是一个地形标签。除非发生了变化，但我不知道它，否则不应在建筑物上使用。另外，绝不应该使建筑物重叠，因为如果其中一个被摧毁/拆除，则游戏崩溃。如果MO地图之一具有重叠的buildins，那就是一个麦格错误。

CanBeBuiltOn was extended in this PR to work on TechnoType.

[TaranDahl]

This PR can cause a crash in an unusual case. If a building with CanBeBuiltOn=true is overlapped with a building with CanBeOccupied=yes, the former will be removed from the game when the latter becomes garrisoned, which somehow crashes the game.-----------谷歌翻译-----------该公关在异常情况下可能会导致崩溃。如果带有CanbeBuilton = True的建筑物与CanBeocupied =是的建筑物重叠，那么当后者被驻守时，前者将从游戏中删除，以某种方式使游戏崩溃。

How to replicate: There is a garrisonable structure overlapped with 2 pipes ([CAMISC05]) in the bottom right corner of the map (6) Stars and Stripes in Mental Omega. Give the pipes with CanBeBuiltOn=true and garrison the structure to replicate the crash.-----------谷歌翻译-----------如何复制：在地图（6）恒星的右下角中，有一个可驻留的结构与2条管道（[Camisc05]）重叠，并在心理欧米茄中的条纹重叠。用CanbeBuilton = True给管道，并驻守结构以复制崩溃。

That crash occurs when one of any overlapping buildings is destroyed. It's a vanilla problem.

[CrimRecya]

This PR can cause a crash in an unusual case. If a building with CanBeBuiltOn=true is overlapped with a building with CanBeOccupied=yes, the former will be removed from the game when the latter becomes garrisoned, which somehow crashes the game.

How to replicate: There is a garrisonable structure overlapped with 2 pipes ([CAMISC05]) in the bottom right corner of the map (6) Stars and Stripes in Mental Omega. Give the pipes with CanBeBuiltOn=true and garrison the structure to replicate the crash.

Translation

• If one of the two overlapping buildings is destroyed/removed first, it will cause the game to crash, which is an inherent problem in vanilla. This requires the map author not to place different buildings overlapping.
• There will be no problem with this PR because the true placement behavior is after removing buildings with CanBeBuiltOn=true. But if the map author overlaps the buildings, and the garrison behavior triggers the Mark, it will trigger the removal behavior and cause the game to crash as mentioned earlier.
• Overall, this is a problem with the map.

原文

• 如果两个互相重叠的建筑其中有一个被先摧毁/移除，这将导致游戏崩溃，这是原版就有的问题，这要求地图作者不应该将不同的建筑重叠放置。
• 该pr真正处理放置的行为在移除带有 CanBeBuiltOn=true 的建筑之后，这不会有问题。但如果地图作者如果将建筑重叠，而驻军行为会导致触发Mark，这将触发移除行为，并导致前面所说的游戏崩溃。
• 综上，这是地图的问题。

[CrimRecya]

Considering that ExpandBuildingPlace and AutoBuilding have already been separated and no longer related in previous updates, and these two functions themselves do not have much intersection, I believe that splitting these two functions will help with code review. Afterwards, AutoBuilding related functions will be removed from this PR and I will submit a new PR later specifically to provide these.

[CrimRecya]