Good results concerning reduced thrust takeoffs in the new version 2.3.5.9.  Did some takeoffs in the 737-600 with a fixed derate of TO-2 (18k derate) plus a flex temp of 38 C.  This restricted the takeoff N1 to 83.1% for the autothrottle.  With greater flex temps than that, the FO didn't recognize the takeoff but  I think that is ok because I've read you aren't allowed to use more than a 25% total derate from the certified thrust anyway, regardless of how much runway margin remains.  Topcat, the performance computing program, probably won't even give numbers that push the N1 that low, so I think this will be more than acceptable.  Thanks for fixing this particular problem so quickly!

One minor critique about the takeoff calls.   On some airplanes V1 and VR are either exactly the same, or else within just a few knots of each other.  The FO will call VeeOne, but there will be a short delay until he calls VeeRotate.  He knows the V speeds, so it isn't an error with that, at least not on the NGX.  On a few takeoffs, when using full rated thrust, I've even accelerated 10 knots beyond the Vr bug before he calls it.  It's not like I'm not watching the speed bugs myself, but it might be good to add a call of "Vee One, Rotate" to the vocabulary to handle the situation when V1 and VR are very close to each other, or the same.

KingGhidorah, on 21 Jun 2013 - 01:41 AM, said:

 

One minor critique about the takeoff calls. On some airplanes V1 and VR are either exactly the same, or else within just a few knots of each other. The FO will call VeeOne, but there will be a short delay until he calls VeeRotate. He knows the V speeds, so it isn't an error with that, at least not on the NGX. On a few takeoffs, when using full rated thrust, I've even accelerated 10 knots beyond the Vr bug before he calls it. It's not like I'm not watching the speed bugs myself, but it might be good to add a call of "Vee One, Rotate" to the vocabulary to handle the situation when V1 and VR are very close to each other, or the same.

I'm assuming that the latest version 2.5.41 has incorporated this modification, because it appears to be working perfectly now in the NGX. He calls "VeeOne-Rotate" with no pause when V1 and VR are the same, or within a knot or two of each other. In the F1 DC9, however, the V1 and VR speeds are typically farther apart, and our acceleration is much less than it is in the powerful NGX, yet he also makes the rapid singular V1VR call, which is not appropriate in this case. Here, he should call V1 as it arrives, and then call VR as it arrives, instead of just making a singular call, just like he was doing in previous versions. The calls should match exactly what the built-in V speed calls are if we had them enabled, and it isn't doing that on this plane. At the risk of nitpicking, perhaps a little more tuning would be in order for a plane like the DC9 :lol: . But it appears to be working quite perfectly now in the fast-accelerating NGX, where V1 and VR are always back to back. Haven't tried it out on the MD11 yet.

While testing out the new priority tweak, I noticed that on the F1 DC9 that the command "slats retract" is acknowledged, but he doesn't actually retract the slats.  At "Flaps up" he correctly puts the Flap handle in the 0 position (slats still extended), but he will not retract slats, despite giving a verbal confirmation, and the handle remains in the Flaps 0 position.

KingGhidorah, on 29 Jun 2013 - 5:31 PM, said:

 

While testing out the new priority tweak, I noticed that on the F1 DC9 that the command "slats retract" is acknowledged, but he doesn't actually retract the slats. At "Flaps up" he correctly puts the Flap handle in the 0 position (slats still extended), but he will not retract slats, despite giving a verbal confirmation, and the handle remains in the Flaps 0 position.

Disregard this. Although on one of my flights with the 2.5.43 executable on the DC9, I could not make him actually respond with action to "Slats Retract", I'm trying it out now, and it's working fine. Don't know what the problem was before, and indeed it wasn't working, but I cannot reproduce it, so I think it must have just been one of those rare errors where something gets mucked up.

I hope you don't mind me reporting possible issues as I find them, although I admit I'm feeling awkward making almost daily reports of problems with any particular airplane, and nobody else is! On the F1 DC-9, the FO won't set the EPR bugs past 2.00. You can say "Set EPR bugs One Point Nine Nine, or One Point Eight Five, but if you say "Set EPR bugs Two point Zero One or above, he does not respond in any way to this command. Nor does this appear to be a confusion between "Two" or "To" or "Engine Two," and I have tried every phrasing I can think of with no result. I'm pretty sure this is a "bug", no pun intended.

 

Assuming you are open to wishlist requests, it would also be helpful if we could have a command "Set Thrust to bugs" or something similar. Already built in to MCE are "Set Climb Thrust" and "Set Takeoff Thrust" which would be useful for an airplane like this, but these appear to be completely generic and they they do not work correctly to set a user specified value or one that is valid for a particular airplane. If we had a "set thrust to bugs", the user could create a Voxscript for Climb Thrust and Takeoff Thrust containing this command (provided an allowance was made to override the default command, as I suggested in a different thread) that would allow MCE to accomplish this very realistically.  Maybe I'm asking for too much, but this is just a suggestion!

 

 

