Regarding taxiways and parking in the world hub

WorldHub Discussions
1

I recently began working on my first World Hub project and ran into several issues. I have several questions, most of them in an effort to establish what the Asobo team regards as acceptable and/or best practices so we don’t have to expend extra time and effort:

First, what is the expectation in regard to completion of edits? For instance, if I were just to go in and change runway lighting, but not touch taxiways, etc, would that be proper?

That said, I get to be really persnickety about errors and anything I start on ends up getting into a deep dive, which brings me to my next question:

In the airport I’m currently editing, the taxiway segments are just paths with no pavement rendering. The actual pavement rendering was previously done (I assume by Asobo) by adding apron polygons underneath (same on the ramps). So I started changing the taxiways to the appropriate category, overlaid on top of the existing aprons. Is this a good practice or should I have left them as generic paths and let the aprons do the work? I did notice that changing them and resizing them correctly helped clean up a lot of misplaced lighting.

Third, when creating parking, at least at a lot of US airports, busier general aviation ramps often require you to get out and back the plane into the spot with a towbar, so it faces outward toward the taxiway. When adding parking spots in the sim, the rotation is often aligned with the parking taxi path, meaning the airplane will be parked nose-in, which is a no-no, especially as ramps are often zipper-parked for saving space, as shown here:

IMG_1902
IMG_19021170×509 98.9 KB

What is the best practice for this? Is it acceptable to connect the parking path to the taxi path and rotate the parking spot 180 to face nose-out? Making it taxi-through to the opposite row could work, but if someone is parked in the intermediate zipper row, you’re blocked.

Lastly, at some point in my edit, the scenery flattened. My edits were still mounted after I left dev mode last night and the airport was still flat (it is not a flat airport). Did my edits break the terrain, or will that re-render correctly? In adjacent regard to this, I would love to be able to correctly terraform runways and taxiways. Protip: the Google Earth profile tool is immensely helpful in doing this.

1 Like
2

A lot of valid questions. I only can assure you that you most probably didn’t break the terrain, as it is normal behaviour (at leat my experience) that the terrain altitude changes (jumps) when starting and leaving the scenery editor.
As for the GA parking spots: just try it out and see how the GA (for instance Corstens offline GA mod) behaves. You can build the scenery in the WorldHub mode and add it to your Community folder.

2 Likes
3

The terrain remains flat in the world hub editor no matter how long it is running (was most of the day for me today), but it doesn’t do that in the normal scenery SDK. I can foresee this causing trouble because some elements like taxiway paths and nodes will remain rendered above or below the flattened surface until you click them individually. These floating elements create false perspectives when trying to place items exactly on the imagery.

I submitted two airports using the tail-in parking spots. We’ll see how it goes!

4

I’ve started working on my first airport and have a similar question on “drive through” parking spots, where you would come in one way and go out the other way. I’m not sure how well parking spots behave if connected front & back to taxiway paths? Does the AI try to turn around and go out the way it came in, or take the shortest route?

I know I should just try it, but I have limited time and so far didn’t reach the point of trying my airfield in the sim (I think I have to suppress the original too). So for now, I thought I’d add this query to this thread for those who’ve already been there and done that. Here are the parking spaces in question. (Between Google & Bing aerials, the aircraft are parked in opposite directions anyway!)

image

5

I got my submissions kicked back, but not for that - it was mostly for taxiways set as type TAXI instead of PATH. I’m re-working this now to see if it will render surfaces correctly using PATH.

6

Thanks. I’m not clear on the differences between ‘taxi’ and ‘path’ options. The SDK doesn’t have much to say about them. It says what they are but no hint on correct usage:

Taxi - This is a general taxiway path showing a surface and
(optional) markings. These will be drawn in green/blue in
the scene.
Path - This is a basic path that has no surface material of
its own showing, so will show whatever is “under” it (ie:
Apron Objects). Note that assigned markings will still be
shown even though the surface is not. These will be drawn
in blue in the scene.

