Disappearing "Add-On" Box

[RichardL]

Hi Pete,

Do you have any updated information on why the Add-On box might disappear from the menu bar?

I've searched the forum and read all the posts I can find. To my understanding this problem belongs to Microsoft and is a SimConnect issue?

Why I ask is I cannot complete a flight without the Add-On box disappearing. As you know, when it disappears I loose control of all the functions programmed in FSUIPC such as yoke, throttles, rudder pedals, etc.

Now, I just phoned MS tech support and the person I talked to said this issue has not been reported to MS. Additionally, since the Add-On box is not part of FSX, I should be talking to you. Somehow I knew that would be the response I would get from MS.

So, I now plan to "email" MS tech support but I need to be clear on what I should report.

Regards,

Richard

[Pete Dowson]

Do you have any updated information on why the Add-On box might disappear from the menu bar?

No, none at all. No one has even been able to supply a log yet.

I've searched the forum and read all the posts I can find. To my understanding this problem belongs to Microsoft and is a SimConnect issue?

There are lots of issues with it never appearing, or appearing on some sessions but not others, but how many references did you find to it actually "disappearing"?

FSUIPC4 (or any other SimConnect add-on for that matter) doesn't control the Menu entries at all. SimConnect supports a request for a Menu entry to be created. SimConnect itself adds the Add-ons menu, and then places the requested entry within that. I think there's a limit of 16 that it copes with.

FSUIPC4 like any other add-on would only ask for the menu to be added once, during initialisation. How it then can disappear I really don't know. It sounds like some sort of menu maintenance bug in SimConnect.

Why I ask is I cannot complete a flight without the Add-On box disappearing. As you know, when it disappears I loose control of all the functions programmed in FSUIPC such as yoke, throttles, rudder pedals, etc.

Ahso you are saying it is NOT a problem with the menu, the problem is that SimConnect itself, or possibly FSUIPC4, actually stop working? LEt me search back on your messages.

...

Ah, is this in connection with the GFConfg program? That's the only other reference I can find to such a problem, here from Nov 4th:

I thought I'd let you know about a GoFlight error affecting FSUIPC4, I think.

First, I have not had this problem until I installed the new GFConfig 1.70.

Something, I think the new GFConfig, is causing the Add-On drop down in FSX to disapear, thereby affecting FSUIPC4 and FSX.

Twice now, while doing an approach, I loose all controls programmed in FSUIPC4. In this case, flight controls. I could not understand why I could not control the aircraft. Nothing worked.

That thread seemed to get nowhere after I asked you to "report it to Microsoft via tell_fs@microsoft.com with as much information as possible."

I don't think MS tech support can help with FSX bugs in that sort of detail. "tell_fs" is the best reporting mechanism.

As far as reported here at least this is a problem unique to your setup. Did you compare notes with others also using GF, such as 'spotlope' who did say in the same thread:

We should compare notes, Richard. I'm using GFConfig 1.70 with FSUIPC 4 (latest build) and am not having any problems. Seems like if we've got one working system and one with problems, we might be able to draw some conclusions.

Is it still happening ONLY with the GF stuff running too? Does the GF software have an Add-Ons menu entry?

Maybe, if it is happening so consistently, as you say, then we can get some really good information on it to pass to MS. Best to produce a SimConnect log so I can see what is happening, and I'll report it direct as well.

To do this create a file containing these lines:

[simConnect]

level=Verbose

console=No

file=\Modules\SimConnect%01u.Log

file_max_index=9

and save it as Simconnect.ini in your "My Documents\flight simulator X files" folder. Then, keeping things a short as possible, reproduce the problem. close FSX, Zip up both the Simconnect log and the FSUIPC4.LOG and send them to me at petedowson@btconnect.com.

Note also that there has been a problem identified with Multipayer -- if an MP mode is entered, SimConnect stops sending data to FSUIPC4. The Add-Ons menu continues though, and other things work. I programmed a work-around for that, which involved closing and re-initialising the SimConnect interface if I saw no data updates for 2 seconds or more. That's in the current release (4.04). It may not help in your case as it still depends upon getting Events from Simconnect, which in the MP case certainly do still arrive.

If you can please look in the FSX Modules folder next time your problem happens, but AFTER closing down FSX. Check the FSUIPC4.Log file. See if it terminates properly (i.e. says Log closed or whatever rather than simply trails off). If the Log closes okay, then FSUIPC4 was still running.

If FSUIPC4 is still running, then that suggests another work-around for now (you still need to report the problem). Maybe I should have a normal timer watchdog too -- and close/reopen SimConnect if I see no events at all for several seconds.

Regards

Pete

[RichardL]

Hi Pete,

Ok. Let me work on getting you some log info.

