Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


tkyler last won the day on May 30

tkyler had the most liked content!

Community Reputation

2,240 Excellent

About tkyler

  • Rank
    Advanced Member
  • Birthday 09/23/1967

Contact Methods

  • Website URL

Profile Information

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

Recent Profile Visitors

16,561 profile views
  1. 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
  2. Looks like the scripts are choking on missing sounds , or so it thinks. Are the sound files indeed missing from the folder specified? -tkyler
  3. 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
  4. 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
  5. 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.
  6. Thx Wycliffe. Rgr the Init page, what is the other page(s) that LSK2 will not function on? -Tom
  7. 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
  8. implemented. Video below shows effect with greatly exaggerated current draw through meter (3000A) for illustration purposes. You can see the voltage drop as the battery nears depletion and the ensuing dimming of the lights as it completely drains. The current draw is miniscule in reality, DC meters exhibit very high resistance for 'lead to lead' voltage measurements, usually several Mega-ohms, etc. It would be a poor meter design indeed if it could drain a battery overnight IMO. That being said, the drain and indication is now there per the wiring diagram; however, the drain is very small, you wont' see it discharging overnight. meter.mp4
  9. the main menu popup? or views popup? or both
  10. This bug relates to VNAV descent calculations and will be part of our upcoming VNAV rewrite. -tkyler
  11. 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
  12. OK, we'll put this on the list to implement then. -tkyler
  13. 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
  14. 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
  15. Towards that end, we are changing a lot of our manipulators to 'more modern ones' that are VR friendly. Several of these more modern manipulators were implemented after we assembled our cockpit, and many of them simply doing what we were doing in our own code already. The good news is that these will still work the same for non-VR users, but will allow the VR features of X-Plane to still work without a new cockpit.obj file. J NOTE, this is our first go-round with making a VR friendly setup natively and Jan is checking most everything and having good succes, but once this goes out, as usual, feedback is welcome.
  • Create New...