Pete Dowson

Following on from above, I had a quick look, and most of the code i needed to identify exactly which joystick was causing the problem 9by ID in your INI) was already there, but disabled. I've re-nbaled it and adjusted it a little. Download this and try in -- change flights or just close down so the same datea as before gets logged, only this time there's a little more. FSUIPC4966p_TEST.zip I'm off to bed now, exhausested! Pete

Okay. That shows the X55 stick as having tat GUID with both 8005 and 8006 (with 8006 being correct) and the Throttle as having both 8007 and 8008 with 8008 being correct. If you look back a few messages you will see how to use that information to make 4.966c work fine. Not that i want you to abandon 4.966n because I'd like to get to the bottom of the problems. however, as I said, I very busy just now and may not give it sufficient attention for a few days. Meanwhile you can still fly ... Okay. That's very useful, thanks. I'll take a look at that in the morning. In the log you added annotation =====>>>>> now the system shows the "application stopped working" dialog and clicked "close application" So, the "application stopped working" occurred BEFORE FSUIPC somehow closed down normally and THEN got the crash in one of the joystick drivers? And crash details or log from that? There seems to be a common cause. Maybe you were just lucky before with 4.966c. It is starting to sound more and more like a corruption in the system somewhere, probably in one of the joystick device drivers. There's no way a freshly installed copy of FSUIPC is going to be different from the previously freshly installed copy. I'll try to do a quick logging addition tomorrow to see if I can identify the joystick which is causing the crash on termination, the one FSUIPC logs, and I'll also check that Windows crash report location. Meanwhile you might like to try removing one device at a time from your system. Just unplug one at a time to check. FSUIPC will only deal with connected devices. If you locate it, use the Windows device manager to uninstall it fully, including drivers, then re-boot with it plugged in again, in the same place, so that Windows will reinstall it automatically, hopefully with uncorrupted drivers. You're not using Saitek software with them too, are you? If so you might want to reinstall that, or just stop using it. Pete

Ah, well, how can you press both left and right together? If you cannot you will have to use the . keypress or a button programmed just to "Brakes". It sounds like you are asking the impossible. Pete

I'm amazed at that. I they actually didn't pay me anything at all, just said they didn't need me anymore! That was years ago. I don't understand what SerialFP2 is for, in that case. That's supposed to be their driver. But they did say they were working on a better one, which I wasn't privy too and which I must assume didn't need FSUIPC in any case, just as SerialFP2 surely didn't. I wasn't their programmer, it was only an extension to my services with FSUIPC, like the GoFlight support -- again, which isn't needed in place of Goflight software. No, of course you need their driver. Just not FSUIPC support!!! Remove the lines from FSUIPC's INI file and stop the VSPE. Just use SerialFP2 -- or download their later drver. I think their English language support was actually run by an enthusiast here in Europe. Have you looked? Haven't you even tried the AVSIM forum fo VRInsight? Actually, I just Googled, and that seems to have disappeared too: https://www.avsim.com/forums/topic/452814-vrinsight-forum/ So the device is virtually useless and of no value it seems? Did you buy it at a junk sttore, or on ebay or somewhere? Didn't you check these things first? There's no such thing as a COM port "taken" unless a program is running which "takes" it. The COM port belongs to the device NOT the program. it sounds like you have some VRI software running which opens the device -- but I thought you only had SerialFP2 to do that! If SerialFP2 can get COM3 then so can VSPE instead. That's the whole point which you don't seem to understand. One of the pair MUST be the device. The other doesn't matter, that's the "virtual" port which FSUIPC will realy the Radio Stacks message to SerialFP2 through. So SerialFP2 then needs to opebn that port, not COM3. But if it NEEDS FSUIPC then you don't need SerialFP2 and you don't need VSPE. Just set only COM3, one port in FSUIPC. What's the point of FSUIPC sending the radio stuff to SerialFP2 if it isn't going to use it? You don't seem to understand much of what I'm saying at all I'm afraid. I do not have any VRI devices any more, not for years. The facilities I added were as a favour to users. There's no way any device being commercially sold can be dependent on FSUIPC, at least not without my agreement and recompense. That makes no sense. If it is really like that then it is junk. Pete