The reference I made to GoFlight may be just a coincidence. From what I recall, the disappearing add-on box issue did not start until I installed GFConfig 1.70. I do have GFConfig update 1.71 installed but no improvements. GF did not comment when I emailed them about the Add-on box disappearing after installing GFC. So either they don't care, it's not related or ..... Either way I do not know if they are looking into the issue or not. I will ask GF again.

Regards,

Richard

[Pete Dowson]

Ok. Let me work on getting you some log info.

Okay .. what about the other questions & suggestions?

The reference I made to GoFlight may be just a coincidence. From what I recall, the disappearing add-on box issue did not start until I installed GFConfig 1.70.

But the Goflight driver is also a SimConnect client, albeit an external one I assume. Does IT stop working at the same time as FSUIPC4? Does it have a menu entry in Add-Ons?

Seems odd that so far at least there's only you with this problem. We need to find out why, what makes your setup so unique.

Regards

Pete

[Pete Dowson]

Ok. Let me work on getting you some log info.

You sent me some good logs illustrating the problem with the disappearing menu (and FSUIPC4 operations thereby stopping). You said:

It seems, at least at this point, that the Add-On box is disappearing just after landing. Not sure why.

I have tried three flights. The first one was almost and hour which made a SimConnect log file of 43mb. I did shorter flight and noticed that the Add-On box again disappeared just after landing. The attached log files are from a third flight specifically to see if the box would disappear after landing. Which it did.

Let me know if you need to see more log file.

I don't think I need any more logs, thank you. Those illustrate it well enough. In the SimConnect log, which is mostly full of GoFlight stuff initially, then a reasonable mixture of GF and FSUIPC4 traffic (the lines with #62 are GF, #63 FSUIPC4), the thing that killed the FSUIPC4 connection occurs in the 1215th second:

1215.99501 [63] I/O Error!

How the hell SimConnect can experience an I/O error when everything is happening in the one machine with no actual I/O involved I've no idea, but it evidently can and it appears it have no recovery built in as it never again talks to FSUIPC4.

I am wondering if it is something simple like running out of TCP/IP buffers of somethnig stupid like that. I am really hating the methods Simconnect uses more and more with each passing day!

There's not a lot I can do except to detect a number of seconds with no Events arriving and re-initialise the Simconnect link. That would be my 'recovery'. I'll put that into the next Interim FSUIPC4 version, which I'll be posting in the Announcement above within the next day or two. Please try it and let me know.

There's also one interesting result I can see in the log which needs a little adjustment from me. You appear to have jittery Rudder pedals/brakes, and FSUIPC4 is sending loads of rudder events to SimConnect. It starts doing this quite early, and in fact BEFORE those events are registered with SimConnect. This is a result of my delayed Simconnect initialisation (to avoid FSX crashes when two clients try to initialise Simconnect together). That results in these errors initially:

> 39.32469 [63, 30]TransmitClientEvent:ObjectID=0, EventID=66387, dwData=-8192, GroupID=2, Flags=0

< 39.32474 [63] >>>>> EXCEPTION=1, SendID=30, Index=2 <<<<<

> 39.32507 [63, 31]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-8356, GroupID=2, Flags=0

< 39.32510 [63] >>>>> EXCEPTION=1, SendID=31, Index=2 <<<<<

> 39.32657 [63, 32]TransmitClientEvent:ObjectID=0, EventID=65764, dwData=256, GroupID=2, Flags=0

< 39.32661 [63] >>>>> EXCEPTION=1, SendID=32, Index=2 <<<<<

66387 and 66388 are left and right toe brakes, 65764 is the rudder. If you aren't shuffling you feet on those whilst FS is loading up then it seems they aren't calibrated well with a decent centre "null zone" to avoid jitter.

Anyway, I'll tidy up FSUIPC4 so it doesn't send these events on until it knows they've been registered. Thatt'll be in the interim version too.

I'll send the details of this "I/O Error" directly to my MS contacts. Perhaps you could make a detailed report, including the Simconnect log (the other logs won't be of interest to them) and send it to tell_fs@microsoft.com too, please.

Regards

Pete

[RichardL]

Hi Pete,

Just to clarify my setup so you have all the details:

Server: FSX, GoFlight GFConfig, GoFlight GFKeys, pmSounds.

Client 1: pmRJ, GoFlight GFRemote, ActiveSky6.5, Integrated Flight Systems FSCockpit.

Not all programs were running for the .log test. I wanted to be sure the problem existed with the minimum of programs operating.

As to the rudder pedals, I use CH Pro Pedals. They are assigned and calibrated with FSUIPC. Any fine tuning will be most appreciated.

Another email is on it's way to tell_fs.

Regards,

Richard

[Pete Dowson]

As to the rudder pedals, I use CH Pro Pedals. They are assigned and calibrated with FSUIPC. Any fine tuning will be most appreciated.

