X-Plane 10.42 Released

25 comments on “X-Plane 10.42 Released”

1. Good job on getting this latest fix out of the door – and out of the way for the new gateway airports injection!

   You can count on me to ping you whenever the eight weeks are up again 😉

   Jan

2. Good evening,

   The 10.42 update seems to have hosed my roll/pitch/yaw control. No control inputs from my joystick accepted (used a keyboard flight control plugin to check that it wasn’t my joystick that went south….no avail either).

   Both joystick and keyboard flight control inputs worked fine in 10.41.
   Is anyone else reporting this?

   Best Regards,
   Xavier Roberts

3. Disregard, clearing my output/preferences folder fixed the issue.

   Best Regards,
   Xavier Roberts

4. SPIM has changed icao code starting this month please update it to SPJC as Im having a hard time configuring weather tools and fms data

   1. File a bug on the gateway please.

5. Hi Ben,

   what’s the policy with exclusion zones and global (default) airports going to be? Right now it seems to me that they are not mandatory and that causes a lot of trouble with 3rd party scenery addons like W2XP. Well, you can blame addons for that…but it will probably also apply if global default scenery is to change (updated). Discovering trees and bushes on the runway during final is not too much fun.
   And idea how to approach this problem?

   Flo

   1. The policy is that exclusion is _not_ mandatory in the global airports.
      – If the boundary polygon is set up correctly, a recut of the underlying DSF will not conflict with the airport in the future.
      – All add-ons should be higher priority. This will be -enforced- in the next major version of X-Plane.

      If you know of a legitimate reason why a third party add-on is:

      1. Lower priority than the airports for a good reason and
      2. Is trying to put 3-d where the airport is

      let me know.

      1. Hi,

         there is fantastic scenery available from sites such as world2xplane or simheaven.

         They generate autogen (fascades, objects) using OSM and other Sources for large areas.

         1. Thesed are of course lower priority than global / custom Airports
         2. They generated objects everywhere, can’t exclude individual spots such as airports.

         Why not excluding by default within the boundary polygon? I do not think that any global or custom airport needs objects or roads packages with lower priority.

         1. Hi,

            It seems to me that these scenery packs are simply -wrong-.

            If the scenery pack contains autogen within an airport and no exclusion zone then, when the airport is used even without the global airports (e.g. let’s assume the global airport didn’t exist) then there are going to be houses on the airport surface area.

            These scenery packs should populate the airport only with airport-like stuff, not non-airport stuff.

            1. well, it seems exclusion zones are just not being created consistently – not for global airports, custom airports or different types of autogen sceneries.

               They might do it all wrong – but that doesn’t help. If the community shall provide this variety of fantastic enhancement such as w2xp or prefab airports, then the handling needs to be more simple.

               When excluding automatically within the boundary polygon, ordering in scenery.ini makes sense. Then users can decide what airport implementation should be drawn – that’s it.

            2. I’m not sold on this for a few reasons:
               – Polygonal exclusion code -does not exist-. This simply isn’t something X-Plane does right now, so any solution that depends on this must be considered as a peer to “better exclusion zone tech” because they are equally difficult to code.
               – Exclusion within the boundary polygon implies that a human makes the airport boundary polygon. If humans are not doing a good job with exclusion zones, what makes you think the boundary polygons aren’t wrong or broken? The boundary polygon cannot be -directly- viewed in X-Plane, so it’s even more likely to contain authoring mistakes.
               – Letting users decide what airport should be drawn strikes me as a step in the wrong direction. Of everyone involved in the process, users are the only group that hasn’t proven at least some knowledge of the scenery system by -making- scenery.

            3. Hi Ben, I am quite sure if you fully got the idea of World2xplane. It generates 3D objects and forests as a complete replacement for standard X-Plane autogen.
               Typically World2xplane scenery psckages cover a whole country or region which embraces many airports.
               You place the W2Xp packages very low in the Custom Scenery.ini. As these packages do not know where the airports are it contains approximations for the airport’s buildings. W2XP is a terifficly great addon, as it replicates entire cities from OSM data.
               If I follow the X-Plane forums here in Europe I feel that World2xplane sceneries are a defacto must-have in the community.
               Please take a second look at these sceneries and reconsider your judgement that these addons are simply -wrong-…
               (they’re not, there is good reason why they behave as they do. X-plane in Europe would lack fundamental addon and enhancement in realism without W2Xp)

            4. Ah – if W2XP contains an “autogen airport” that -is- an airport, but is -not- as good as what’s on the gateway, then I agree that it is not wrong. (If W2XP contains “city” autogen on the airport, that is what I would consider wrong, because _reality_ is the standard we are trying to match, so putting a house where there is an airport means your source data is broken.)

6. Hello Ben. Go one-by-one updating X-Plane 10 , to correct different kinds of errors are added to the model airports, but why even so nothing new is coming out globally has recently emerged ATC for X-Plane 10 , but why still no normal aircraft traffic at airports, aircraft services, passengers and other teamwork in aerodromnyi and dispatching services it would be good to see the loaded airports are seeing large and small aircraft of different airlines at the airports, preferably based on data from Flightradar24, but in fact, only see the meager traffic of a Boeing 747-400 and at all airports.
   Kirill