That was one of the few I didn't know. Ah. That's a crash associated with a joystick device driver. Interesting. The location is in DirectInput: REgarding this: Is there a log or Event information for this? the logs you show are all on exiting FSX or loading it. I don't see any reason for exiting a flight having anything to do with any of this. The Windows Event you depict is in fact the one which the Loader's patch to the Registry fixes. It is "FSUIPC4_Unloaded" which means SimConnect tried to call FSUIPC4 but it hadn't been loaded, so causing the crash at the intended entry point (the address confirms this). SimConnect is buggy in that it loads modules then assumes they've loaded. very bad programming practice. it should give an error message instead. In order to identify which joystick driver it is I shall look a loogging the separate Joystick Device closing actions. but that will be tomorrow now. Sorry. Where's the csv file I asked for? Pete

Really? That surprises me. I though my implementations were solely to help use the VRI devices on non-default aircraft. In that case do you actually need SeriaFP2 for anything? It sounds like it doesn't do anything for the RadioStack. If it doesn't there's no point having VSP and two COM ports, just tell fSUIPC to use just COM3 and be done with it. Devices occupy whatever port it is when you connect them. It's the device and device manager that does that. If you unplugged it and plugged it in somewhere alse it would probably change. You CAN usually change the port used in the Device Manager, buty there's no need unless there's a reason you don't like COM3. That's correct because it it did how would FSUIPC get it? It doesn't "hijack" it. It's where it is! Your VSPE links COM3 to COM4 so FSUIPC can read COM3 and send to SerialFP2 on COM4. That's the whole point which you seem to misunderstand. You then have to make SerialFP2 read it on COM4. I think this is where I need to refer you to VRI support. There's a very good website somewhere -- take a look. Pete

For FSUIPC application mostly it's just library function calls, so the Lua package supplied in your FSUIPC Documents folder should be the biggest help -- there are a lot of examples there too. And check some of the threads in "User Contributions" subforum too. Pete

No. If anything, because the plug-ins run in their own, separate, threads (not in the main thread like your Button programming), it would tend to be less. And you can have plug-ins loaded once (eg via an [Auto] entry in the INI, of using ipcReady.lua to load them), and just responding to events just like the button assignments. Of course it can be easier just to assign a Lua to a button so it loads and unloads then, but considering there's a limit on how quickly you can press buttons that's pretty neglibible too. Pete

Okay. Here: Is these any reason you delete the INI? It would mean re-making all your settings. Also you don't need to delete FSUIPC4 when copying in the new one, just confirm to "overwrite". If it makes a new INI it will make a new LOG file ands also a file called "FSUPC4 JoyScan.csv". Could you show me both of those please? They are most important. The latter would also show me how to tell you how to edit your INI to make 4.966c work with the X55, which you could therefore use until we sort the 4966n problem out. Oh dear. I do wish you wouldn't delete files. Now it means doing it all again to make those LOG and CSV files. There really is no need to delete anything. It just makes things harder. From your list of steps i would say that the previous session to the CTD one actually crashed and disappeared rather than terminated normally, though it may look like that. I know you said there were no FSX events in the Windows Application Log in the Event Viewer, but could you please just check again immediately after it all looks to be closed correctly? I know crashes can occur without being recorded there -- i've had them myself, many times, when developing with Beta versions of FS and P3D. But still. Also the FSUIPC log will hopefully show whether it whought it closed cleanly. The Installer will make a new DLL.XML with only FSUIPC4 loading. Well there you are. Proof that it's a crash on the preceding close, not 4.966n crashing on start up at all. 4.966c does too after a previous crash on close. There is a positive aspect to that -- it means it is far less likely to be due to initial timing conflicts with the other DLLs being loaded. I'm likely to be avay from the PC for most of the rest of this evening. My wife tells me I shouldn't be working all my waking hours at my age (74) and Sunday afternoon and evening have traditionally been "lazing about" periods (especially on a holiday weekend). Pete

