Jump to content

tkyler

IXEG
  • Posts

    2,812
  • Joined

  • Last visited

  • Days Won

    564

Posts posted by tkyler

  1. 5 hours ago, leinsters said:

    Not really sure what X-Aviation and IXEG are afraid of or thinking

    We're thinking "time is money".    My mortgage payments runs on a timeframe...my internet fees...my software subscriptions, my commissions.....special offers in the mail......all time frame limited to encourage folks to act to keep the economic cycle moving.   Time and money is inextricably linked.  Without this principle, no business would survive and we've have no products...no add-ons, no x-plane,  etc.   Who is John Galt anyhow.

    TK

    • Like 10
  2. @Pils

    I can say that the throttles / reverse lever operation, in general are a decade old paradigm and have always bugged me a little bit.  As usual a "usability pass' is in order where we evaluate every control / animation and think of better and more robust was to interact with these things.

    In the early days, we were limited by several "isms" with X-Plane for sure, but I think we have more leeway now and can use PREFs to cater to differing preferences ...so we'll be looking over this again I'm sure.    I'm looking to animate more controls over time as I 'weave' some of my library animation code from the MU2 back into the IXEG.

    -TK

     

    • Like 2
  3. On 9/18/2023 at 9:47 AM, VasilisMaximos said:

    Is there any available dataref command for Landing Gear off?

    I assume you mean a command to "move the landing gear lever to the OFF position"?  ...to bind to hardware or a keystroke?   

    I've added this in, using the default X-Plane command you mentioned.

    -tk

     

    • Like 4
  4. the fact that you're getting the message at all indicates that things are probably working. 

    There is a course a valid range to enter, and the number value you enter is checked against the "units" you have set in your prefs.     I think a preferences file has been going out with the installer....and folks prefs are getting overwritten by the one in the installer.   So first thing, check your preferences to see if you are in "imperial" or "metric" as it were.   If you enter a number thinking you're in one unit, it will come up INVALID as it will be out of range.

    If that's the case, sorry for the inconvenience, we obviously need to preserve users PREFS when updating.

    -TK

     

     

  5. NOTE that the B733_mcp  image file (png and dds) will be gone in the next patch.

    It was a hack of a system from 2010, before the DDS textures...and I've redone it to proper XP standards with modern lights.

    image.png

    @maub  Unsure how that may affect the text at night....be curious to know..even if that texture is going away.

    @Bulva replace the two DDS textures with theses PNGs and you should be fine.   

    B733_mcp.zip

     

    • Like 6
  6. Ok this one is fixed for next update.   We had really tricked x-plane's lighting system way back when to simulate multiple light sources on a single surface...but with XP's real lighting...this is normal nowadays.  The problem was the way we had our assets set up for export...so a small rearrangement was required (typical of remodels), but this should be good for the next patch.  Its looking pretty good now, day and night.

    -tk

    • Like 3
  7. Verified...this is attributable to the DDS textures.  In 1.5.0,  we shipped PNGs...which are more reliable, but take up more VRAM.  Laminar recommends DDS for optimization.

    NOW....the MCP lighting is a bit of a special beast...and we MAY be misusing the DDS textures for this guy. For the next patch, we'll ship PNGs for this object at least. ...in the meantime, I'll talk with Laminar about whether this is in their court, or we misbehaved with DDS and have to find another way.

    -tk

    • Like 1
  8. Was looking into this just now and wondering if there's something more sinister here.  I made some changes to the MCP and just assumed it was messed up via your report...but now, testing it in both day/night with all light levels...its looks fine on my end....however....there are some things I can check...clearly someothing is going on for you.

    For the pedestal..looks like you have the pedestal "panel lighting rheostat" down.?

     

    image.png

     

     

  9. 33 minutes ago, AngelOfAttack said:

    It kinda bother me as I'll have to use the PACKs to cool the airplane (or to warm it up few month later) when parking at jetway with ground AC unit hanging down. So could it possible add the low pressure conditioned air input as a ground service?

    Certainly possible and I've made note of this to revisit.   For a little while, I'll be repeating the following info so as to make sure folks know where the IXEG is going.  The IXEG is undergoing a remodel, mostly under the hood in code, but the outcome of this work will be integrating the kinds of requests you're making here.

    -tk

  10. 2 hours ago, manguras said:

    In my case, I see the wing lit up but the source where the light comes from is as if it were inactive.

    @manguras  There will be a temporary compromise here....because of our older 3D exterior at the moment.  For now, I've put in a small billboard light source for the next patch.  Note that I'm reworking the 3D exterior to be high-resolution and in doing that, will be creating a 'proper' recessed wing light with lens cover.  But I hope the billboard suffices for the interim.

    -TK

    @cloudfreak1 In your case, you're correct the wing lights didn't show with winglets, a bug.


    Both fixed for next patch

    -TK

    image.png

     

    • Like 3
  11. Let me take this opportunity to ask a question.   We get some requests for Cargo.

    Are you more interested in only the exterior LIveries of cargo?  or...you also want a full 3D cargo interor, etc?   Modifying the 737 to handle "no windows" is significantly easier than putting in a full 3D cargo interior.

    -TK

  12. 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

     

×
×
  • Create New...