The order of radio events

[some1]

Hello Pete,

during testing of A2A C172 we have found that there is a potential issue with how FSUIPC processes radio events.

Basically, the sequence of events like this:
NAV1_RADIO_SWAP
NAV1_RADIO_WHOLE_DEC
NAV1_RADIO_SWAP

is transmitted to FSX in this order:
NAV1_RADIO_WHOLE_DEC
NAV1_RADIO_SWAP
NAV1_RADIO_SWAP

NAV1 is just an example, it happens with all radios (COM, NAV, ADF).
We need to send such sequence because the radios in C172 have an "active entry" function, which allows you to tune the active frequency directly, even though the radio has both active and standby.

Because this issue happens only with the full FSUIPC version, I suspect it is a "feature", but I can't find anything in the configuration to turn it off. Can you advise how the FSUIPC should be configured to restore the original events order?

best regards
Mike Krawczyk
A2A Simulations.

[Pete Dowson]

during testing of A2A C172 we have found that there is a potential issue with how FSUIPC processes radio events.

 

Sorry, but FSUIPC doesn't "process radio events". If you send events to FS they go to FS. The only time FSUIPC sees them is for logging purposes. FSUIPC is not involved at all apart from the logging, if enabled, and there is certainly no way it can re-order any events as it has no memory for them.

 

Pete

[some1]

Unfortunately this is not the case here.

 

A simple three lines of code in the aircraft's c++ gauge like this:

 

trigger_key_event(KEY_COM_RADIO_SWAP, 0);
trigger_key_event(KEY_COM_RADIO_WHOLE_INC, 0);
trigger_key_event(KEY_COM_RADIO_SWAP, 0);

 

will send the events to FSX in the correct order only if FSUIPC works in the unregistered mode. When I put my FSUIPC key file, then the events get reordered as I described previously. This is reflected in FSUIPC event log.

 

What's interesting, is that when I send events using Simconnect calls instead of C Gauge API, then it works fine.

[Gypsy Baron]

I can confirm the above observations vis-a-vis the registered vs unregistered behavior.

 

The radio 'direct tuning' works properly when the FSUIPC4 key file is removed, making it an unregistered version.

 

With the key file present, the radio 'direct tuning' feature does not work. Checking the above situations by logging

confirms the reordering of the KEY events.

 

   Paul

[Pete Dowson]

Unfortunately this is not the case here.

 

A simple three lines of code in the aircraft's c++ gauge like this:

 

trigger_key_event(KEY_COM_RADIO_SWAP, 0);
trigger_key_event(KEY_COM_RADIO_WHOLE_INC, 0);
trigger_key_event(KEY_COM_RADIO_SWAP, 0);

 

will send the events to FSX in the correct order only if FSUIPC works in the unregistered mode. When I put my FSUIPC key file, then the events get reordered as I described previously. This is reflected in FSUIPC event log.

 

What's interesting, is that when I send events using Simconnect calls instead of C Gauge API, then it works fine.

 

 

Aha!  Yes, sorry, I see now.

 

It must be due to the addition of those Radio events which can be followed by a KEY_SELECT event in order to determine which radio is being addressed.  This applies to these events:

 

    KEY_NAV_RADIO, KEY_COM_RADIO, KEY_FREQUENCY_SWAP,

    KEY_XPNDR, KEY_VOR_OBS, KEY_ADF, KEY_DME, KEY_JET_STARTER,

    KEY_COM_STBY_RADIO_SWAP, ,

    KEY_NAV1_RADIO_SWAP, KEY_NAV2_RADIO_SWAP,

    KEY_ADF1_RADIO_SWAP, KEY_ADF2_RADIO_SWAP

 

The event is batched with the SELECT and sent to SimConnect using the Macro facility ("macro begin" and "macro end"). Of course this can only be done if FSUIPC holds over the main event for a short time to see if a KEY_SELECT occurs.

 

This is the facility in FSUIPC to prevent those add-on panels which constantly send events to FS from stopping these select actions operating correctly. It's actually an option in the Miscellaneous tab in FSUIPC. It defaults to 4 seconds. You could try setting it to zero. It's saved as the "TimeForSelect" parameter in the INI file.

 

