tkyler

definitely not implemented yet. The Rad/Dist values do update now as you fly though and will be out with the next hotfix. There are several route calculations we currently do that do not take into account the magenta route, but only the 'point to point legs" between waypoints. I do plan on correcting this at some point to improve the LNAV/VNAV and that is when the fix interceptions will probably get addressed. -tkyler

Hi Tom...well we have been working on a new Hotfix with a lot of VNAV tuning, so you might be reporting things we have already fixed. In particular, I am working on the VNAV target speeds on the descent. The hotfix will be out soon....it takes a lot longer to fly flights and test the VNAV than to fix soft crashses....hence the extra time. I can only get in about 5 flights / day . -tkyler

In theory, ours will handle any number of sequential bypass situations...I think the real FMS might be a memory limitation. This is a known bug that, as Jan says, can be cleaned up with some route editing most of the time, but I still want to clean it up a bit.....its a challenging section of code in bypass situations and I need to address it slowly and carefully. Interceptions after bypasses are the most complex code in the entire LNAV....but we'll get there. -tkyler

I do not think it is not a matter of setting the course in order to FOLLOW the ILS, but rather dialing in the course to fly to INTERCEPT the ILS. ...at least as I understand it...I admit I didn't code this up, but maybe Jan / Nils can chime in once they see the post here. -tkyler

*Sigh...I have never seen this one before. There is a waypoint of type "Runway" in the Sid departure procedure. My code doesn't even attempt to handle these becasue it never expected them. It should not be there period. I am wondering if this will be a constant struggle with the nav data...always watching out for "abnormal stuff" and having to code around it. I am wondering if we should try to code around it, or contact the provider for "fixing"? If I simply open the XML and delete the offending waypoint altogether then this is what I get......and probably a lot closer to what you want Tom -tkyler

We don't support the *.ixg format any more actually, so no surprise it caused issues. The current hotfix 1.0.5 will refuse files with the *.ixg extension. It was more of a format when we were doing repetitive testing and it created some problems once it got in the big wide world. The following coroute in *.fpl format DOES work with the default data; however, the arrival and departure procedures are not included, those still have to be entered, -tkyler LKPRLIRF01.fpl

The MU-2 developer must be pissed -tkyler

This is simply a difference of perception in using words A over words B Look is the "input", "think" is the logic that drives the output. It does no good to take in some knowledge if you don't act on that knowledge. The system may very well be engineered to "look" at the autobrake switch (I'd have to look at the schematics).....at which point it then deployes the spoilers with additional conditions...but the engineer who designed it......he has to ask, 'IF autobrake switch on landing, THEN deploy the spoilers"....well he is the one "thinking" and decided what to do....its just a convenient choice for me to use the word 'think' -tkyler