I think you misunderstood me there. You need to do "fine tuning" on your calibrations -- a larger null zone is needed to stop the constant jitter seem on all three axes (rudder and both brakes). The central "null zone" for the rudder is determined by the central two numbers in the calibration -- you need to move the pedals slightly one side and the other of centre to set two separate values there, far enough apart so jitter is eliminated. Similarly depress the brakes slightly before setting the brakes off position. Usually it's a good idea to depress them quite a way to avoid accidental application.

My adjustment in FSUIPC is merely to avoid sending Events to SimConnect before those Event numbers have been established. It doesn't affect anything except the logging of spurious errors in the Log.

I'm testing changes to FSUIPC4 now to try to recover from an erroneous SimConnect disconnection, but whilst it suffers from such weird errors there'll be some problems. I will try to recover exactly where it left off, after 5 seconds or so of non-communication, but data like the whereabouts of all the AI may be wrong for a while after that.

Regards

Pete

[RichardL]

Ok, I get what you mean. I believe right now both center values are identical. I'll get that corrected.

Regards,

Richard

[RichardL]

Pete,

Thought I'd update you on the vanishing Add-On box in the menu bar.

So far it has not vanished again. I'm using FSUIPC 4.06. If you addded the routine to re-establish a connection if dropped, it appears to have fixed the problem.

Regards,

Richard

[Pete Dowson]

So far it has not vanished again. I'm using FSUIPC 4.06. If you addded the routine to re-establish a connection if dropped, it appears to have fixed the problem.

I did add that -- check the FSUIPC4 log, it will say if it recovered.

Regards

Pete

[BoHappy]

hi Pete

i think i know what the problem is with vanishing add-on menu in fsx

it occurred to me as well after i installed fsuipc ver 4.04

apperently it writes the following to the dll.xml (located in C:\Documents and Settings\user name\Application Data\Microsoft\FSX)

FSUIPC 4

False

Modules\FSUIPC4.dll

but it is missing this

FSUIPC 4

False

Modules\FSUIPC4.dll

i was having problems with add ons for me but someone figured this out for me - hope this helps other people

Bo

[Pete Dowson]

it occurred to me as well after i installed fsuipc ver 4.04

apperently it writes the following to the dll.xml (located in C:\Documents and Settings\user name\Application Data\Microsoft\FSX)

FSUIPC 4

False

Modules\FSUIPC4.dll

but it is missing this

FSUIPC 4

False

Modules\FSUIPC4.dll

No version of the FSUIPC4 Installer has ever omitted any part of the complete section needed. I don't know how your file got corrupted like that, but if you think you can reproduce it, would you mind kindly sending me the original DLL.XML file which you start with, before installing FSUIPC4, so I can see what is happening?

Did you install anything AFTER FSUIPC4 which may have changed the file?

The Installer, if it finds no DLL.XML file at all, writes the whole thing. If it finds a DLL.XML file but no mention of FSUIPC4, it adds its complete section -- and ALWAYS includes all the lines necessary.

What it doesn't do is check all the lines are correct from a previous installation, so that's probably something I can improve upon. I may do that for the next release.

Thanks,

Pete

[BoHappy]

Pete

i am sorry, i did not mean to imply or accuse that fsuipc did this to my dll.xml file - as per my memory recollection this occurred to me after installing fsiuipc, but i could be totally wrong which appears to be the case.

here is the original dll.xml file before correction

<?xml version="1.0" encoding="Windows-1252"?>

Launch

dll.xml

False

False

FSDiscover!

False

False

C:\Program Files\FSDiscover!\FSDiscoverFSX.dll

Object Placement Tool

True

False

..\Microsoft Flight Simulator X SDK\SDK\Mission Creation Kit\object_placement.dll

AbacusCatapult

False

AbacusCatapultFSX.dll

Traffic Toolbox

True

False

..\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Traffic Toolbox SDK\traffictoolbox.dll

Visual Effects Tool

True

False

..\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Special Effects SDK\visualfxtool.dll

FSUIPC 4

False

Modules\FSUIPC4.dll

Traffic Toolbox

False

False

MyTraffic\traffictoolbox.dll

thanks for all of your great work and contribution to fs community

Bo

[Pete Dowson]

Looking at the end of that file:

FSUIPC 4

False

Modules\FSUIPC4.dll

Traffic Toolbox

False

False

MyTraffic\traffictoolbox.dll

This shows that the last amendment was, in fact, the addition of the MyTraffic version of the traffictoolbox -- FSUIPC4 currently always adds itself to the very end, just before the " terminator.

The question therefore arises -- how was the MyTraffic part added. When I bought and installed MyTrafficX I had to edit the DLL.XML myself -- does it now come with an installer which does this? If so, then please send a report to the MyStraffic support for Mr. Renk to attend to, as that needs fixing.

If on the other hand, you had to edit yourself, then possibly you made a small error?

I have changed the FSUIPC4 Installer to do this:

