Yes. It does run-time proximity checks. This is necessary because you can have a pair of parking spots targeting different plane sizes (e.g. CRJ goes here, A340 goes here) that share a gate and overlap – they will be mutually excluded from use by proximity checks.

Thanks, that makes sense.
From trying densely parked size A prop ramp starts it seems to me the static aircraft autoplacer does some checking and only populates position that do not result in overlapping. True ?

That should be up to the designer to take screenshots and have and ability to show them in the gateway

Not right now, no, so we are not actively encouraging people to make taxiway routes for non-towered airports. If you’re going to do taxi routes, your time is definitely more valuable where there is a tower.

We may someday have AI operations at non-towered airports and at that point we will need them.

The routes do not harm anything though.

Please file a bug.

Already did one some days ago …
‘E/NET: Download failed with error: 6 for URL &var_VGRD=1’
is the only indication in the log and the weather download percent counter running 3 times in a row, but that might be for each item separately (metar, winds, turbulence).

Ronny

Hrm – static aircraft on top of ramp start was never in the validation checks. The reason is: we never check -any- obj-vs-other-stuff conflicts because we can’t know whether the giant pile of OBJs you have made is a good idea or bad idea. For example, if you have an OBJ with ground markings, it -should- be on top of a ramp start.

We could flag our own static aircraft but that’s a drop in the bucket – a user can go get a third party library of airplanes, dump them on the ramp starts and …. splat.

Please file a bug ASAP!