I've had a look at your DLL.XML and EXE.XML file. I think you need to carry out a process of elinination. To start with rename the DLL.XML, or save it elsewhere, then re-run the FSUIPC installer. Make sure 4.966c works so we know there's no registry entry stopping the DLL later. Then copy in 4.966n, and test it. Let me know the result of that. If it still crashes, then try with the EXE one renamed too, though that's more of a long shot as EXEs aren't in-process and rarely cause conflicts. We'll proceed from there, assuming you've decided to be cooperative. Pete

It means COM3 is taken. No point if COM5 isn't the device. It stretches my memory, but don't you have to run it separately to determine the correct COM port. Don't use FSUIPC in any case, or at least not with any VRI lines until you know which COM port your device is connected to. The Windows Device Manager may help. idplay the COMs devices whilst unplugging it and plugging it in. See which entry changes. Don't VRI suply setting up instructions? You must be able to use the device without FSUIPC' too, There must be a way to determine where it is connected. I don't know VRiSIM at all. Pete

Yes, it happens. most of those things are matters of timing -- the occurrence of one ecent juxtaposed to another. Those happen in different orders on different systems, with different add-ons and with different updates of the same programs. Additionally every change to FSUIPC creates a different memory pattern and depending what the interaction is which is the problem it may have a serious affect or no noticeable affect at all. It is all in the nature of complex programs in ever more complex systems, and most of every developers support time is occupied by trying to reproduce these things so they can be nailed, but that turns out to be more and more difficult becase of the huge number or variables. I have solved many problems over many years (I started programming in 1963, when things were just starting to get complicated), and very many of these were never reproducible on my development systems. To re-create what you have set up here would be well nigh impossible. can only try to gather sufficient information to assist you in either overcoming it, or help me to work out avoidance action. A combination of the changes in 4.966n AND other things on your system. If there were a definite bug in this version which is independent on everything else in the systam I could reproduce it as could all other users. Sorry, but honestly you don't know what you are talking about. You are assuming some moral high ground and stating your thoughts as if they were facts. It is becoming tiresome. I will try to help,but you aren't helping at all. I don't care whether you paid, you haven't got any right to treat me in such a downright disrespectful and obstinate manner. If I can find out what is wrong I will do. But you will need to help. If you want to continue the way you are instead I will personally refund you and revoke the license. As well as asking for the files you attached I also asked "if you can please clarify the earlier confusion (difference between an iNI file creation start and subsequent ones), ..." Pete

No: you are correct. No such facility exists. You are inrementing or decrementing 66C0 between 0 and 7 but only using value 0 and 7? Why not just have t toggline between 0 and 1? No, not in my opinion. I wish I hadn't added any button programming features to the INI as it is, without making it even more complicated and arcane. I added the Lua plug-in facilities specifically to avoid all that complication. what you want to do would be far cleaner and easy to understand in a simple plug-in. Pete

Exactly what I said and it shows in the document. I don't understand what you mean by If you added exactly the same to both assignment lines, then both assignments will do the same at the same time -- which is what you said you wanted, no differeerantial braking! It's only a few characters to add to two lines. where's the problem, please? Pete

Ah, you DON'T want differential brakes? So just adjust the values to run 0-16384 for both assignments, from -16384 to +16384 that means ,*0,5,+8192 added to both assignment lines. Pete

Many devices have a setting which splits the axis into left and right for you. Doesn#t yours do that? Otherwise, you can't have the same axis assigned to both left and right brakes without doing some "fiddling" with the values. Both sides will need 0 - 16384 (brakes off to full brake) and the other the same. However, your single axis will want to send -16384 fully pressed one way to +16384 the other way. Making changes like this can be done in the FSUIPC4.INI file -- see the section entitled "Additional parameters to scale input axis values" on page 46 of the FSUIPC4 Advanced Users guide. You will have to adjust the values on the problem assignment to make it run from +16384 There's an example of that. The calibration will need setting to ignore values below zero on both sides. Pete

