Pete Dowson

Er ... Where is the light switch operated? You seem to have just assigned buttons to loads of different keystrokes. I don't know what those are assigned to -- not in FSUIPC for sure. You've made the log impossible to resolve by pressing loads of buttons or switches and sending lots of keypresses! Surely all you should do for this test is operate just the one toggle switch? I see nothing there but standard FS controls and assorted key presses. Why do you think FSUIPC is having anything to do with what you are seeing? Earlier you said But I see nothing there which I would have helped you with. Pete

I'm afraid you need to explain more. How are your toe brakes assigned? All aircraft or only one specific one? What other offset were you testing? Please use the FSUIPC logging facilities to see what is happening. Monitor the offsets and log the events which occur when you press your toe brakes. Don't forget, also, that on most (if not all) aircraft the parking brake is merely the latched application of both toe brakes. In fact if programmed correctly, you have to press both toe brakes then pull the lever to lock them on. Releasing them is then a matter of pressing both toe brakes sufficiently. If assigned through FSUIPC there's actually a threshold value you can set for this in the INI file. Pete

FSUIPC only does what you ask it. I've no idea what operates switches in the PMDG 777, I don't have it, but i'd be very surprised if changing one switch operates every single switch in the whole aircraft. If it does there is something very wrong with the 777! Perhaps you only mean all of the light switches, not all the "rest of the switches in the Virtual cockpit" as you said? If so them it will probably be related to how you've programmed the switches. Do two things 1. Enable button logging and also event logging (not axis) in FSUIPC's logging page, operate the switch, then turn the logging options back off. Show me the resulting LOG file. 2. Also show me your FSUIPC4.INI file. Both files are in your FS Modules folder You can paste their contents in a message here. Pete

No. That's exactly like a corrupted FLT or WX file being loaded by default -- i..e. \\PC\Flight Simulator X Files\Last Flight.FLT As soon as FSUIPC starts doing things, it is accessing the weather through SimConnect. A corrupt WX file, saved with the FLT, can cause problems. Try deleting just \\PC\Flight Simulator X Files\Last Flight.WX In fact, after doing a search on EV_MENU I found an earlier thread in which the Menu wouldn't appear for exactly the same sort of reason. There is another file which can get corrupted -- WXStationList.BIN, in your FSX.CFG folder. You can delete that too -- FSX will build another. Pete

Yes, as I've now discovered trying to send an email to Enrico. I tried his hotmail address ... ah, he's just replied! He says "I really do not know what is going on… SQL, Mail, FTP and all sorts of other things are fine. They are working on it to find out what is going on." Pete

Those are the two instances of the menu being called. In the first the "dwMenuEvent=0" value says that SimConnect is not at present in Dialog Mode, so the very next thing FSUIPC does is ask SimConnect to enter dialog mode. It then has to wait for a response from SimConnect saying that dialog mode has been successfully enabled. This event is never seen! So FSUIPC cannot display the actual dialog. The second time you selected the menu entry, "dwMenuEvent=15" occurs, which tells FSUIPC that SimConnect has exited dialog mode. So, something in your system is preventing SimConnect from sending the confirmation event, or, more likely, is stopping FSUIPC receiving it. The DLLs will be running no matter what aircraft you are flying. They should only do something when needed, but they are running as SimConnect clients all the tim, receiving and handling all the events they have registered. I'd mostly suspect the "PMDGoptions.DLL" module -- early versions of that did cause problems. Please try renaming just that module, so it doesn't load, and see if this is the case. If so I think you need a PMDG update installed, because it was fixed some time ago. If it isn't this then, please, as a test, rename both your DLL.XML and EXE.XML files, so no add-ons/ins load, then re-run the FSUIPC4 installer and test again. If that works, then there's a process of elimination to be followed on each add-on/add-in in turn. If none of this gives a result then I can only think your SimConnect installation is faulty. Regards Pete

