tkyler

IXEG
  • Content count

    1,781
  • Joined

  • Last visited

Community Reputation

1,492 Excellent

6 Followers

About tkyler

  • Rank
    Advanced Member
  • Birthday 09/23/1967

Contact Methods

  • Website URL http://www.x-scenery.com

Profile Information

  • Gender Male
  • Location San Antonio, TX USA
  • Interests Aviation, sailing, woodworking, family, engineering, philosophy, psychology, travel

Recent Profile Visitors

9,835 profile views
  1. MU-2 Upgrade for X-11

    squeezed in a bit more work on the Version 11 compatibility...but I keep trying to sneaking in a few bits. The annun system really needed some love, so I dumped the prior code based and got the annunciator system rewritten so the annunciators lights are back. It won't feel much different from the consumer end, but the system is much more flexible for future dev work when I get onto the V2.0 version. Of course the brakes were re-done, etc. I'm currently working on wiring up on the annunciators to their systems. ...at least the systems that are relevant. Once the annun stuff is done, we'll test again and see where we are. -tkyler
  2. To IXEG - a roadmap?

    The road map is to get the V11 compatibility version out, which is imminent....then go back over the FMS ...VNAV, holds, etc. While that is ongoing, we are also working on new cabin 3D elements. That is the immediate path. After all that...and the plane is performing well and looking well, then I myself will be interested in some failures type of interaction -tkyler
  3. Unable to shut off VNAV v1.1

    indeed that is one we have never seen.....if its a quirk in our code, then I'm thinking maybe our code is self-aware and writing itself As Jan said, we're going to do a revamp here in the near future. -tkler
  4. Battery Bus sources

    Hi Jens, its a bit of a convoluted circuitry dependent upon multiple inputs...especially when messing about with failures. Standby power is normally sourced from "Transfer bus 1" via a relay that is energized from the DC bus 1. When the transfer bus 1 fails (or DC Bus 1), then this relay relaxes and connects the standby busses to 'Side 2'...specifically the battery bus. You should be able to fail the transfer bus 1 (or DC Bus 1) and the battery bus and have the standby system go down....BUT that won't happen because I just discovered a bug in my code while testing this. It does not affect your scenario however. ...and I have fixed the bug! -tkyler
  5. First official XP11 screenshot

    The above question illustrates the challenge for XA in developing a robust installer. The installers used have to be programmed to handle a wide variety of cases and some unknown number and type of files that may or may not be changed by the IXEG team in the future. This requires some time of fore-thought to determine what will be required by users and ensure those cases get coded into the installer. Bandwidth on this level is quite expensive so just downloading everything every time is not a valid option...so crafting a "smart installer" is where the time is going currently. The payoff will be a robust and quick installer for future updates. This whole transition to V11 has caused a bit of a "traffic jam" in our infrastructure and that's all this is....best to proceed through it cautiously lest we end up missing something obvious. Once past it, we expect a clearer road for updating. -tkyler
  6. MU-2 Upgrade for X-11

    Hey Dion....I removed the "lens" for the turn coordinator so you can see the ball, though the guiding lines are not there anymore. The lighting model has changed significantly enough that I can't fix it with the current paradigm of the Mu2, which is rooted in V8 tech...BUT you can at least see the ball now. Of course the pure V11 2.0 will rectify all that business. V11 is fancy enough that there will be some visual compromises is getting this one "compatible"...some parts that are shiny that shouldn't be...mostly exterior stuff. But I figure better to be able to operate it in V11 in the mean time. -tkyler
  7. MU-2 Upgrade for X-11

    I did manage to get quite a bit of time today working on the Moo in V11. I think I got everything under control and threw in a few texture effects. The nacelles are now 'true mirrors" as opposed to baked on...and the yoke is a bit shinier. I'm going to let a few people test it out to see if things work OK. I did make an adjustment to the brake code also...hopefully it'll be a bit more consistent. when the testers give me the all clear, we'll get it out for V11 compatibility. -tkyler
  8. [Solved]Objects transparency

    Hi Cris, Those have been fixed for the V11 update, which is not too far away. -tkyler
  9. MU-2 Upgrade for X-11

    One thing for sure is that the Moo will be "developed" for XP11, but the V11 version won't be just a compatibility update of the existing version. The MU2 has been updated for free for over 8 years running and its a bit long of tooth. I am looking to do a 2.0 for V11 that is quite comprehensive, leveraging my experience and code from the IXEG project, i.e 3D sound, more accurate and detailed 3d, lighting, deeper systems, etc. The 3D çleanup is already underway. That being said, I know that the Laminar team work very hard to make sure products don't become broken between versions..within reason, so while there were some incompatibilities during the beta run, they may have been solved in later beta releases. Now that XP11 is past the beta, I will take a look at the performance and fix whatever I can for compatibility of the existing version until a replacement comes out. The replacement 2.0 will be a paid update. -tkyler
  10. Next update

    I agree the question warrants an answer. I don't mind putting it out wherever I can so the word gets out. We don't know exactly when....and here's why. We all have day jobs but my particular day job is project based, rather than 9-5 based. Sometimes, these projects, being deadline based, can consume multiple months with narry any time for anything else...which is exactly what is going on at the moment. Despite my deepest desire to NOT being working on my current project, I am contractually obligated to finish it....and it is now consuming 70+ hours a week of my time and feels like "work prison". .....here's the good news though. When this project is done....and do note that I initiated this contract a good 8 months before the release of the 737..... I won't be taking on another. I will go back to the 737 and you will see the frequent updates you saw after the release as long we can find things to improve. When is this magic date? To be perfectly honest, I thought it would be by now....but sewing up final details is dragging out longer than I thought and I have no path but forward to get it out of the way and get back to the 737 for you guys. This is not an "abondonment" issue. Just the nature of the beast for x-plane devs who have to supplement the work with other forms of life support for the moment. I wish it were not so...but until x-plane has a larger market share, tis what it is. I can only assure you these folks on the team are some of the most dedicated and stable individuals I have ever worked with and have no doubt we'll be delivering again soon. -tkyler
  11. Soft Crash touching VNAV

    I can see from your CDU LEGS page that you do not have any predicted speeds for waypoints. What this tells me is that there is no valid VNAV calculation, which gives rise to this gizmo error. This means you either have: a disco in your route when you hit EXEC.... AND/OR you did not enter aircraft weights on the PERF INIT page (required for VNAV calculations)... AND/OR there is not cruise altitude entered. If you DID do those two things and still get the error, then that is something I would definitely like to take a look at....but to do so, I would need the "IXEG_FMS_debug.txt" file from you after you enter and EXEC the route NOTE that this has been fixed for the next update so you will not get the gizmo error message when VNAV is invalid. IF it turns out that you either DO have a disco OR do not have any weights entered on the PERF INIT page before EXEC your route, then ensuring those two issues are addressed will probably avoid this gizmo error message. -tkyler
  12. All fixed up. Had a > 2 when it should have been >=2. Hope that doesn't break something else Was able to put "CH" at the beginning of the route successfully though after confirming the bug before the fix. -tkyler
  13. [1.0.7] LNAV not following SID route

    I just fixed a bug from another report that I believe is related to this. Whenever you have an acute turn at a waypoint...and the next waypoint after the acute turn is too close to make (bypass)....then the plane would depart the LNAV path after teh waypoint BEFORE the acute turn. This bug is due to our "look ahead" code that tries to anticiapte turns in order to give better LNAV tracking I just enterd the route and see the waypoint combo I expected to see (OTBED > MONTY > WAL24)....and the route draws well now (it was kink'd before). So I think this is fixed for the next update. -tkyler
  14. [1.07] Soft crash on next waypoint

    this one has been fixed for the next update. It generally happens when sequencing the last waypoint. If you enter a approach that has a missed appraoch (with waypoints after thee runway), then you probably wouldn't see this one. If a RWY is your last waypoint, then you'll probably get the bug after crossing the threshold. It will be corrected in the next update. -tkyler
  15. Problem on approach for SNA

    I just fixed another bug that was very similar, so similar in fact, I think it might fix this issue too. Had to do with a very acute turn into a tight sequence of waypoints. -tkyler