Philipp Ringler CFI

There's several ways you can do that. You could make a user-defined waypoint if you wanted to refer to those coordinates by a name. That's what you do on the define pilot waypoint page. Start by entering the coordinates into the scratchpad, and then line-select them into LL3 (latitude and longitude) Then, give your point a name (I chose "MYWPT1") and line-select that into LL1 (ident). You can then line-select LL6 to store the waypoint permanently under that name. You can now refer to this point in your flightplan under that name, here for example by entering it on the LEGS page: You can also enter the coordinates directly on the LEGS page, bypassing the "define pilot waypoint" stage: You can tell it's the same waypoint as they are 0.0 nautical miles apart. You can also use the shorthand notation with no minutes, just full degrees. Finally, you can also use the ICAO notation, 4550N (more information here: http://www.jeppesen.com/download/navdata/navdata_info1.pdf on page 3) As you can see, there are many ways you can use the default FMS to navigate to a coordinate pair.

10.30 is still beta. Only stable versions are distributed over Steam.

TrackIR3/4/5 support is native on Windows, where X-Plane can use the native TrackIR driver. For Mac and Linux there exist "unofficial" solutions using the third-party plugins "linuxtrack" and "PilotView".

I added the ability to extract the IAFs from the transitions for Beta3. It will work only with Navigraph data, though. I've reported the missing IAF flags to Aerosoft a few months ago.

Of course your way is the correct way to do it. But we live in a world where there are two providers now, each with their own quirks... And the number of würgarounds seems to grow with O(n!)...

And here we go again.... The never ending fun of "there's always one more way to do it": You (navigraph) mark the IAFs in the transitions. But Aerosoft doesn't. In fact, there's not a single point marked as IAF in the whole database from Aerosoft. So if I filter the IAFs out of the transitions, it still won't work with the Aerosoft data. As I said, the fun never ends...

Personally, I don't use the FMS data manager as it's not very intuitive to use on Mac. Here's what you can do: Download the navdata for FlightFactor 757/777 in "native" format from the navigraph website. Unzip it and find the folder that contains the Airports.txt. Navaids.txt etc... Copy that stuff into X-Plane/Resources/GNS430/navdata/ overwriting the Airports.txt, Navaids.txt, etc.. already there. Done. To bail out and go back to what is shipped with X-Plane, run the X-Plane updater, and when it asks to overwrite a file that you modified, say "Yes to all".

Upgrading a plane to the new GPS requires setting one checkbox in PlaneMaker. But we can't do it automatically on all planes because some authors intentionally misplaced the G430 screen texture to model other types of GPS. Think of the old G430 texture misplaced so the left part is cut off. Then you get the GPS part only, which some authors used to create a hand-held GPS receiver. Problem is, the old G430 is both way too small and not proportionally correct in screen layout. So if we were to just exchange the screen texture with the new, both bigger and different and layout, screen texture, panels using such "hacks" would all be broken. Therefore, we leave it to the authors to decide whether they want the new screen or not, rather than risking breaking existing planes. And if you don't have the patience to wait for the aircraft author to change it, you open the aircraft in Plane Maker, go to the aircraft system screen, check one check-box, save, and done. We'll have two dedicated articles on authoring planes and panels specifically for the new GPS features posted once we go public.

More on the case - a film team was visiting Austin last week: http://vimeo.com/93143166 http://vimeo.com/93143918 http://vimeo.com/93144399

More information, yes, but no release within 24hrs. The wish was father to the thought for the opening poster.

I agree with most of what was posted in this thread. We are a very small team, and given the team size, we are currently working on A LOT of new products. X-Plane 10.30 being one of them of course. Being a small team does have its benefits, though. We have absolutely minimal management overhead, and no Dilbert-style marathon meetings keeping us from doing what we actually need to do. X-Plane 10.30 is already very heavily being tested by selected people using most of the current add-ons to make sure there are no regressions before it goes into public beta. And no, messaging or e-mailing me won't get you in the private beta testing, so don't bother. We are also in contact with many third-party developers to make sure they can make ever-better add-ons with 10.30. The list of additions and bugfixes in 10.30 is currently more than two pages on Austin's monitor. And Austin runs at 3840x2160 resolution, so that should give you an idea how long a page is. Ben has a blog post coming up talking about all the major features of 10.30. Philipp