1. Create a completely new DLL.XML, placing its own entry first.

2. Copy any other entries (except its own) from the original DLL.XML, keeping the same order.

This will, I hope automatically correct the sort of problem you found when re-installing FSUIPC4.

Regards

Pete

[BoHappy]

Pete

you are absolutely correct!

i did in fact had to edit after i installed mytraffic and i totally forgot about it

i backed up the file prior to doing this and when i looked at it there was fsuipc and the end with correct phraseology

my fault, i sure do apologize

best regards

Bo

[RichardL]

Hi Pete,

I received an email from an individual named Piyali Jana at Microsoft. Maybe you know who he (?) is.

He stated that he had went through the simconnect.log file, which you suggested I send. He was not able to duplicate the disappearing add-on box problem without GFDevFSX.exe and asked if I would send him a copy.

While it is encouraging that Microsoft is looking at the problem, I suggested he contact GoFlight, Inc. directly.

Regards,

Richard

[Pete Dowson]

I received an email from an individual named Piyali Jana at Microsoft. Maybe you know who he (?) is.

Yes, I know of Piyali. He does testing for the team in this area.

He stated that he had went through the simconnect.log file, which you suggested I send. He was not able to duplicate the disappearing add-on box problem without GFDevFSX.exe and asked if I would send him a copy.

The loss of one or other SimConnect client after an logged "I/O Error" in SimConnect appears to be quite common with multiple clients on some folks' systems, but impossible to reproduce on others. I have FSX now installed on 5 PCs -- an Intel 3.0 GHz, Athlon 4000+, FX-57, FX-62, and Inte x6800, and I've not been able to make it happen once no matter how much I load them up, even on the slowest, whilst on some other folks systems it fails as easy as anything.

I hope that there are enough inputs through Tell_FS to encourange Piyali or others in the team to try harder. I find it rather disappointing that it has taken several months from the first such reports before they even ask for more help in these matters. I had been hoping for some update fixing many of these things this month, but it doesn't look likely if this is an indication of how far they've come so far. :-(

Regards

Pete

[RichardL]

I completely understand Pete. I sent that email with the simconnect.log on 20 November.

On a different note, I put the question of releasing small quick updates vs very large time delayed updates to Phil Taylor in the Avsim forum. As suspected, they, MS, are more inclined to release one or two large updates that we may not see for many months.

Richard

[beatle]

Hey Pete (and all),

No fixes to suggest right off the top of my head, but is it possible that the folks who are having problems with I/O errors might have something odd installed in their networking stack (ie some sort of debugging/monitoring driver, weird network card with older driver, etc). If only some folks are having it, and its related to the networking section of the code, seems likely something in the networking driver stack.

In a networking system where clients connect to servers, if the server gets an error trying to talk to a client, there really isn't anyway for it to recover and rebuild the connection, since the clients are the ones that make the connections :-> The fact that FS doesn't crash and removes any menues that the add-on that got the error had created seems to me like its handling the error correctly. I would think this is the behavior you would want if a client suddenly stopped responding (because it was remote and the network went down or the external app faulted, etc).

Tim

http://beatlesblog.spaces.live.com

[Pete Dowson]

No fixes to suggest right off the top of my head, but is it possible that the folks who are having problems with I/O errors might have something odd installed in their networking stack (ie some sort of debugging/monitoring driver, weird network card with older driver, etc). If only some folks are having it, and its related to the networking section of the code, seems likely something in the networking driver stack.

Yes, maybe. But this really does show a big big weakness in the way SimConnect works. Here we are talking about errors occurring between DLLs running inside the FSX process and FSX, via SimConnect, and sometimes between an EXE in the same PC as FSX and FSX, again via SimConnect.

I really would be most surprised (and rather shocked, from a performance point of view) if network drivers are really involved in comnunications between FSX and EXE's running in the same PCs, let alone with DLLs like FSUIPC4 and FSXCopilot running in its own process. Surely all that, even though it is via the TCP protocol, should be well within the Windows & Microsoft sphere of control.

I would think this is the behavior you would want if a client suddenly stopped responding (because it was remote and the network went down or the external app faulted, etc).

Nothing is faulting here other than SimConnect as far as we can detect or determine. It seems that the errors occur just because SimConnect or TCP gets "too busy". And the result of, for example, FSUIPC4 being denied further access to FSX is a gross loss of anything the user has set it up to do -- very often all his joystick, joke and button operations to start with, apart from all the instrumentation in a Project Magenta cockpit.

Talking of which we have 6-10 PC Networks running with the FS PC as the server and instrumentation and controls spread all over the Network, and never have I seen any unspecified "I/O Error" occur with no idea what it is or how to recover. The fact that they occur within one process and not over real networks is rather odd, don't you think?

Oh, Happy New Year by the way! ;-)

Best Regards

Pete