touchdown84

Does that mean there is already some work done understanding on the structure of the scenery/airport BGLs from 2024? Because I couldn't find any information on the structure anywhere and for a small project I want to read part of the BGLs, but can't figure out what has changed from the offsets/field sizes etc. since 2020. If there is already some structure documented somewhere it would be nice to see that.

I think there is something weird with linked templates when you add a "Fast Turn" assignment to an aircraft where a linked template already contains a normal (slow) turn assignment. In that case the slow turn assignment in the template is never triggered, when slow turning nothing happens and only when fast turning the direct assignment in the aircraft is triggered. When I apply the template directly to the aircraft everything works as expected, as well if both assignment (slow & fast turn) ar both part of the linked template.

Just use 105 Render Scaling with or without TAA, there is an OBVIOUS difference in aliasing, especially visible on sharp edges (e.g. wings in external view), TAA is doing the heavy lifting there. It is applied in two completely different stages of the render pipeline, Render Scaling affects the initial internal render resolution and TAA is a post-processing effect. By the way, combining different AA methods has always been a thing, like MSAA+SGSSAA, and especially when one of the passes is a post-processing effect like FXAA or TAA.

I think you misunderstood the information text in the settings, Render Scaling > 100 does not "switch" from TAA to SSAA. TAA and Render Scaling are applied sperately for a combined result. The information text just states that it is recommended to use TAA when using Render Scaling < 100, as hard upscaling is increasing aliasing. But that does not mean you can't use it as well when downscaling (super-sampling).

It cleans/sharpens up some more edges, I use a large 42" display, that increases the perception of aliasing. Even with frame gen I'm limited by CPU anyway.

For me, at 4K, TAA + 105% Render Scaling looks good.

Hello, I see a weird behaviour when I want to merge a template into an aircraft configuration when the template already includes a linked template. When I do not merge but replace (or apply to an empty config) everything works fine. But when I merge, the linked template is not added as a linked template to the aircraft but the content is instead applied hard to the aircraft config (including e.g. aircraft automated scripts). Also during the merge dialog when I can select what entries from the template should be merged there is nothing mentioned from the linked template. I would expect to be added as an linked template (ignored when that aircraft already has that template linked), or at least offer to de-select those entries in the merge dialog. And another thing regarding templates, when during export I de-select a script group related to that template, it still gets added to the exported file. Seems a bit confusing to me.

Don't forget to apply the additional 20% discount code if you already own the 146.

Aerosoft has a sale on the Honeycomb Alpha for 199.99€ (may vary a bit depending on VAT) until end of week (regular current price is 280€, old release price was 250€). Probably mostly interesting for German/EU customers due to shipping (e.g. 6.99€ shipping in Germany or free if you buy anything else as they have free shipping to Germany from 200€). https://www.aerosoft.com/de/shop/flight/hardware/yokes/2567/honeycomb-alpha-flight-controls

It does not contain any physical media (confirmed in the Aerosoft forum), just an activation code for the MS store. I guess they learned from their stupid DVD-DRM decision for the 2020 physical edition.

I just ordered the Collectors Edition from Aerosoft, I think the value for the physical extras is ok. It's 60€ more than the digital Aviator Edition here (280€ / 220€, no shipping costs for Germany). And I also only already have bought one of the extra planes inlcuded in the Aviator Edition.

Just Flight is working on the A300B4.

I know, but I find it easier to edit the txt file directly.

I am using this https://de.flightsim.to/file/38162/x-touch-mini-gauge-for-use-with-aao-axis-and-ohs It's a bit complicated to set up and you have to assign the controls for the X-Touch in a separate config file, but it also allows you to control the LEDs.

I think you can make duplicate names unique by appending the name with its coordinates in the gfp file, see this post in the Navigraph forum regarding the gfp export from Simbrief: https://forum.navigraph.com/t/gfp-format-garmin-gtn-wrong-export-for-ambiguous-waypoints/11182

