Please add a reset / restart option

[RALF9636 1,920]

A few more flights and still no lags any more. Stress testing as you described is hard to do though because flow items are skipped so that the flow is completed before I could issue many commands.

For now I press numlock immediately after starting the flow and everything works perfectly.

Looking forward to the next version when pressing numlock won't be necessary to have everything work perfectly 😉

 

Edited September 16, 2019 by RALF9636

[FS++ 707]

On 9/16/2019 at 8:31 PM, RALF9636 said:

A few more flights and still no lags any more. Stress testing as you described is hard to do though because flow items are skipped so that the flow is completed before I could issue many commands.

For now I press numlock immediately after starting the flow and everything works perfectly.

Looking forward to the next version when pressing numlock won't be necessary to have everything work perfectly 😉

 

Latest is ready for download and should settle things.

 

[RALF9636 1,920]

I hate to say it, but the lags returned with 2.8.0.5.

I reinstalled 2.8.0.4 and compared the time it took to completely execute a flow that always seemed to be prone to the problem. Whereas in 2.8.0.4 it took about five seconds (no skipped items in my test) it was around thirty seconds in 2.8.0.5 (like in the versions before 2.8.0.4). And pressing the mutekey did not help to speed things up in 2.8.0.5.

 

Another observation that probably is unrelated but notable anyway: There seems to be an issue with the uninstallers. Both uninstalling 2.8.0.4 and 2.8.0.5 (and I think I first noticed that already when uninstalling 2.8.0.3) there was a long pause for about five minutes at around 10 % of the uninstalling progress, before the uninstaller then quickly finished. That seems to be unusual.

 

[FS++ 707]

25 minutes ago, RALF9636 said:

I hate to say it, but the lags returned with 2.8.0.5.

I reinstalled 2.8.0.4 and compared the time it took to completely execute a flow that always seemed to be prone to the problem. Whereas in 2.8.0.4 it took about five seconds (no skipped items in my test) it was around thirty seconds in 2.8.0.5 (like in the versions before 2.8.0.4). And pressing the mutekey did not help to speed things up in 2.8.0.5.

 

Another observation that probably is unrelated but notable anyway: There seems to be an issue with the uninstallers. Both uninstalling 2.8.0.4 and 2.8.0.5 (and I think I first noticed that already when uninstalling 2.8.0.3) there was a long pause for about five minutes at around 10 % of the uninstalling progress, before the uninstaller then quickly finished. That seems to be unusual.

 

We use Microsoft installer-uninstaller technology. Nothing we can do about that. It's completely managed by Microsoft.

I believe at some point UAC should pop-up and it doesn't always kick in in a timely manner (shows up on task bar but no fading Window screen immediately as you would expect).

With regards the latest changes made to MCE, from now on, do not use the Mute button or key key as a means to speed up the flow.

It works OK now. No skipping and the execution speed is improved. MCE enforces a minimum delay of 2.5 seconds between 2 consecutive commands, even if no pause is inserted in the flow.

As long as "mce.exe" is V2.8.0.5 you're on the latest.

Unlike with previous iterations, this one should make a real difference. Try again please.

Would appreciate if others chime in to provide more feedback, as it's hard to work out what needs to be changed.

 

[RALF9636 1,920]

I confirm I am on V2.8.0.5 now and do not use the mute key.

In V2.8.0.4 there was no 2.5 seconds delay between two commands. It was less than a second. So that easily explains why the execution of the flow is slower in 2.8.0.5.

The deterioration of the performance over time and the temporary unresponsiveness seems not to occur anymore in 2.8.0.5.

But there are delays much longer than 2.5 seconds between two commands, in particular if these are voxkey commands (and I use lots of them).

In this context I noticed that the "reply" is not spoken out if the first command in the script is a voxkey command. When I add "pause=2" before the first command the reply is spoken out; also the reply is spoken out when a "normal" command is the first command. Maybe this is related to the delayed execution of the voxscript commands.

In V2.8.0.4 the commands were executed with less than a second in-between, also with voxkey commands. There was just the problem that some commands were skipped which could be prevented by pressing the mute key. So MCE basically is able to execute the commands in short sequence.

So why are the delays happening again in 2.8.0.5?

Isn't it possible to do some kind of logging to find out what is happening on my system? Apparently this is not a common issue for MCE users so it must be related to my way of using MCE: FSLA320 (involving 2D panels, these commands also seem to be prone to delays), PF3 interaction, around 30  - some very short, others quite long - voxscripts (always verbose=0) I run during a normal flight, lots of my own voxkey commands integrated into the voxscripts.

 

 