Sorry Mario, but you are wrong here. Adding a waypoint to a flightplan assumes there is only one type of waypoint. Which is correct for enroute, but not for DP+STAR+IAP+Transitions. Here "a waypoint" is actually one out of 23 different leg types. Historically, the X-Plane GPS and flightplan only knew about 1. The new 430 knows about all 23. And that's what makes all the difference.

I don't think PMDG can ignore 50% of X-Plane's user base, meaning 50% potential customers. However, this might be a time-consuming process. I think I summed this up before *dig dig dig in old posts* : http://forum.avsim.n...ost__p__2157629Quoting myself: "There is the programming of all the systems. Also this cannot be converted (automatically). Sure, the logic can be re-used, and if PMDG did a good job in software design and have a good separation of concerns in their code, they can re-use some of their sourcecode, but at least all the data-access (converting from simconnect to X-Plane datarefs) and all the display rendering (converting from GDI+ to openGL) code has to be rewritten from scratch.And, moreover, right now they programmed on Windows, and used a Windows toolchain. For X-Plane, they have to be Mac compatible. This means a switch to another toolchain (from visual studio to gcc or clang). If they use a lot of windows-proprietary stuff in their code, this will also have to be rewritten."

Guys, I was there and listened to the original announcement that was made there: Mr. Diekmann, CEO of Aerosoft, who are responsible for the distribution of X-Plane 10 in Europe, said "PMDG have received a copy of X-Plane 10 beta, so they can consider converting their 737 or 747 for X-Plane".Someone heard "Beta, PMDG, 737, XPlane" and concluded that PMDG had a beta of the 737 running in X-Plane. That is NOT what they said.PMDG got a copy of X-Plane 10 beta 7. It's not sure they even asked for it. Aerosoft send them one as a compliment.It is not even sure that PMDG will even look into it. Well, they would be foolish if they didn't, so I think they will.Then they must decide whether they want take up the process of converting.Converting the 3d exterior is the easiest part. There exist export plugins for Autodesk 3ds max to X-Plane. Aerosoft has them. Also, the 3d interior shouldn't be a big problem, also the textures.The problem starts when they want to convert the flight model. There is no converter. This is not an easy process, and not a process that can be automated. It takes a lot of time of manual tuning.The IXEG folks spent half a year of tuning their 737-400 flightmodel for X-Plane. With a considerable amount of hours in a real D-Level 737 sim at Lufthansa. And those are the best experts for X-Plane, having worked on X-Plane for years already. If it takes them half a year, it will take PMDG without X-Plane experience a year to reach the same result.Then there is the programming of all the systems. Also this cannot be converted. Sure, the logic can be re-used, and if PMDG did a good job in software design and have a good separation of concerns in their code, they can re-use some of their sourcecode, but at least all the data-access (converting from simconnect to X-Plane datarefs) and all the display rendering (converting from GDI+ to openGL) code has to be rewritten from scratch.And, moreover, right now they programmed on Windows, and used a Windows toolchain. For X-Plane, they have to be Mac compatible. This means a switch to another toolchain (from visual studio to gcc or clang). If they use a lot of windows-proprietary stuff in their code, this will also have to be rewritten.All things considered, I would be extremely surprised if we see a 737NGX for X-Plane any sooner than Christmas 2013.Philipp

Did you read my OP?And I tried the english version also. It fails right awy because it correctly tells me that it cannot update this version of Fs9. Of course, it's the wrong localization.And no, the crashing update doesn't leave a BACKUP folder behind, but instead some .dlls updated to 9.1 and other still 9.0 - what a mess.