Posts by Trespassers

    The issue mentioned by Antoine is not a bug, it's just that Aerofly FS conceptually does not consider individual TSC files at the same location, e.g. autoheight will only work if XREF objects, 3D runway meshes and other stuff is defined in a single TSC file otherwise we would have to implement a priority system which is not a clean solution.

    So as a short answer: Please define 3D runway meshes, XREF objects and all other 3D objects using auto height in a single TSC file.

    it is unfortunately not the case. In my example both xref and cultivation were called from the same tsc as the airport.

    So yes, I’m afraid it’s a bug !




    Masks for islands are seldom an issue since the merging terrain is generally sea at zero altitude.

    Scenery borders, with or without masks, are much more of an issue when falling on ground. How to stop then the mesh without causing walls ?

    The smoothest transition is achieved by first stopping HR mesh and leave an outer band of mesh compiled in Level 9 or so.

    But how then should another editor add a neighbouring scenery ?



    Yes, we need a correction by IPACS, that is out of question.

    With "affecting existing sceneries" I mean especially the regular, non xref objects which we gave an offset.

    I updated my initial post with the case where 3D objects are declared in separate TSC files, i.e. not in the objects section of an airport.

    Objects declared in the airport tsc section are not affected by the bug.

    This is another demonstration of the need for scenery priority concept.



    However a solution will hit all our sceneries, where we used a height correction for objects near runways.

    Well, Z height correction is merely an enabling workaround for this bug.

    Since it was introduced 3 days ago for xref objects only (not yet for cultivation), it should not be difficult to set it back to zero when IPACS fixes autoheight.

    If you add now Z correction to your sceneries, simply keep a backup with zero value to instantly revert.

    3D objects in the corresponding section of the airport are not affected by this bug, thus they need no correction.



    Dear IPACS team,

    After some testing I have identified a bug in autoheight calculation, affecting both cultivation and xref objects placed on airport ground surface.

    BUG: autoheight of xref or cultivation objects placed on airport ground is not computed based on that airport ground, but with the underlying elevation mesh instead. This results in floating or sunk objects.

    Demonstration with XREF objects declared in the airport tsc file

    Demonstration with CULTIVATION objects declared in the airport tsc file

    3D OBJECTS declared in the objects section of airport tsc file have their autoheight properly computed.

    CULTIVATION and XREF objects placed on a scenery mesh have their autoheight properly computed


    3D OBJECTS declared in a separate TSC file (i.e. not in the objects section of airport tsc file) have their autoheight wrong computed.

    Conclusion : this bug seems to specifically affect cultivation and xref autoheight calculation in places where a ground flattening surface is declared (typically airport).

    3D object declared outside the objects section of airport TSC file are also affected, due to lack of scenery priority setting.

    Please keep in mind that xref and cultivation may also be declared in a separate scenery folder from airport tsc, thus it must be possible to force priority to the airport local flattening before computing autoheight of whatever placed on it.

    Hope you can fix this bug soon.



    I made a test XRef and reset all objects heights to "0". I removed the Runway folder, and all XRef objects were perfectly positioned on ground.

    Hi Jake,

    Thank you, this confirms my observation : xref autoheight placed on airport platform is not computed based on the airport mesh but on the underlying scenery.

    This is a bug in AFS2. Z height correction is merely a workaround, not a solution.



    I can do the test in the next few hours, but Tom and I believe that this might have something to do with AC3D. Regardless it is still nice to adjust heights for other reasons.

    There's a bug in the 3DSMax exporter : when I export as Object or Scenery, the Z placement of my model in 3DSMax is not considered. I have to export as Aircraft as workaround. But a bug in the 3DSMax exporter doesn't necessarily mean the same bug in the AC3D exporter.

    Example of sunk aircraft exported as Objects.

    Exporting them as Aircraft instead fixes this issue, but placing several time the same XREF object using autoheight on an flat airport ground results in fancily floating/sunk aircraft:

    BTW this is not a cinematic of me bouncing my landing ;)




    I had the chance of doing the test tonight, it's obvious now : autoheight is computed based on the underlying mesh below the airport ground instead of airport ground.

    It's a priority issue in scenery loading, despite xrefs belong to the same scenery folder as the said airport.

    Airport ground enabled

    Airport ground disabled

    Airport ground enabled

    Airport ground disabled

    This fairly explains why so many encounter floating/sunk xref objects on airports!

    Z correction is an enabling local workaround for a couple of objects, but it's no solution for scenery making.

    Once again a clear priority setting capability is compulsory for scenery design.



    BTW I have the same issue when xref are called from the airport TSC, meaning that there’s no way I can force autoheight to work properly.

    Anyone here to confirm?

    Is it a systematical wrong priority setting ? or a more or less random issue depending on uncontrolled parameters ?

    Thanks in advance for feedback



    Ok, thanks for the quick feedback. It looks like the z-component was indeed not used anywhere else yet. We will move this enhancement to the official channel once we come out with a normal update anyway, maybe within 2-3 weeks.

    Yes, it also lacks to cultivation, where its effect is obviously disabled..

    The fix works beautifully for xref objects.




    Friendly reminder that Xref height adjustments would be greatly appreciated.

    Hi Jake, hi everybody,

    Now we have a fix for xref height adjustment, but not the reason for initially floating object.

    I have currently no access to my PC, but could you please do me a favor with that very scenery where you display floating fuel pump and cars?

    Or anybody else willing to try it with their own floating/burried xref issue?

    Could you please make a test without height correction (0) and without the airport ground and post here a screen?

    In other words, just see how those xref objects would sit on default ground mesh, without airport flattening.


    To disable a scenery folder just add __ (double underscore) prefix to folder name.

    In case you call these xref objects from the same TSC file as airport ground, just deactivate airport ground by commenting (//) the corresponding object block.

    Thanks in advance



    Back to the topic, this explains why creating extended wide range scenery in single tiles is suboptimal.

    Due to the still few available HD-covered scenery zones, few people actually fly from a scenery to another.

    When users create a scenery they’ll usually load and start from their scenery, so load radius effects mostly get unnoticed.

    But when creating a scenery one should always keep in mind:

    - how does it load in-flight when coming from far enough for the scenery not to be in memory at startup?

    - how easy someone I don’t know can create and seamlessly merge the patch of scenery next to mine?



    Heu... je ne suis pas sûr de comprendre, mais tu me sembles te mélanger les pinceaux :

    1) où se trouve pylongen.exe ? J'imagine dans le répertoire _PYLONGEN\pylongen\, mais pas dans le répertoire depuis lequel tu essaies de le lancer...

    2) map.osm ne se trouve pas dans le même répertoire, mais dans _PYLONGEN\

    3) il n'y a pas d'espaces dans les arborescences


    YBSU (Sunshine Coast) is a Fscloudport airport with a size value of 5000 in the TSC, and has no cultivation. In the screenshot below you can just make out the buildings of the airport from 20nm, then runway and buildings are clearer at 14nm. The last screenshot is the 14nm view with the airport TSC deleted, to show it is not the underlying textures that are rendering the airport and its buildings. I had started my journey some 200km distant.

    Units in AFS2 are (generally) SI, thus 5000 stands for 5000m.

    As long as loading a TSC file is concerned, two parameters in the TSC are relevant: size and position in the upper block.

    Position is usually in lon lat degrees and size is in meters.

    However depending on your graphics quality settings the size value is not a total value but just an extra offset.

    The position value should be roughly the center of an imaginary bounding sphere around all your objects in the TSC file - in your case an airport, but it would be the center of your TOC file tile if we're talking about cultivation.

    If your setting is ultra quality, the distance from viewer to the tsc loading threshold is around 30 to 40 km, so size 5000 in the TSC file means a load radius of something like 35-45km...




    Could you explain this statement in more detail? Even though Nick is correct that it is just a few more clicks to make a larger block of grid 9s in to an equivalent grid 7, those grid 9 look quite small when you look at the big picture.

    Please refer to my unofficial AFS2 Geoconvert knowhow base document for tiles size and AFS2 Levels, everything is detailed.

    (also available on if the link isn't active anymore)



    What you can do also is use Vogel69's AFS2 grid Generator (available on to generate a kml file of your scenery area in Levels 7 and 9.

    You open both of them in Google Earth to display the corresponding tiles with their name and coordinates, then you know exactly what Level 9 tiles to process with Aeroscenery.



    I must admit I don't know the altitude cutoffs where Aerofly displays a certain level of scenery (i.e. at what point would it show the very basic default level 7 scenery over the level 9 scenery described above - if at all).

    As I only fly GA I never reach it, or maybe it will always use a minimum of level 9 if available.

    I noted that most add-on scenery includes a minimum of level 9.

    I will take a look at the blank pixels in USGS scenery though. I thought that one was fixed.

    Hi Nick,

    This is quite true in Europe or US where default IPACS texture are good enough (generally free of clouds and major artefacts) for the Level 9 vs Level 7 difference to be imperceptible, but the cutoff distance is not so far.

    This becomes highly visible where default IPACS textures are poor.

    For instance, my Caribic scenery (Petites Antilles) requested me to generate Level 7 too, otherwise Level 9 scenery pops up in the distance when flying GA from an island to the next one, even as low as 5'000ft (default IPACS textures are scattered with clouds).

    Anyway, I assume one can easily group several Level 9 tiles in Aeroscenery and manually add the section in the TMC file for geoconverting Level 7...



    There’s a new line in Main.mcf :


    Just activate with true to make the pilot visible (without head to prevent obstruction) when sitting at the controls.

    If you altered the aircraft tmd file (showinside) to have this effect, just remove it.

    The main.mcf switch is universal => affects all aircraft having an IPACS pilot...



    Hay ed I re done the orthos but when the water masking was done , the standard photo scenery showed through, and looked like a right mess ,so looks like I'm going to have to redo them again and make a larger area of the orthos to cover .

    Hi Brunnobellic,

    Yes, water mask is always an issue in AFS2 due to lack of both:

    - a water texture in AFS2

    - decent orthophoto for the sea

    As a result, the only workaround in many cases is tho paint the sea, far enough from the coast to blend with deep sea without masks.

    Since default terrain is an harmonized low res satellite picture, there's no universal deep sea color that'll blend seamlessly anywhere.

    In many places I was however successful using R0G11B24, you may try this color as a start point and fine tune if necessary (or, worst case, you'll have to search for another color if the deep sea in Greece is very different from the ocean).



    It's not strange, it's the exact reason for making the head invisible.

    Before that possibility, I slightly moved the pilot's eyes point of view - you'll find the switch for it in the upper part of the file, just uncomment the line you want to activate, and comment the other one (do not uncomment the lines with comments).

    Now that the pilot head can be hidden, I reactivated by default the original IPACS point of view...

    Or just below the PilotHead line, you'll find an alternate switch to make the complete pilot invisible, but flying in an empty seat is a weird thing.



    Well, I haven't noticed yet since I've been essentially working with the dev camera lately, but if it's true that's really good news : the pilot head is a real immersion-killer with the Track IR or in VR.

    Making it optionally invisible is a big improvement to me.

    I think Jet-Pack gave a hint to activate it by adding "PilotHead" just after "PilotBody" in the graphics human.

    I'll try it out tonight