Pete Dowson

What sort of "variables" are you talking about? If you mean L:Vars then I believe the LINDA add-on uses LVars for that aircraft. If you searched for answers you'd find this relevant thread: You might also want to try Mouse Macros. Pete

Why not tell them to enable the Lua debug/trace option (in Logging) and return the logto you? So you say it works as you wanted on FSX but not on their P3D4.? Let's look at the code: -- QUIT IF NOT A DIAMOND DA20 AIRCRAFT local AircraftType = ipc.readSTR(0x3C00, 256) if string.match(AircraftType, "DA20-100_V3.7.air") == 0 then ipc.exit() end Two points there: 1. That looks like the whole AIR file name. Are you sure he has that version? Why not simply match the "DA20" part. 2. You check for == 0. But if it isn't found the result is nil. In Lua nil is not equal to 0, it's a "non-number" -- FOR P3Dv4 ONLY if FSUIPCVersion > 5000 then ipc.setdisplay(SET_PCTS, 37, 8, 26, 20) end What is this for? It affects an EXISTING window only. And I think Simconnect overrides positions these days. You could remove the whole check for P3D4. -- FOR BOTH FSX+ and P3Dv4+ n = tonumber(ipc.ask(Katana_Options, WHITE)) ipc.log("result = " .. n) That works fine -- I added the log entry so I could see the number entered. If your friend can't see the window it is probable that he has "Information text" unchecked in his P3d settings. this prevents all Simconnect messages (it is used when diverting them to a different PC using WideFS). Pete

There's no change in HotFix 2 which affects anything in FSUIPC. Have you asked over in the PMDG support forum, as I assume it must be a change which affects that add-on? Pete

If one of your axes keeps sending values ("jitter") then the re-scan will pick that up. Use "Ignore axis" to get to the other! Well of course it would if the same device is reconnected and keeps jittering! The log doesn't show anything of interest as you've not enabled any relevant logging. Also, please always close down P3D before grabbing the log as relevant information is often part of the summary at the end. Sometimes with jittery axes you can get them to stop jittering by "parking" them at one end of the movement or the other. Pete

FSUIPC assignment tabs react to a CHANGE in a button state. It won't change if the button isn't changing. It sounds like the "on" switches are actually pulsing on/off. Use the Button/Key log option (Logging tab) to see what is going on. You can see this in real time if you enably the Console window. In order to program any button FSUIPC needs to see it going from "off" to "on". Pete

As well as what Thomas has said, here's some more details about OOMs and solutions: The memory is that available to your FSX or P3D process. Closing down other programs is not going to help -- unless, like Active Sky they are injecting data into the Sim. A 32- bit program like the Sim you are using is limited to 4000 Mb or memory, of which abount 2,000 Mb is taken up with Windows compaonents and hardware drivers. OOM will be caused by scenery not being flushed, weather textures not being flushed, and AI traffic textures not being flished. You might find that merely saving the flight and reloading it will give you much more time before the next OOM warning. Another likely cause is "memory leakage". That's when something you are using (IN the Sim, not outside) is not freeing memory it uses, and just grabs more rather than freeing or re-using what it has. There have been a number of add-ons which have such faults over the years. In the end there are two solutions: 1. Save your flight, close the sim completely and start it up again, reloading your saved flight. OR 2. Update to a 64-bit sim such as P3D4. The incidence of OOMs in P3D3 and FSX/FSX-SE was a prime motivator for many to move on to P3D4. Pete

FSX assumes you've ca;ibrated in windows, so do thgat first. If it still misbehaves in FSX then there's not a lot FSUIPC can do about it. FSUIPC can provide more precise calibration, and provide more options for how the response feels, but if your device is still only setting a few discrete values (positions) rather than running smoothly from minimum to maximum, then there's not much software can do. Pete

Yes, it will be the yoke if none of the others suit. Pete

Sorry, but that is not really helpful. Please show the files Thomas so carefully and fully pointed you to. My first guess is that the device is registered incorrectly in Windows. Unistall it (including drivers if that option is presented) using Windows Device manager. if it came with any software, uninstall that too using Windows "Programs and Features". THEN re-boot the PC so the device gets re-detected. Pete

