Pete Dowson

Sorry, those links tell me that LINDA does it for you, for certin aircraft at least. What is it you now want to do? The image you posted looks like one from an iPad or Android running EFC for ProSim. Pete

If you have a small Lua plug-in which gives the problem, and which I can run here with P3D, then maybe I can work out why. The Lua interpreter coding is very similar -- identical for the most part. Pete

Yes. It's a different product, as P3D4 is from P3D3 and FSUIPC4 was from FSUIPC3. It's the first new product from me for 12 years. Not now. There was for the first few months. Pete

Ah, so something in the mean time is corrupting something. I wish you'd told me it wasn't consistent in the first place. It would have saved be delving into archives on another PC. You said and that almost explicitly says "others crash ... if they are used". Never mind. Not if it works some of the time. I suppose it could be a timing glitch, catching FS9 when it isn't able to respond to the request for a Container pointer for the panel. You're not changing aircraft whilst this is going on I hope? The only way to tell if it is timing would be to slow it down. You could try using FSInterrogate for a similar batch of offsets and having that repeat fast, too, just to see. Otherwise, it it isn't an FS9 timing problem -- FSUIPC asking for something not possible at that time, or maybe asking for it before the previous response is provided, then it definitely seems like some corruption is occurring, but, i'm sorry, there's no way I can track it down. Do you have FSX? If you can reproduce it with your Lua plug-in on FSXthen it must be related t the Lua interpreter and I can maybe get an idea of what it is, even if i can't fix it on FS9. Pete

To eliminate the Lua end, ry using FSInterrograte to read offsets directly? I think 036C, 0B18, 0BCC, 0BE8, 11BE use the same methods -- as far as I recall it's a request to the PANEL of the aircraft. Are you using an add-on aircraft of a default. If a default then I would suspect some corruption in your FS9 installation, maybe in FSUIPC3 itself. Even if it is an FSUIPC3 bug,I'm sorry, but I'm afraid I'm well beyond any ability to find it and even less fix it. 02C8 is the current vertical speed and I'm sure many programs for FS9 must be reading it quite happily. The Lua support code to read offsts is no different fom one offset to another -- as I said, they are, by then, all simply numbers in memory, bo action is carried out. So it must the the part of FS which FSUIPC is calling. [LATER] Did some more research with some archives. Those variables depend on a "container" for the aircraft, where the latter is identified by an ID. The same data is read not only for the user aircraft (for those offsets) but also for all the AI traffic. So my TrafficLook program will be requesting the same values, albeit not from the same offsets. Another test, to check, in any case. Pete

Okay. Apologies. I found another code entry which does a FORWARD search for the '.' character, and removes everything thereafter! This was done to fix a program with certain P3D airport names which ended with a '.' -- this caused any flight saved with that airport name at the end to have "..fxml" at the end, which then failed when sent to SimConnect to do a flight load! I reported this to L-M, so they probably eventually fixed one or the other (airport names, or SimConnect FlightLoad, or both). However, I "fiddled" it in FSUIPC so that users could continue safely as they were. This fiddle" has come back to bite me, it seems. 😞 I will remove that fiddle -- or rather make it conditional on seeing ".." not just ".". Then adding another .flt at the end of your strings will work. This will just be for P3D4 and FSUIPC5. Okay? Pete

Just find the [Profile.A2A Comanche] section in the FSUIPC ini file, and delete the line in that section referring to the V-Tail. Pete

Is the text actual ASCII characters, or part of an Image? If it is a character string then of course you can using the standard Lua string library functions to search for specific words or phrases, and thus act upon them. Refer to string.find. Image recognition is far too complex. I doubt if Lua is the right language for that, and I wouldn't know how to even begin! That image looks like it is from the EFC program which is in Beta at present, from the ProSim forum. Correct? On P3D4 you can get texts as above, in searchable string form, from SimConnect directly, or using FSUIPC + WideClient. Then run your Lua program in the client. Pete