I noticed that when I was trying to create a dgml and had to mostly rely on looking up dgmls of other maps to see how it works. No worries, what I did now was create a simple http proxy between the dgml and the OFM page that on the fly resizes the images from 512x512 to 256x256 in the response, that way I have the more user-friendly zoom level of the smaller tiles while not impacting the performance of LNM. http://s000.tinyupload.com/index.php?file_id=00123782338147292791 Proxy implementation in case anyone is curious, dgml needs host/port of the proxy server and 256-tile-setting, otherwise the configuration is same as going directly to the OFM server.

I had a further look and managed to create a map definition that pulls the tiles remotely from the Open Flightmaps page: http://s000.tinyupload.com/?file_id=66428361868327531392 It's basically a composite of two tile layers, one base JPG-tile and a PNG-tile containing the aero/nav data blended on top (as defined by the dgml). That's not an official API, the URL contains the AIRAC and only the last few AIRACs are kept available, so the URL in the dgml needs to be updated regularly and there is no guarantee it will work in the future. It seems only the 512x512 tiles are available this way and only zoom levels 7 to 12 (in contrast to 4 to 11 in the download ZIPs). To have some indication for where you are I copy/pasted the cartolight tile layer until zoom level 6 to the definition. OFM is also only available in parts of Europe, so once you are zoomed in 7+ somewhere else in the world you only see blank space. @albar965 Is it somewhere configurable which tile-zoom-level LNP is using for a current in-application-zoom-level? As the map style changes and increasing information is added with higher zoom it would be nice to composite more detailed tiles already on a lower zoom on the map (for example the low zoom levels contain very little details and only the level 12 tiles contain VRP-flight-paths). If that's not possible a workaround is to change the tileSize width and height in the dgml from 512 to 256 or even 128. That has the effect that even though 512-tiles are loaded from the server the higher level ones are already used one zoom step earlier. Basically each decrease in the configured tile size shifts the zoom level by one. But this also has a performance impact, the program seem a bit more sluggish (probably because the raw data displayed is 4, 16, ... times the size as normally. Edit: Just checked, as expected RAM usage of LNM increases when using a lower tile size configuration: 512x512: 200MiB; 256x256: 500MiB; 128x128: 1400MiB on the same effective zoom level

Well, it's working without a problem with the OpenFlightMaps tiles. You download them as a zip package that already includes all the zoom level folders and the directory/filename structure is already in the OSM-format so no need for custom modes, just OSM-mode in the marble-dgml, serve the tile root from the web server and it works.

How to use OpenFlighMaps tiles in Little Navmap: Run a local web server that serves the tiles Create a marble-compatible, OSM-mode styled structure (dgml, preview, 0/0/0 dummy) and add to the LNM maps directory (data\maps\earth) (see example) (optional) convert all tile PNGs to remove transparency Example map definition: http://s000.tinyupload.com/?file_id=09950983582843687034 (extract into <LNM_root>\data\maps\earth) You can run a simple web server with python, just run python -m http.server 7878 (port must match port defined in dgml) inside a tile root (the directory that contains the 4, 5, 6, ... directories, e.g. slippyTiles_original\original\merged\256\latest\). If the tile root contains more levels than 4-11 adapt the minimumTileLevel and maximumTileLevel in the dgml. If you want to use tiles other than size 256 adapt the tileSize in the dgml. Hint: This changes the detail at zoom level in LNM because OFM has different map styles for different zoom levels. For example if you are using the 512 tiles from OFM you have to zoom in further in LNM until the map style that includes roads is shown. On removing transparency: Little Navmap does not handle tiles cut off with transparency well, when moving the map it will produce heavy ghosting/duplicating in the transparent areas (hard to describe). When you download the tiles from OFM in the settings you can select clipped or non-clipped, clipped has much more transparency because the area is cut out much more detailed, but even the non-clipped variant can have some cut off (transparent) areas in some border tiles on certain zoom levels. I suggest removing all transparency/alpha from the tiles completely, you can do that easily with a command line script using ImageMagick and Powershell. Example script: http://s000.tinyupload.com/?file_id=00282460439308057246 Multiple regions You can serve multiple regions from the same web server, just put the tile roots in sub directories for the regions (e.g. ed, lo) and serve from the directory that contains the sub directories. Then create/clone map definitions for each region and in the dgml adapt path="/" to point the matching sub directory. You can try to serve multiple regions from the same tile set by just copying the tiles together, but there can be differences between the regions for the same tile, mostly in the less detailed, zoomed out levels containing the regional boarders. If you do this make sure to use the non-clipped tiles! Serving from LNM You can also use the inbuilt web server from LNM to serve the tiles, copy your tiles directories to the web root (default <LNM_root>\web), adpat the port and path in the dgml and make sure the LLN web server is running. For me the inbuilt server was a bit slower in serving the tiles.

