Bug in NonBlocking YardMaps for NanoTowers & MetalExtrac

[QMan]

The engine only assigns a YardMap to units classified as a "Factory" or "Building", however, units such as Metal Extractors (classified as "MetalExtractor") and Nano Towers (classified as "Builder") aren't classified as either of these types, and as such, are given a fully transparent (non-blocking) yardmap, instead of using the one given in the unit file. This causes some weird issues for the CanBuildAt function in AICallback. Since these buildings have no blocking yardmap, the CanBuildAt function returns true when something tries to build on top of one of these buildings, and the Construction Unit attempts to wait for the non-blocking building to move out of the way (since it thinks it is a mobile unit). I propose a simple fix to this, as detailed below:

In UnitDefHandler.cpp @ line 576

Change line:
if(ud.type=="Building" || ud.type=="Factory"){

To:
if(ud.speed == 0){

This will allow blocking yardmaps to be used for any stationary unit, regardless of the classification type.

Thanks!

[AF]

This would fix a number of hub related AI glitches. But ultimately this is caused by the bug that I and zwzsg ahve been complaining about for the last year and a half.

[trepan]

Do transportable immobile units need to be taken into consideration?
(ie: shouldn't their yardmaps be updated before and after transport?)

[AF]

The bug I mentioned prevents them from doing that. Normally such a unit would use the BOS script to change their yardmap btu ti seems that this is a double edged sword as the BOS commands todo it dont work as they should do, and the yardmap entries that some of them use arent supported by spring due to the bug that I've been on about. Its this yardmap entry being missing that got zwzsg complaining to begin with.

However with the advent of possibilities such as zwzsg flying factory transporter script, I guess a spring side fix for that would be necessary, and indeed preferable.