Jump to content

Holger Sandmann

Moderators
  • Posts

    11,024
  • Joined

  • Days Won

    9

Everything posted by Holger Sandmann

  1. Hi there, unfortunately, autogen excludes don't work on autogen placed with photoreal imagery. That's not specific to TrueEarth but rather true for all autogen that isn't placed via landclass tiles. To manually remove or alter this type of autogen requires loading the corresponding orthoimage tile into Annotator.exe, along with the correct autogen definition .xml files; see the SDK documentation of autogen placement. A work-around, if it's only a few trees or buildings, is to place small objects on top of each autogen object, for example one of the default shrubs. If those objects have their suppress-autogen flags set the autogen will no longer display. Cheers, Holger
  2. Hi Marc, thanks for the kind words! We do think of our Landmarks products as "dynamic" meaning further updates and additions are planned, though depending somewhat on how well received a given city is. Given that the original selection of custom objects is necessarily a compromise we tend to have pretty long "wish lists". I'll certainly add your suggestions to it. Cheers, Holger
  3. Hi Brian, try verifying Orbx Libraries first. It's the "product" that checks and repairs the necessary entries to terrain.cfg that are then used by Vector, openLC, the regions, etc. Cheers, Holger
  4. Hi David, in Central's options menu, under Downloader, try setting concurrency to Hard Disk Drive, which reduces the number of parallel download threads. Another tip is to prevent OC from being the only app downloading data, e.g., running a random YT movie in the background helped in my case. Not sure if you're having the same issue though; for me it was that the multiple threads somehow "overwhelmed" my modem, causing the interruptions. Cheers, Holger
  5. Hi Paul, those MSFS bgl files can actually be loaded into the TMFViewer tool from the FSX/P3D SDK to examine their content and coverage area. In this case the file contains local terraforming and object/vegetation exclusion polygons limited to northern Orcas Island and Sucia Islands. Those are the yellow polygons I've circled in red. The blue water layer I just added for spatial reference. I don't know why the freeware mesh would be affected in other areas but that's probably due to nature of how it was made, presumably one of those heightmap mesh files. Heightmaps are essentially complex terraforming rectangles meant for airports and local adjustments. Since they work at the same priority level as other terraforming polygons (unlike a MSFS native mesh file compiled to .CGL format), conflicts of this nature are inevitable. The usual workaround is to remove the mesh heightmaps in the overlap areas. Cheers, Holger
  6. Hi guys, thanks for the kind words, much appreciated. We are experimenting with better terrain data for the local mountains including the entire Cape of Good Hope area. Google Maps extracts aren't an option for us but there are other possible approaches so stay tuned. ... and once we have a better and stable terrain model for Table Mountain we can implement a proper (animated?) cable car. Cheers, Holger
  7. Hi guys, the weird thing about those hovering lights above buildings is that their appearance is inconsistent; during some of my night flights across the city there are none, during others the entire road network seems to have lifted off. Possibly related to start location and flight path but I'm not sure. It's not a local issue though as it does happen in many default areas too. What would be helpful if MS/Asobo gave us the ability to exclude or place these floating orbs; at the moment we have zero control over their position and altitude. Cheers, Holger
  8. Hi guys, thanks for the feedback. The "water glitches" on Table Mountain are actually temporary tears in the terrain itself, the light blue being the colour of "nothing" meaning no textures get applied. It happens in mountainous areas across the world, at specific view distances, and the issue has one of the longest running threads in the official forums: https://forums.flightsimulator.com/t/transparent-strips-in-the-mountains/360660 We're experimenting with different ways to remove or minimize them in this area and elsewhere; fingers crossed. Cheers, Holger
  9. Hi there, sorry, but that's the way it works in FSX/P3D when placing landclass features as polygons: we developers have zero control over which part of the tiled texture gets displayed where because that is hard-coded globally. Think of it as a planet-wide layer of golf course textures, and each golf course polygon cuts a hole into the general landclass above, revealing bits of that layer. The only other option is to place golf courses as raster landclass. That would mostly avoid cutting through features but then the golf course will appear anywhere within about a square mile of its actual location and with incorrect outlines. Given that it's usually the spatial orientation and position that pilots use to navigate visually we believe the polygonal approach is better for clearly delineated features such as gold course, towns, forestry areas, etc. If golf courses are 'your thing' then some photoreal coverage would be the better solution for you -- with its specific downsides, like lack of seasons and huge storage requirements... Cheers, Holger
  10. Hi there, it's possible to create very large ortho CGL files as long as they don't cross one of those grid cell boundaries I mentioned, in which case they would need to subdivide the product into separate layers. When covering relatively small islands, the likelihood of crossing grid cells is, of course, smaller. In any case, the developers won't be able to sell these on the MS Marketplace, at least as long as MS has that 4GB cap for any single file in a package. Note also the product sizes for their higher-resolution (probably 60-100cm) version: ~20GB just for the 850 sq km of Lanzarote! Ortho coverage for New Zealand, for example, would require more than 300 times that Cheers, Holger
  11. Hi guys, no need to go 'dude' here. Big things that can't make it up or down the tricky stretch of the 'impossible' highway get shipped in by barge. There's plenty of large equipment in Bella Coola. Cheers, Holger
  12. Hi pezi, as I mentioned, at the moment we don't have the ability in MSFS to alter default buildings, like changing height or appearance. In MSFS the only option is to exclude and replace them with custom models, until Asobo/MS expand the SDK accordingly. All those buildings in Niederrad that are currently too low are default 'autogen' office buildings. As with any product, there's a limited budget, hence we had to pick some of the more obvious buildings in Niederrad, which are the seven marked on the Google Earth screenshot. I assume there will be a World Update for Germany at some point, or at least an update of the generic buildings database with the correct number of floors. Also, should Landmarks Frankfurt sell really well, we may have the budget for a v2, like we're currently working on for London. Sorry that your workplace didn't make the cut. Hopefully, the other parts of the city improve sufficiently on the default city. Cheers, Holger
  13. Hi all, thanks for the feedback. Out of our budget of about 110 custom buildings we managed to replace seven in Niederrad (see screenshot below), the others remain the default 'autogen'. Our buildings are scaled with official data like Emporis, eg Deka Bank is 45m tall. Unfortunately, the SDK doesn't allow us to alter default autogen at the moment so all other buildings are unchanged. We're aware of the change of main sponsor for the Waldstadion. It's not an easy fix though as the sign is 3D geometry not just a texture. Good tip with the ICE being on the wrong bridge; fortunately that's an easy adjustment. Let us know if you spot other issues, please. I grew up near Frankfurt but it's been ages since I've been there last. Cheers, Holger
  14. Hi there, those look like the issue users of a Zinertek product reported, which supposedly has been fixed via an update; see https://orbxsystems.com/forum/topic/205731-brisbane-terrain-problem Cheers, Holger
  15. Hi there, At the moment, this is not possible as far as the orthoimagery is concerned. While the SDK does allow us to compile custom orthoimagery -- some of our MSFS airports and landmarks city packs include it -- there are several hard barriers to cover areas much larger than ~100 sq km, and TE Eastern Alps is ~1,000 times that size! The MSFS package builder only allows for a single ortho CGL file per project, while Eastern Alps, in the P3D version, has some 350 tiles whose individual Photoshop source files are about 5-8GB each, meaning we can't possibly combine them into a single source file for compilation. Moreover, the MSFS compiler itself is much more limited in terms of influencing compression and output resolution, and the MS Marketplace currently has a limit of 4GB for any single file included with a product. That being said, there are opportunities for porting some of the components of TE Regions to MSFS, and the Regional Packs announced in this thread are an example of that approach. Cheers, Holger
  16. Hi there, the intention certainly is to have those pads landable. I've just checked and the collision flag is actually set for that building's pad area so I'll need to investigate further what's going on. Does the helipad on the Allied Health Building at the NE end of downtown work? Cheers, Holger
  17. Hi Chris, we would have liked to cover the entire Adelaide region with custom orthoimagery. However, there are hard limits for this in MSFS, at least for now, and thus we had to select about 100 sq km of the downtown, industrial, and shoreline areas. As John mentions, hopefully a future update by MSFS will bring better-coloured Bing imagery to the larger Adelaide area. Cheers, Holger
  18. Hi Hendrik, looks great, thanks! Apologies for making you run circles around the static vessels. I was wondering how Landmarks Singapore might impact your project as I was placing the 150 or so offshore statics; pretty crowded anchorage indeed... On the plus side I've "rescued" the submerged naval port to the southeast of Changi Airport so at least your military vessels have somewhere to aim for. Cheers, Holger
  19. Hi Ben, not sure how that can be as openLC Europe doesn't include any shoreline vectors for GB. If you don't have Global Vector installed then the default shoreline vectors and their respective surf effects remain active. Cheers, Holger
  20. Hi Andy, We're actually keeping the five default landmark objects in Singapore -- they are of very good quality indeed -- but are adding things that are missing like night lighting, rooftop vegetation, etc. Fair point, thanks for the feedback. Cheers, Holger
  21. Hi Michael, no news yet but I'll check with the "bridge maker". Cheers, Holger
  22. Hi all, starting today we're releasing updates for our FTX Regions that primarily deal with the larger airports in each region. The underlying issue is that the default airports in Prepar3D v5 have received new generic terminal buildings and layout updates. Our airport enhancements, at these larger airports, incorporated some of the v4 versions of these features, which then ended up missing or misaligned in P3D v5. These small service packs make the necessary adjustments. Also, some airports within the FTX Regions have had their ICAO changed and those will be updated as well. April 26, 2020 release: FTX Southern Alaska: PANC, PAJN, CYXY adjusted FTX Pacific Fjords: PAKT, PANT, CYBD, CYYD, and others adjusted FTX Pacific Northwest: CYVR, CYYJ, CYXX, KSEA, KPDX, KEUG adjusted May 9, 2020 release: FTX Central Rockies: KBIL, KBOI, KBZN, KGTF, KHLN, KIDA, and KPSC adjusted ; also Driggs-Reed Memorial ICAO changed from U59 to KDIJ FTX Northern Rockies: CYEG, CYLW, CYXD, CYYC, KFCA, KGEG, and KMSO adjusted June 18, 2020 release: FTX Northern California: KFAT, KMFR, KMRY, KOAK, KRDD, KSFO, KSJC, and KSMF adjusted; also ICAO changed for Nevada County from O17 to KGOO, for Mariposa-Yosemite from O68 to KMPI, and for Westover Amador County from O70 to KJAC FTX Southern California: KBFL, KLAS, KLAX, KONT, KPSP, KSAN, KSBA, KSBD, KSNA and MMTJ adjusted; also ICAO changed for Boulder City from 61B to KBVU June 27, 2020 release: FTX Germany North: ETNL, EDHL, EDDH, EDDW, EDDT, EDDB, EDDV, EDDG, EDLP, EDLW, EDDL, EDDP, and EDBH adjusted. August 1, 2020 release: FTX Germany South: EDDC, EDDE, EDDF, EDDK, EDDM, EDDN, EDDS, LFSB, and LSZH adjusted. FTX Norway: ENBO, ENBR, ENGM, ENTO, ENVA, and ENZV adjusted. October 5, 2020 release: FTX England: EGBB, EGCC, EGKK, EGLC, EGLL, EGNM, EGNT, and EGSS adjusted. FTX Scotland: EGPF and EGPH adjusted. September 8, 2021 release: FTX New Zealand South Island: NZCH, NZCI, NZDN, NZNS, NZNV, NZQN, NZRT, NZTI, NZTU, NZUK and NZWL adjusted. --------------------------------------------------------
  23. Hi Michael, indeed, it currently is missing. In P3Dv5 the old default model got replaced by a generic extrusion bridge (!?!), which the PNW exclude files (thankfully) remove. The good news is that we're working on a custom solution for not just the Lions Gate Bridge but also all the other landmark bridges in PNW's Vancouver area -- stay tuned! Cheers, Holger
  24. Hi guys, very weird, I've never seen a report of this before. The thing is that landscape components, like mesh or flattens, are passive meaning they can't reach up and grab an airplane out of the sky. Thus, I'd think that it must have something to do with the coding of the aircraft, in particular what ground data it reads (and when) while close to the ground. As far as I know a lot of the flight modelling with these complex aircraft is computed externally and thus they (intentionally) behave differently from aircraft relying on the default flight model. Have you shown the video to the respective developers? Maybe they can elaborate how their aircraft determine their position in the final moments prior to touchdown and how a sudden change in ground elevation can confuse the aircraft's flight model; perhaps something related to computing ground effect? (i.e., in this case the effective height of the air column underneath the aircraft suddenly decreases by 12ft, which could make a big difference in the calculations). The default altitude for KSFO is 13ft (3.96m). With NCA we change this to 3.69m = 12.1ft, not because we wanted to but because, for whatever reason, Flightbeam's KSFO team had done so and many NCA customers wanted the two products to be compatible. However, the difference is less than a foot, much less than the drop experienced by your plane, so I don't think this really is a factor. Moreover, Tristan has stated that the issue occurs with both default scenery and NCA meaning default and altered airport elevation. Given that reducing the mesh resolution setting makes a difference it seems to me that the critical factor is the slope of the step, which is controlled by the adjacent flattens (ocean water and airport ground, respectively) and the spacing of mesh points as set by the mesh resolution slider. Does the issue still occur if just the NCA mesh entry is deactivated? If not perhaps the successful test with just Global Vector also was without an added terrain mesh file (the default mesh is coarser meaning less steep slopes). Either way, unless we know what actually triggers the change in the aircraft's flight model it wouldn't make much sense to attempt to make any adjustment to NCA files. You'll also need to deactivate ADE_FTX_NCA_KSFO_elevation_adjustment.BGL in scenery\world\scenery as it enforces the NCA elevation change. Cheers, Holger
  25. Hi again, Global Vector doesn't exclude, place, or alter antennae, so that cannot have been the issue or trigger. Any particular reason all of your screenshots are taken at night? Makes it difficult to cross-check. Also, coordinates blended in with all screenshots would help to find the same location. I did check the area south of KCDW and there are lots of default antennae in the area (more noticeable when temporarily deactivating all autogen). However, they all have different heights, which is different from the display issue in the referenced threads where all antennae show their full length of ~300ft. Difficult to say from your night screenshots whether you're just looking at the default scenery or whether you do have the display issue. Cheers, Holger
×
×
  • Create New...