Jump to content

tkyler

IXEG
  • Content Count

    2,016
  • Joined

  • Last visited

  • Days Won

    212

tkyler last won the day on August 11

tkyler had the most liked content!

Community Reputation

2,348 Excellent

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

17,361 profile views
  1. working on it as we speak. Work on it IS in active rotation and its priority. -tkyler
  2. There is no power button on the copilot side Avitab. Since the avitab screen is shared between both, and 99%+ of users fly from the pilot side, we didn't want a copilot actuation of a power button to shut down the pilots side (in the case of a shared cockpit). Are you encountering the same issue with the power button on the pilot side Avitab? -tkyler
  3. Thx Gents. Both these errors (legs page) and the #503 errors are fixed and in the next patch. -tkyler
  4. The error message pertains to the LEGS page "drawing function", which means you were showing the LEGS page on CDU2.. Indeed I can recreate this error if I put CDU2 on the legs page and then repeat your procedure! Lucky you were on the LEGS page (sort of). Thx for finding and reporting. Its already fixed for the next patch. -TomK
  5. Thx Tim....we've seen one code break already and I'm already looking into that fix. I am quite driven to make this very reliable and accurate and user tests/inputs such as yours are. a great help. I'm committed to hunting these down as soon as they're found! -TomK
  6. Thank you gents. Its amazing to me that diversity of situations that you find that we just can't seem to locate ourselves. I will jump on this asap; however, we've had a death in our immediately family I'm dealing with the remainder of this week, but will return to debugging these straight away. With the rewrite out of the way, I do not expect this debugging to take long. Thanks so much for reporting. -TomK
  7. In order to build the thing in 3D, I created some drawings of my own that I could probably develop a bit further for you (and corroborate with Rob Archer) and send you a DXF or DWG. It may take a week or two as I'm traveling about for the next 10 days. Alternatively, I can get you a really high rez orthographic rendering of both our panel layouts when you can probably scale the dimensions off of somehow knowing a reference dim. That I could get to you pretty quick. -tkyler
  8. I have to admit, if I was going to be a phiser, then without a doubt, I would absolutely use Gizmo Beta Version as bait to get folks to click on it. I bet every one on the planet is tempted to get them some of that Gizmo beta. its much better than those lame phishing offers of winnings, or money, or completely undesirable stuff like that.
  9. Another weekly update. The rather rigorous testing of route editing over the last week had brough forth a few more issues, not unexpected during such a substantial rewrite though... but without a doubt, there are substantially less issues with route editing. Jan's last round of route testing, he was unable to get a gizmo crash when changing procedures aggressively and could swap any procedure at any time. Our goal here is for folks to not be scared of to push any buttons on the procedures page during descent / approach for fear of a gizmo crash, and be confident they'll get the route they
  10. Ok..another week gone by. 60 more hours of rewrite on the FMS route editing and guess what, we're still easily 95% of the way done Seriously, we are into the more hardcore route editing features now, the really fringe type of data entry patterns...changing your mind "mid transition" selection for example, or selecting a STAR, then approach, going to other pages, then coming back to select another STAR, then TRANS, then swap to a runway with an extension, then shortcut points, etc. Testing earlier in the week had us redesign some other algorithms and we figured we should just power thro
  11. how repeatable is the event. Does it happen at exactly the same time? or about the same time? etc. Also, if you can repeat it and then post the X-Plane log file (Log.txt in the X-Plane root folder) that would be a good data point also. -tkyler
  12. Hello all. What started out as a 'quick bug fix" for our annoying gizmo '470' error has, over the last 80 hours in one week..... turned into a very significant rewrite of our route procedures editing code. I was hoping to have it done by this weekend, but we are not quite ready. We are easily 95% of the way though and will continue to push to get this rather significant FMS update out asap. Depending on the routes you enter, some may not notice much difference, but for others, the difference will be quite noticable with the "routes editing as expected". Of course there is no way we can t
  13. Many procedures are "mated" to runways. On the Beoing 737 NG, if you select a runway that is not mated to a currently selected SID, you will get a message "RUNWAY N/A FOR SID:" The FMC will then make that runway the selection, delete your SID waypoints and filter the SIDs list for you to select a 'matching' SID. Conversely if you select a procedure that is not mated to the currently selected runway, the message then reads: "DEP N/A FOR RUNWAY" ...and the FMS again selected the SID, dumps any previous procedures and filters the runway list for you to select a mating runway, We n
  14. Jan is right, we have not touched the AP or VNAV code at all since 1.21, so if something is worse, we need to know exactly what it is that "makes it worse". Debugging is quite tough business, not so much the fix, but the amount of diligence it takes to quantify what the issue is and put it into words. Good VNAV starts with good routes to make calculations from, and that is where we currently are as of this instant, fixing the STAR / APP route building code as these procedures are selected...since they are clearly resulting in 'funny routes' where VNAV calculations make no sense. That '
  15. Ok...fixed. here's the deal for the curious. one darn character I have code that evalutes scratchpad entries to see if they're user created. For Lat/Lon types, the format is latitude letter (N or S) followed by number, then a longitude letter (E or W) followed by more numbers. My parser looks like so: [NS]%d*[EW]%d* The problem? using an asterisk allows "no results" to be valid....so this pattern doesn't require any numbers to be between the letters, so SEA for example....the parser is finding the S and the E...and thinks its a Lat/Lon point. Same for CRUSE or ANY way
×
×
  • Create New...