Yes, of course. Selecting "Extras" in the Logging tab is recorded in the Settings, like all the other selections there. What is confusing you? BTW, not relevant to this problem, but these logged errors: IPC ERROR: Unrecognised FS6IPC request indicate that the request block being sent to FSUIPC by your program is corrupted, or improperly terminated. I'm wondering if that is also related to your using character '0' instead of a real zero byte to terminate strings elsewhere? Otherwise it could be a length being set incorrectly. That's a concern. I'll double check here that it isn't being removed twice. Before I wrote last I did go through the function activating the SimConnect call, and it definitely looked like it only did it the once, seraching from the end backwards for the last '.' character. Pete

Sorry, you mean nothing appears to have changed at all even with the updated version? I am now confused! Looking at the only part of the PFChid64 log which appears to be all of the testing of TankSelect you did, from here on: 3078: Using macros from "C:\Flight Sim\Prepar3D v4\Modules\PFC.mcro" selected 3078: Macroflag mask for "TankSelect" = 00070004 These three lines show position 1 using the correct macro: 11328: Device #2 received: TankSelect[0] = 1 11328: Full macroname for decoded switch = "PFC:TankSelect1/1", mask = X00070004 11344: Requested macro "PFC:TankSelect1/1",00 via offset 0D70 Then this is position 3: 15375: Device #2 received: TankSelect[0] = 3 15375: Full macroname for decoded switch = "PFC:TankSelect1", mask = X00070004 15375: Requested macro "PFC:TankSelect1",0E via offset 0D70 which does not select a /3 macro! Then there's another position 1, followed by positions 0 then 1 then 0. 19235: Device #2 received: TankSelect[0] = 1 19235: Full macroname for decoded switch = "PFC:TankSelect1/1", mask = X00070004 19235: Requested macro "PFC:TankSelect1/1",00 via offset 0D70 23110: Device #2 received: TankSelect[0] = 0 23110: Full macroname for decoded switch = "PFC:TankSelect1/0", mask = X00070004 23110: Requested macro "PFC:TankSelect1/0",00 via offset 0D70 27375: Device #2 received: TankSelect[0] = 1 27375: Full macroname for decoded switch = "PFC:TankSelect1/1", mask = X00070004 27375: Requested macro "PFC:TankSelect1/1",00 via offset 0D70 Another position 3 for the same tank: 31157: Device #2 received: TankSelect[0] = 3 31157: Full macroname for decoded switch = "PFC:TankSelect1", mask = X00070004 31157: Requested macro "PFC:TankSelect1",0E via offset 0D70 But no test of position 2 on the first switch! You moved to the second switch: 34235: Device #2 received: TankSelect[1] = 1 34235: Full macroname for decoded switch = "PFC:TankSelect2/1", mask = X00070004 34235: Requested macro "PFC:TankSelect2/1",00 via offset 0D70 36641: Device #2 received: TankSelect[1] = 0 36641: Full macroname for decoded switch = "PFC:TankSelect2/0", mask = X00070004 36641: Requested macro "PFC:TankSelect2/0",00 via offset 0D70 40516: Device #2 received: TankSelect[1] = 1 40516: Full macroname for decoded switch = "PFC:TankSelect2/1", mask = X00070004 40516: Requested macro "PFC:TankSelect2/1",00 via offset 0D70 So, positions 1 and 0 on that apear to be okay. Finally we get to the only test of position 2: 41719: Device #2 received: TankSelect[1] = 2 41719: Full macroname for decoded switch = "PFC:TankSelect2", mask = X00070004 41719: Requested macro "PFC:TankSelect2",0F via offset 0D70 which, like postion 3 on the first switch, doesn't select a /2 macro. So from that log it appears that there's a problem with TankSelect1/3 macro, and TankSelect2/2 macro. Now, looking at your macro file: [Macros] 1=TankSelect1/0=C65958 2=TankSelect1/1=C65955 3=TankSelect1/2=C65957 There seems to be no TankSelect2 macros supplied in any case (!???) and no TankSelect1/3 macro. So, please, what is going on at your end? The macro file doesn't appear to match the log, and is incomplete in any case. I can't see anything I can do this end, it appears to be incorrectly configured, that's all. The bug I fixed was that with certain mactos, the switch was being placed into a "scan" list and so repeatedly queried and actioned. That's appropriate when the offset being set doesn't match what is needed, so that the computer settings stay matched to the switch setting. But it gets into that never ending loop when you have a macro not setting that value into the offset. with macros it shouldn't have attempted to match anything. BTW in FSUIPC you are Monitoring offset 0D70 with the wrong Type seleected. Please change that to an ASCIIZ choice for your next test. Pete