There are two current versions of FSUIPC -- FSUIPC3 for FS2004 and earlier, and FSUIPC4 for FSX and Prepar3D. If your key was purchased for FSX in 2010 then it is still valid -- they don't expire, and you never pay for updates. Just download the current Installer (4.931) and run it. There are instructions inside the ZIP file which tell you whhat to do. discard your old copy. Pete

Appears so at present. But you can still get everything here in the Download Links subforum. I'll check with Enrico Schiratti about his site. Pete

Sorry, it isn't available through FSUIPC for FS2004. In FSX and P3D it is the (mis-labelled) "Engine N fuel elapsed time", offsets 0910, 09A8, 0A40 and 0AD8, respectively for Engines 1-4. The word "fuel" shouldn't really be there I suppose, though the time only counts when the engine is being fuelled, of course. Pete

All you need to know is that it is dangerous to use the wrong version of FSUIPC and cannot be supported. If you don't mind having P3D crashes and don't want support from me, it doesn't matter. Good decision! Pete

That'll be because an axis is jittering -- constantly sending changes. You should find a place to park that one which is stable (usually at one or other end). The whole point of using letters instead of numbers is so that changes, wrought by Windows updates or disconnecting and reconnecting devices, don't mix up your assignments. However, FSUIPC still has to use the numbers in its calls to Windows. The entries in [JoyNames] allow FSUIPC to relate the letters to the current numbers by using the names, or if there are duplicate names, the "GUIDs", which should be unique. The entries also allow me to assist diagnosis from logs when needed. But of course I don't need it if it is all working. Pete

Yes, the log shows everything okay. In both Windowed and full screen modes? What other add-ons / add-ins are running? Please add the following to the [General] section in the FSUIPC4.INI file before running FSX. Then run it and try to enter the FSUIPC Menu, and show me the resulting Log. Debug=Please LogExtras=x8000 Pete

4.929 does not know that version of P3D. You MUST install 4.931. Why so reluctant? There are many places where FSUIPC hooks into P3D code. Those places move each time P3D is updated. If you don't update that, where those hooks can be cross-checked, they will simply not be placed -- no crash, but equally no facility in that area. But some hooks cannot be cross-checked, and if they are ever invoked you will get a crash. I will not support you if you persist in using the wrong version of FSUIPC. Don't forget you don't have full control over when FSUIPC facilities are invoked. you may only use a few of the user facilities, but it isn't really the user facilities that use hooks very much. It is add-ons. Pete

Did you do the logging as suggested earlier in the thread? It would provide more information. Do that and show me the results. I also need to see your FSUIPC4.INI. Currently there's no information at all. for instance, does FSX see your axes? Do either see buttons? The strongest suspect at present is a corrupted Windows installation, so be prepared for the advice to reinstall it. Pete

Well, FSUIPC certainly thinks it is P3D for some reason. Most odd. Please show me the FSUIPC4 Install log file (paste in in a reply). Also check the FSX folder "K:\FSX", as I think that FSUIPC might be seeing a Prepar3D.exe there too. Unfortunately FSUIPC cannot trust just the name of the EXE in which it finds itself because folks appear to be renaming these to try to get around installers not yet updated to deal with P3D. Therefore FSUIPC does additional checks. It assumes it won't find a Prepar3D.EXE inside an FSX folder (why should it?), but because of installer faking it has to be able to recognise a P3D folder with an FSX.EXE inside it. Pete

I suppose without ProSim737 the MCP one doesn't do anything or won't load, so it isn't possible to isolate it just to the MCP one ... or is it? Hmm. Very strange. I don't understand why that would be any different. Doesn't show anything different, does it. Well, interesting but it doesn't really help. Any the above log shows everything normal till the freeze, which oddly is NOT happening after a client has called WideClient for data, but just during normal polling. It's as if the Network part of Windows has simply stopped calling WideClient with the WSA_READ message which tells it it is okay to ask for more data. So, like the NTDLL crash, it implies the problem is actually occurring in the Networking part of Windows. Can you reproduce the hang and/or the crash with Log=Yes rather that Log=Debug please. I'm not sure we are going to get anywhere with this, at least not without some sort of clever network analyser. Do you have another PC to try it on at all? As I said, the only similar crash I get with WideClient (and in my case only when FSX crashes) happens only on one out of 6 client PCs in my system. I've never got to the bottom of that. Pete