It's worse than that. You actually have three Josticks with ID 0, one with ID 1 and two with ID 2. I've no idea how your Registry got so messed up. Try replacing the [JoyNames] section in the INI file with this: [JoyNames] AutoAssignLetters=Yes 0=Saitek Pro Flight X-56 Rhino Stick 0.GUID={C507AB90-E9FE-11E9-8004-444553540000} 1=Saitek Pro Flight X-56 Rhino Throttle 1.GUID={A6909910-E9FE-11E9-8002-444553540000} 2=Saitek Pro Flight Cessna Rudder Pedals 2.GUID={C507AB90-E9FE-11E9-8004-444553540000} I've set AutoAssignLetters=Yes to get letters assigned (A, B, and C), so that if you unplug things and connect them differently your assignments will still work. Pete

Those event IDs look like the <custom controls> for PMDG boeing aircraft. You can assign them in FSUIPC Buttons & Switches tab, selecting <custom control> in the dropdown. The PMDG offsets listed in the PMDG lists are all READ ONLY. You can't write to them! The only way to control PMDG aircraft with assignments is via the curstom controls. Please see PMDG help on their forum. All this is from their SDK, installed in your PMDG Aircraft files on your PC. Pete

Now at least you can point the developer to that module and get him to do something about it! Pete

Well, a corrupt BGL might, i suppose, be able to corrupt P3D, but it seems unlikely. But certainly it is possible for corrupt Image files (bitmaps and the others used in Texture folders) to cause corruption. If you are the only person getting this problem, maybe your specific copy is corrupted. Have you tried re-installing the scenery packages? Did you yet try updating P3D. If it is corruption, it is possible that the change in code locations will either cause different problems, or make them seem to go away. In fact it occurs to me that simply running it on a different PC, with different video driver versions or windows could also change things a bit, but usually not so much within the P3D process itself as those areas are in a different part of virtual memory altogether. Pete

4200-42FF if you don't use my own ESOUND. Actually, that is obsolete these days, replaced by the Lua sound facilities. So i should make 4200-42FF also "for users" in FSUIPC4 and FSUIPC5 (just not FSUIPC3). Pete .

It isn't really doing that. It is stopping SimConnect closing. The log shows this: 48860 === Closing session: waiting for DLLStop to be called ... "DLLStop" is the call back any SimConnect program needs to wait for before freeing up everything to do with SimConnect and closing down. Closing programs started by FSUIPC is only part of that whole process. there are also numerous threads which have been started for the various functions FSUIPC performs. they all need closing for a tidy finish to the session. So what appears to be happening is that some part of your addon "scenery" is causing some internal problem to P3D. In your reply to Thomas you mentioned two elements: "Real NZ Christchurch" and "VLC Libraries". Do those addons only consist of BGL and texture/graphics files, or are there programs involved as well? I suspect that the reason disabling either is because the problem is in the "Libraries" and tose are only used by the other package. Maybe disabling (renaming) each file in the Libraries layer, one at a time, will pinpoint the problem further. If there are a lot of files I use a binary chop method -- i.e disable one half, if that fixes it, half again and so on. Easy bulk disabling is moving them to a specially created subfolder. Can he not reproduce the problem? He'd need to be using the same build of P3D as you. You should also be using the current version of P3D (4.5.13, also known as "Hot Fix 2", or HF2). Try that first. This is not a problem we can fix in FSUIPC, and it likely affects other SimConnect clients, especially those running within P3D (DLLs etc). Pete

Provided you are not using certain applications you can re-use the offsets assigned to them. One example actually doumented in the list is 04E0-0537 Project Magenta (88 bytes). There are others but you'll need to tell me how much you need. Many things can occupy just one bit (on/off indicators or switches), one byte (values up to 255, or signed -128 to 127(, so it is best to make good use of the space available. Pete

Your question is premature. There are no addon developers in a position to do anything yet. Ask again in about 6 months. Pete

