Pete Dowson

John obviously thought you were asking about FSUIPC -- this is the support forum for FSUIPC after all, not for MSFS. Pete

The .NET DLL from Paul Henty would be a much smoother way to go. There are lots of functions for doing all the common things (as far as I understand from browsing other folks posts -- i only program in C/C++). Pete

Interesting -- neither INI or LOG files contain anything showing aileron or rudder trim controls operating, and the offsets showing the values of these trims are never logged. The log just shows both Aileron and Rudder axes jittering a little around neutral. I see you run both PFChid and PFCcom: 453 Loaded PFCcom64.DLL okay! 485 Loaded PFChid64.dll okay! I really don't know how the aileron and rudder trim are changing in MSFS. There are no controls for it, and the relevant SimVars aren't providing values. PFCcom64 sets these trims via offsets 2EB0 and 2EC0, but those, in turn, operate via 0C02 and 0C04, yet there's no change in those offsets according to your logging. I'm going to have to do some further investigation. If you have time, i wonder if you could change the 0C02 and 0C04 entries in the Logging Offsets options to 2EB0 and 2EC0, of type FLT64, and repeat the test for me, please. Pete

But you need LorbySceneryExport next to MakeRwys, otherwise the data generated won't include any sceneries added by the "Add-On.xml" method! Pete

