tkyler

This is one of the major areas that will be fixed by switching to the XP1100 navdata set. The XML data format does not delineate between the "runway transition" portions of a STAR vs the common portions very well at all. If you enter a STAR and the runway isn't entered yet, then ideally it should either 1) load the common part of the STAR, until the runway is selected or 2) let you know that a runway selection is required. (which does exist in some cases) The XML format we use is proably 15+ years old and just not the most flexible format. While this can be coded around, the code turns in to bloat very quickly with this XML format. I can't wait to move from it. Maybe I'll think of something clever or have some aha moment to get this to work with this format until then. -tkyler

Also....those who have the Gizmo Error when entering a PBD waypoint....FWIW, that message results when entering a PBD and the reference waypoint isn't in the Database for whatever reason. I have since fixed that for the next patch. Being as we're now dedicating development time to the FMS again, we will be endeavoring to organize our error handling much more gracefully. -tkyler

I don't know what P/GVA is, but that could have something to do with it...log file definitely shows it doing a lot regularly and it does precede our issue. All our GUI interface code is event driven and uses the same function to process clicks, only receiving differing "constants" depending on what is clicked. I have never seen our "widget code" attempt to index a nil value. I too, would be very interested to see if you could reproduce it. I haven't the slightest idea...I tried recreating your pref settings, then went to town clicking everything I could to no avail. -TomK

Definitely on the short list. I'm working on the remaining user waypoint code even now, to include the fix page. -TomK

ALS is the first point of the enroute portion, but looks like you have several points before that (being your on page 3). Did you select a SID? or insert the points manually? If you can give me all the individual waypoints up to ALS, that would be helpful. Those distances are large enough that I wouldn't expect a bypass...indeed do not get one with the dataset I'm using. (Navigraph 23 Apr 2020).

Certainly we'll look into this. FMS work is ramping up and focusing on these things is "front and center" for us. Thanks for your report -Tom

I need to organize my error checking messages better and also supress them better for sure. i apologize. I'll be working on this straightaway along with the other user created WPs, which are part of the whole process anyhow. -tkyler

GCRR/03 is not a valid format. PBD means "Place Bearing / Distance, i.e. "text number / number". You have Text / Number The error message, unfortunately arose from a debug message I use. When I test for 'invalid formats', I want the console to pop up, but I should display "invalid format" or "not found" on the CDU for you guys and suppress the message so you can keep using the CDU. I'll make that adjustment for next release, my debug code is in the "wrong spot" for final users and causing this error when a Waypoint isn't found or a user created waypoint is wrong format. -tkyler

so the 1.31 update has gone out, with the objective being to stabilize our "get back to where we left off with the new toolchain, but conformant to XPlane 11.5" update. Assuming we don't have really big show-stoppers, it is now time to start moving foward rather than just get stable. We have a few things we'll be working on simultaneosly from this point on. With an eye on X-Plane 12, we'll be working on swapping our sounds to the FMOD sound engine. This is a compatibility move, moreso than changing the way our sounds are played because we quite like our sounds. In addition, we'll be working on incorporating particle effects in spots. On the 3D front, the 3D changes will begin with the galleys, cabin and cabin doors and after that wing flex. On the FMS side, first up will be the remaining user-created waypoints, (PB/PB, ATD, LL), then probably VNAV work, including PROGRESS page predictions.. A better VNAV algorithm will make programming holds a bit more predictable and so HOLDS will be after our VNAV work. Once all that is working reasonably well, then we'll look at porting our navdata over to the XP1100 navdata format....which will probably be after the XP12 release and be a pretty heavy FMS rewrite. Thanks for the support and patience, its time to starting improving things again. -TomK

that wreaks of HDR processing not working....but can't speak as to why as of yet. -tkyler

So we got PBD user created waypoints in for 1.31....we'll set about getting the others, including LL for the next update. -tkyler

all fixed and covered elsewhere in the forums. They'll be included in the next update, which we're finalizing presently. -tkyler

It is more difficult than it appears yes. variation in winds alone change all predictions. If you have a 200kt headwind and are flying with thrust for 200kt, you'll go nowhere an burn all your fuel. . If you climb vertically while doing it, your fuel burn rates will change, complicating gthings more..and if the wind speed changes as you climb, it gets even tougher. The real FMS uses a "step integration method" for prediction.....and the only way that could ever be accurate in X-Plane is if we had access to the real performance database of the aircraft...which we don't as its proprietary. So we have to use a few heuristics and our own test data, that I'm sure we can improve upon, but its not as straightforward as it looks. We'll revisit that aspect of the FMS also -tkyler