The radio stuff was added to this facility when a user pointed out that the facility was not working correctly on these events -- version 4.91, August this year.

 

Sorry that this action didn't occur to me earlier. A SimConnect log would have shown the macro facility being used here.

 

Regards

Pete

[some1]

Pete, sorry for the late response. I tried your suggestion, but this fix does not work. Anyway, since I learned that simconnect events are not affected by this issue, I will use them to tune radios instead of Panel API.

[Pete Dowson]

Pete, sorry for the late response. I tried your suggestion, but this fix does not work.

 

Probably because the events are still "hooked". I would have to change the code to not hook any of those events if the time is set to 0. I could consider that for a future update.

 

Anyway, since I learned that simconnect events are not affected by this issue, I will use them to tune radios instead of Panel API.

 

Well, you are probably sending the events at the same priority level as FSUIPC sends them, so not hookable by FSUIPC.

 

If you are happy going this, it is excellent, because a lot of folks do depend on FSUIPC's "time for select" option on some add-on aircraft, and it isn't easy to make this action aircraft or profile specific because of all the unhooking and re-hooking required.

 

Regards

Pete

[Adrijan]

Is there any workaround at all, besides of course disabling FSUIPC? 
It's also starting to bother me a lot, as I have discovered the A2A C172 direct tuning feature :P 

Thanks in advance. 

[Pete Dowson]

Is there any workaround at all, besides of course disabling FSUIPC?

 

Apart from the solution using SimConnect events as stated above, you mean?

 

If this is important then I can disable the entire "TimeforSelect" facility when the value is set to 0. but I can only do this when FSUIPC is first started -- so it won't be changeable in the Options. I can do this in an update tomorrow if you need it.

 

Pete

[Adrijan]

I'm sorry for asking this but, how can I make it use SimConnect events instead of FSUIPC? 

[Pete Dowson]

I'm sorry for asking this but, how can I make it use SimConnect events instead of FSUIPC? 

 

If you are not the programmer of "it", you can't. Sorry, but you appeared to have injected your request into a thread started by and 'solved' (potentially) by a developer. If your question is not related to the original one where a solution was already proposed by the OP, then see the part of my answer about an update to FSUIPC instead. Perhaps you'd like to consider that and answer it instead?

 

Regards

Pete

[Adrijan]

Erm okay, thank you for the answer. I guess an update would be fine too, but is it possible to not get rid of the function for doors/engine/pushback/etc selection (in seconds)? 
I "injected" my request as this is the topic I found and the guy had exact same problems as I did, thought it would be fine :)

Regards

[Pete Dowson]

Erm okay, thank you for the answer. I guess an update would be fine too, but is it possible to not get rid of the function for doors/engine/pushback/etc selection (in seconds)?

 

If I can, I will. I'll take a look.

 

Pete

[Pete Dowson]

.... but is it possible to not get rid of the function for doors/engine/pushback/etc selection (in seconds)?

 

Okay. All done. Download FSUIPC4921g

 

The instructions for TimeForSelect options are explained in the Changes document included in the ZIP. Please confirm it solves your problem, as I've no affected add-on to test it with here.

 

Regards

Pete

[Gypsy Baron]

Hello, Pete,

I just installed 4921g and changed the entry in the ini file:

//TimeForSelect=4

TimeForSelect=0

But, as soon as I do a 'Reload all buttons' operation the ini file reverts back to the default value.

//TimeForSelect=4

TimeForSelect=4

On further investigation I find:

If I make the ini change and then start FSX the change does work as intended. I can tune the

A2A C172 Nav radio Primary channel when that mode is selected. But, as soon as I reload the ini file,

say whenmaking a change to asdsignments, etc during testing, the ini file entry reverts to the

default value of '4'. This is undesirable. None of the other options that I have changed from

default in the ini file are reverting to default. Only this new option.

Paul

[Pete Dowson]

If I make the ini change and then start FSX the change does work as intended. I can tune the

A2A C172 Nav radio Primary channel when that mode is selected. But, as soon as I reload the ini file,

say whenmaking a change to asdsignments, etc during testing, the ini file entry reverts to the

default value of '4'. This is undesirable. None of the other options that I have changed from

default in the ini file are reverting to default. Only this new option.

 