Okay, after some analysis with this data and he code in FSUIPC, i can see that this problem is one which has occurred periodically before with COM devices. I'm pretty sure it is associated with using COM to USB adapters with small IO buffers or other flow problems and which in turn cause the low level driver in Windows to hang. Certainly the analysis shows that the thread trying to close the COM ports is waiting for a return from a call made into Windows. Could you please tell me exactly how your VRI device is connected to the PC? Is is a built-in COM port board (the recommended way) or a line adapter COM to USB? If the latter can you tell me the make please? I ask because i've had serious problems with some of those devices. I ended up paying more for the Brainboxes ones -- I can recommend those, never a problem since. (I don't use VRI devices but my PFC cockpit is mostly on COM port , as is my GA28R VFR cockpit). Anyway, one of the workarounds for VRI devices we devised which has worked for others is: VRIDisableCMDRST=Yes in the [General] section of the FSUIPC6.INI file (if the parameter is already there, make sure it is set you 'Yes'. Else add the line. This will simply not try to reset the device when you finish. Pete

Me too! By "PFC.dll" do you mean "PFCHid64.dll" or "PFCcom64.dll"? I would assume the former if you are using the standard USB Cirrus? Could you do some logging for me please? In FSUIPC7 open the Logging options and check the options for Axes Controls, and Offsets 0C02, 0C04, 3BC0 and 3BC2 all as type "S16". Then operate those trims a bit, using the PFC assignments, then show me both the FSUIPC7.LOG and your FSUIPC7.INI, from the FSUIPC7 folder. Thanks. Meanwhile I'll try some things here. Pete

For the latest version you need to download again. There's no built-in automatic updating. Either of the original links will provide the latest file. Both sites are maintained. Pete

The only indication you would get is the lighting of the VS hold indicator on the autopilot. I don't think it can affect the G1000 -- that does its own thing and there seems to be no controls listed for it in the MSFS SDK. The VS to be held is the one in the VS digital display. I don't know how these are dealt with in the aircraft you are using. I don't know the GA. On my GA sim (a Piper Arrow III dedicated piece of hardware) there's no "VS" setting or VS hold labelled as such. But the autopilot has an "Alt" mode, and "up" and "down" buttons with which you can control climbs and descents, so it's an effective VS setting facility. It would perhaps be useful to know if the VS hold control works on the Airliner autopilots in MSFS. If so, but not on the GA ones with a G1000, then I can only think the facility is implemented locally to the G1000. In FSX or P3D we'd deal with that using L:Vars (local panel variables), as roa said, or mouse macros. I'm afraid neither of those methods is available for MSFS. We need to wait for more SDK development and, probably, a method of having a module running inside MSFS with which we can communicate. I'm afraid it is very early days for add-on applications for MSFS and what you want to do may not be possible yet. Pete

The program only ever creates one window. for some reason you seem to have executed it several times instead of just once. Select the EXE file, right-click on it, select "Run as Administrator". Pete

What is a "vertical speed toggle"? Do you mean the Autopilot VS Hold option? There is a control you can assign to for that: "AUTOPILOT VERTICAL HOLD". Ah, I don't know about the G1000 (even in FSX/P3d). I only know the A/P controls on MCPs. If you are building an autopilot why are you basing it on something like the G1000? Pete

Those are two good ideas John! I should have thought of trying those!

Ah, so it might just be a local function in the graphics, same as those aircraft letting you open the windows or operate the air vents. For some of these things there's nothing built into the sim in any case. Pete

Using the regular controls. does it have more than 4 door operations too? There are probably a lot of ways, but using the regular controls? Pete

That code area is the same as before, so I can only think it is some timing problem (the SimConnection problem -- delays and stutters both sides). If so then like the rest of SimConnect users, we are at the mercy of ASOBO/MS updates. The logging should still be there. Try these lines in the [General] section of the FSUIPC7.INI file: Debug=Please LogExtras=4 There's also a COM data logger which can be enabled too with LogExtras=x44 (or 68) Pete

It might be that, being mouse emulations, they are just too fast for the gauge to respond to both. We could really do with some sort of delay option, even an added control that simply does "sleep for 30 milliseconds". Maybe John might consider this when the rush for MSFS subsides. Meanwhile, doesn't the regular landing light control work for at least one of those switches? (If you were using a button instead of a latching switch you could program one on press and the other on release). The only other thing I can think of is to try one or more other, time-wasting, entries (controls that do nothing on your cockpit) between the two mouse operations, but I don't know if that would work. Something I think I'll try -- when I have a bit of time. Pete

If you just want the latest FSUIPC4. just download it and run the installer. It will replace your old version and keep your settings. You only buy FSUIPC4 once. You are actually expected to want to keep it up to date, and we want that too as we cannot support old versions. BTW you posted this in the Download Links subforum. As it is just a support question you should have posted here, in the Support Forum, to which I moved it. Pete

It isn't just with FSUIPC, all Simconnect applications are affected. Why didn't you look at the existing threads? This one, not far below yours, gives you a lot of information, for example:

Did you assign a key or button to PAUSE ON, and use it? Or you could try PAUSE SET with parameter 1. Pete

You could use 4 virtual joysticks (vJoy supports up to 16) to get 128 buttons mapped. Pete

As John says, we don't use it now in any case. AND I'm pretty sure those two 'releases' are actually identical. I tried the older one before downloading and installing the later SDK and the performance was the same. It's the release version of MSFS that's responsible, not the SDK. The SimConnect.DLL is only a set of calls using TCP/IP or PIPE into MSFS itself. It does no work as such. Using the static lib we integrate directly instead. Pete

Sorry, I don't know. I don't think it is time-related. Could something (not necessarily related) have changed the order of things in the Registry? The installer will believe the first valid link it gets for the Install folder. Pete

Please don't rush. i might not get to it anyway till Monday. I'll be finishing soon, and tend to take most if not all of Sunday off. Pete

Aha! So you have an FSX.CFG rather than an FSX_SE.CFG, which is what the installer is looking for. With my last install for FSX-SE I got this is the log: Looking in "C:\Users\JohnG\AppData\Roaming" Found FSX.CFG in "C:\Users\JohnG\AppData\Roaming\Microsoft\FSX\FSX.CFG" Now in my case it was actually looking for an FSX.CFG rather than an FSX_SE.CFG. I think this is because of your EXE being found as: Looking in registry for FSX-SE install path: HKEY_LOCAL_MACHINE\SOFTWARE\DovetailGames\FSX Parameter"Install_Path" ... >>> OK! FOUND FSX-SE! <<< ... SetupPath=F:\Steam\steamapps\common\FSX whilst mine is: Looking in registry for FSX install path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\10.0 Parameter"SetupPath" ... >>> OK! FOUND FSX! <<< ... SetupPath=C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\ So, somehow you have a sort of cross-over FSX/FSX_SE install. In my FSX-SE installation I have no FSX-SE.exe file. mine installed as FSX.exe. Did you nename the EXE? If so it is that which is confusing my Installer. Checking version of the FSX-SE EXE:... Version 10.0.62615.0 (Need at least 10.0.62607.0) Anyway, please see if making a copy of your FSX.CFG and renaming the copy as FSX_SE.cfg will work with an installer re-run. Pete

Ah, so ... it is a mystery. We need to know where it is hung. I don't know if it will be any good, but could you try this to get for information? https://www.nirsoft.net/utils/what_is_hang.html Pete

The only problem I see in the Installer logging is that the DLL.XML file couldn't be edited. You need to check why. Have you actually run FSX-SE since reinstalling? Is not, that will be the reason there's no FSX_SE.CFG file. If you have run it beforehand, where is your FSX-SE.CFG file? It should certainly be in one of the folders searched according to the Log! Also, don't forget to run the Installer "as administrator". Pete