Pete Dowson

Download the latest version of the Installer (eg from FSUIPC.com) and run that. If it has a problem show me the Install log file it generates. Your FSX should be fully up to date (if it's an FSX-SE you should be okay, but if it's a Microsoft FSX make sure you have both SP1 and SP2 updates in stalled. They are still available on the Internet (use Google). The only difference between a registered and unregistered install is whether it is registered. Your registration details are help in an "FSUIPC4.KEY" file in the Modules folder. If you need to register again you can get the details from your account in SimMarket. Pete

That would certainly lead to a bit of a mess in the registry, but it might be manageable with care. You might first try uninstalling both devices completely, including all software associated with them. Ensure there are no entries for them in the windows Device Manager. then re-boot the PC. If the registry is in a more serious mess John can help with Registry editing. It would need more logging first. Pete

Your joystick IDs have probably changed. You aren't using Joy Letters (you should do). Also, look at the [JoyNames] in your INI file: [JoyNames] AutoAssignLetters=No 2=Bravo Throttle Quadrant 2.GUID={B37451E0-502C-11EB-8001-444553540000} 4=Alpha Flight Controls 4.GUID={FB8E0F80-0B07-11EB-8001-444553540000} 1=Saitek Pro Flight Rudder Pedals 1.GUID={A50CABA0-0C9A-11EB-8002-444553540000} 1.WARNING=This joystick was ID 2, but was duplicated: review and fix assignments, reload settings 2.WARNING=This joystick was ID 3, but was duplicated: review and fix assignments, reload settings You have a registry problems with both the Throttle Quadrant and the Rudder Pedals. You have lots of button assignments to device 1, which is now your Rudders -- seems unlikely that it has so many buttons. You have assignments to axes and buttons on a now non-existent device 0. If you have your previous INI file, from when the assignments were correct, then it would be easy to simple change the numbers assigned in your [joyNames] section. You should be able to figure it out yourself. But the duplicate device 2 and 3 IDs are worrying. You might need to try some registry tidying up first. And when it is sorted at the AutoAssignLetters parameter to 'Yes', so FSUIPC can keep track in future. Pete

Because they evidently check specifically for FSUIPC5. I don't know why, you'd have to ask them. However, as John points out, you need to update your LINDA. Evidently they changed that check in the later version. If the later version of LINDA doesn't work that needs sorting out. FSUIPC5 will not be probably not be supported for much longer. Pete

I think you have ignored much of what John has been telling you. "Spoofing" is done via offset 0x0024. Writing direct to 0x3367 will not work! Please go back and read the whole thread again but more carefully. i'm really surprised John has had so much patience with you! Pete

Fine, but you should certain make an extremely strong complaint to the LINDA people. If it refuses to run with FSUIPC6 it can only be because they've deliberately incorporated a check on the version number, because FSUIPC6 is 100% compatible with FSUIPC5. The whole point of the way the FSUIPC programming interface has evolved (and the Lua library included) is to do with ongoing compatibility. This has been so since FS98 days. New facilities are added but existing facilities are kept compatible. It would be possible for an application to be written for FSUIPC6 or 7 and not be compatible with FSUIPC5 or 4, but not vice versa. Pete

I think it depended very much on the aircraft concerned (the amount of data to collect). PMDG add-on aircraft are notorious for flight saving as they freeze their operations whilst collecting all of the internal data for saving in several additional files, on top of those which P3D produce. I suppose it is inevitable that as the simulation of aircraft and flight gets ever more sophisticated and detailed that the collection and saving of data for each possible saved restart instant will take longer. There are several answers. One is to be satisfied with only a save every 30 seconds or more, and put up with the short freeze, and another is to use the recently added facility to trigger an autosave by added FSUIPC control, and so choose your own moments (by buton press, perhaps). There is a plug-in to do this automatically when on approach, as perhaps being the most usual part of a flight needing a retry. See: Pete

I replied to this where you posted on AVSIM, but I'll repeat it here for completeness. This is a well known result of the saving of the files for the flight. FSUIPC does nothing except send the save request to P3D and delete the oldest in the cycle. The same would occur if you did it manually (plus the time to enter the menus etc) -- the extra in FSUIPC is just the deletion of the oldest save in the cycle. It has always been the case and the code in FSUIPC can't be any more efficient as it is so simple. You could stop the deletion of the oldest in cycle if you want -- just use the "also save" option instead of the regular cycle of a selected number. If you've never noticed before then it must have been because of more efficient disk organisation (eg less full) or something else related to the file operations. FSUIPC cannot influence how and what P3D saves in the flights and associated files. Pete

No. Plug-ins are user facilities, not part of the core interface which has always been free for freeware and shareware programs. No. How do you expect software developers to make a living, to be able to spend so much time developing and maintaining programs against moving targets such as MSFS and P3D? User-oriented facilities will not be 'given away'. Sorry. Maybe you need to learn some programming. These are features which an application interfacing to FSUIPC could include. Pete

Your key won't stop working. Are you sure you installed FSUIPC5, not FSUIPC6? If so you are simply making a mistake entering one or more of the details. All three parts -- name, email and key -- must be exactly as in your notification. Use cut and paste. Pete

Before FSUIPC receives ANY data from Sim all of the offsets populated by SimVars will be zero. FSUIPC doesn't invent any of these values! Try using the Offsets facility in FSUIPC's logging in order to show the values in the log as they change. This will not only show the offset itself but also the actual value read from SimConnect. It sounds like SimConnect is first sending the default (on ground) value when initialised, but this additional logging will show. you'll need to set this logging option in one session so it starts off enabled in the next. FSUIPC can only pass on what it gets. it may change to scaled value, to maintain compatibility with past FS versions, but it doesn't do any real state changes on its own. Pete

Look in the FSUIPC Documents folder first!! The FSUIPC implementation of Lua is pretty clearly laid out in the documents provided, and there are plenty of examples to look at in the ZIP file also provided. For the language itself there's the website www.lua.org and there are some good books too. For what you want to do it's only really matter of a loop writing to the offset(s) using ipc.writeUD with the timing dictated by ipc.sleep. See the FSUIPC Lua library pdf. Pete

Does the trim wheel turn continuously, or does it have stops? If it has stops there's nothing you can really do except make sure it is in a sensible place each time you close down so that it is okay next time. If it doesn't have stops then it is more difficult. What happens at the crossover point: does it suddenly change from s maximum to a minimum value and vice versa? I've never heard of an axis with no end points. You'd probably need to deal with is using a Lua plug-in, to arithmetically convert the value you read into a value relative to the neutral point (0), allowing for the wrap-around of the value where the end stops should be. Pete

FSUIPC offers options to display these facilities in the AddOns menu: Load a Flight Load a Plan Save a Flight but there's no "Save a Plan". Unfortunately this is not an option offered in the Sim's facilities. Those three are making use of Simconnect functions. (The Save a Flight function is also used by the FSUIPC AutoSave facility). Just a choice of where you want to store them. Perhaps you like having them categorised according to aircraft used, or areas of the world. Pete

I very much doubt there's a way in MSFS -- there never was any way of doing that in FSX or P3D that i know of. I think it would have to be implemented as a possibility in the individual add-on aircraft. 25 mSecs is only 40 times per second. You'd probably need the sim running at 20 fps or less in order to even have a chance of not getting any flutter. You could try a lot faster, but i fear you'd then come up against the problems of the inter-process delays -- your program, FSUIPC and MSFS. You might be able to do it by writing your own WASM module running inside the simulator. I don't understand what this is about. Why are you opening and closing the connection to FSUIPC? What are the errors? Note that a simple Lua plug-in could run the repeats much faster than 25 mSec intervals. Pete

The WideClient log shows a connection, but the Server log doesn't. Thee reason is that you supplied a Server log timed at 17:52 whilst the Client log is at 11:48. It's no use providing logs which refer to totally different sessions. Furthermore, after 15 seconds of waiting for the Server to be ready, the Client log shows a good connection with the exchange of lots of data: 901609 ****** End of session performance summary ****** 901609 Total time connected = 805 seconds 901609 Reception maximum: 32 frames/sec, 1486 bytes/sec 901609 Reception average whilst connected: 24 frames/sec, 982 bytes/sec 901609 Transmission maximum: 9 frames/sec, 373 bytes/sec 901609 Transmission average whilst connected: 0 frames/sec, 24 bytes/sec 901609 Max receive buffer = 876, Max send depth = 2, Send frames lost = 0 901609 **************** Individual client application activity **************** 901609 Client 2808 requests: 385 (Ave 0/sec), Data: 398218 bytes (494/sec), Average 1034 bytes/Process and that last entry refers to 33391 New Client Application: "pmfilecheck" (Id=2808) and shows it read a lot of data. So if it doesn't like what it is reading you need to refer to PM support. Maybe it is not compatible with your current FS version. Pete

Does it not register in FSUIPC's Axis Assignments tab? If not, check if it works in Windows own game controller. Calibrate it there first to make sure it is registered correctly in Windows. That looks okay. If you enable axis logging in FSUIPC does it log the PAN VIEW control? If so it is definitely getting sent to P3D (the log is from notifications by P3D's SimConnect). Just ZIP them! They are simple text files and ZIP up really small! Not for FSUIPC5, for which development has ended. You could put a request in to John for such an enhancement in FSUIPC6 or FSUIPC7, but I know for FSUIPC6 at least it is not a trivial job. The options screen is a standard Windows tabbed dialogue and it appears as that facility dictates. You could possibly try increasing the font scaling in Windows, making the text larger, but that might result in text partly disappearing outside its confining box. I know it used to on Windows 7 but Windows 10 may handle it better. I have a similar problem in that I have a 7680x2160 display on a large curved screen. The size is good enough, but the curving and the blending in the centre makes dialogues hard to use with mouse positioning. What I do is have another cheap small monitor to the side and have the options (and other things) positioned on that. If it a normal 1920 x 1080 monitor. FSUIPC will remember the position. Pete