Hmm. Very odd. The "reload" function does not read nor write any of the [General] section parameters, it is only concerned with the section of the INI which relates to the options tab in which you are operating the button. Additionally, there is no retention of '4' as the default value once it is changed in memory, so that's even odder.

 

Can you therefore be more specific. Which particular 'reload' are you pressing. Each attends to its own area.

 

I'll investigate this later. Gotta go just now ...

 

Pete

[Gypsy Baron]

Hummm, now this is very strange. That value is staying set now. I have no explanation as to

why it was reverting before but it definitely was. I would open FSUIPC and got to the

Buttons + Switched tab and simply hit the 'Reload all buttons' option, then 'OK'.

The tuning function stopped working and when I opened the ini file again, the entry

had changed. I did this several times.

It appears to be working just fine now.

EDIT: OK, I can reproduce the behavior. It seems that the first time I changed the parameter was

after I was already in FSX. I opened the INI file, changed the entry, saved the file and

then hit the 'Reload all buttons' option, then 'OK'. This is what I do when changing

button/switch assignments when testing or creating my 'aircraft specific' settings.

For those operations, the new data is entered and retained in the appropriate section.

I don't recall having had the need to change an entry in the "General" section while

running FSX before so I never encountered this behavior.

It would seem that when the ini file is re-written when FSX is running, the "General" section

is retained as it existed at the start of FSX. I just closed FSX, changed the parameter,

started FSX and then checked that the 'fix' worked. I reverted the value back to '4' while in

FSX, reloaded Buttons + Switches and saw that the previous value of '0' was retained.

So, it all comes down to when the value in the ini is actually changed. It must be prior to

starting FSX.

So, all is well and I learned something. :)

Paul

[Pete Dowson]

I don't recall having had the need to change an entry in the "General" section while

running FSX before so I never encountered this behavior.

 

Aha! The [General] section is not re-read at all, and you cannot make permanent changes there whilst FS is running. The only "dynamic" sections are those which can be reloaded -- Profiles, Buttons, Keys, JoystickCalibration and Axes.

 

So, it all comes down to when the value in the ini is actually changed. It must be prior to

starting FSX.

 

Yes. And especially for this type of parameter because it controls the way FSUIPC initialises everything -- the value determines whether certain FS events are intercepted ("hooked"), and this interception is only set once, at the beginning.

 

Regards

Pete

[Adrijan]

Okay. All done. Download FSUIPC4921g

 

The instructions for TimeForSelect options are explained in the Changes document included in the ZIP. Please confirm it solves your problem, as I've no affected add-on to test it with here.

 

Regards

Pete

I applied the update, and it doesn't seem to work. With value set to 4 or 0, I can't get "direct tuning" to work in the A2A cessna. 

[Adrijan]

Actually, I apologize for not reading the previous replies. It does work when I set it before starting FS, through the .ini file. But, the problem is that now doors, pushback, etc don't work (as they should). Any workaround for this now?

Thanks,
Adrijan

[Pete Dowson]

Actually, I apologize for not reading the previous replies. It does work when I set it before starting FS, through the .ini file. But, the problem is that now doors, pushback, etc don't work (as they should). Any workaround for this now?

 

Didn't you try setting -4, as documented?

 

Pete

[Adrijan]

Once again I apologize for not reading the document. -4 works flawlessly, thanks a lot! 

[some1]

Thank you Pete for the quick hotfix. I also changed it on our side, so the next update to C172 will remove this issue completely. 

[Schaefer]

I have just tried to download the FSUIPC4921g but am being apparently blocked  by my antivirus program (AVG). I am speculating as to whether this is a side effect of the new IE11 version released last week.

 

Would anybody have any insight in this as this is the first time I have experienced this type of problem?

 

Thanks in advance for your help.

 

Schaefer

[Pete Dowson]

I have just tried to download the FSUIPC4921g but am being apparently blocked  by my antivirus program (AVG).

 

I've never known AVG to have a false positive virus detection on any ZIP file of mine, but you need to report it, and in any case override it.

 

The current Installer in Download Links subforum is for 4.921f, and there's a 4.921i update also there. Have you tried either of those? As soon as I've done the changes for Prepar3D V2 these will be replaced by 4.923 -- certainly by the weekend.

 

Regards

Pete