Jump to content

Litjan

IXEG
  • Posts

    5,604
  • Joined

  • Last visited

  • Days Won

    404

Everything posted by Litjan

  1. You are seeing the left spoiler "float" a bit - this happens when there is no hydraulic pressue on system B and can happen on the real aircraft as well (the pressure holds the spoiler down). The graphics anomalies you see are mismatched UV maps - we have them on our list. The two graphic "issues" you circled in your last picture are scuff marks that are present in a lot of aircrafts - where the shoes of the pilots scratch up the plastic covers. Jan
  2. Yeah, the real one isn´t backlit I think...so we didn´t make this one be backlit, either, it is just painted white. I agree its hard to see at night. Maybe we can make it a bit fluorescent at least. Cheers, jan
  3. No, just checked, works fine, even from turnaround state. Checked EDDH runway 05. Set NAV 1 to 110,50 and it showed the ILS for 05 with indication. Tuned NAV 2 to 113.10 and it showed indication to HAM VOR. Cheers, Jan
  4. Weird! Ok, I will do some checks myself from the turnaround state. Thanks, Jan
  5. What was the FMS input? And how did you set the flaps (with a dedicated axis possibly?) Cheers, Jan
  6. Yes - I see the problem on my computer as well - the computed N1 is correct, but autothrust does not set it... I will investigate! Thanks for the report, Jan
  7. I understand that for testing/dev...and/or if you really know what you are doing...
  8. You can also doublecheck if you have the option "turn downwind ILS off" enabled in X-Plane. If that is on, the ILS will be "switched off" if there is a tailwind on the runway... Cheers, Jan
  9. Good morning Seamaster, while we have some VNAV problems, often the problem you report is due to the MCP altitude not being lowered prior to reaching the TOD. Once you are past the TOD the plane will switch to ALT HOLD and will not descend by itself anymore, even if the MCP altitude is lowered then. Cheers, Jan
  10. Thanks for the report! Not sure about the takeoff config - it doesn´t sound for me. The thing most people forget is to set the trim, so it is not in the green band, which triggers the warning. Could you doublecheck if that is the problem? Cheers, Jan
  11. Good to hear that. Yes, you will need electrical power for the navigational radios to work. Cheers, Jan
  12. Hello Faisal, can you see the ILS on the X-Plane map (m key)? Can you click on it and choose "tune on Nav1"? Maybe you can load the plane at an airport with an ILS serving that runway you are on, then tuning it to NAV1 and then send me two screenshots (of the Nav Radio and the artificial horizon)? Thanks, Jan
  13. Hi everyone, we are happy with the renewed interest in our beloved 737 and while we would of course prefer you to not have any problems with it - the next best thing is you reporting your problems so we can fix them and hopefully one day (unlikely!) get to the point of no one having any problems with it anymore . If you encounter what you think is a bug or observe a problem: 1.) Do a search in this website (IXEG section) to see if anyone else reported it and what the status on it is. We want to try and avoid having 27 threads of "oh, it looks like the mousewheel scroll direction is wrong, has anyone else seen this?" 2.) If you report a bug, it almost always pays to attach the LOG.txt file (found in your X-Plane main directory) to the post (attach, don´t copy the contents of it to create a wall-of-text). 3.) If you encounter a crash of X-Plane, the culprit is usually an incompatibility with a plugin or memory exhaustion (RAM or Lua). To troubleshoot, please remove all plugins except for the Plugin Admin and Gizmo, then try to run the IXEG 737. If that works, add your plugins back one by one or in batches to isolate the problematic plugin. Often you will find that this plugin has been updated and you can get a more recent and hopefully compatible version. Let us know - even if you succeeded, other users may benefit from your findings. 4.) The same applies if a weird bug or unexplainable behavior is exhibited by the IXEG 737. We need to rule out third-party interaction, so to troubleshoot, please remove all plugins except for the Plugin Admin and Gizmo, then try to run the IXEG 737. If that works, add your plugins back one by one or in batches to isolate the problematic plugin. Often you will find that this plugin has been updated and you can get a more recent and hopefully compatible version. Let us know - even if you succeeded, other users may benefit from your findings. Thanks for all your continued support to help us improve the IXEG 737. Jan
      • 2
      • Like
  14. Oh, wow - I really don´t know what went wrong there... Initially you moved your controls (with the mouse) so the autopilot reverted to CWS pitch. I assume you tried to re-engage VNAV which did not work because probably your controls were still deflected. I have no idea why VNAV calculated these high speeds, though. I think I would like to add that some of the more serious problems we have seen are with users that fly with a mouse or trackball. I would even go as far as saying that if you are serious enough about flightsimulation to buy and fly the IXEG 737, you should really buy a joystick first before spending 75$ on an add-on aircraft like this one. Even if that means that no money is left for the IXEG 737 and we loose a sale . Cheers, Jan
  15. Thanks for the report - both known - the flap will be fixed, for the seat we have to see how we can improve the "fuzzy" looking of the edges without killing framerate. Cheers, Jan
  16. Hi there, you are running quite a few plugins that have been causing conflicts in the past, Silver Lining, Flywithlua, XPUIPC,... I would ask you - to test - to remove all the plugins except Gizmo and PluginAdmin. Then run the IXEG and see if it crashes. After that you can add your plugins again in batches until you find the offending one. My bet is on SilverLining, it messes with the art of X-Plane and is known to be iffy. But also some of the plugins for scenery (KSFO) and other can be a problem. Cheers, Jan
  17. Will check those, thanks for the report! Cheers, Jan
  18. This is what I see in your log: Loaded: C:\Users/jeffr/OneDrive/Desktop/X-Plane 11/Resources/plugins/XPUIPC/64/win.xpl (XPUIPC/XPWideFS.). Lets try to REALLY get rid of it and then see what happens... Jan
  19. The N1 bug is showing the maximum N1 (full takeoff thrust) for the given environmental conditions. Just so you know where to put your engines if you need that. The actual N1 commanded will be much lower if you derated your takeoff thrust (TASS or Derate). Could this be the case here? Cheers, Jan
  20. To add what Tom said - we have not seen many of these errors popping out the gizmo log window anymore, so while the VNAV code isn´t working correctly, at least it is working pretty stable...except in your case here, sorry for that. Whenever you see this and want to continue your flight you can do this to at least somewhat "continue it" and do the landing. Bump your mouse on the right side of the screen to open the gizmo window. Click the reboot symbol. Now you have to be quick to raise your landing gear, deploy flaps again - but at least you can keep flying. Cheers, Jan
  21. Hi Bryan, I have consulted my documentation again, it says: "With the APU operating and AC electrical power on the airplane busses, operate at least one No.1 fuel boost pump to supply fuel under pressure to the APU". So operationally your setting is against the rules ...but I am inclined to say that it should indeed supply fuel to the left manifold and with the APU DC boost pump being off if APU RPM is >95% (running), it should supply fuel from the right wing tank. I will put it into my bug list, good find. Can´t say when we will get to it, though... Cheers, Jan
  22. Hi Robert, you will notice that the "linearity" setting is gone from the control setup - you can make a "response curve" now. This is what mine looks like: Cheers, Jan
  23. Good morning, please add an exclusion to your antivirus (usually Windows Defender is the problem) for the whole X-Plane folder. It checks in and out operations when the IXEG is accessing the nav data (during FMS route modification) which slows the rendering extremely. Let me know if that helps? Cheers, Jan
  24. Yes, same here. Tom has been using a new export script for Blender...I wonder if that has anything to do with it. This line in my log: 0:00:20.648 E/SYS: MACIBM_alert: C:/jenkins/design-triggered/source_code/app/X-Plane-f/../../engine/hardware/vr_manips.cpp:471 may hint at a deeper problem with this that may have to get solved by Laminar Cheers, Jan
×
×
  • Create New...