The entire number of buttons can be read and interpreted (best sent to "virtual buttons" for assignment) by using a Lua plug-in. A suitable Lua plug-in is provided, as an example, in your FSUIPC documents subfolder -- in the "Example Lua plug-ins" zip file. Look for "HidDemo.lua". That handles many axes and up to 256 buttons on a device, mapping them to "virtual buttons" in FSUIPC which will be seen in the Buttons & Switches tab and can be assigned there. All you should have to do is change these two lines: Vendor = 0x16C0 Product = 0x05B5 Get these values either from the FSUIPC log file, or possibly easier by using HidScanner (a small usitility in this thread: The other lines which you might want to change are: Device = 0 -- Multiple devices of the same name need increasing Device numbers. -- Logging on or off (to see when numbers you are getting) Logging = false -- Polling rate in number of polls per second Pollrate = 25 but this won't be needed for a simple button mapping. Pete

Why do you have to hide the IP address? It should be local to your local networked system, it means nothing to anyone else. These are usually like 192.168.n.n. If it looks like an Internet type of IP address then it's a problem with your router. Try setting you internal server IP address explicitly, "ServerIPAddr= ..." instead of giving the name. Pete

Ah, Sorry. There's no further development of FSUIPC for FSX (or 32-bit P3D for that matter). I'm afraid SimConnect may be your only resort. Pete

You should assign the button to the "Throttle Decr" control, not an F3 keypress. And check "repeat". Pete

All files related to FSUIPC are always in the Modules folder, next to FSUIPC itself. For FSUIPC4 it's "FSUIPC4.INI". For FSUIPC5, it is "FSUIPC5.INI". It is only "FSUIPC.INI" for FSUIPC, FSUIPC2 and FSUIPC3. Pete

There are no offsets for reading a camera setting, only for setting those values for a defined camera (offsets 8680-86DF). It might be possible to make a similar facility to Read a specified camera's "6DOF" but I'm not sure without checking the SimConnect interface specification. If it were added as a facility it would only be for FSUIPC5 (i.e. P3D4_ -- you don't mention what sim you are using). It would probably need to operate with a specified camera name. I don't know whether it is possible to read the current camera name ("current" presumably meaning "selected"? After all several cameras can be currently active). Have you looked at the SimConnect interface to see what is possible? Pete

The SimConnect interface necessary for FSUIPC has grunched slowly to a complete stop. This actually starts early on: 1475984 **** No SimConnect events or states being received! Re-connecting now ... **** That's a sure sign something is wrong in the system. Maybe it is just that too much load is being placed on the SimConnect nterface. You can try increasing the timeout (NormalStallTime in the FSUIPC4.INI file -- it defaults to 1 (= 1 second). That will make the timeouts less likely to do suchdamage, though if it's progressively worse, as it looks, that probably only delays the inevitable. Otherwise I suspect you have some sort of memory leak going on which is causing this -- maybe a faulty aircraft, cloud textures, or even something in the scenery. One thing you could try, to see if it helps, is adding NoWeatherAtAll=Yes to the [General] section of the INI. That will stop FSUIPC asking for weather data al the time. If that helps then there might be a corrupted WeatherStationList.bin file, or .WX file. Pete

If you route the controls via calibration they are then sent on to the sim at a different Simconnect priority level. This has to be done to avoid an eternal loop. Some aircraft (and PMDG Boeings are like this) collect the values at the same, higher, priority level as FSUIPC, and go on to use them directly. In the case of the PMDG aircraft, they still respond to the lower priority values too, so conflicts can arise if the calibrated values are different to the original ones. Maybe that Eaglesoft one does something similar to PMDG, but then only takes note of the higher priority posting from the control axis. That's one possibility. The only other possibility i can think of is that their model doesn't accept the older (FS98) type of throttle axis controls, the only ones which allow a reverse range (which is why FSUIPC uses then if you calibrate with a reverse range). You can still use FSUIPC for assignment, but for such aircraft use the "send to FS" option in the assignment tab, not "send to FSUIPC ..." option, and then don't calibrate. You'd need to calibrate only using the Windows Game Controllers method. But by using profiles you can have this method just specifically for the Eaglesoft. Pete