Jump to content

tkyler

IXEG
  • Posts

    2,818
  • Joined

  • Last visited

  • Days Won

    577

Everything posted by tkyler

  1. Agree that's a bug, not sure its a bug with the IXEG just yet. There are some tell-tale signs in your first screenshot that's its a hardware/driver type of bug...though the source we don't know . Its not night texture bleeding or spilling light sources. Historically, these types of visual anomalies would be caused by either poor UV mapping (coincident UV coords), a normal map with black in the color channel, or a LIT textures with an alpha channel in them, but in those cases, the anomaly is generally consistent all the time. I'd expect to see more reports from customers if it was a textural problem on our end. I'd say start with checking your graphics drivers. After that, try altering some graphics settings....it could be some type of "rendering mode" that's struggling....and please do post your hardware config here. On my end, I'll double-check my LIT textures for alpha channels (not supposed to be there for LITs) and I'll check my normal maps for black pixels. TK
  2. Thx Pils, logged fixed.
  3. Generator temps are a known deficiency....that model will be refined as we revamp the 737. Thx.
  4. Logged in our issues list.
  5. the valid range is > 110 and < 210. TK
  6. works great here in my 1.5.1 What value are you trying to enter. -TK
  7. I am unsure. I'll look into and let you know in a bit. Not quite 'in the office' just yet. I can add these of course if not. -tk
  8. You're welcome..work in progress, early framework, but we (ok..me) have grand visions for it as a repository for information and training resources eventually.
  9. Thx Pils...yea, its a transition between old and new and we apologize for the bumps. Certainly saving those prefs file should get you fixed up for any updates, but as usual, I've made notes of this post to keep it fresh in my mind. -TK
  10. Note that this is a temporary situation, due to our changover of technology and X-Plane's new "loading system"....there's some remodeling going on under the hood. We have to make sure we understand the intricacies of X-Plane's new features and then design a new GUI around those. I can't say when we'll get it back in, but it is certainly on our roadmap...see bullet points at the end of this link. http://www.togasim.com/ixeg/product_info/whatsnew_15.html
  11. Thx...I do keep a private tracking log (it gets published when the patches go out)....and add these reports to them immediately. I definitely track stuff better nowadays. MU2 starting to get warmed up for sure.
  12. and TBH....this UI with the cockpit is over 10 years old. There are a lot of things I want to redo for more "natural immersion"...so usability will get its turn soon. -TK
  13. Thx @Pils I hope these didn't work in XP11 and then just "stopped working" in XP12 ??? We really haven't changed any of our manips / command structures. I will say that I think a really comprehensive "hardware compatiblity pass" for these kinds of things....similar to the MU2 hardware pass, is warranted. X-Plane has introduced tons of commands that weren't available when we coded this thing up...and we didn't tie into all of them at the time. Of course hardware wasn't as prolific and as full-featured as it is now.....so we do have some catching up to do here. As usual..this post is logged on my list. We're prepping a patch now for the obvious stuff from the last week...and I suspect we'll go a few more weeks seeing what else turns up, and once I feel we're stable...then I'll set about with the hardware pass. I'm also preparing 'MU2 like" online docs...and we have over 1200 custom datarefs....no telling how many commands. So it needs a good audit. -TK
  14. I have begun to isolate and document the datarefs to put on the Togasim website like I did for the MU2 here. But the 737 has...oh ...1200+ datarefs so its taking a bit to cull through them all and organized them. But we'll have these up and avail before next weekend I believe...that's the target....and this will make it a bit easier to track requests for hardware support and get those on our todo list. -tk
  15. There's no doubt the engine model needs some work. This is simply a matter of 'business triage'. there is some truth here; however, one could rephrase to say, " the most important issue of a .......flight simulation experience for enjoyment" is NOT the performance! A great many number of simmers enjoy the more visceral aspects of simming..."sights / sounds / perception of flying / visual stimuli", rather than the performance. The airliners certainly attract simmers who enjoy the cognitive and intellectual aspects of simming, ergo the performance aspects of those classes of products, but for GA aircraft? its is a very small percentage of users who are "by the book"...and that simply doesn't pay the bills for the work involved. I definitely will come back to the Moo engine model at some point....and I won't charge any hidden fees when I do, but from a strategic perspective, its simply having to wait its turn. But your points are noted and I've logged this post to revisit. -tk
  16. It's safe to say that "everything is changing...all the time" and its simply a non-stop adjustment, that's just tech. X-Plane is somewhat like "The Borg" (for any Trekkies) in a way, which just absorbes more features and functionality....and in doing so, sometimes steamrolls our implementations causing us to have to re-tool. Certainly as new hardware has come available, it has continually stressed X-Plane to adapt, which further stresses our implementations and its just a bit of a merry-go-round that is the nature of the beast. -tk
  17. The ECAM "pie needle" illumination is missing, I've logged it and addressing it for the next patch. Can't explain the weird texture....XPlane 12 lighting still brings up surprised every now and then. -TK
  18. Four new commands: ixeg/733/engines/left_fuel_lever_to_idle" ixeg/733/engines/left_fuel_lever_to_cutoff" ixeg/733/engines/right_fuel_lever_to_idle" ixeg/733/engines/right_fuel_lever_to_cutoff" So for the next patch, coming up shortly....executing these commands will animate/move the levers between the extreme positions with a single command/click. We did not originally embrace the concept of animating the controls based on single clicks for various reason at the time. IN the MU2, this paradigm is ubiquitous and I suspect I'll end up auditing all the controls in the IXEG cockpit for which ones are suitable to animate to some position with a single click -TK
  19. I'm not seeing that in the code @daemotron, in other words, we haven't changed anything here since day 1 it looks like, so if it worked with switches previously..it would have probably been something XPlane changed. So you're wanting a "single event" command where it moves the lever to full mixture on / off? ...which is perfectly reasonable -tk
  20. Indeed...I've been dealing with it for over a year....good thing its a relatively quick keystroke. -TK
  21. that would be the internal air stairs...much more fun. I suppose external airstairs would be a good option too...hrm....yea, think I'll do both. External would be pretty quick...yea, I think I'll add "external stairs" to my near term todo list! Not everyone has a jetway! -tk
  22. With regards to your observation of the exterior sounds...our sound engine makes no distinction between interior vs exterior with regards to the software...its simply a "sound" in all cases. All our sounds are effected only through: "play", "stop", "adjust volume", and "adjust pitch", nothing more. When you open the window from the inside view for example, we simply "ramp up the volume" of some sounds...they are already playing. Moving the camera around the interior has the same effect on other sounds...you get closer to the panel, the fan noise "ramps up" too...yet doesn't cause a crash. I think there's something more sinister going on; however, as Cameron mentioned......X-Plane and plugins is real chemistry. It only takes one unique combo to create a reaction and finding the catalyst can be a challenge. We are certainly dealing with that here in my opnion and getting Laminar to help find data points at this stage is a prudent step. Ceratainly we want to add this one to our knowledge base. -TK
  23. @fortinworkaround....put two waypoints in the LEGS page at minimum before executing.....that should get you past the error.....then after you get airborne, you can put MIGLO into the first line and execute if that was your intended plan (one waypoint only). Looked like the crash happens when running a VNAV calc with only one waypoint in the legs page. Already fixed for next patch. TK
  24. fixed. I had a '>' instead of a ">=" DOH...tk
  25. ...was able to reproduce. bug logged. Thx. -tk
×
×
  • Create New...