I upgraded to 5.2 and have no such problems. There really isn’t anything in FSUIPC these days which is dependent upon P3D differences. All that finished with the change from 32 to 64 but (P3D3 to 4). There will certainly not be an update simply because 5.2 has been released. I think you need to look elsewhere in your system. FSUIPC doesn’t ‘manage’ devices, it simply responds to signals from them. Your devices are managed by Windows and possibly your USB hubs. Check that your install of 5.2 has not reenabled P3D joystick processing. Pete

No. If WideFs is enabled in FSUIPC (check that) the if WideClient isn't receiving the version number for FSUIPc then it is more likely to be a problem of communication between the PCs -- probably a firewall issue. You need to show the WideClient.log from the TC PC and the WideServer.Log from the P3D Pc. Pete

I'm actually retired and have little to do with MSFS, and John doesn't work 24/7. I'm just trying to help. And you are not asking specifics. A specific is stating exactly what to want to accomplish, specifically, and then we can assist, specifically. Incidentally, if you truly want SimConnect SimVars as opposed to values derived from those and written for you into offsets, then why aren't you using the SimConnect SDK instead? Please do go and have a look and see how easy that is. I'm going out soon so there may be a delay till a further reply, unless you are very quick. Pete

Reading offsets to get sim values is just a matter of using the relevant ipc.readXXX library function. You would need to refer to the Offset list to find the values you want , noting the offset value (0x????) and the size (signed or unsigned, byte, word, dword, float double or string), and read them in your script using the appropriate ipc.readXXX function. Many of the example Lua plug-ins provided show uses of these functions. Take the VAS_Monitor or the ThrustSym ones, for instance. You need to make a little effort to help yourself. We cannot spoon-feed you. Sorry. Pete

