Jump to content

Litjan

IXEG
  • Posts

    5,694
  • Joined

  • Last visited

  • Days Won

    417

Everything posted by Litjan

  1. @aeroguitarist and @SkyFly, can you confirm that this is what you see on your end? No button on the FO side, but a power button on the CPT´s side? Just want to make sure that we don´t have an export error? Thanks, Jan
  2. This is in the works - barring any undiscovered showstoppers it will be in the next upate. Cheers, Jan
  3. Thanks for the kind words, Rich! I have flown the 737 classic for 10 years, both as FO and CPT and while I enjoyed my time on the 747-400 as well, it is by far my favourite aircraft to fly (lets not talk about the A320s I fly now)... We will continue to work and improve this, make sure to follow my videos where I talk about development of the plane, besides also doing some flying... https://forums.x-pilot.com/forums/topic/17872-ixeg-videos-13-and-onward/ Cheers, and looking forward to hearing from you again with anything else you might spot, Jan
  4. Hi Rich, Nothing was changed with regard to the altitude alert in the last few years. There is an option for different behaviours of the altitude alerter which airlines can choose from. The ones I flew on did not have the "900 feet to go" chime - tone would only play if you approach the set altitude with a vertical speed that requires a "faster than normal" pitch maneuver to level off. The altitude alerter will also sound if you deviate more than 250 feet from your set altitude. I have the request to have an option for this already filed - we just didn´t get around to implementing it. I personally think having this option is not optimal, because it will make the pilots accustomed to that tone and possibly not give it the due attention if it sounds in a real deviation alert. Cheers, Jan
  5. Yep, I will try to test this tomorrow as well! Cheers, Jan
  6. I am sure (if you are into cockpit building) that you have looked for some datarefs already... I know very little about this, but from what I can tell the datarefs: ixeg/733/engine/eng1_thro_angle ixeg/733/engine/eng2_thro_angle output the throttle angle at all times? Jan
  7. I still have to try - but there is one thing to consider: If the thrust levers are advanced into forward thrust, they will disarm the autobrake. So even a little bit of thrust still set at touchdown will disarm them. Now normally the reversers will not deploy while the thrust levers are not at idle - but I don´t know how X-Plane handles that. I could see a scenario where the pilot lands with the thrust levers not completely at idle, or maybe advancing them again before the plane registers that the reverse thrust is active (the dataref needs a second to switch). The real plane will not allow the reverse levers to be pulled back before the reverse sleeves are in the fully deployed position, while X-Plane may allow that. So a good test would be to touch down with idle thrust, keep the nose up, deploy reversers, keeping the nose up, then adding reverse thrust when the reversers are definitely deployed (it takes 2 seconds or so). You could actually start deploying the reversers when radar altitude is below 10 feet, but that is really bad piloting technique, so I don´t even want to encourage that ;-) Cheers, Jan
  8. Hmm, do you have a physical throttle that can move by itself? If you do, then I can see the purpose of this request. If you don´t, then "aligning" the physical throttles with the virtual ones is the only way to sensibly achieve what you describe, because nothing would be worse than switching back to a hardware throttle that is not at the correct powersetting - ask any A320 pilot that inadvertantly disconnected the autothrust before aligning the thrust levers with the "donuts" on the engine display (it is like falling off the horse, every rider needs to have done that at least once , and so did I!) Cheers, Jan PS: If this is related to XPUIPC interface - we do have a dataref that may help: Try to set the ixeg/733/hardware/xpuipc_overrides to 1 and see if that helps?
  9. There is no dataref for that. We move the thrust levers within our code, without a dedicated dataref - we write directly to the throttle position of X-Plane, iirc. Cheers, Jan
  10. Ha, good find - yet I am confused that this happens only on our aircraft - we are using the default X-Plane system for both reverse thrust and the autobrake, so I would assume similiar behaviour on the default 737, for example... I will see if I can find out what is happening. Thanks for the hint, Jan
  11. Here is the next version of LOWI that Laminar will include soon: LOWI Demo Area V1.1.zip
  12. Hi Daniel, I hope you are succesfull! There are many possibilities for plugins not to work together, the first step is always finding out which ones clash. Please let us know when you find out! Cheers, Jan
  13. Well, you are running librain, that is not compatible with X-Plane 11.50 I think... plus many other plugins that could cause all sorts of problems, too. Add on top of that any scenery that one can possibly download, all crammed into a beta version of X-Plane. Your log is full of reports of stuff going wrong and not working... Something is gotta give at some point. I suggest a thorough housecleaning of your X-Plane installation (imagine two big containers in front of the house and a crew in full-body white suits and breathing gear)... and then we can start guessing what the cause might be Cheers, Jan
  14. Wow, you are right! Good catch! Cheers, Jan
  15. Well, knobs can´t move up or down, they are fixed on the rotational axis and can only rotate counterclockwise and clockwise. The consensus so far is that "mouse up" increases the value and "mouse down" decreases the value represented by the knob. I know that in the case of the EHSI mode there is no real "increase or decrease", but we are going with "increase = clockwise" for commonality. I think I understand what you are trying to say - if you see the "marker" on the side of a knob in the 3 o´clock position you would expect to push it "up" towards the 12 o´clock position. And if it is in the 9 o´clock position you would also expect to push it "up" to the 12 o´clock position... Now what do you do when the marker is pointing straight up at the 12 o`clock position - and you want to move it to the 9 o´clock position? Do you "pull it down"? But what happens if it slides down "the wrong side" and now ends up at the 3 o`clock position? Do you hold your mouse sideways? This isn´t going to work in any way that makes sense - I think that Apple does it that way - but there you go (I said "makes sense" ). And no, we aren´t even going to consider changing it or making an option, either . Cheers, Jan
  16. The idea here is to "increase" the value, you push your mousewheel up. And just like turning up the volume in your car, turning the knob to the right (towards PLAN) means "increasing" it. Just like on the range button. Turn left is decreasing, turn right is increasing. It works that way on all the knobs in the whole cockpit - or did you mean something else? Cheers, Jan
  17. Atlichna!
  18. None of that modern gadgetry...we follow the floatsam and the direction of the seagulls! Use the Aviat you got in flightschool to correct for drift and coriolis force and you don´t even need to tune the ILS when landing in foggy JFK 8 hour later!
  19. Hi jojo, thanks for the report...I thought we had fixed this, maybe it crept back in with exporting the cockpit object. Funny enough the yellow bug starts out at the first line, but then you can never push it back all the way up. I also want the checklist to be "flush" against the yoke - we only flipped it up to read it, then would pop it back in. It bothers me that it is out all the time :-) Cheers, Jan
  20. Hallo Jürgen, the only way to fix this would be changing the "increments" for the mousewheel - but then you would have to turn it a lot to achieve the desired dimming/brightening. I think it is a good compromise... Bis dann, Jan
  21. b. look at my video - I think the problem is you using the mousewheel, it will "jump" the knob by certain amounts, so it looks like it moves backwards (strobe effect). EHSI brightness.mp4
  22. Hallo Jürgen, this is a known problem with beta 15. You can update your avitab to fix it or wait for beta 16 which should be out fairly soon. Viele Grüße, Jan
  23. Hallo Jürgen, I know about the DME ID´s - this seems to be an X-Plane issue - as there is no special procedure to tune and listen to them, compared to the VORs. The direction of the brightness knob for the Captain´s ND seems to be working fine on my end - make sure you are not misled by the "stroboscopic" effect when turning things really quick at low framerate (like a car´s wheels seem to turn backwards in old movies). The brakes don´t work exactly "opposite" - in real life you can depress the brakes to release it, just like in our plane. It is true, however, that in real life you have to depress the brakes to engage the parking brake, this is not modeled in our aircraft (we use the default X-Plane parking brake system). Changing the way the brakes work is not very easy in X-Plane, you can "fail" them (we do that to simulate them running out of hydraulic pressure) but to override them is a different thing (you can´t overwrite the brake dataref). Viele Grüße, Jan
×
×
  • Create New...