Please read the solution earlier in this thread. Pete

There's your problem. If you rename the EXE then FSUIPC will most certainly not be using it's normal files and can go very wrong. It depends on the EXE name. Update your P3D with the Hotfix to build 10438, and make sure you are running Prepar3D.exe. Pete

Version 4.928 isn't supportable I'm afraid. The current version is 4.931. Please update. If using IPC write logging no entry appears when you think you werite to 07F4 then I'm sorry but you are not writing to 07F4. Perhaps you should show me the log rather than report what you think it is telling you? Please? Pete

What was your previous version, then? I have actually never known any such problem in FSUIPC itself. It can be caused by FSUIPC client programs, notably add-ins like aircraft gauges and at one time certan plug-in methods. Do you have any Log to show me? The only way that can occur is when if the standard Windows library for dialogue displays isn't compatible with the video driver. Some video drivers used to replace that library, so on a subsequent driver update which didn't change it they brought about a mismatch. The only other way iI think it could happen is if some other add-on is aactually somehow intercepting the SimConnect even from the menu entry. Pete

Is an FSUIPC4.LOG file produced in the Modules folder? Are there any crash details mentioning FSUIPC4 in the Windows event viewer? If either, or both, I need to see them please -- paste into a reply here. And where are these "the details pointing to FSUIPC" -- obviously I need to see those, so why keep them to yourself? One of the most likely problems is a corrupt Weather file (.WX file) being loaded by default, or a corrupt WXStationList.bin file (same folder as your FSX.CFG file). You could try deleting both. Otherwise, if no log is being produced and there is no crash reported in Windows, then it is the usual SimConnect timing bug. Please see the FAQ subforum. There's a thread relating to such problems. Regards Pete

If you've calibrated them correctly then pressing them all the way will give the maximum braking designed into the particular aircraft you are concerned with. If you don't like the modelling you may be able to increase the braking effect by altering either the AIRCRAFT.CFG file for it, or the AIR file -- but the latter needs a special editor,such as AirWrench, and great care. I'm afraid I don't know what parameters there are for this -- it is probably some inertia or momentum value. Of course you could get more braking action by simply lightening the load. Maybe you're carrying too many passengers or too much fuel? With most aircraft I've flown in FSX I've found the braking is rather too effective, often probably unrealistically so.. Pete

For many years the system was based only on aircraft names. The Profile system, which is much easier to use and more versatile, was added later, and eventually became the default for new users. The manual was adapted to deal with both and help the very many earlier users change over. Stay with profiles. No: whatever keyboard assignments exist in P3D will still be the same unless you change them. If you assign the same keypresses in FSUIPC to other things, they will take precedence as FSUIPC intercepts them before P3D sees them. It would do this for buttons and axes if it could, but any number of users can access USB devices at the same time. Neither. It just does what you tell it to do. If you don't assign any keypresses in FSUIPC, it does not obey any because they aren't so programmed. Only if you actually assign them. FSUIPC doesn't do anything all by itself. It's a tool. You decide what you want to do, not FSUIPC. Not if the assignments you make that way are specific to the Profile you create for that aircraft. Pete

I think the flight plan issue affects some of the SimConnect functions which may be used. The same applied to Radar Contact, when it tries to apply an initial position. Pete

I think this is another case of the crash caused by the bug in P3D build 10437. Could you please apply the 10438 Hotfix from Lockheed-Martin and try again? I might have to put out a note saying 10437 cannot be supported. Pete