I hope you don't mind me reporting possible issues as I find them, although I admit I'm feeling awkward making almost daily reports of problems with any particular airplane, and nobody else is!

 

Please don't feel awkward. If one thing these kind of reports will get the product refined even further.

 

There is actually a command to set EPR, however it doesn't have the flexibility found in other commands.

 

Try...

 

Set one point nine nine EPR

Select one decimal ninety nine EPR

 

Just don't start the sentence with "set epr".

 

Needless to say, after this, the speech grammar will be updated to accept your own version.

 

"set thrust to bugs" will also be considered for next update

Just to avoid confusion, in this particular case I actually only wanted him to set the EPR bugs, not actually set the thrust to that EPR.  He correctly sets the bugs to 1.xx, but can't set the bugs to 2.xx.  So I'm reporting that for some reason the grammar I was using actually worked to set the bugs but not when the value is below 2.00.  I think I already tried saying "Set Two Point Zero Five on the Eeeper bugs" and IIRC in this case he actually attempted to set the thrust itself, not the bugs, but I would have to go back to verify.

 

I should have mentioned that I already had experimented with him actually setting the thrust to the commanded EPR on the DC-9.  You'll have to see it for yourself, because I'm not sure I could describe it adequately except to say that he set it very very slowly, and he didn't succeed in setting the correct EPR despite acknowledging it.   I didn't play with it too much, or report it, because I assumed that the command was generic and probably wouldn't have been customized to work with this specific plane.

Just to avoid confusion, in this particular case I actually only wanted him to set the EPR bugs, not actually set the thrust to that EPR.  He correctly sets the bugs to 1.xx, but can't set the bugs to 2.xx.  So I'm reporting that for some reason the grammar I was using actually worked to set the bugs but not when the value is below 2.00.  I think I already tried saying "Set Two Point Zero Five on the Eeeper bugs" and IIRC in this case he actually attempted to set the thrust itself, not the bugs, but I would have to go back to verify.

 

I should have mentioned that I already had experimented with him actually setting the thrust to the commanded EPR on the DC-9.  You'll have to see it for yourself, because I'm not sure I could describe it adequately except to say that he set it very very slowly, and he didn't succeed in setting the correct EPR despite acknowledging it.   I didn't play with it too much, or report it, because I assumed that the command was generic and probably wouldn't have been customized to work with this specific plane.

 

OK got it. The issue was with the speech grammar only expecting "one" as the first digit when it should expect "zero", "one" or "two" for EPR.

 

That command to set EPR bugs isn't generic at all. It's only enabled for aircaft where we are able to read the status of those bugs.

 

Remember the CoolSky DC9 doesn't have an SDK, and we have to interface it via our home grown techniques.

 

To see what's generic and what's not, temporarily rename "mcmddc9X.dll" inside \Flight Simulator X\MCE dlls\ to "disabled-mcmddc9X.dll"

 

In the absence of the custom interfacing, MCE will revert to using "mcgeneric.dll", and although you will hear FO saying he's gonna do this or that, nothing will happen on the overhead panel. He will only manage a few things via the generic dll. Basically, Flaps, Gear, and radios tuning. In the DC-9 case, almost everything else is custom and the "mcmddc9X.dll" is vital.

 

Note: To prevent MCE restoring the file which it does when the custom dll appears to be missing, you also need to rename the "mcmddc9X.dll" in \Multi Crew Experience\Support\Files\FSX\MCE dlls\ to "disabled-mcmddc9X.dll".

Hi

 

When I go into FSX using MCE the mission editor opens, then the diplay of the frame rate in red at the top of the screen, and if I'm using the PMDG NGX I get the copilot continuously saying "EFIS minutes button has been pressed" and he gets rather cross if I ask him to do anything for me. It then continously cycles between these so I have to keep closing them. This happens independently of which joysticks I have connected and even when I have no joystick connected at all.

 

I've tried reinstalling MCE using the latest version each time but the problem only seems to be getting worse. I've also tried deleting the FSX and PMDG key assignments for each of these things, but no joy. Seems like it must be a clash with something else (UIPC?).

 

Can you help please as I think MCE is a great program but this is making it very difficult to use.

 

Thanks

 

Jim

Hi

 

When I go into FSX using MCE the mission editor opens, then the diplay of the frame rate in red at the top of the screen, and if I'm using the PMDG NGX I get the copilot continuously saying "EFIS minutes button has been pressed" and he gets rather cross if I ask him to do anything for me. It then continously cycles between these so I have to keep closing them. This happens independently of which joysticks I have connected and even when I have no joystick connected at all.

 