7. Witth regards to the adding of airports from the Scenery Gateway, how would we know what’s included in the release version vs what’s on our own installations?

   Is there an easy way for us to tell whether we have “duplicated” scenery in our custom scenery folder or report to us that we have an old version that needs clearing? I assume old versions in the custom scenery folder will take precedence over the newer versions in the release version?

   1. You are correct about precedence. There is no good way to tell this. This is why I suggest that users -not- install tons of airports directly off of the gateway.

      1. I find this tool useful “Remove duplicate Global or Prefab airports V1.1 ”
         //forums.x-plane.org/index.php?app=downloads&showfile=27785

8. After upgrading to 10.42 the application crashes with a tdr error from Nvidia. This is with driver 358.87. 10.41 was working perfectly fine. Anyone else seeing this maybe?

   1. PS: Interesting observation: This does not happen if I set my monitor’s refresh rate to 60Hz. I normally have it at 30Hz.

   2. Found that it was not the refresh rate. The crash occurs when I have DSR enabled in the Nvidia control panel. My guess is that X-Plane then tries to load a DSR resolution which overloads the gpu’s ram.

9. Hi Ben,

   I just discovered reading the comments above that exclusion zones
   need to be rectangles because of the claimed difficulty to deal with
   polygonal exclusions.

   The point in polygon algorithm in its winding number version
   works for multiply connected polygons and is linear (with a small
   constant) in the number of boundary points. It is roughly ten lines
   of code (here is a C++ implementation //geomalgorithms.com/a03-_inclusion.html).

   Is there a reason why including it in the X-Plane code wouldn’t
   be straightforward ?

   1. Yep – I am familiar with this algorithm:

      //dev.x-plane.com/cgit/cgit.cgi/xptools.git/tree/src/Utils/CompGeomDefs2.h#n1676

      Here’s an example of why it’s not as easy as you think it is:

      We go to rasterize a forest. The forest code works by rasterizing an arbitrary polygon with holes _restricted_ to within an axis aligned bounding box. This AABB restriction is important for ensuring that the cost of forest rasterization doesn’t become amplified by the subdivision of the final output mesh into “buckets” for scenery paging and scrolling.

      So you want to go exclude with a polygon. Okay – you’ve now made each tree test “N” times more expensive where N is the number of sides of the exclusion zone.

      By comparison, with the box rasterizer, we simply _skip rasterizing entire scanline segments_ when a box excludes it.

      In other words, AABB exclusion zones exclude many trees with a single very cheap test; polygons exclude a single tree with a significantly more expensive test.

      There is no question that with if the user inputs a large number of AABBs (to try to simulate a complex shape) then the shear number of AABBs makes things expensive. But it is also true that users will be able to make arbitrarily complex polygons – WED makes it cheap to really make a complicated exclusion zone.

      One other note: a number of DSF shapes -are not points-, so the point-in-winding test doesn’t do us a lot of good – it’s only useful for objects (where it is reasonably cheap) and trees (where it’s cheap by the tree but since there are a huge number of trees, it’s not cheap compared to what we do now).

      There is another option: convex polygon exclusion zones. In a convex polygon test, you test whether the entity is on the left side of your polygon edges – if you are inside -every- edge, you are inside. On paper it’s O(N) just like the winding rule, and it’s more restricted, but it has one really nice feature: if you are outside of ANY edge, you are outside the polygon and you can -stop the check early-.

      For something like a DSF where exclusion zones are small and most stuff is outside the polygon, the early exit is a pretty nice win. In the case of an airport being excluded from a DSF, most of the trees are outside the airport, and on average half of them will be outside the first segment of the polygon’s contour, letting us skip a lot of checking a lot of the time.

      (Realistically a better implementation is probably to have polygonal exclusion zones with an AABB saved around them as an early-exit test.)

      1. thanks for the open discussion. such a polygon (hull around the airport points) maybe be even created automatically – and not by the designer. I think a very simplified hull would be sufficient. See: //en.wikipedia.org/wiki/Convex_hull

      2. I completely agree with this :
         “(Realistically a better implementation is probably to have polygonal exclusion zones with an AABB saved around them as an early-exit test.)”
         Shapes in shapefiles all come with their bbox precomputed, there must be a similar reason.

         Two remarks though :
         1) I was skeptical too initially about implementing the w-n algo for one-one checks, but if you put actual numbers in front of your data (Ntrees*Nexcl*Nnodes) and divide by common flops you’ll probably end-up in the order of the second [implemented and tested in a nearby setting].
         2) Initially your forest information is a polygon. It would make a lot of sense to clip it first with the exclusions zones. Clipping an arbitrary pol by another one is more complex as you know but there is an efficient algorithm since the work of Vatti. Actually as far as I can see it (your description was a bit sketchy) your rasterizing process is half-way towards Vatti (raster colons or lines corresponding to the scanbeams), but you clip with 4 half-planes rather than polygons.

         Any way, chatting is easy but in the end this is your code and your choice given your time, and it already works quite well 😉

         1. Clipping polygons by polygons can be done efficiently, but the algorithms that I have seen (sweep-line algorithms) have to cope with precision limitations, which makes them significantly more complex and hard to debug.

Comments are closed.