Radio Stack? Is that a new one, or one of the original serial port versions? Are you sure it uses the same protocols -- VRi changed everything after I added support for their early devices. I thought they changed over to make them more normal HID devices, like Goflight and so on, for which you need their own drivers. The original devices are supported by FSUIPC, so if yours is one of those, the error must be in your serial port settings. COM1, COM2 sounds most unlikely, actually (COM1 usually gets used by the system these days). Have you poisitively determined that the device is connected as COM1? And "SerialFP2" is running and set to COM2? If you run SerialFP2 without FSUIPC and the Eterlogic program running, does it see the device on COM1? Pete

What version of FSX or P3D are you using, please? Both offsets 3102 and 281C (both master battery switch offsets) should operate the battery switch by direct action in SimConnect, being controlled by a "SimVar". This worked in all versions of FSX and FSX-SE, and also in P3Dv1, but it was broken in the Simconnect included with P3Dv2. Until it was fixed I implemented temporary action (called "P3Dfiddles" -- there are more than one!), which could be turned on or off by INI file parameter. The parameter should be defaulted 'on' for P3D2 but off for everything else, where the problems are supposed to be fixed. But it looks like it is now Off by default in any case. [LATER] I've just tested with P3D3.4 and it still hasn't been fixed in P3D. I'd better check P3D4 too! For now, instead of using that Lua plug in, just add "P3DV2fiddles=Yes" to the [General] section of the INI file. I'll make the battery option fix default in 4.967. Pete

Strange. Which device is the "tiller"? The CSV shows 6 good and usable devices, but with 4.966c there are only 5 selected, as shown in the log. i.e. 281 Joy#0: OEMName = "Pro Flight Yoke" 281 Joy#0: GUID = {C8053830-C09A-11E5-8003-444553540000} 281 Joy#2: OEMName = "Mad Catz Pro Flight Rudder Pedals" 281 Joy#2: GUID = {C802C730-C09A-11E5-8001-444553540000} 281 Joy#3: OEMName = "USB Controller" 281 Joy#3: GUID = {848199F0-C162-11E5-8001-444553540000} 281 Joy#4: OEMName = "Button Box Interface" 281 Joy#4: GUID = {8EE7B440-C938-11E6-8001-444553540000} 281 Joy#5: OEMName = "BU0836X_1" 281 Joy#5: GUID = {CE02BA90-7BF8-11E6-8001-444553540000} Is it listed? All of those above are unambiguous, with correct GUIDs shown by DirectInput and in the Registry. The missing one is "USBAXES_PLUS V2", which should appear as Joy#6 according to the csv results, but in the log it is listed as: 281 Product= USBAXES-PLUS V2 281 Manufacturer= Opencockpits 281 Vendor=04D8, Product=0000 (Version 2.0) 281 Assigned joystick id 1 (Registry okay) 281 GUID= {37E9E100-17C5-11E7-8001-444553540000} So I'm puzzled. I need to see a detailed log relating to 4.966n please. ut before starting the sim, add these lines to the [General]section of the INI: Debug=Please LogExtras=x200000 Can you run my HidScanner please and show me the Log it makes. (Useful additional programs thread in Download Links subforum). It would be a good idea too, please, to show me your FSUIPC4.INI file. Pete

