Jump to content

tkyler

IXEG
  • Posts

    2,812
  • Joined

  • Last visited

  • Days Won

    564

Posts posted by tkyler

  1. Its a simple business decision based on our many years of experience, more than most developers.  We've kept metrics since day 1 and still do.  When a new version of XP comes out and stabilizes, the majority of users migrate to the new version.  XP12 is so vastly different from XP11 technologically, that maintaining two development branches such that fewer and fewer XP11 users over time can benefit is incredibly costly timewise...and users who linger in older versions commonly do so to avoid the cost of upgrading, either the software or suitable hardware to run it.  They don't usually refrain because they like the "older uglier version" more than the "newer prettier version".......and this generally means they also do not want to pay for the work to upgrade a V11 version either...and catering to that dwindling market would come at the cost of development time to improve the XP12 version for the majority of customers who have moved to XP12, and will do so in the near future.  We have to move where the business is, or go broke and nobody gets the 737.   We deal with this every time X-Plane changes a major version.....nobody that we know of is using XP9 or 10.  Eventually, no one will be using XP11 either.

    -tkyler

    • Like 1
  2. 14 minutes ago, OneOffRegistrationUser said:

    Your Main tank is empty. Engines are feeding from Main tank in MU.

    Correct....no fuel in main, no engine start.  You can transfer fuel into the main tank by setting both fuel transfer switches to OFF...and then turning the 'outer pump' switch to MAN...you should observe fuel increase in main, and decrease in outers.  After engine start...when you put the fuel transfer switches back to AUTO, then the tips will begin filling up the main tank.

    OR...you can simply use X-Plane's fuel settings dialog to put fuel in the center tank

    OR...using the MU2 pref dialog, click "fill main tank"

    -tkyler

    • Upvote 1
  3. 20 hours ago, martinlest said:

    include one for XP11, I very much hope. :-)

    having begun the IXEG 733 development at the later stages of Version 9 of X-Plane....and witnessing the transition to 10, 11, and now 12.  It really is not worth the effort to support past versions ..sadly there just isn't enough users to justify the effort.  As my Dad used to tell me,  "keep up or get left behind".   I did not like hearing that many times... indeed I did fall behind at times...but that didn't make the maxim any less true when dealing with large populations.   Sorry about that...but XP12 is just too cool to look back :)

    -tkyler

     

    • Like 1
  4. 1 hour ago, PEPcessna said:

    If they remain the same then this mod should work. 

    definitely.  we're not touching that.

    On another note, we are back full steam on the IXEG after that short MU2 detour for Sporty's Pilot Shop.  Working the lighting pass now, probably one of the bigger jobs.  We have over 700 inidividual surfaces / lights that we have to audit 1 by 1 for the proper brightness values in XP12.   After that, I'll hit the wing-flex and then the final punchlist items list.  Jan is performing more test flights for any obvious bugs also.

    After the V12 compatibility / port release and bug chasing dies down, we'll start the "improvement" phase.

    -tkyler

    • Like 10
  5. 3 hours ago, arctic85 said:

    Am I missing something?

    yes you are...you are missing that button...because its not there :)   Another user caught this and it has been fixed for the next patch.  Sorry about that!

    -tkyler

     

  6. @Meliok

    Can't see I've ever seen someone not able to access the prefs.  I assume you hit the  Mitsubishi Icon more than once?   FYI, I'm changing that GUI for the next update....its good you can access it through the menu for now. 

    For the ghost throttle to appear, you need to check the pref, "auto-stop power levers at detent"...and then set the ghost throttle pulldown to show the ghost throttles in the situation you'd like.

    -tkyler

  7.  

    There is no overlap in the code between the condition levers and the power levers directly; however, some other axes drive X-Plane code no matter what and we can't change that...which is why we have to move to other axes.   I consider this a Laminar oversight but they have bigger fish to fry and we have more axes to choose from and can save joystick configs, so they're not in any hurry to change this behavior.

    The prop/throttle code does not share any 'joystick axis' inputs..that is there is no overlap of code; however, it could be that other axes inputs could trigger x-plane code if the hardware is noisy or bumped, which in could trigger my code, thinking there's some other hardware config and cause stuff to move.   All I can say is best practice is when it comes to props/throttles is, assign the levers desired and set all unused lever to none (or anything else but prop/throttle)...anything else would be a "I have no idea whats going on".   

    -tkyler

  8. 1 hour ago, PEPcessna said:

    Intergrated Cue EADI texture mod work with it? 

    I apologize, that's a new one on me.  What is the 'Integrated Cue EADI texture mod'?   

    That being said, Any symbology on the EADI that is texture based, then modifying the texture would change its appearance.  Not sure if that answers your question.

    -tkyler

  9. the first thing to try is clicking on the Mitsubishi Icon again, which should center the pref screen.  If it does center the dialog and you still can't close it, the only thing then is to make your X-Plane window bigger, and hitting the mitsubishi pref icon again (which execute a command to center it as well as show it).

    This dialog was my first effort at using imgui and I've gotten quite a bit better since redoing the GUI for the IXEG.   I am going to rework this pref dialog ASAP after the IXEG V12 port release...smaller fonts, more compact appearance, more organized, and such.   Really sorry for this inconveneince atm, it is big and ugly and cumbersome I agree.  

    -tkyler

  10. 13 minutes ago, tkyler said:

    so the start up times are reasonable as is...for a good and fresh TPE engine.

    I will add that I myself prefer a bit longer startup as I enjoy the sights/sounds of the start process myself.   Right now its hard coded and I can lower the 'starter strength' to slow it down a bit, which I probably will when I get back to the Moo engine tweaking...to make it more of an "average" start time of 40 - 50s, etc.

    -tk

     

    • Like 1
    • Upvote 1
  11. The friction ratio mostly affects "free-spinning" unpowered behavior.    Setting this value to chase some specific start time, may make the shutdown time unrealistic.    Its been set to match shutdown times.  I have noticed the faster start times; however,  I have seen TPE engines start up fully in 20s, but also have seen them taken over a minute.

    I  selected somewhere in the middle in 2.0.4, just because I felt like it. So while it may be faster in 2.1.0  than in 2.0.4, it doesn't mean its wrong or "more or less" realistic.   It depends on battery level, temperature, engine state, age, etc....so the start up times are reasonable as is...for a good and fresh TPE engine.

    -tkyler

    • Like 1
  12. 5 hours ago, OneOffRegistrationUser said:

    Just checking: engines spool-up time feels like twice faster than in 2.0.4. Is it me or something changed?

    Nothing on my end, but XP12 is a different beast and could have changed "starter strength" effect.  Note that I haven't gotten deep into the engine changes yet for XP12 and there have been some changes for sure........so there is still an "engine performance" pass yet to be made and that's when it will get addressed.    All that said, start times are affected by battery type, temp and engine condition etc...but more than likely XP12 has changed some engine perf I have yet to evaluate.

    -tk

    • Like 1
  13. To those who have watched the livery demonstration video above.  I've made some small changes to the paint kit FBX 3D model.  You can download the changed kit via the link from the first post of this thread.

    I'm splitting the "Ext 3" object (with the tail) into 3 objects.  Two "tail halves" and the rest of OBJ 3.  So you'll see 3 "Ext 3" objects total in the outliner after importing the *.fbx model.

    image.png

     

     

    Towards the end of the demo video, I show how the 'number 5' of the tail number did not come out as desired... and the reason the 'number 5' did not come out right was because of the way "cut through" works.  When we unchecked the 'cut thru' option, those polygons on the leading edge of the rudder are occluded slightly and so were not cut.  

    Now...by separating the tail into two halves, you can select each half independently and use the "cut thru" option, which will result in a much cleaner look of tail graphics.

    So...heads up / FYI

    -tkyler

  14. 7 hours ago, martinlest said:

    No mention of 'manip_placebo' in the Laminar vrconfig file format specifications BTW. 

    The manip placebo is not part of any vrconfig file "syntax specification", its part of the user-defined dataref name, which  can be anything we want.

    Some manipulator types require two datarefs to complete their definition for two axes; however,  in some cases, we only choose to use one of the axes and therefore the other axis is a 'placebo' and not used.   In the early days of manipulators, a drag in a single direction was accomplished using world coordinates, but this created not so good side-effects for some camera angles.  Laminar then introduced 'screen based' or pixel based drag manipulators, but these required X/Y coordinate information.  So if you wanted to use a single axis "screen based" manipulator (for reliability),  you had to supply two dataref values where one was essentially doing nothing (again..the placebo).

    That explains the placebo name, but not a solution.

    I too cannot exactly recall what the particulars of the VR config file are; however, I have noted this post and as we get closer to release, will review the settings with regards to VR.

    -tkyler

    • Like 1
  15. 2 hours ago, Bulva said:

    Should these lights come on when the GPU is plugged in even though the Battery is in the OFF position

    Yes....as far as I can tell.  There's use of the phraseology in the maintenance manual of "turn battery key on (or connect external power)".  The key essentially "connects the batteries to the busses", whereas the external power receptable also engergizes a relay that can connect the GPU power to the main busses also.

    Indeed there is a troubleshooting step in the maintenance manual for when connecting external power does not power the main busses, and the battery key switch does not factor in to those troubleshooting steps. 

    As far as the torque gauges goes, they indicate 100% when unpowered. When connecting the GPU, which energizes the DC busses,  they spring to life and 'indicate'

    I'm going to do a deeper dive into the electrical system at some point to try and get it as accurate as i can. These older analog wiring diagrams can be a challenge to interpret and take some time.

    Regarding the GPU toggle, I'll add that command (though I have no idea why I didn't when  making the on/off commands.   mind-blank apparently)

    -tk

    • Like 1
×
×
  • Create New...