we are actively working on the route reset of the route as part of this weeks work. A bit further down the road, we will remove sections of the magenta route during the flight. We believe (not sure cause nobody bothers to lock it in their brain as they're too busy flying the airplane)...that the magenta route is erased "behind the aircraft" as it flies the route, but only prior to the last waypoint passed. This would keep from getting a cluttered route display on the EHSI in tight procedures, especially during approaches. If this is not correct behavior, then I'd welcome any confirmation of proper behavior. -tkyler

If you go into reverse and wheelspin is > 60 (on the ground), the spoilers will deploy (a few other caveats for RTO though), the plane thinks you are wanting to stop...and if you're going over 60knots and have the reversers actuated (not necessarily fully deployed), then its a good bet a pilot wants to stop. The whole concept of "arming" for landing is simply a way to get the spoilers out as quickly as possible as it takes precious runway real estate before you can get the spoilers out from reverser actuation alone. If you are wanting to do touch and gos, then simply advancing the throttles past 40% of travel for the "go takeoff" will cause the spoilers to to retract automatically...again, because the plane now thinks you are wanting to takeoff (lots of throttle and increasing wheelspin) -tkyler

I don't disagree Richard and we'll get back to it. Having a few conflicts early on just made us want to be a bit cautious, that's all. We selected the most common and shortest format we could find. The file extension needs to be .fpl. you have .flp Also, you need to account for 'Direct To' using DCT (except the first point after the departure airport). So try: Page 11 of the Interface Guide in the Docs folder covers the particulars of the file format. -tkyler

I think you're probably right...but this is now on our current plate! Hopefully soon -tkyler

Hi Tchou, yea the temp model for the generators was a 'quick and dirty' to get the gauges going way back when. They are so far down the priority chain that they have been ignored. They are due for an upgrade to factor in amperage, age, and heat transfer. Good catch, I was waiting -tkyler

I also agree with you both; however, we are in a bit of a unique spot. Established companies like PMDG and such, having a reputation and sizable user base to interact with, already had a basis for a good beta program based on previous products and customer base. Being this is our first product, and not having any type of "team" or customers we had relationships with made it a bit more difficult to get participants on the scale needed for proper QA work IMO. I could pick about 30 people from these forums now that would make superb beta testers for a next product, etc. Also, we are using some new tech that is a bit different...and on the one hand, allows us to further the state of the art is some areas because it allows us to do more faster...but when you do more, you also have more areas you can trip up, which also means even more areas to test, etc. Finally, as Nils mentioned, we are seeing issues that are not ubiquitous...and so our internal team is still only a few people and none of us may see an issue and only when it gets out on a larger scale do these come to light. We are strategizing ways to deal with it though.....without a doubt the ONLY way to battle-test any fix is by volume testing....and volume testing requires some adminsitration and willing participants. I have no doubt we have enough willing participants now....all you guys are great, its more a matter of administration and implementation on our part. We are still getting our legs as a study level simulation 'company' and we really do appreciate your patience and support. I think the hotfixes will slow down a bit as things have settled down a bit....and we begin to work in earnest on the 1.1 release and indeed, be a bit more comprehensive in our testing. -tkyler

best practice is to restart X-Plane after the hotfix....and if the crash is still happening, then do please post the GizmoLog.txt file in the root x-pllane folder and that will give me the rror message and place to look to track down the issue. -tkyler

I couldn't say for sure as I don't know a lot of those; however, page 12 of the Interface Guide in the Docs outlines the particulars of the fpl format we implement. Perhaps you can correlate one of those in the list with the requirements of the *.fpl format we use? -tkyler

yes we have removed it. It seems that some other software used that file extension but with a different internal format. With two different file formats using the same extension, we thought that was risky and so removed it until we can sort it out. Stability against soft crashes is the priority and I think we will soon start looking at all possible formats users will want to enter and evaluate those and come up with a solution. -tkyler

I do know the problem, and the fix...but need to just approach it cautiously, the LNAV code is mind-numbing. I'm not sure if I'll get this one in for 1.0.5 as I've focused on soft-crashes, but it is on the short list. It is definitely tied to the first waypoint being really close to the beginning of the route. -tkyler

that one is fixed for the next hotfix. -tkyler

CDU items have been addressed for next hotfix....the LEGS distances and also the OAT entry ( addition is NOT subtraction Tom)...equation error No work on the electrical yet...that is definitely last page stuff as it took a real pilot who actually gets into the electrics (cause Jan didn't) to catch it. ...but I will want to fix this up one day. -tkyler

No, because the arm light works within a tolerance zone that is probably bigger than the noise deviation you are experiencing, whereas XP does not. I am unsure if the nullzone applies to axes settings. I have confirmed that there are no nullzone sliders for indiividual axes in the hardware setup screen. I'll probably talk to Laminar about this as we don't want to have to code around such low level behavior (even though we do it for the throttle) if we don't have to. -tkyler

I'm betting a "noisy axis"....not unlike Jan's throttle in his movies. The axis system employed by x-plane only reads the axis values if they are changing. If they are "fixed"...then x-plane does not try and read your hardware....if the value is changing, x-plane will try and match your hardware.....so in this case, there was a fight between X-Plane and IXEG....most likely instigated by your hardware though. Moving your hardware lever ever so slightly might be enough to stabilize the dataref, of course you have zero clue if this is going on without watching the datarefs....which is impractical for the end user. Without opening X-Plane and looking right now (cause I'm hungry and lazy)....does each axis have a nullzone adjustment? If so, it probably exists for this reason. -tkyler

I'll give this one a look see tomorrow...dig into the nav data and see whats what. -tkyler

yea, Tom does have a professional itch to get these a bit more refined at the proper time. This post is noted -tkyler

Are your rendering settings set to HDR? -tkyler