I've tried reinstalling MCE using the latest version each time but the problem only seems to be getting worse. I've also tried deleting the FSX and PMDG key assignments for each of these things, but no joy. Seems like it must be a clash with something else (UIPC?).

 

Can you help please as I think MCE is a great program but this is making it very difficult to use.

 

Thanks

 

Jim

 

Sure we can help Jim.

 

To make sure you're all setup with the latest version, restore to factory settings.

 

Click Start->All Programs->Multi Crew Experience->Tools->Restore factory settings.

 

Answer "Yes" when prompted.

 

The next time you start MCE, you'll have to go through the wizard instead. Perform all steps except speech training if you already completed that earlier.

 

PMDG NGX Interfacing is done via the published PMDG SDK. It doesn't rely on keyboard assignments. There is no need to delete those in FSX or PMDG.

 

If for some reason you cannot see the spoken commands in red font, proceed as follows...

 

Right-click anywhere on the user interface, a drop down menu will appear, then select "Recover text display" and follow on-screen instructions.

 

There is no known compatibility issue with FSUIPC.

 

Maybe the main issue is the quality of the speech input. You are getting too many spurious commands (FO hearing things). You definitely don't need an expensive headset, however you need to keep a few things in mind.

 

When you perform speech training, it's usually against a completely silent background. You will get better results if you direct all sounds (including engine sounds) to the headset.

You can still keep engine sounds on speakers if you wish, but you'll have to position them in a way that they don't feed directly to the mike.

 

Mike calibration is vital.

 

If using a USB headset, make sure you plug it straight to the back of the PC, and not via a USB port or the front USB connectors.

 

Would appreciate more info about your machine

 

Thanks

Sure we can help Jim.

 

To make sure you're all setup with the latest version, restore to factory settings.

 

Click Start->All Programs->Multi Crew Experience->Tools->Restore factory settings.

 

Answer "Yes" when prompted.

 

The next time you start MCE, you'll have to go through the wizard instead. Perform all steps except speech training if you already completed that earlier.

 

PMDG NGX Interfacing is done via the published PMDG SDK. It doesn't rely on keyboard assignments. There is no need to delete those in FSX or PMDG.

 

If for some reason you cannot see the spoken commands in red font, proceed as follows...

 

Right-click anywhere on the user interface, a drop down menu will appear, then select "Recover text display" and follow on-screen instructions.

 

There is no known compatibility issue with FSUIPC.

 

Maybe the main issue is the quality of the speech input. You are getting too many spurious commands (FO hearing things). You definitely don't need an expensive headset, however you need to keep a few things in mind.

 

When you perform speech training, it's usually against a completely silent background. You will get better results if you direct all sounds (including engine sounds) to the headset.

You can still keep engine sounds on speakers if you wish, but you'll have to position them in a way that they don't feed directly to the mike.

 

Mike calibration is vital.

 

If using a USB headset, make sure you plug it straight to the back of the PC, and not via a USB port or the front USB connectors.

 

Would appreciate more info about your machine

 

Thanks

Seems to be much better following your advice aobve. Still get the odd appearance of the mission screen but only occasionally now thanks.

 

Spec of PC is:

 

Processor

Intel i7-3770K CPU at 3.60 GHz

RAM

8 GB

Graphics card

Nvidia GTX 275

Controls

Saitek yoke and throttle, CH pedals

 

and Steelseries headset.

 

Many thanks

The accidental appearance of the mission screen is related to specific commands to interact with the FSX (FS9) user interface.

 

Example of commands

 

"Display weather dialog"

 

They can be useful for people operating projectors, so they can do without fiddling with keyboard.

 

If you don't need these, go to the <Sim> tab of the user interface and disable option "FS Dialog Boxes".

sorry, wrong page

Hi!

 

Sorry if this is posted on the wrong site, or in the wrong topic, but I still struggle on these endless-big-none-navigation-able site.

 

Well, anyway why do my MCE only understand what I am saying when I am flying PMDG 737-600?

 

If I change to PMDG 737-700, 800, 900 with or without winglets or the PMDG 747-something it won't understand a word i say.

"Power up with ground power" turns out to be like "left APU power on", whatever that is. "Prepare aircraft" turns out to be "right pump off" or something like that. It just won't understand. I am me always, with the same voice, same intonation, same headset, yes actually same everything. So what is happening here?

 

Another thing, when I installed the latest update, couple of weeks ago, nothing worked at all. It just crashed after a few seconds. Every time. So I installed the old version again. But even now it seems to be much more unstable than before and I can no longer talk to ATC.

 

Anybody out there who may have answer to this?

 

Regards, Ompakar