I know this feature has been asked a few times before, but there has never been a response from PMDG and it isn't a feature in any of PMDG's products.

 

As I don't sit in front of my PC for 10 hours just in case a failure occurs, I have failures turned off. But I feel I'm missing out on quite a lot this aircraft has to offer because of it.

 

Is it possible to implement a option where the 777 can pause the sim if a failure occurs?

 

This means I won't come back to the PC to find an engine has failed and the aircraft has crashed because I wasn't there to deal with it.

I agree, very good idea !

I'm kinda torn on the concept.  One the one hand, I see where you're coming from; but on the other hand, I feel like if you truly want failures, you should put the time into the simulation.  Part of the reason failures are there is to hit you when you're not expecting it and see how you react in the moment.  If it pauses on a failure, you have time to react, assess, hit the books, unpause, and execute.

 

Like I said (and I'm not answering for the team in any particular way at all), I'm torn.  I can see why some justify wanting such a feature, but at the same time, I feel like if you want some of the neater aspects of the sim, you should pay the price of admission.  In other words, if you want the realism of realistic/random failures, you should man the aircraft expecting those realistic/random failures, which requires sitting there.

 

Just my opinion, however, so please don't get bent out of shape...

I'm kinda torn on the concept.  One the one hand, I see where you're coming from; but on the other hand, I feel like if you truly want failures, you should put the time into the simulation.  Part of the reason failures are there is to hit you when you're not expecting it and see how you react in the moment.  If it pauses on a failure, you have time to react, assess, hit the books, unpause, and execute.

 

I'd say the feature is more for learning how to deal with the failures. If I could say, fail an engine, and then have time to look at the warnings, the symptoms and such things, I could walk through resolving the issue, before executing. That would be of most benefit to someone who wants to work up to having anything fail at any time, with the time constraints and stress that come with it.

I'm no real pilot in any sense, but from what I believe to know, real airline pilots are sim trained to deal with at least the most common or most dangerous failures.

 

The middle ground between a pause at failure mode, and full realism would be a function to add a failure at let's say X UTC, or Xnm from waypoint Y (if operating on a typical flight). Then you would still have a sense of urgency, since you still need to fly the plane, but on the other hand, since you programmed the failure yourself, you know what is coming up and when, and can prepare. The next step to this would to add a "buffer" function around the specified fail point, in which it would randomly fail the component either prematurely or delayed.

 

I think the best way to go with this is to go with the "give the customers as many choices as possible" kind of approach.

 

That said, should this functionality ever be considered, a "pause at stepclimb" function would also be neat. I wouldn't use it myself though

The following is just counterpoints - not saying you're wrong:

 

 

 

I'd say the feature is more for learning how to deal with the failures. If I could say, fail an engine, and then have time to look at the warnings, the symptoms and such things, I could walk through resolving the issue, before executing. That would be of most benefit to someone who wants to work up to having anything fail at any time, with the time constraints and stress that come with it.
I'm no real pilot in any sense, but from what I believe to know, real airline pilots are sim trained to deal with at least the most common or most dangerous failures.

 

Then why not use the existing feature where you can ARM a failure and have it go off in a set amount of time?  That feature exists already.

 

 

 

The middle ground between a pause at failure mode, and full realism would be a function to add a failure at let's say X UTC, or Xnm from waypoint Y (if operating on a typical flight). Then you would still have a sense of urgency, since you still need to fly the plane, but on the other hand, since you programmed the failure yourself, you know what is coming up and when, and can prepare. The next step to this would to add a "buffer" function around the specified fail point, in which it would randomly fail the component either prematurely or delayed.

 

Kind of already exists in the above, though it requires more work than your option, which simplifies the timing of it all.

 

 

 

I think the best way to go with this is to go with the "give the customers as many choices as possible" kind of approach.

 

The only problem with that approach is that it generally adds a ton of complexity to the simulation.  It would really bog down the developers with little in the way of return.

 

 

 

That said, should this functionality ever be considered, a "pause at stepclimb" function would also be neat. I wouldn't use it myself though

 

With the auto step climb feature, why would this be necessary?  Additionally, it doesn't take a degree in applied math to look at the step time on the VNAV page to figure out how much time you have until the step comes up.

Some failures take time to develop- so do you fail immediately, or when the failure first is "implemented" by the sim. (See: hydraulic leak, followed by RUDDER RATIO after a minute, an associate failure)

Some failures take time to develop- so do you fail immediately, or when the failure first is "implemented" by the sim. (See: hydraulic leak, followed by RUDDER RATIO after a minute, an associate failure)

 

Good point.  I hadn't thought of that angle.

Wow, that response came fast! BTW, I'm currently watching your videos as my version of IFE (In Flight Education) on my 12 hour haul. Your content is superb!

 

Anway, BTT:

 

 

 

The following is just counterpoints - not saying you're wrong:

 

I'm not saying you're wrong either. I understand the need/want for realism. Don't take me wrong, I'm not attacking your arguments. Just trying to find a middle ground.

 

 

 

Then why not use the existing feature where you can ARM a failure and have it go off in a set amount of time?

[...]

That feature exists already.Kind of already exists in the above, though it requires more work than your option, which simplifies the timing of it all.

 

I didn't know of such function, seems like I have to do more reading/flying!

 

 

 

The only problem with that approach is that it generally adds a ton of complexity to the simulation. It would really bog down the developers with little in the way of return.

 

I understand that. Of course, more features, more development time, more costs, less time for expansions and patches. I was going off the assumption that integrating a "pause at failure" function would be able to benefit from the current "pause at TOD" functionality. Being no dev, and obviously not involved with developing the 777, I can't say how much work it would be. But maybe it would be possible to port the "pause at TOD" function over to the failures as well.

 

 

 

With the auto step climb feature, why would this be necessary? Additionally, it doesn't take a degree in applied math to look at the step time on the VNAV page to figure out how much time you have until the step comes up.

 

Well, by that logic, why need a "pause at TOD" function? Technically (without going on about if it's realistic or not), after TOC and level out, you could just dial down the MCP ALT to your selected ALT, like for example FAF ALT, and set override A/T to never. Haven't done so myself, but I'm sure it's possible. So you wouldn't need to pause, right? Also, it also just as much doesn't take a degree in applied math to memorize when your TOD comes up.

 

My point is, some of the functions might not be realistic, but the sim community is diverse, and PMDG put these functions in to cater to that. I see no reason aside from dev time and cost to expand on that, being it because of a failure, or of an upcoming step climb.

 

Now that you mention step climb, let me adjust this one real quick...

 

 

Wow, that response came fast! BTW, I'm currently watching your videos as my version of IFE (In Flight Education) on my 12 hour haul. Your content is superb!

 

First days of work are like first days in college (not a new job, just a new contract):

"Here's some paperwork.  You're going to be doing lots of stuff in the future, but for now, sit there and look pretty while we figure things out..."

 

That said, I'm really not doing much at the moment.  I managed to place out of an 8 hour information security class by taking a test, too, so I have a ton of extra time on my hands now.

 

...and thanks!  If you have any ideas on what to make a video of next, I'm always up for suggestions.

 

 

 

I'm not saying you're wrong either. I understand the need/want for realism. Don't take me wrong, I'm not attacking your arguments. Just trying to find a middle ground.

 

I didn't take them as attacks.  I was just providing counterpoints - no worries!

 

 

 

I didn't know of such function, seems like I have to do more reading/flying!

 

I think it might be in the intro manual somewhere, but I'm not sure how much depth it gives.  Once you see the FAILURES pages, it'll be kinda obvious how it all works.

 

 

 

I understand that. Of course, more features, more development time, more costs, less time for expansions and patches. I was going off the assumption that integrating a "pause at failure" function would be able to benefit from the current "pause at TOD" functionality. Being no dev, and obviously not involved with developing the 777, I can't say how much work it would be. But maybe it would be possible to port the "pause at TOD" function over to the failures as well.

 

I couldn't say for sure how easy or difficult it is, but I try not to assume too much when it comes to programming.  Pause at T/D shouldn't be too different from a pause before S/C, but I can't say much for the rest.

 

 

 

Well, by that logic, why need a "pause at TOD" function? Technically (without going on about if it's realistic or not), after TOC and level out, you could just dial down the MCP ALT to your selected ALT, like for example FAF ALT, and set override A/T to never. Haven't done so myself, but I'm sure it's possible. So you wouldn't need to pause, right? Also, it also doesn't take a degree in applied math to memorize when your TOD comes up.
 
My point is, some of the functions might not be realistic, but the sim community is diverse, and PMDG put these functions in to cater to that. I see no reason aside from deve time and cost to expand on that.
 
Now that you mention step climb, let me adjust this one real quick...

 

Yeah, but T/D is a lot more important than a S/C.  S/Cs aren't really as regular and programmatic as simmers tend to think.  Yes, they're done, but they're not always on exact schedule as you see on the ND.  If you miss a S/C, you burn a little more fuel.  If you miss T/D, your entire descent and landing is going to be messed up.  It has more consequences.  I do see your point, though.

 

I understand the diverse nature of the sim hobby, so being diverse as a developer to cater to that diversity would only theoretically increase your sales, but there exists a point where you're spending more money on trying to draw people in than you get back from them.

Wow, that response came fast! BTW, I'm currently watching your videos as my version of IFE (In Flight Education) on my 12 hour haul. Your content is superb!

 

Anway, BTT:

 

 

 

 

I'm not saying you're wrong either. I understand the need/want for realism. Don't take me wrong, I'm not attacking your arguments. Just trying to find a middle ground.

 

 

 

 

I didn't know of such function, seems like I have to do more reading/flying!

 

 

 

 

I understand that. Of course, more features, more development time, more costs, less time for expansions and patches. I was going off the assumption that integrating a "pause at failure" function would be able to benefit from the current "pause at TOD" functionality. Being no dev, and obviously not involved with developing the 777, I can't say how much work it would be. But maybe it would be possible to port the "pause at TOD" function over to the failures as well.

 

 

 

 

Well, by that logic, why need a "pause at TOD" function? Technically (without going on about if it's realistic or not), after TOC and level out, you could just dial down the MCP ALT to your selected ALT, like for example FAF ALT, and set override A/T to never. Haven't done so myself, but I'm sure it's possible. So you wouldn't need to pause, right? Also, it also just as much doesn't take a degree in applied math to memorize when your TOD comes up.

 

My point is, some of the functions might not be realistic, but the sim community is diverse, and PMDG put these functions in to cater to that. I see no reason aside from dev time and cost to expand on that, being it because of a failure, or of an upcoming step climb.

 

Now that you mention step climb, let me adjust this one real quick...

 

 

By that philosophy sure- but I think what Kyle was explaining (and I kind of clued into) is that it would take an investigation of each failure to guess where to put the "pause" in. With the hydraulic failure, do you stop immediately after the first quart leaks (users would be annoyed- "Why did it pause? There are no failures"- yet!), or do you wait until the failure is developed (cautions for flight controls, overheated HYD demand pump). Also, part of the realistic failure simulation is that an unattended failure can sometimes cascade into another failure if not dealt with. 

 

With pause at TOD, it's a very easy calculation, and helps those of us who step away from the computer for periods of time (since FSX is fairly unrealistic at cruise and doesn't give you much to do, especially over oceans). Much happiness for little programming effort.

Anyhow, aside from all of this, yes it could be a really cool feature and training tool (especially when an initial caution light leads to two different checklists). 

 

If you miss the T/D and you've not setup, briefed, bugged your approach data, you'll be a little behind. 

 

Auto stepclimb I guess could save virtual fuel and make your virtual airline greener, but who cares about virtual fuel right? Couldn't you program the FMS with your highest planned cruise, and then just have VNAV altitude constraints for each waypoint? The aircraft would observe those and climb automatically. Of course, no real airline procedure does this since your engines would be in CLB the whole time, and this opens up a whole possibility for "entry errors" that pilots are prone to.

I couldn't say for sure how easy or difficult it is, but I try not to assume too much when it comes to programming. Pause at T/D shouldn't be too different from a pause before S/C, but I can't say much for the rest.

 

Well, there *has to be* (take with grain of salt) a logic in the system that says "TOD reached = 1" (simplified, of course it would be more complex than that). That results in the FMC knowing "hey, I have to start the descent now."

From my limited understanding, when that value is set to 1, and the "sim pause at TOD" function is 1 (active), then send some magical dodad command to pause the sim. Of course there are more complexities than that, like interfacing simmconnect or whatever they use to tell the sim to pause. But from the way I see it, it would be a relatively easy thing to do, copy the "send pause" command and set it to a different condition. I can of course be wrong.

 

And for the FMC/CDU to know that a failure is active (any failure), I'm sure there is a global value that is turned to 1 (again, active) as soon as ANY failure is triggered.

 

 

 

By that philosophy sure- but I think what Kyle was explaining (and I kind of clued into) is that it would take an investigation of each failure to guess where to put the "pause" in. With the hydraulic failure, do you stop immediately after the first quart leaks (users would be annoyed- "Why did it pause? There are no failures"- yet!), or do you wait until the failure is developed (cautions for flight controls, overheated HYD demand pump). Also, part of the realistic failure simulation is that an unattended failure can sometimes cascade into another failure if not dealt with.

 

I understand, and you are right. Going into full detail to where exactly the pause would be triggered would be a larger programming undertaking. I interpreted the OP in the sense of "trigger at first failure". It wouldn't be necessary to take cascading into account in that scenario, since the sim is paused. If it's unpaused, then the simmer is in the cockpit again (if he was gone), and aware that failures are pesent (assuming the aircraft tells him so - EICAS, STAT, master caution/warning...). So, subsequently, if the failures indeed cascade, the simmer can decide when he wants to pause again, and take his time to go through the documentation.

 

But what if the simmer has service based failures on, but isn't in the cockpit at that time? A step climb can be missed (or set to auto), a descent can be missed, but in both cases the plane would continue to fly until it's fuel runs out. In the event of an urgent/serious failure, and subsequent cascading, which let's say results in total engine failure, the simmer might come back and find his plane with no power and thrust, or worse, crashed, given the time. Which would be more frustrating to a simmer that leaves his pit during cruise?

 

Not to forget that a novice simmer would have to deal with more stress should he/she encounter failures during high activity phases like takeoff/landing. But in those scenarios, I'd assume the simmer has access to his or her pause key.

 

Edit: Removed some typos

Good feature request.  It is no less reasonable than having auto step climbs and stability in time-accelerated flight.

I support this request too, love too see it implemented. I too fly with failures turned for the exact sam reason of the OP.

I think this is a brilliant idea and would rate it up there with showing the actual throttle position. Programatically, it could be done by checking an option when a warning light is about to be illuminated. After that, it could be made as simple or as complex as time allows.

 

I respect the Heros who sit watching their the cockpit displays for hour after hour just in case, but I am not one of them. I prefer flying to monitoring to the degree that I (like most others) will disable errors rather then have to sit and wait with a finger on the pause button. If you want to believe that makes me a gamer and not a true simmer, I wont be too offended. 

 

Having this option would allow me to use acceleration, take rest breaks, and live a normal family life, and still allow the cool programmers at PMDG to show off their subtle and complex skills. And the beauty of it is, there would be absolutly no impact on the pleasure the Heros get since they would not need to use this option. Of course, they would no longer be the only ones who get to see the incredible depth of detail that PMDG can get into a sim, but perhaps seeing this detail in person might convince more 'gamers' to give true 'simming' a try.

Anything that would encourage simmers to try failures and more complex aspects of the sim gets a thumbs up from me

 

It would need to be well thought out, no point pausing for a fire detection loop failure, or many of the other minor system glitches simulated.