Pete Dowson

I am still awaiting information on this from the first person who posted several days ago, so I've not been able to do anything about it yet. Can you do the same checks and supply the information, please? Otherwise we shall get nowhere! Pete

Having ours very soon. I always enjoy my wife's delicious Sunday roasts,with lots of tasy veg! 😉 Pete

Why? They are all essential. If you reinstall and Register, then the FSUIPC4.KEY file will be produced. It is a text file containing the registration details. Then, when you run the sim, the FSUIPC4.INI and FSUIPC4.LOG files will be produced. They are an essential part of what FSUIPC does! What is worrying you? Why fussing over these? Just carry on and use your purchase! Pete

What error message? What does it say? Error messages are messages to tell you something, after all. The two deletions you mention appear to be identical! How do you "rerun the registry"? What does that mean? And what is the end result of this error? Pete

Yes you do! You've not disabled the stupid Windows Explorer folder option which hides filetypes from you. The Installtion guide for SUIPC tells your how (last page of 6). See the 3 files just shown in your pic as "FSUIPC4"? There are NO files with that name, In fact you can't have two or more files with the same name. One will be "FSUIPC4.KEY" (your registration), one will be FSUIPC4.LOG, and the other FSUIPC4.INI The FSUIPC4_Prev file os also .LOG (the previous session log). Pete

