Posts by Trespassers

    Hi Thomas,

    I haven't thoroughly tested it, but I guess the cultivation texture distribution is simply related to the number of available textures.

    In other words if you have 2 textures, the distribution chances will be 50%-50%.

    Now, it you have 4 textures for white houses and 1 texture for brick houses, the chances will be 4 to 1.

    Technically you may set as many toc files as you want. Of course, the more you have and the longer they get, the more you load the cart...



    Have you try to modify the tsc file and choose autoheight off, like chrispriv explain to me :

    Absolute height is an acceptable workaround, but it only works with the elevation mesh on which it was setup.

    If someone creates a more refined elevation mesh for your scenery your object won't adapt.

    Moreover, wind turbines are seldom single, isolated objects, but usually there are fields of them, so manually adjusting each single object height means a lot of work.

    I have a group of airport buildings that suffer the same issue, I'll look into them if I find a fix on the 3D objects themselves and let you know...



    Hi ozhomeroz,

    Thank you for sharing your interesting investigations and results.

    I just tried your method on a nasty part of mesh causing spikes. It happens to be an unsigned 8bit 5m dem

    Here's how default IPACS mesh looks like (quite good thanks to neighbouring Switzerland DLC).

    And how it looks like when I activate the geoconverted mesh (8bit source):

    Now, after translating in 16bits in Qgis according to your technique, the geconverted mesh looks like this (note de default IPACS mesh in the background)

    Default IPACS terrain without the mesh:

    So the method is not yet universal, I guess I should add a voids filling with an average value...



    It seam also to have the [autoheight_override-value] [1]. --->Does somebody now the meaning/effect of it?

    There are two settings :

    autoheight (true or false) which is a global switch for the tsc file

    autoheight_override (0 or 1) which is linked to an object. The value -1 gives the same result as 1, I haven't noticed a difference.

    Example with [autoheight][true] and [autoheight_override][0], note that I have given an offset of 35m, which is approximately the local ground altitude AMSL.

    If I set [autoheight][false], then whatever the autoheight_override value my object is placed at absolute altitude, i.e. 35m AMSL

    If I set [autoheight][true], and [autoheight_override][0], then I override the autoheight algorithm and my object is still placed at absolute altitude (35m AMSL).

    If I set [autoheight][true], and [autoheight_override][1], then autoheight computes the local ground altitude and my object is placed at relative altitude (35m AGL).

    [autoheight_override][-1] gives the same results as [autoheight_override][1]

    In other words :

    [autoheight][true] + [autoheight_override][-1 or 1] = autoheight is on and the Z coordinate works as an offset to local ground

    [autoheight][true] + [autoheight_override][0] = autoheight is off and the Z coordinate works as an offset to sea level

    [autoheight][false] = autoheight is off and the Z coordinate works as an offset to sea level



    Thank's, I've just try it but no more success unfortunatly.

    And I can't understant why I have no problem with two buildings (the tower and the building below) and problems appear with a third, one that uses the same textures

    How did you do it?

    I think there's an option in 3DSMax to merge the origins of multiple geometries into 1 common. This is something that can be checked when trying to rotate your object : each geometry rotates around its own centerpoint instead of seeing the complete object rotating as a block. Of course you won't notice it by translating objects.

    There must be a similar option in Blender or AC3D.

    I don't think there's a feature in MCX to do it

    At least, it is something I noticed on some occasions, and I would expect, as Jet-Pack wrote, that once all geometries share the same centerpoint that the resulting 3D object TMB behaves as a block. Again, I've not yet tested but I know in which building I want to do it next...



    (...)The most important difference I felt were the forces acting back from the control surfaces upon the controls.


    Exactly. There's no spring to recenter the yoke/stick in an aircraft: the control surfaces recenter in the air stream.

    On the ground there's thus no force (except weight if unbalanced controls), and the faster you fly the stiffer the controls.

    The trim alters the centering of the control surfaces in the stream, allowing the pilot to reduce the necessary effort to maintain the yoke/stick in the position corresponding to the desired aircraft attitude.

    For instance, in order to fly level, the pilot pulls/pushes on the yoke/stick to get the desired nose attitude, then holds firmly the controls in this position while trimming until no more force is needed, the yoke/stick now naturally recenters in this position.

    Of course, each phase of flight may require a different trimming and it's really up to the pilot how and when to use it. Some like to keep a light positive effort in the stick.

    Non-FF desktop yoke/joysticks, on the opposite, are spring-loaded and usually recenter on a fix position. Trim acts then merely as an offset.

    For flying level, you push/pull the joystick against the spring to get the desired nose attitude. But then, if you hold the yoke/joystick while trimming, you just loose your attitude because trim acts as an offset on elevator.

    You need thus to simultaneously progressively relax your effort on the yoke/joystick while trimming, until you achieve the desired nose attitude when your spring-loaded controls are back in their mechanical center zone.

    As a result, one usually flies yoyo until approximately finding a suitable trim setting... Flying by the trim is a common FS-grown pilots mistake (I did it too by the past until figuring out how to properly trim my aircraft).



    Salut Michel,

    Ne le prends pas mal, mais si tu as besoin d'aide, évite stp de poster n'importe où en hors-sujet. Je ne suis pas sûr de comprendre le rapport entre ta demande et la discussion de ce fil.

    Il vaut mieux créer un fil dédié.

    Pour essayer de répondre malgré tout à ta question, c'est vague et il y a plein de raisons possibles, à commencer par une fausse manip (cliquer-glisser par erreur un dossier ou un fichier ailleurs)...

    Si tu dis que tu n'as fait qu'ajouter un fichier tsc, eh bien la première manip à tenter pour troubleshooter est de désactiver ce tsc en ajoutant le fameux préfixe __ (double underscore) au nom.

    Soit ça rentre dans l'ordre et le conflit provient de ton fichier tsc, soit ça ne rentre pas dans l'ordre et je te conseillerais de commencer par inspecter tes répertoires à la recherche d'une fausse manip ou de fichier/dossier manquant.

    Pour la suite, comme évoqué il vaut mieux créer un fil dédié. ;)



    Darken or brighten the image in GIMP untill it matches the terrian height as described above.

    Well I wouldn’t advise this.

    First it may work on flat ground, but not in mountainous terrain where spots of your higher resolution mesh are higher than default mesh, and other spots are lower.

    Then, it alters elevations of your complete mesh.

    The solution for merging mesh borders is usually to stop your Level 10+ compilation earlier inside your scenery and leave an outer band of ground that you don’t compile higher than Level9. Points are then distant enough to absorb height differences without making walls...



    I had some time hands on with the Honeycomb yoke at Flight Sim Cosford. Nice kit. However I also had some time with this. Bit more expensive (£450 I was told), but very nice and superbly built. The equal of a Yoko I'd say but better in every sense. Out in December I believe.

    Thanks for the feedback, the Fulcrum reads more attractive to me than the Honeycomb, though still no talk of force feedback...



    Tried it yesterday. Expectedly, it doesn't look great close-up around an airport, however, at 6000 ft or above it starts to get really convincing and looking good. In any case, it would be a big improvement over default ground imagery.

    Thanks for providing and kind regards, Michael

    Actually it's a great improvement for what I call "en-route" scenery, even for VFR GA.

    Say you have a nice HR photoscenery for Martinique and Guadeloupe and want to fly from one to the other.

    Just midway you have Dominica, which like all of Antilles is featured in IPACS default scenery as an ugly patch of ultra low res satellite pictures scattered with flattened clouds wide in the sea... (cf. Vogel's pictures above, seen from 5'000 ft it looks even worse)

    Total immersion killer.

    En-route scenery provides a very consistent Dominica for such a flight, as long as you don't aim to go sightseeing from too close.

    I initially created an en-route scenery in 2m/pixel out of Virtual Earth orthos providing harmonized (though quite dull) colours for the complete Petites Antilles, cleaning flat clouds from the sea, and compiled down to Level 7 to prevent distant scenery from popping-up in such flights.

    However most islands still had clouds on theirs summits, and the low quality of sea picture forced me to paint over most shallow waters...

    This is for instance Dominica



    After a quick comparison with Vogel69's latest work I can say despite the lower resolution his en-route scenery is way superior, with beautiful colors and much fewer clouds.



    Thank you IPACS for your reactivity!

    Autoheight works now fine with airport ground mesh for xref and cultivation buildings (I haven't tested yet with vegetation and lights) of TOC files declared within airport tsc file.

    @Scenery designers, please keep in mind that autoheight won't consider airport ground for autoheight calculation of objects declared in separate tsc files, causing then potentially floating/sunk objects.

    In other words, keep clear enough from airport zones when placing objects like cultivation or xrefs on regional scenery, and declare everything around an airport within the airport tsc file if any.

    Airport creators can then easily extend their cultivation/xref coverage to seamlessly merge with regional scenery...

    Remainder : airport ground mesh is not just the strict area containing runways, taxiways and apron, but generally an "island" shape around the airport, allowing for soft, seamless, mesh integration.

    Airports creators should ideally share a KML of their surfaces footprint...

    Example from the wiki tuto:




    This is the real hard work in photo-scenery making !

    Grabbing orthos from the net is easy, compiling them into a scenery is easy, but making a quality photo scenery out of it is a real hard work, no magic wand nor automated tool to just click and get the result.

    Congrats Schnuffelduffel for your ongoing work, it looks gorgeous ! Toi, toi, toi !!!




    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 ?



    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