• Content count

  • Joined

  • Last visited

Community Reputation

26 Excellent

About mfor

  • Rank
    Advanced Member

Recent Profile Visitors

108 profile views
  1. Well I'd prefer it to be constant to be honest or even an increased chance at the start, as a failure shortly after takeoff is more uhmm.. intense. Also unless you set the MTBF really low you're not really going to hit the "above MTBF" phase. So instead I'd suggest some button (or dataref) that you can hit to cause a random failure in the next 5 or 10 minutes or so. That way you do have a way to trigger a fault quickly (if you are bored or want an interesting takeoff/landing) but still be somewhat surprised by it and don't have to lower the MTBF to ridiculous levels.
  2. number of passengers and cargo weight

    But you are demonstrably sooo much better at coming up with descriptive tags - not to mention proper weights for them, that I hoped, you would do that work for us
  3. number of passengers and cargo weight

    But isn't that slider more or less what we already have? I'd say the current implementation is even better because you can enter what you really care about in the end: (Zero Fuel) Weight and CG - both of which may vary even with the same amount of passengers. I think, adding some more descriptive tags would be nice instead of (or in addition to) average, packed, etc., for example "morning business route (pax full but little cargo)", "holiday bomber (extra seats, full, lots of luggage and newspapers), "island hopper (fewer passengers)" or ".com jet" . That way you could pick a typical load for the flight you're planning and still have full control over the weight by simply looking at the numbers instead of the descriptions. Wouldn't be that much work either.
  4. You are confusing MTBF and lifetime expectancy. The former is about random failures of a device while the latter is about how long a device is expected to last. Those two can be very different. For example given the 2003 "life table" for the US - a 30-year old has a ~0.1% chance to die in that year - this translates to a MTBF of roughly 1000 years, however even the best wear out long before that - their lifetime expectancy is a mere 49 years. So MTBF expresses really just a random chance to fail and thus does not require any life time tracking. If you were to implement some form of that (e.g tires lasting only X landings), then you'd need indeed some form of air frame state save. In reality, you'd also hope that maintenance is aware of the lifetime expectancy of the various devices and replaces them before that. So I don't think you would gain much by tracking stuff across flights, unless you want to implement some sort of maintenance simulation, i.e. replace engines after X hours (depending on usage), etc. along with the financial impact to enable some kind of "running an airline" experience. In this simulation MTBF is really just there to give you a better idea of what to expect, i.e. a MTBF of 20h would mean you should expect one failure in 20h of flight (or 5% per hour, or adhering to how it's programmed: 0.0139% per 10s ) regardless of how those 20h are composed. Since it IS random however, you might experience 20 faults in 10 hours or none in 100h. In reality the MTBFs are much higher of course and vary from system to system as well, while here it's all combined into one.
  5. 733 long haul

    Nice. These "Alaska Milk Runs" sound fun too. For the long legs step climbs could be beneficial - not sure if/how you could calculate that with the FMC, but it does give you the optimal cruise altitude. Still need to consider (enter?) the winds though. The 737OM has some tables though, so I guess you could do the math in the old-fashioned way - it'll give you something to do on those long flights if nothing else
  6. 733 long haul

    Hope your ground grew handled it better than the guys in this incident Probably HAM-PMI - a bit short of 3 hours, but I do prefer shorter hauls as well.
  7. Probably taking his SR-71 for a quick spin
  8. Autobrakes not working

    Well it works for me, so I suppose it's either a conflict with other addons or some procedure/input error. There's a few things I would check: Auto-brake disarm light extinguished until manual brakes are applied or speed brakes retracted thrust lever idle speed brakes armed before landing and automatically applied on touchdown if you have a joystick axis assigned to the brake try with it unassigned (spikes might apply manual brakes slightly) So in short watch the disarm light and follow procedures (IXEG has some tutorial videos on youtube) - a video or a series of screen shots might help if you still can't get it to work. Also see
  9. Horn sounding on takeoff in XP11.05r1

    I think at that point the AP should not be able to trim the aircraft. So maybe some keybinding problems or xp11.05 has a bug/feature that sets the trim on takeoff?
  10. Horn sounding on takeoff in XP11.05r1

    The horn indicates a takeoff configuration error and will sound when the throttle is advanced beyond 50% and one or more of the following is true flaps in the wrong position for takeoff trim outside of (green) takeoff band speed brake not fully retracted (mustn't be armed either) - this can easily happen if you've assigned a joystick axis parking brake set If you've checked all those it might be an issue with 11.05 or I'm forgetting some other condition...
  11. lua script for x737

    Well this forum is about IXEG's 737 not the x737 by EADT, but I think they provide datarefs to access those levers, see
  12. Clouds visible through the fuselage v1.2

    The sooner, the better - I'd love to see those 60 fps
  13. Clouds visible through the fuselage v1.2

    Bingo. Default 737-800. cloud2.avi
  14. Clouds visible through the fuselage v1.2

    Did a flight from KFAT to KSFO and played around quite a bit with weather settings and finally got the problem to show up again during descend. Here's the settings/configuration, local time was 17:59 - note that changing the reflection detail had no effect. I've also attached video (41mb) where you can see that it is in fact multiple cloud parts that are shining though. Video driver is unchanged from above, scenery is Ortho4XP based on HDMeshv3. If you need a HQ video or any other information let me know. Otherwise, I guess the next step is testing one of the default planes clouds.avi