I think I'll use SET_PCTS and SET_SCRN, with the latter defaulted if omitted for compatibility. setowndisplay will use SET_PCTS automatically, and, for now, discard the title. Ah. Ah you full screen? If not it automatically disables in any case. I should have mentioned that. When i first implemented it, it wasn't optional and tried to work no matter what. But when folks changed between full screen and windowed it all got into a mess for them. There was really no way of making it work cleanly with a Window which can be anywhere. The sizes and positions are saved in the INI file in new sections -- but only once the displays have been used once, because they don't seem to exist till then. in a session, once used once they always exist even if not visible. If you send me an email (petedowson@btconnect.com) by Monday when a test DLL is ready I'll send a link. (DLL's like EXE's don't pass many checkers these days). Pete

Further to my last message, I think a work-around i eventually hit upon is working well. Would you like to test it further for me? I can make an interim build (replacement DLL only) for Monday. I am also thinking of having an option so that: ipc.setdisplay(SET_PROP, x, y, cx, cy) (say -- not sure of what name to give the option selection. PROP is ambiguous. PERCENT perhaps?) which would enable the Window still to be set in relative proportional coordinates the same as setowndisplay used to. If I do that I can resurrect setowndisplay so it acts like setdisplay except of course for the "own" part, until (or if) I manage to find a way ... Pete

Ah ... but surely that, like all of those, if checked by default? I've never seen any of those options unchecked (I uncheck them all myself in my cockpit installation, because I have the test and message windows tranmitted via WideFS to a little screen in-cockpit). FSUIPC should save the sizes and positions for you and restore them next session. You have to change "RestoreSimcWindows=No" to Yes in the [General] section of the INI file. I've made progress since my last message, but I don't think it is foolproof. doing more checks now ... I agree. I used to use it a lot when I was developing my cockpit software. Pete

FSUIPC Logging Tab, enable Event logging. Operate the switches and look in the Log to see what it did, if anything. Note that some add-on aircraft won't use standard Flight Sim control codes. Folks then resort to either Mouse Macros or L:Var access, whichever works for that aircraft. But try seeing if standard controls are being used. Of course, if the add-on aircraft authors have kindly provided keyboard shortcuts for them, you can assign joystick buttons to those instead. BTW please always post support questions to the Support Forum (i.e. here). Also, for specific aircraft you might find you get answers from folks who know the answers if you mention the aircraft in the subject title. Also mention which Fight Sim as it will likely be different between them. Pete

I am currently investigating a problem whereby trying to set the display size and position more than once appears sometimes to stop the display actually appearing. i think this is a bug in P3D4, because all the correct calls are still being made to SimConnect. What seems to work reasonably consistently is using setdisplay only AFTER displaying something. But even then it appears to be precarious. I am trying to find a work-around at this moment. No luck so far after several hours of trials. On your previous points: 1. I will be removing "setowndisplay" completely in FSUIPC5 until I can find a way of doing it in P3D4 2. The coordinates and sizes in setdisplay are in SCREEN coordinates, and the top left position specified is relative to the main P3D window. This has always been the case. Only the setowndisplay was in percentages of that window. 3. I think this next part is the same problem as the first paragraph above. It's to do with repeated use of the setdisplay function in the same session. You might find that it works more consistently if you do the setdisplay AFTER the display. I don't think it is related to the simple one-line text display. It is certainly due to the attempts to size and move the Window -- something done via Windows itself, not via Simconnect as the latter provides no such facilities (and shouldn't really need to). P3D4 seems to use some method of hiding the wndow which contrives to stay hidden one the change is made via Windows. I'm trying to track that down. BUT you don't NEED to position and size the Window. I'd recommend commenting out those attempts until I can sort it out, if indeed that is possible without L-M's cooperation. Pete

You have B, C and E referenced in the [Axes] section: 0=BX,256,D,1,0,0,0 -{ DIRECT: Aileron }- 1=BY,256,D,2,0,0,0 -{ DIRECT: Elevator }- 2=CX,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 3=CY,256,D,8,0,0,0 -{ DIRECT: RightBrake }- 4=CR,256,D,3,0,0,0 -{ DIRECT: Rudder }- 5=EY,256,F,66994,0,0,0 -{ TO SIM: AXIS_ZOOM }- 6=EZ,256,D,10,0,0,0 -{ DIRECT: Throttle2 }- 7=ER,256,D,9,0,0,0 -{ DIRECT: Throttle1 }- 8=ES,256,D,21,0,0,0 -{ DIRECT: ElevatorTrim }- Similarly the [Buttons] section has references to B and E (plus two good ones to T). The sections for Profiles are not revised UNTIL they are actually read, which will be when you load an aircraft with that profile. Pete

Error message seen where, when (during loading?), which flight Simulator, which version of FSUIPC? I can't answer questions with no information at all. It isn't a message from FSUIPC in any case, so you need to say what program you think it is from! If it is a program trying to use FSUIPC then the error means that FSUIPC "maybe running on WideClient, but FS not running on Server, or wrong FSUIPC". Pete

It's the assignment of the ID numbers which should make it "seen" (i.e. not clash). AutoAssign merely assigns A, B, C, D ... etc to whatever devices are uniquely seen. Otherwise it is the same as manualy choosing letters. (The latter is obviously better in the sense that you can then assign meaningful letters, like J, T, W, R. but it is an easy option to let FSUIPC do it for users not so good at editing files). There must be assignments to those. Deleting the entries in [JoyName] cannot change those. You'd need to delete the assignment lines to those letters in the Axis and Button sections, or, better, cange the letters to the ones you want assigned. Once you've started using letters, whilst they will be automatically used to change the previous numeric ID assignments in those sections, undoing them is not automatic. It cannot be, because as "missing joysticks" FSUIPC doesn't know which other letter to use. I suppose it could just delete all such lines, but then folks wouldn't have the better option and changing the letters (see your point 2, which is exactly this). This is the problem I've just explained above. you would either need to change them to the correct letter, or easier, change the letters to the A, B, C etc, as appropriate, in the Joynames section. Which you choose to do would depend on how much work changing the assignments represents. Best always to ZIP files as, being pure text, the Zip up pretty small. However, it makes it easier for both of us, with text files, simply to click on the <> button just above, and paste the whole text into the box presented. This produces a result like this (for this paragraph in this case): Best always to ZIP files as, being pure text, the Zip up pretty small. However, it makes it easier for both of us, with text files, simply to click on the <> button just above, and paste the whole text into the box presented. This produces a result like this (for this paragraph in this case): Scroll bars are provided for overwide text and long texts. Pete

You supplied useful files, but not the FSUIPC5.INI file, in which you define the ID numbers. The problem, as shown in the Log is that the same ID is being used by both devices: 265 Device acquired for use: 265 Joystick ID = 3 (Registry fixed) 265 3=Saitek Pro Flight Cessna Trim Wheel 265 3.GUID={ED1EE8B0-A133-11E8-8001-444553540000} 265 Device acquired for use: 265 Joystick ID = 3 (Registry okay) 265 3=F16 MFD 2 265 3.GUID={B6D35820-5B64-11E6-800A-444553540000} Best show the INI file next time. Meanwhile try changing it to define a free ID for one or the other, such as 5. Naybe use 5 for the trim wheel as you aren't assigning to that at present. Be sure to changet both the 3= and 3.GUID= lines. I hope you are using Joy Letters so that assignments you make are retained should the IDs change. Pete

But Lua is slower that a program could be to do the same thang, and the fastest changes there appear to be of the order of 100 mSecs or more per change. Isn't that enough for you to see it? What sort of programming are you doing? You said: There's none in the log that brief, so I'm not sure what the log is to illustrate. Unless of course the frame rate waa 10 fps or less. I don't think there's any way FSUIPC, let alone Lua, will see very quick changes, of the order of any reasonably usable frame rate. It might do if it were a SimConnect variable, but L:Vars are available through SimConnect. Pete

I don't know of one, but then I have never written a Gauge and really know nothing other that a few of the functions availble to gauges (and DLLs of course), such as those to read and write L:Vars, and enumerate them to get their names. FSUIPC makes little use of the PANELS interface, and this is one (or tather "these are 4" actually). Since I think many of the gauges using these variables are written in XML (?), maybe some sort of intervention is possible, using XML? I don't know I'm afraid -- XML is merely a parameter setting system to me, I have no idea how it is used for programmng. Sorry. Pete

But FSUIPC will not log a keypress out of nowhere. It happened according to the log, and twice. Perhaps you showed the wrong log. Try to do the test again and show me a log with no such keypresses. Well that's the log I need to see, please. You could also go into the Logging tab and, on the right-hand-side, use two lines to add offset 3110 as type "U32" decimal (not hex) and offset 3114 the same. Then check Normal Log below. That will show when Prosim is writing the 1009. Could the V1 signal be getting signalled more than once? Of course, that still wouldn't explain impossibly occurring keypresses! 😞 I might be able to try it over the weekend. My cockpit is "being worked on" at present (and keeping me very busy!). 'll add it to thge list of things I need to do when it is next up and running. Pete

Yes. FSUIPC5 is not FSUIPC4. They are different products. FSUIPC5 is 64-bit and matched exactly to P3D4. Your WideFS7 key will still work, however. There was little change needed for that to make it work with P3D4 and the WideClient end of the connection is identical. Pete

No, not as it stands at the moment. No one has ever asked for that, and I'm not sure how easy it would be to implement, because the 10 seconds are from an event used by other parts. Using a Lua plug-in which loads a program using the ext library functions would allow you to do what you want, with more flexibility. The Lua plug-in facilities were added specifically to meet needs not thought of before or not asked for at a more appropriate time. Take a look at that. The Lua documentation is in your FSYUIPC Documents folder. Pete

Which version of FSUIPC5 and which version of P3D4? Pete

My son John has just pointed this part out to me. You MUST use P3D4.1 or later to run the latest version of FSUIPC! You should really be using P3D4.2 or later (4.3 is current), as I'm not sure what state the underlying P3D facilities were like in 4.1 even. Pete

I moved this support question from the FAQ subforum, which is a repositiory for answers to FAQs. Please always post support questions to the support forum. What "indicates" this, and how? If all cards appear completely identical to Windows, it might mix them up. Once all installed, this should happen again if you never move them to different sockets or unpug them and reconnect them later. You need to enable the Lettering system in FSUIPC INI file -- please see the Joy Letters chapter in the FSUIPC User Guide, You mean joystick type devices. FSUIPC cannot distinguish an "interface card" from any other device classified by Windows as a "joystick". The limit in FSUIPC derives from pre-DirectInput days of Windows, which used IDs 0-15 only. So the limit for FSUIPC is 16 such devices. Hopefully Windows will differentiate them by serial number. FSUIPC is dependent on the entries Windows makes for them in the Registry. Windows assigns "GUIDs" (complex and unique 64-bit ID numbers) which should remain fixed for the same device even if moved. But this may not happen, and moving them may change IDs. If the GUID stays fixed, the Joy Letters get over the problem of IDs changing. Pete

Yes, they are. Pete

Sorry, but there is nothing in FSUIPC which is location dependent. It may however be a corrupted weather file being read by SimConnect. What version of FS and FSUIPC are you using (information ALWAYS required)? Pete

Hmm. That is indeed very strange. That sounds as if the "rectangle numbers" are changing, being assigned at load time not defined in the panel definitions. I don't have those aircraft so I can't test specifically, and I don't seem to have such a problem with default aircraft. If that is happening, it is a serious deficiency in the facilities L-M provided. Can you test this for me before I report it to them? Do this by: 1. Start creation of a macro file with a new name (say "test1"). Choose one of the switches on which this definitely happens, and make a macro for it. Then end macro making. 2. Close the sim down and start it again. 3. Start creation of a macro file with another new name (say "test2"). Choose the SAME switch, and make a macro for it. Then end macro making. 4. Show me, or attach for me, both macro files. They are plain text inside, so you could simply paste the couple of lines from each here. If they are different, that would explain what is happening and be grounds for me to ask L-M what is going on. Thanks, Pete