I still use WoAI, but it's a true pita to install it for optimal performance (installing into dummy-fsx-folders, moving files, repair some minor bugs, convert flight plans, convert bmp textures, find textures without mips and add mips, ...). That's the reason why I only update traffic once a year. I'd love to see (and pay for) a modern out of the box traffic addon without much performance impact.

I would check the XML files in the "categories" directory. Those control which mission categories show up. You shouldn't need to edit the original "FSCategories.xml", but you can create additional XML-files in that folder. I don't know exactly how they must be build. For normal missions the <Title> has to be the folder name in the mission directory. Don't know which IDs to use, I just copied missing categories from the FSX file to another one...

I don't know if the OP is having the same issue, but for me it is as follows (and you cannot see it on screenshots, as I'll describe below): - It is not blurry cockpits per se, but the small texts (e.g. tiny scales in the instruments or small print on the cockpit) are kind of shimmery fuzzy. - When your virtual head is not moving, you can't see the issue. So you can't see it in screen shots either. - When you are moving your virtual head with normal controls, you also can't see it, because you are moving too fast. - But when using TrackIR it is there because your head is always moving a little bit, even when you focus on one spot. That humble movement is enough for the fuzzy texts to appear. - Some planes are more prone to it than others. From the stock P3D planes I see it most obvious in the A36 Bonanza. - When I have SGSSAA enabled, I do not have the issue any longer.

I have a GTX 770 SC with a [email protected] and 4x MSAA + 4x SGSSAA works without a problem. Without the following settings my GPU is only on about 60% load through the game, with it the GPU is fully used. With the settings everything is fine, lower frames only in city areas, but that is even without AA and CPU capped on high scenery complexity / autogen settings: Additional Prepar3D.CFG settings: [Display] TEXTURE_BANDWIDTH_MULT=1800 TextureMaxLoad=30 [Main] FIBER_FRAME_TIME_FRACTION=0.05 [TERRAIN] SWAP_WAIT_TIMEOUT=2 [JOBSCHEDULER] AffinityMask=15 When in areas with low FPS I just lower the scenery complexity/autogen settings until it's fine. Keep in mind, AA impact is influenced by the screen resolution. I'm using 1920x1080.

@ X16 1.1 means you are only running with PCIe 1.1. But it could also mean it is in idle mode. When idling my card also shows PCI-E 3.0X16 @ X16 1.1, under load it is PCI-E 3.0X16 @ X16 2.0 (that is because my board only supports 2.0).

Maybe it is the same problem I had with importing the stock FSX aircraft. It seems Prepar3D didn't like that the default texture was referenced in the aircraft.cfg directly (with 'texture=' or 'texture=""'). When choosing a variant from the list often only the default texture was shown (and also loaded later), it seemed kinda random, sometimes it worked, most times not. The solution was adding a texture.0 directory only with a texture.cfg with the following: [fltsim] fallback.1=..\texture fallback.2=..\..\..\..\Scenery\Global\texture and I also copied the thumbnail.jpg from the default folder into this (maybe optional). Then in the aircraft.cfg I changed 'texture=' or 'texture=""' to 'texture=0'. That solved all my problems with showing/loading textures of the stock FSX planes. Kinda weird though as I have other planes that also directly point to the default texture without a problem... Cheers, Jan