Jump to content

tkyler

IXEG
  • Posts

    2,809
  • Joined

  • Last visited

  • Days Won

    558

Everything posted by tkyler

  1. Fixed for next patch. Note that using these commands will "auto-save" the prefs on close if you're on the PREFS tab...so no need to hit the SAVE button when closing/toggling. -TK
  2. 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
  3. You know Pils, it did cross my mind ....and for the life of me I cannot remember why I did not go ahead and add in the others.....all 15 lines of code of em...probably had tunnel-vision DOH
  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. yea...when certain texture files have certain pieces of information in them...in the alpha channel, etc..it caues X-Plane to change rendering state and stuff can start drawing weird and not "getting light", etc......and we had an alpha channel where we weren't supposed to....so just a matter of time before it caught up to us. Glad to move past this one. TK
  6. 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. @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
  7. 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
  8. 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
  9. 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.?
  10. Fixed for next update. When in AUTO mode, now mode C, so PE should pick it up. When set to "ON", then only mode A -tk
  11. 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
  12. @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
  13. This is a bug....Note that the IXEG 737 is getting "remodeled" under the hood, to handle future improvements. So some of our systems are "in migration" from old tech to new. Preferences is one of those systems and I obviously missed this pref. I'll be looking to get this cleaned up quite quick. -TK
  14. 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
  15. The MU2 autopilot has a "roundout" rate based feature. So it should denote capture on the ALTSEL....but the ALT (hold) light itself won't illuminate until the final captured altitude...50' I IIRC. It it doesn't illuminate at all clearly within 50' of target...certainly that's worth a look on my end. TK
  16. Thx. will try and retune. We had a bug report that the MCP was too dim at night....and the day/night behavior of X-Plane's LIT texturing system is like a see-saw (teeter-totter) where trying to get both day/night texturing looking good is a non-stop battle. I'll keep at it. Thx for reporting. TK
  17. 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
  18. Generator temps are a known deficiency....that model will be refined as we revamp the 737. Thx.
  19. Logged in our issues list.
  20. the valid range is > 110 and < 210. TK
  21. works great here in my 1.5.1 What value are you trying to enter. -TK
  22. 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
  23. 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.
  24. 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
×
×
  • Create New...