Air Unit Collision Behavior

Handling air unit collision is clunky.

SetSolidObjectBlocking does not have any way to affect the unit->collide unitdef parameter, so game-side lua code cannot turn on and off air unit collision (would be useful for air repair pads, factories, and aircraft carriers, where collision can be temporarily disabled to prevent units getting stuck on collision enabled aircraft and other units)

Air units only update Block and Unblock when landing and taking off. This can lead to blocked areas becoming disjointed from the air unit. (BAR had a glitch where a gadget would make units just finished being constructed block the ground under them, to prevent a fresh nanoframe from being immediately placed right on top of them, but sometimes aircraft would fail to unblock the ground once they flew away, locking up factories)

And some air units poorly calculate reservedLandingPos, leading to disjointed blocked areas (as seen in the attached image, where the landed bomber claimed the yellow squares way in front of it)

As the only way to control and delay factory construction is to block the yard (no easy way for a unitscript to tell a factory to wait X frames after a unit is finished), air factories almost always start building nanoframes directly on top of recently constructed air units (who usually remove their blocking squares as soon as they enter the takeoff state, but have not yet cleared the buildpad).

Start at SetSolidObjectBlocking and trace the air-unit Block/Unblock paths used during landing and takeoff, including reservedLandingPos handling. Compare these with factory nanoframe placement behavior; done should include a Lua-controllable collide setting and blocking areas that remain aligned as air units move or change state.

Written by the indexing model from the issue text.