On the first launch, as well as an INI is there a LOG file? At what stage does it crash on the first launch, compared to the subsequent ones, as it seems you are saying they are different? The only part of FSUIPC which is different in this so-called "Beta" version (to be released this week as 4.967, replacing 4.966c) is the Joystick Scanning, which has been completely replaced with a much more locial system than the one which has grown up with bits and pieces patched into it over the last 20 years in order to cope with different things as they cropped up. If the crash you are getting is occurring before FSUIPC has even started, which it sounds like (except for when an INI and/or LOG is produced), then it is invariably due to a previous crash or hang on closing FS. This is actually indicated also by your previous report: The Installer makes a change to the Registry each time it is run which removes FSUIPC from a list of "DLLs not to be loaded". Those DLLs seem to be automatically classified as "bad" if they were still in FS's process memory when a terminating hang or crash occurs -- i.e. one which may even not be noticed which occurs during the process termination sequence. The main things which can cause this for FSUIPC are Lua plug-ins which use external drivers for hardware access, like LINDA. However, I see no indication of anything like that from the Log file you posted a while ago. The reason the X-55 was not handled correctly in some (not all) configurations in previous versions of FSUIPC was because somehow their installers provide 2 entries in the Registry for both Stick and Throttle, with slightly different GUIDs. With the earlier FSUIPC scanning method these were indistinguishable so FSUIPC chose the first of the two, which seemed the obvious choice (and which does actually work for everything I've ever seen up till the X-55 and X-56). Your earlier log shows: 187 Joy#2: OEMName = "Saitek Pro Flight X-55 Rhino Stick" 187 Joy#2: GUID = {299EC5D0-3D62-11E7-8005-444553540000} 187 Joy#5: OEMName = "Saitek Pro Flight X-55 Rhino Throttle" 187 Joy#5: GUID = {337E3D10-3D62-11E7-8007-444553540000} I woould expect the correct GUIDs to be identical to those except with the 8005 and 8007 part different -- possibly 8004 and 8006 respectively, or 8006 and 8008. For use with 4.966c you could try just editing the GUID lines in the INI file. For a definitive answer to whuch GUIDs to use I would need to see the Registry entries, which I could do if you wish (I'd provide the details for you to use RegEdit to export the relevant section). That is grossly unfair. FSUIPC is 100% stable and reliable for 99.9% and more of its many users. The main start up problems reported have almost all been due to end of session crashes which has an assortment of causes. FSUIPC just happens to be one of the last parts of the process to terminate because of how much tidying up it has to do and also to give WideServer clients time to see the closure themseves. There have in the past been known conflicts, only occurring during the loading times, with other DLLs being loaded and initialised -- BGLMANX.DLL was one such, and earlier versions of PMDG_Options was also one. Generally it is best to have FSIPC loading last in the DLL list, which is where the Installer places it (except for Active Sky's DLL, which is loaded even later, otherwise FSUIPC's weather radar provisions do not work. This is because of conflicts in hooking into FS's weather system). If you are judging the reliability of FSUIPC by reports here, you are mistaking the use of a Support Forum for a consensus from users, whichit plainly isn't. Well. that's not strictly true as you will see if you review the other X-55 reports, However, one reason is that FSUIPC has grown from a purely registry and old "Joy" interface user, in FS2000 -- FS2004, into a DirectInput user, but still identifies devices primarily via the Registry. The X-55, X-56 series is the first encounter where the Registry can be misleading (and then not for all -- the order of the GUIDs in the Registry appears random). The whole point of the changes made in 4.966n is to remove the legacy scanning code and replace it with something which does cope properly with such discrepancies. And I am very pleased with the results. The code is now clear, relatively simple, logical and reliable. The problems you are having are very very unlilely to be due to those changes. If I knew whether FSUIPC was actually starting or not, when you get the crash, I could look at ways of trying to identify the reasons. First, though, if you can please clarify the earlier confusion (difference between an iNI file creation start and subsequent ones), and also show me your DLL.XML and EXE.XML files (so i can see which other things are happening at the same time), then I can consider what to do. Unfortunately I am overloaded at present with preparing for the release of FSUIPC5 for P3D4, but i will do what i can. If you continue in such an objectionable and unfair manner I would be loathe to help you with anything. I try my best to help everyone here and work more than full time on support and ongoing developments. Just look at the history of FS and FSUIPC and you will see. It was free for many years until my income dried up and I was forced to either abandon FSUIPC altogether (before FS2004 release), or move it to a payware base (and then, only for user facilities, not for its prime purpose as an application interface, which is still free). With more users with such an attitude I'd be inclined to stop FSUIPC4 development and support now, withdraw it alogether, and also ditch FSUIPC5. FSUIPC4 has now been continuously developed and well supported for 12 years with no upgade price or subscription once initially purchased. I would seriously ask you to reconsider you attitude and treatment of folks who do their best to help, often with little or no supporting information. Pete