Check the Lua Library document for event.terminate. That will call a function in your plug-in which can turn off your LEDs. If you don't understand Lua itself you will find lots of assistance on www.lua.org. There are also several good books on it -- start with "Beginning Lua Programming". But for many simply things the examples provided in the ZIP file should help. mostly, in simply plug-ins, the code is almost all calls to FSUIPC provided library functions, documented in the Lua Library PDF. We can help if you don't understand the library functions, but we cannot undertake to teach Lua. Pete

When changing PCs the "GUID"s, which are guaranteed unique but which are generated afresh on your new PC, will be different. This section of your new INI defines which device each of your letters actually now refer to: [JoyNames] AutoAssignLetters=Yes 0=Controller (Gamepad F310) 0.GUID={AEE20C10-C9DC-11EB-8002-444553540000} 1=Flight Yoke System 1.GUID={FE9129C0-CA9B-11EB-8001-444553540000} 2=Saitek Pro Flight Rudder Pedals 2.GUID={FE9150D0-CA9B-11EB-8002-444553540000} 3=Saitek Pro Flight Quadrant 3.GUID={FE9BB110-CA9B-11EB-8003-444553540000} A=Controller (Gamepad F310) A.GUID={AEE20C10-C9DC-11EB-8002-444553540000} B=Saitek Pro Flight Yoke << MISSING JOYSTICK >> B.GUID={FE9129C0-CA9B-11EB-8001-444553540000} C=Saitek Pro Flight Rudder Pedals C.GUID={FE9150D0-CA9B-11EB-8002-444553540000} D=Saitek Pro Flight Quadrant D.GUID={FE9BB110-CA9B-11EB-8003-444553540000} E=Flight Yoke System E.GUID={FE9129C0-CA9B-11EB-8001-444553540000} If you can recognise which should be which you merely need to change the letters accordingly. I can see two which should be easy to change, but you first need to delete the two lines starting "B", as that one doesn't exist now. It would be much easier if you still had a copy of the INI file from your previous PC. Then the changes would be easy t do as you could match one to the other (or I could do it for you). I can do a little -- according to your [Axes] assignments A should be your Yoke and B your pedals, so instead of E: A=Flight Yoke System A.GUID={FE9129C0-CA9B-11EB-8001-444553540000} and instead of C B=Saitek Pro Flight Rudder Pedals B.GUID={FE9150D0-CA9B-11EB-8002-444553540000} that leaves just: A=Controller (Gamepad F310) A.GUID={AEE20C10-C9DC-11EB-8002-444553540000} D=Saitek Pro Flight Quadrant D.GUID={FE9BB110-CA9B-11EB-8003-444553540000} Strangely you don't seem to have any Throttle assignments for the quadrant -- only one throttle on the Yoke system. Aren't you using the quadrant? So, that just leaves some button assignments. Those appear to be either on the yoke system (already sorted), or device C. So: C=Controller (Gamepad F310) C.GUID={AEE20C10-C9DC-11EB-8002-444553540000} And that completes it, giving: A=Flight Yoke System A.GUID={FE9129C0-CA9B-11EB-8001-444553540000} B=Saitek Pro Flight Rudder Pedals B.GUID={FE9150D0-CA9B-11EB-8002-444553540000} C=Controller (Gamepad F310) C.GUID={AEE20C10-C9DC-11EB-8002-444553540000} D=Saitek Pro Flight Quadrant D.GUID={FE9BB110-CA9B-11EB-8003-444553540000} Try replacing the contents of the [JoyNames] section with that. Pete

I've moved your message to the Support Forum. Please do NOT post support questions to any of the reference subforums. FSUIPC5 is replaced by FSUIPC6 and is no longer in development and is not sold. I think you must be wrong in any case -- there are plenty of Linda users on FSUIPC6 (and even FSUIPC7, for MSFS). Check with Linda support. Pete

That's one way. Or just uncheck the assignment in the Axis assignments tab. If you assign another control in the same line (there are 4) then it will replace the previous one in any case. Unticking it instead allows you to change from "Direct to ..." mode to "Send to FS" mode, where you can access the Axis ... Set controls. Pete