Pete Dowson

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

Isn't there some parts of the SimConnect SDK providing details for managed languages. I'm not the right person in any case -- my languages are nly C, Assembly code, and even machine code. Pete

Okay. Thanks. That sems to imply that offset 3102 isn't working correctly. I'll take a look. Pete

There is the original crude text display (basically using the same one as the scrolling ATIS one, but possibly multilined if new line or return codes are implanted. That window can be resized and even undockey but otherwise, by dfault stretches right across the top. I will be pressing L-M hard to enable the few remaining features I need. Obviously they were more occupied with getting the 64-bit conversion working and making a release. Yes, colours might be nice but I probably won't press my luck -- just a mention rather than a "demaind" i think. ;-) Pete

INI files can only have one parameter with the same name in any one section. Those parameters are "UpdatedBy", "FSversionUsed" and "SimConnectUsed" and get written every time you start the program -- it's just a way of me seeing what you are using even if you don't supply a log file. Pete

Does the FSUIPC log file show any problems. Note that I have about 600 layers of scenery files, and it takes at least that for me even on a fast PC with SSDs. Pete

No, the offsets are part of FSUIPc, populated by information from FSX. The point of FSUIPC is to allow folks to interface to FSX in a compatible manner across versions of FS. If you want to interface directly to FS, it isn't anything to do with FSUIPC. You need to refer to the FSX SDK. Pete

I don't think I understand the "issue" well enough to fix it What would FSUIPC have previously seen when you operate the BAT switch? Is it a button numver? A virtual button perhaps? I really don't know what SPAD does -- maybe its author or support can investigate whether it is something I can do. I see Thomas found the same, but without knowing more I'm not sure what I can do. I was planning on releasing version 4.966n properly next week as 4.967, along with the 64-bit version for P3D4 at the same time. I would rather fix it before then than have to change both soon after. Well, trying that would probably tell me all I need to know, so it is important. Otherwise it just won't get fixed. Bumping this thread "so it won't get lost" is a bit pointless without doing that first. Pete