They shouldn't.....none of the dataref names or 'state values' have changed...only the manner of manipulation in VR and with the mouse. Things should work fine with Smart-Copilot -tkyler

Looks like the scripts are choking on missing sounds , or so it thinks. Are the sound files indeed missing from the folder specified? -tkyler

this is FYI only, in case you're curious.....without a doubt, the speed is too great (bigger turn radius, earlier turn point, later rollout point) to finish the turn before passing KK371, but probably just barely.....and I suspect that our bypass code isn't being run since the next waypoint is a runway, which is a bit of a special case waypoint. I will revisit our bypass code to check it out and under what conditions it runs, but it does need to run and would fix this issue. -tkyler

What dataset is this? Aerosoft or Navigraph. and what cycle? Agree the loop shouldn't be there; however, it is probably a bypass situation, which the FMS is supposed to handle, indeed ours is normally very good about it. Those two waypoints are probably too close together to make KK371 at 170 knots when you shortcut to 'VAXOB', so lowering the speed is quite appropriate since you altered the published procedure. If you shortcut at KK501, you probably won't see the issue. Procedures are generally designed so that they can be flown without bypassed waypoints, so when you modify them, it is possible to get unexpected results (but not a circle...the FMS should bypass KK371. -tkyler

anyone who has this problem, pleast note in your post what FMS page you were on when you had the problem. It will speed our fixes. Thx.

Thx Wycliffe. Rgr the Init page, what is the other page(s) that LSK2 will not function on? -Tom

Since the 1.3 update was released, we've been working to fix all the squawks that have been reported since the release. I want to extend my thanks to all who report items. While folks may wonder why we do or do not catch things, I can assure you the list is quite long of things we have to check constantly and I'm actually somewhat proud of the effort. Supporting VR and also integrating the mousewheel involved a little over 300 manipulators, each of which having anywhere between 3-9 parameters to enter/ check....easily over 2500 "fields" to look at when making these conversions, and that's just checking the manipulator interaction, not even checking their usability in VR, with mouse, with hardware, prefs on/off while also catering to cockpit builder needs, etc. The good news is once configured properly, things stabilize, so each successive update gets more reliable than the last, but being this is our first relatively big "conversion update" with features sprinkled in, the only way we'll really catch it all is with the community inputs. So....we are getting close to releasing our 1.31 patch, which definitely includes the reversed scrollwheel fix. We have several other fixes in addition and much better VR support also though some straggling VR features remain. After this patch, we will begin working on the FMS also with other items, whereas up till now, it was about just getting all our new workflow and converted stuff back to normal with XP 11.50 and Vulkan/Metal. I've seen a few posts facebook posts about the IXEG overshooting flybys. We do not have wind factors in our FMS code currently, Turn points are calculated with no wind so any form of tailwind on turns may cause the plane to go wide. Bankangle for lnav calcs are taken at 25º of bank, leaving a little margin if you have the bank limit set to 30º. We do track the crosstrack deviation from the route though, so if there's roll margin, the plane should track still with some tail/crosswind; however, late entries in higher winds will probably run wide. Given the outstanding VNAV work to be done, we did not implement the wind factorization as of yet. As we begin our FMS work, we'll focus on the holds and VNAV somewhat simultaneously. Improved algorithms there will naturally be reflected in the progress page output. Once we get some traction with our VNAV / holds, we'll start factoring in the wind corrrection to the route calculations, which will hopefully snap everything into place. -TomK

the main menu popup? or views popup? or both

During development of the VRconfig.txt.....and via discussions with other very helpful folks, we won't be providing a "both throttles" manipulator into this next patch, but will pursue it shortly after. It may seem straightforward on the surface, but part of our quadrant / throttle lever code is configured to simulate "single engine" operations....and when a user has only one throttle paddle, (very common), then this causes a conflict with the quadrant levers in-sim where the user's one joystick lever needs to move only one throttle lever in sim and not both. Accomodating both VR and this single-engine operational scenario means we'll have to rework our code a bit to achieve it and so it'll have to wait for the following patch. -Tom Kyler

OK, we'll put this on the list to implement then. -tkyler

things are not the same as in the past....updates will be much quicker than in the past and more frequent. This won't be a long wait I assure you. The mousewheel issue practically demands we update asap. -tkyler

thx guys, the new blender scripts dont 'aim' lights the same way it did before (its more intuitive now thankfully), I will reorient these lights. -tkyler