I assume to use ‘taxi’ for the main taxiways and ‘path’ for everything else.

Same documentation issue with my query on parking spots and multiple paths. Possible but not normal with no further details:

When you connect the point to the parking, the parking spot heading will be
rotated to be parallel to the path. Also note that you can connect more than
one Taxiway Path point to a Parking spot if required (although you wouldn’t
normally)

Hopefully we’ll get a few clarifications in a summary document for the World Hub at some point.

7

I highly suggest you use PATH, as every single one I changed to TAXI was rejected for that reason alone.

8

See WADB (released in the first batch) for an example of “drive thru” parking spots, with explicit blessing of the moderators.
Executive summary: connect the parking spots to taxiways on both sides with green “parking” paths and make sure the parking spots point in the direction you want them to point.

So far, I haven’t noticed the AI doing donuts on those parking spots, and the taxi ribbon always pointed in the “sensible” direction.

9

Thanks for the tip, also to @aurel42de for the above. Much appreciated :slightly_smiling_face:

Going back to editing tonight, I followed the tip in this post to suppress the original scenery (e.g. extra windsock) while editing, but now have a new problem. My loaded WIP scenery is ‘below ground’, meaning that all of the placeholder lines & nodes showing taxiways and parking spots are clearly some metres below the surface when moving the camera around. If I attempt to move any node, it jumps up to the surface.

Anybody else had this situation arise and if so, how to rectify? (Except NOT selecting the option to load my scenery exclusively, which is what I’ll do for now…)

Edit/update: After dropping to the menu, reloading and doing the exact same steps, it’s now OK. :man_shrugging: The ground does drop a few metres when first loading the project, before I load the BGL in the editor. Guess it’s normal though.

Second edit: Opposite issue in fact. The runway outlines and some aprons edges and nodes (the ones which I did not edit) are now floating above the ground. Textures are rendered on the surface. Gives me less confidence it’ll reach approval… but it’s a learning exercise. (Sorry to derail the thread…)

10

I had an airport in which some nodes were above ground and some nodes underground! My assumption is that the nodes are loaded following the normal, terraformed terrain. Then the World Hub flattens everything during editing, so you get some nodes that appear to not coincide with the ground. The airport which I spoke of is located in the Sierra Foothills and has a fairly good slope to it, so the nodes that were at the airport elevation were okay, but those above floated, and those below sunk.

I haven’t been able to tell whether dealing with this, I dunno, parallax(?) will cause errors in rendering once it’s rendered back into 3D.

11

To expand a bit on the parallax issue - say you have a runway that’s either very humped or very bowled. When projected into 2D, it will appear shorter than the actual runway length, so if one were to set lengths using the configuration tool and place endpoints in the flattened view, it may move things laterally when it gets restored to 3D.

12

Thanks. It is a little confusing. The terrain seems to flatten as soon as I load the project, but before I ‘load in editor’. I think I read somewhere that this is normal (whether only for World Hub mode or the regular edit mode, I’m not sure). Any part of the airfield that I haven’t touched, e.g. boundary, runways, a couple of aprons, remain at their original height. Everything I’ve touched is at a different height.

It may not matter as you said - the objects will just render on the surface, shifted up or down as needed to suit the terrain. However, when aligning notes between objects which are at different heights, a parallax error might occur if the object isn’t near the centre of the screen. After all, the top-down view doesn’t have an infinite focal length which would remove any parallax effects and make the 3D scene effectively 2D like a map.

Currently unsure how the terrain will end up (flattened or not) as I need to figure out how to test it outside of the editor, in game. The World Hub packages are different to the normal output, but I’m sure a little searching will find me the answer there.

13

That is the core of the problem. We need a very high viewpoint for the top-down-view or a true orthographic projection for the dev mode. That surely would mean some work for Asobo, so little hope.