Tests of v. 2.7.90, VoxKey issues and actions

[goggi 9]

I tested the new MCE (v.2.7.90) with my PMDG B737NGX. Apparently there were timing issues, with the program seeming very slow at times. However.

I realised, after several tests, that there were issues with VoxKey. Some commands did not work, others did. I inspected the key allocations and modified some of them. Strange enough, the situation worsened over a few test cycles. In the end none of them, particularly those painfully tuned for repetitions in order to control the timing issues, seemed to work anymore. However.

The same commands, when issued manually by keypresses, were recognised and executed (i.e. manually pressing the  corresponding keys worked just fine). In deleting VoxKey commands and re-creating them I realised that the command name field was automatically rewritten as “GamePath”. Ha ha. Re-modifying them seems to cure the problem, but something fishy is going on under the VoxKey hood. In my last test this problem spread to all Voxkey commands. Maybe the overwriting of the commands name happens automatically somwhere.
As far as I am concerned, solving this issue this is preliminary to addressing the overall timing issues, or improvements, of v. 2.7.90.

Let me now mention two issues with the FO (showing since previous versions, but not worth a specific request for mods at the time):

1- When climbing, the FO does NOT announce  “about to cross ten thousand”, which - on the contrary - works fine when descending through 10000’ (very useful).

2- When requested to “Set altimeter to standard”, one of the FO replies is “Setting altimeter to 29.92 inches”, even when the baro setting is 1013. In several countries outside US (e.g. Europe) the units are hPa. The simplest solution would be to delete just this one reply (the other reply “Switching the barometer to standard setting” being clearly OK and sufficient).

Thank you, as usual; MCE is more and more a must have!
Regards,
Giorgio
 

Edited March 13, 2019 by goggi

[FS++ 708]

On 3/13/2019 at 1:40 PM, goggi said:

I tested the new MCE (v.2.7.90) with my PMDG B737NGX. Apparently there were timing issues, with the program seeming very slow at times. However.

I realised, after several tests, that there were issues with VoxKey. Some commands did not work, others did. I inspected the key allocations and modified some of them. Strange enough, the situation worsened over a few test cycles. In the end none of them, particularly those painfully tuned for repetitions in order to control the timing issues, seemed to work anymore. However.

The same commands, when issued manually by keypresses, were recognised and executed (i.e. manually pressing the  corresponding keys worked just fine). In deleting VoxKey commands and re-creating them I realised that the command name field was automatically rewritten as “GamePath”. Ha ha. Re-modifying them seems to cure the problem, but something fishy is going on under the VoxKey hood. In my last test this problem spread to all Voxkey commands. Maybe the overwriting of the commands name happens automatically somwhere.
As far as I am concerned, solving this issue this is preliminary to addressing the overall timing issues, or improvements, of v. 2.7.90.

Let me now mention two issues with the FO (showing since previous versions, but not worth a specific request for mods at the time):

1- When climbing, the FO does NOT announce  “about to cross ten thousand”, which - on the contrary - works fine when descending through 10000’ (very useful).

2- When requested to “Set altimeter to standard”, one of the FO replies is “Setting altimeter to 29.92 inches”, even when the baro setting is 1013. In several countries outside US (e.g. Europe) the units are hPa. The simplest solution would be to delete just this one reply (the other reply “Switching the barometer to standard setting” being clearly OK and sufficient).

Thank you, as usual; MCE is more and more a must have!
Regards,
Giorgio
 

Regarding Voxkey.

Be aware, if you're using a custom profile and not adding commands to "Prepar3D Demo.vkp" existing profile, MCE might end-up loading the latter rather than your own. It happens when the custom profile file name is alphabetically behind "P" (For Prepar3D).

Therfore, if no command is working, either delete the Demo profile, or add your custom commands to it.

[goggi 9]

Thanks for your suggestion about the VoxKey profiles. That was indeed causing the problem. Using the “P3D Demo” file is fine.

I found some hidden conflicts when assigning some keys in VoxKey (hidden: assigned neither in P3D nor in the PMDG FMC, but nevertheless not being executed by VoxKey). After changing key assignments repeatedly, all seems finally to work, although the reason remains unknown.

The new 200ms timing (as posted by you about a week ago) works very well in general scripts and in connection with VoxKey, but for one general case: commands to/via another program (ChasePlane) to switch views are correctly executed by setting “Execute = 2 times”. “Execute=1” is mostly fine, but not always. So, the delays can be critical.

I would like to experiment with different delays: can you please indicate where in the MCE.ini file is this value set (I could not find it)?

Thanks,
Giorgio

[FS++ 708]

5 hours ago, goggi said:

I would like to experiment with different delays: can you please indicate where in the MCE.ini file is this value set (I could not find it)?

Thanks,
Giorgio

Open "mce.ini" and add this line to [PACE] section

VoxKeyAction=whatever_amount_in_,milliseconds     (1 or higher)

When option is missing it defaults to

VoxKeyAction=200

 

[goggi 9]

Thanks, I'll investigate and keep you posted.

In the meantime, please remember -when possible- the suggestions I posted on 3/13/2019 (see above) concerning:
- "about to cross ten thousand" in climb (missing), and
- "setting altimeter to 29.92 inches" (delete)

Thanks a lot !
Giorgio

[goggi 9]

Hello FS++ Team,
VoxKey is a fantastic tool. It interfaces MCE to any program in the sim suite accepting keyboard entries. It also allows, together with MCE, to develop powerful key sequences. The diversity of the add-on programs, however, presents difficulties, due to their inner workings and different delays. Maybe one additional specification in the MCE .ini file can help addressing the whole issue once for all.

The issue: I have been trying to interface MCE, through VoxKey commands (single or in sequence), to: P3Dv4, PMDG NGX (via FMC), ChasePlane and GSX-2. In most cases, all is fine. In some cases, however, the VoxKey “virtual keypress” recognition is marginal or insufficient. Repeating the same command (e.g. by voice) helps, but not always. However, pressing the very same keys MANUALLY works ALWAYS fine.
So, VoxKey commands to be interpreted by another program are not always captured (and do not get executed).  In the end, there must be a delicate timing issue.

Tests: I made tests (over months!) (i) bracketing the command by different Pause lengths, and/or (ii) using different VoxKey internal repetitions (Execute “n” times). These attempts can alleviate the problem, but cannot be used effectively with commands having a toggle effect. Not a real solution (see also the Note below).
Then, following your advice, I played with the VoxKeyAction parameter, in the range from 100ms to 1800ms. Above about 200ms everything behaves consistently, but the core of the issue does not change. No real improvement.
All this, including the manual keypress crosschecks, shows that what should be controlled in VoxKey is not the overall delay between commands, but (probably) the duration of each “virtual keypress”.

Proposal: if such a parameter would be made available in the MCE.ini file, one could try to optimise the VoxKey command duration towards its capture and execution by other sim add-ons.

Thank you very much for your continuing help,
Giorgio

NOTE: The situation is particularly complex with GSX-2, which has a number of nested menus, some with default choices, having different latencies. This requires several VoxKey “virtual keystrokes” to be carefully timed in sequence, on top of the issue described above. A nightmare.