The engine? You don't need to start "the engine". Just proceed with letting FS get to the point that you are in the cockpit and can do things there -- whether look around or start engines or whatever. That's when FSUIPC (+WideServer) actually starts. Before then there is too much undetermined data and FSUIPC is in "limbo". Pete

But the FSUIPC log shows that it never reached the "ready to fly" state, which is where other things like WideServer are started. Did you actually let FSX reach the stage where you are in the cockpit and ready to fly? Pete

Then in that case you have not enabled (registered) WideFS iin thefSUIPC installer. No. As it says, WideServer is built into FSUIPC4. Excellent! No!!! WideServer is part of FSUIPC. I think you need to show me the Install FSUIPC and FSUIPC log files, form that same folder. If you have registered with your correct WideFS key then WideSever should be enabled as soon as FSUIPC is running okay and it then creates its log immediatlely. WideServer does not start till FS is "ready to fly", and it seems FSUIPC is never getting there. Let me see the logs! Pete

WideFS only links FSUIPC applications to FS. AS16 is not one. I think PF3 may be but i'm not 100% on that -- see its documentation. Flight Planners vary, some do some don't. Those that don't are using Simconnect instead -- and instructions to set this up are provided with the application (eg AS16). That's not actually needed for either WideFS or SimConnect, but will be for Flight Planners and the like. There will be a WideServer.LOG on the Server too, in the Modules folder. There are always two ends to a connection and it is useful to see details for both. The IP address is generally more reliable because sometimes the Router uses fake "proxy" IP addresses and you need then to find the true one. Best to assign fixed IP addresses to each PC, not allow the DHCP system in the Router to assign them -- the latter is okay for transient devices over WiFi. Did I read it correctly. Are you using two Laptops? I hope they are not both using WiFi? You might get away with one on wifi and the other wired, but even that can be flakey. With two I'd be surprised if it worked. The communication needed, whilst not heavy (a 100 M wired connection is sufficient) it is frequent, and WiFi can impose too much of a delay which can cause conflicts. However, now looking at the log I see Error on client pre-Connection Select() [Error=10061] Connection refused In my experience the "Connection Refused" error is almost ALWAYS down to Firewall protection, at one end or the other. It won't be anything to do with the router firewall if that's what you were tintering with -- that's only for external connections, the Internet -- check the Windows Fiewall in the Laptops -- either or both ends. Also any additional protection programs used. I also see it says: 618844 Trying TCP/IP host "DESKTOP-7264SC4" port 8002 ... 618844 ... Okay, IP Address = 192.168.0.19 so the Server name is "DESKTOP-7264SC4", not "DESKTOP"? And is the IP address 192,168.0.19? Check that. It looks like the right range (proxy ones look more like Internet IPs). If I were you I'd see if it works with both Laptops connected to the router by wire. If so then it is definitely WiFi problems. If not I can suggest some extra logging you can get -- but first let's see the server log. Pete

I've just spotted the likely reason for your problems. You are using a very olf P3D3. See this item in the 4.966c changes list: The version of SimConnectP3D3.DLL installed with 4.965 was not compatible with all earlier versions of P3D3 – probably anything earlier than P3D3.4. This was a shock and surprise as the SimConnect libraries are normally backward compatible within the major versions. The version now installed is compiled against P3D3.2.2, so is certainly okay with anything from that one to the latest 3.4. I’m afraid I can’t guarantee it for 3.0 or 3.1 releases as I do not have them now. The critical part is in red. I don't understand why you are using 3.0 still when all P3D3 updates to 3.4 are free and fix many bugs, and improve performance. The real fix, in my option, is to update. You could also try just removing SimconnectP3D3.DLL from the Modules folder to force it to use the old FSX version. That will reduce the facilities available a bit, but it would still work better than it is now. FSUIPC isn't connecting to SimConnect at all at present so offering hardly any facilities at all. Pete