Edited September 19, 2019 by RALF9636

[FS++ 707]

46 minutes ago, RALF9636 said:

I confirm I am on V2.8.0.5 now and do not use the mute key.

In V2.8.0.4 there was no 2.5 seconds delay between two commands. It was less than a second. So that easily explains why the execution of the flow is slower in 2.8.0.5.

The deterioration of the performance over time and the temporary unresponsiveness seems not to occur anymore in 2.8.0.5.

But there are delays much longer than 2.5 seconds between two commands, in particular if these are voxkey commands (and I use lots of them).

In this context I noticed that the "reply" is not spoken out if the first command in the script is a voxkey command. When I add "pause=2" before the first command the reply is spoken out; also the reply is spoken out when a "normal" command is the first command. Maybe this is related to the delayed execution of the voxscript commands.

In V2.8.0.4 the commands were executed with less than a second in-between, also with voxkey commands. There was just the problem that some commands were skipped which could be prevented by pressing the mute key. So MCE basically is able to execute the commands in short sequence.

So why are the delays happening again in 2.8.0.5?

Isn't it possible to do some kind of logging to find out what is happening on my system? Apparently this is not a common issue for MCE users so it must be related to my way of using MCE: FSLA320 (involving 2D panels, these commands also seem to be prone to delays), PF3 interaction, around 30  - some very short, others quite long - voxscripts (always verbose=0) I run during a normal flight, lots of my own voxkey commands integrated into the voxscripts.

 

 

Possibly related to Voxkey commands as I didn't test that scenario with latest changes.

The 2.5 seconds delay relates to the absolute minimum delay between 2 commands sent to speech engine to simulate spoken command.

It's actually a bit more complicated than that as you don't just simulate a spoken command, wait for 2.5 sec and send next one.

You have to wait for speech engine to recognize previous one, process it  as if you gave the command directly (which could take up to 10 seconds), then wait 2.5 for safety and send the next one.

2.5 sec is arbitrary, and could eventually be lowered. It hasn't changed for the last 3 years or so.

its main purpose is to ensure Fo can properly identify which command is spoken directly and which one is part of a flow.

For instance, if a flow is silent, he has to keep quiet, while maintaining the ability to be vocal when you eventually ask him a question, or command him to do something else while a flow is in progress.

In verbose mode, you may not even notice the delay as the Fo could take 3 seconds or more acknowledging the first command.

There are exceptions, like a command for flight control check which allows for up to 30 seconds to be completed before the next one is sent to the speech engine.

Try it with PMDG 737 NGX, T7 or B747 or some aircraft with which MCE doesn't need to pop-up 2D panels  if you can.

Thank you once again for forcing a re-think of this particular feature.

 

[RALF9636 1,920]

Thanks for the insight to the reasoning for the 2.5 sec delay. Apparently you experimented without that in 2.8.0.4. which led to that some commands were skipped because it was too fast to simulate the spoken command. And by pressing the mutekey that was not a problem because that way simulating a spoken command was not necessary. Just wild guessing... 🙂

 

But I wonder, isn't it possible to take the scripted commands as such - without the detour of simulating a spoken command? It seems to me 2.8.0.4 did something like that. I understand that then it probably wouldn't be possible to give additional verbal commands while the scripted commands are executed, but I would be fine with that. Many of my longer scripts include some pauses so I could give necessary commands then. And the shorter scripts would be completed within a few seconds, so it wouldn't be a problem.

Maybe optional for every script, like "verbose=1", something like "scripted execution=1".

 

Apart from that I would appreciate if you test some voxkey commands and make them as fast as the other commands.

 

I almost exclusively fly the FSL A320 these days and the only other Airliner I sometimes use is the Q400 which also involves 2D panels.

 

Edited September 19, 2019 by RALF9636

[FS++ 707]

19 minutes ago, RALF9636 said:

Thanks for the insight to the reasoning for the 2.5 sec delay. Apparently you experimented without that in 2.8.0.4. which led to that some commands were skipped because it was too fast to simulate the spoken command. And by pressing the mutekey that was not a problem because that way simulating a spoken command was not necessary. Just wild guessing... 🙂

 