I tried, but NOT work ! I have checked the code which was added to remive the .flt part of the fi;ename provided, and it is very simple. All it does if find the last '.' character in the name, then if the string at that position is equal to ".flt", replaces that with a zero, as string terminator. This would mean that the ending ".flt.flt" changes to just ".flt". So it must work. I think you must have made an error. Can you enable "extras" logging (one of the options in FSUIPC's Logging tab), then try one of your flight loads and let me see the Log, please. I think this would be better than fiddling an option in 3F00, and it will also work in P3D3 and FSX with FSUIPC4. I am in England, and night is almost the same time! 😉 Pete

What did you download? It's a ZIP file, containing Installation instructions and an Installer! ZIP files are not Adobe icons of any sort, let alone "Adobe Air", whatever that is! Pete

And TankSelect1/3 worked before? What about TankSelect2/3? The number is simply a number. The code doesn't do someting different just because its a 3 instead of a 0, 1 or 2. I could really do with seeing your current macro. Pete

Why not just read the documentations?

The problem is not that the buttons aren't recognised. They are, and FSUIPC is sending the control. The problem is much more serious. you P3D4 system appears to have a corrupt SimConnect. Every FS control FSUIPC attempts to register with SimConnect, by its correct documented name, is rejected as unrecognised! There's one possible error which might cause such corruption: a bad wxstationlist.bin file. Try deleting that before loading P3D. It's in your AppData\Roaming folder for P3D4. (FSUIPC 5.14 was changed to delete that in any case on proper close down of P3D4, but your system is not closing properly! Both of the Logs you've shown end with: 123812 === Closing session: waiting for DLLStop to be called ... That's only the start of the closing process! So that file isn't being deleted! I am not sure why it isn't closing -- I think another of your add-ons is stopping it. Otherwise but the only fix I can think of is an uninstall and re-install of P3D. You might get away with doing that just for the Client component, but if it is due to corrupt files you'd need to do it completely. Pete

Okay. The aircraft which shows as loading in the LOG file was: F-4J VF-103 which doesn't have a Profile, so your default button attignments should be operative. i.e. 6=P1,5,C65758,0 -{FLAPS_INCR}- 7=P1,4,C65759,0 -{FLAPS_DECR}- 8=R1,21,C65607,0 -{ELEV_TRIM_DN}- 9=R1,19,C65615,0 -{ELEV_TRIM_UP}- 10=R1,22,C66276,0 -{AILERON_TRIM_LEFT}- 11=R1,20,C66277,0 -{AILERON_TRIM_RIGHT}- 12=P1,6,C65589,0 -{SPOILERS_TOGGLE}- and on a POV: 4=R1,32,C66416,0 -{PAN_VIEW}- 5=R1,36,C65734,0 -{PAN_UP}- I don't see anything wrong at all, so I need more logging to help. In the INI file please add thesetthree lines to the [General] section: Debug=Please LogExtras=3 LogButtonsKeys=Yes Then run P3D. When it is readyto fly, press each of those buttons, once each. Then end the session before the log gets too big. Show me the Log from that, please. It would also be useful if you can figure out what changed since a few months ago, when it was okay. Pete

Those files show nothing wrong. It is the INI file, the one with your settings, which is more important. The fact that it was okay last time you used the Sim, and now, with no changes whatsoever (is that right), suddenly the buttons do not work is difficult to imagine. FSUIPC reads buttons and axes together, they are not separable. So either your settings have been corrupted (and you haven't shown those), or there's a problem with your configuration which has somehow changed all by itself. There's no way I can tell from the inforamtion you supplied. Pete

Sorry, but gauges are run as part of the FSX process and can only be run on the FSX PC as part of that process. WideFS is a way of extending the FSUIPC programming interface to networked PCs, so enabling a number of FSS utilities to be run remotely. Possibly you are thinking of WidevieW, which is an entirely different product which links several PCs all running FS. Pete

You need to state their functions, else how can you use them anyway? COM3 isn't supported as an FS facilty, nor are PA, MXR MUTE, AUX, MANSQ, PILOT, TEL, SPKR, HI SENS, PLAY, COPLT (though I don't know what one or two of them could be). COM1MIC and COM2MIC will be the COM transmits of course. Normally you'd only hear the selected COM sound, but COM1/2 would probably be "receive both". The plain COM1, COM2 are presumably on/off sound buttons -- most cockpits have volume controls on the audio panel. Not simulated in FS though, you have to use the volume on your sound system. ADF, NAV1 and NAV2 sounds are self-evident -- the morse signals confirming identity. AUX could be anything. You could use it for Marker sound perhaps. You then just need to choose one of the others for DME sound (identity again).. BTW, that pic looks nothing like the audio panel in the 172 I flew when learning to fly aeons ago. I assume it's an enhancement? Pete

Just checked. The reason FSUIPC discards the .flt is so that P3D will load the FXML file if it exists. The actual entry, for version 4.936c (September 2014) says: However, I do see this in the description for the SimConnect facility being used: I've not seen that before. FSUIPC has been this way now for 4 years with no problems, noone affcted. Shouldn't your program be updated to use FXML files? I'm not updating FSUIPC4 any more. I can make an option in FSUIPC5. A flag set in offset 3F00 (not just 0 to load a flight, but another value to load a "deprecated" .FLT file, or just leave the extension alone. Meanwhile, can you try adding another .flt at the end? eg. cybervol_IFR.flt.flt FSUIPC might only take the last .flt off. If this works and is satisfactory, I suggest you do that instead. Also, can you explain the 0x30 ('0') at the end of your flt file name: you sent cybervol_IFR.flt0 so it wouldn't have worked in any case for a .flt file. Pete

Replied since then. Pete

Why does that mean? That's the write to 3F04. Your program is writing all 252 bytes? The byte following the ".flt" part is 0x30. Surely the string written should terminate after the .flt in any case? And please show me the Log file next time, NOT you interpretation! Only fxml flight files are supported. Because the sim assumes fxml. hat is what it supports. Well, I've not been able to load .flt files into P3D for several versions, not just P3D4. Can you load them manually, though the menus at all? And what is with the HUGE font Please don't do such things!!!! Pete

Sounds like there is something seriously wrong with your installations or the way you are using the offsets. The flight loading and saving facilities via the offsets are working fine -- I use them almost every day from a Wideclient remote PC. In FSUIPC's logging use the Monitor facility to monitor offset 3F00 type S16, 3F02 as type U16 and 3F04 as type ASCIIZ, then try again. Show me the FSUIPC log file. BTW I am only interested in supported versions: 5.14 and 4.974 or later. Note that I don't think P3D3.4 supports the old .flt format files. Flight files are in XML and have filetype .fxml. (I don't think you need to give the filetype anyway). BTW what is this "Cyberavia" program? Pete

No, of course not. That is the heart of P3D. But it means the registry is all screwed up, so things cannot be found where they should be. If you look at the right-click Properties of the shortcut icon you use to run P3D you will find the path to it. Pete

The expoerter is designed to be used automatically by other programs, like makeRwys. You do not run it yourself. The Lorby-Si "AddOnOrganizer" is the program you need to sort your add-ons out, especially scenery. That is worth getting, and it is freeware too. Ouch. It does sound like your P3D install is messed up. I think you should uninstall it properly: use the Uninstall facility in the Windows setting "Programs and Features". Scroll down , find the main P3D entry, right-click and select uninstall. When it is completely uninstalled, try installing it again, but change its install location. Something like C:\Prepear3D would be good. Just not "Program Files" which can cause some programs all sorts of problems because of Windows protections. Pete