But I wonder, isn't it possible to take the scripted commands as such - without the detour of simulating a spoken command? It seems to me 2.8.0.4 did something like that. I understand that then it probably wouldn't be possible to give additional verbal commands while the scripted commands are executed, but I would be fine with that. Many of my longer scripts include some pauses so I could give necessary commands then. And the shorter scripts would be completed within a few seconds, so it wouldn't be a problem.

Maybe optional for every script, like "verbose=1", something like "scripted execution=1".

 

There is a reason for that.

If you handle scripted flows commands directly, you'll have to do a lot of text parsing and eventually tell users they have to write commands in this exact manner and you could mix-up commands that are very similar, never mid the fact you wouldn't allow any variations or let users write custom commands acting as aliases for existing commands, for natural speech.

You also need to have duplicate code paths doing the same thing.

Speech engine returns what speech was recognized, but more importantly tells you this speech matches rule XX MCE has defined.

You then know which item the command relates to without needing to wade through all the possible speech variations.

There is still room for improvement.

V2.8.0.4 was flawed because it favored speed over reliability.

It would typically send commands and if for some reason a simulated command takes much longer time than expected, it would eventually skip all the next commands.

You run the same flow at a different time and it may go without a hitch.

V2.8.0.5 is robust now. Just need to see how far we can push it.

If you go to the <Edit script commands" panel in the UI and press "Test" for each individual command, you'll notice there is almost no delay. Whereas before, it could take 1 to 3 seconds (and sometimes more) for the command to be acknowledged by speech engine.

 

 

[RALF9636 1,920]

Ok, I'm starting to see the genius behind all that... 😉

So I guess when you manage to execute the voxscript commands and those opening a 2D panel at the same speed as the others, everything will be fine.

Edited September 19, 2019 by RALF9636

[FS++ 707]

17 hours ago, RALF9636 said:

Ok, I'm starting to see the genius behind all that... 😉

So I guess when you manage to execute the voxscript commands and those opening a 2D panel at the same speed as the others, everything will be fine.

The automatic opening/closing of 2D panels happens in the "mcfslA3X.dll" running inside Prepar3D.exe process.

It adds a level of complexity as MCE needs to give it enough time before it assumes item has been clicked.

Luckily, most items are handled directly in VC and the few that require 2D panel are only touched at the beginning (preparation) of the end of flight.

[RALF9636 1,920]

A couple more flights with 2.8.0.5.

I confirm it is a very stable and reliable version. Voice recognition rate seems further improved, flows are executed reliably, no more hangs or degradation of the execution speed over time.

The only issue left is that voxkey commands and some 2D panel commands in the flow are executed siginficantly slower than other commands. There is a pause of sometimes more than 5 seconds before and after a voxkey command.

So, to get back to my original post: A reset / restart option is obsolete now.

Edited September 27, 2019 by RALF9636

[FS++ 707]

3 hours ago, RALF9636 said:

A couple more flights with 2.8.0.5.

I confirm it is a very stable and reliable version. Voice recognition rate seems further improved, flows are executed reliably, no more hangs or degradation of the execution speed over time.

The only issue left is that voxkey commands and some 2D panel commands in the flow are executed siginficantly slower than other commands. There is a pause of sometimes more than 5 seconds before and after a voxkey command.

So, to get back to my original post: A reset / restart option is obsolete now.

Roger that.

Regarding Voxkey.

Are they occasional key combinations sent to the sim, with single shot, with the next one being more than a second away, or multiple key presses required in a short succession (repetitive keys)?

 

[RALF9636 1,920]

I use both.

Multiple voxkey commands in a row or before/after a 2D panel command are the main problem. With single voxkey commands the delay is not so significant.

[FS++ 707]

3 hours ago, RALF9636 said:

I use both.

Multiple voxkey commands in a row or before/after a 2D panel command are the main problem. With single voxkey commands the delay is not so significant.

You may want to read this thread and see if adjusting the [PACE] value in mce.ini makes any difference

 

[fyase 2]

Hi Gerald,

on my RIG even with the last version I found some slo down. Performing this flow:

[SCRIPT]
parking brake on
slats retract
spoilers down
battery on
Notify=cockpit to ground
cockpit to ground
Pause=4
Notify=ground connect ground power
ground connect ground power
Pause=3
ground power on
Notify=standby for systems to power up
Pause=80
system display clear
check fire detection
Pause=5

 

There was a very long, more the 10 seconds, when performing each of this two commands

I dind't try in deep on a complete flight beacuse I running out of time. I'll try again soom and report back.

Raffaele