Pete Dowson

It seems to be a P3D4 bug. SIM RATE and SIM RATE SET controls appear to do nothing, as before. FSUIPC uses SIM RATE INCR and DECR to change the frame rate to x1 as indicated by 256 in offset 0C1A, set from Simconnect informing FSUIPC of the multiplier (1 is converted to 256 for compatibility with past sims). I've tested SIM RATE DECR and INCR separately, and they simple don't work properly in P3D4. After using either a couple of times they stop working altogether, and you have to resort to the P3D Options menu. Worse, setting "slowest" then trying to use SIM RATE INCR causes P3D4 to crash! I'll try to gether together some more specific information on all this and report it to L-M [LATER] Report to L-M done, as follows: Pete

I've checked the files made by EFB2 and I don't think there's a suitable one produced, I've really no way of decoding whatever there is. Sorry -- looks like i'll just have to make the READ ME document explicit that it is an EFB v1 installation which is needed. Pete

Looks like corruption in P3D. Just about every Sim Var FSUIPC needs to populate the offsets is failed. The only thing I know which causes such weird symptoms (different on different folks systems) is a bad wxstationlist. bin file or weather (.wx) file. Ask him to make a copy of the first as I would like to look at it IF it isresponsible -- I'm trying to convince L-M to check such files before using them -- then just delete it, before running P3d (it will make a new one). If that fixes it please send me a copy of the bad file. The bin file is in his AppData\Roaming ... folder, same place as the main P3D cfg. Pete

There are 4 controls still defined by P3D4: SIM RATE SIM RATE INCR SIM RATE DECR SIM RATE SET Which ones have you tried by assigning, instead of using the Hot Key? Theoretically SIM RATE SET with a parameter of either 256 or 1 (?) should work, but I know it didn't in FSX. I'll check later today, and also look at the Hot Key option. Pete

I assume you mean /+T? I've just tried it, and you are right. It doesn't appear to be working now. [LATER] Have you moved on to EFB version 2? If so then I'm not sure it can work, not as it is now. It needs to access this file: Aivlasoft\NavData\Airports.DAT where the Aivlasoft folder is within the P3D folder, like MakeRwys. Check the log (Runways.txt). mine has this line at the end: **** The /+T option is ignored because of no Aivlasoft\NavData\Airports.DAT! **** So, three questions arise: (1) is there such a file in the new Aivlasoft installation? (2) is it in an easily predictable place? (3) is it in the same format as before? I don't even have EFB installed on this PC. I'll check on my main cockpit PC. Problem is that I don't have EFBv1 any more so i cannot compare files to see if they are similar enough. Do you have such a file, from EFBv1? Pete

Well, to explain that: In P3D4, to avoid having to hack directly into the code, FSUIPC uses regular SimConnect facilities for the displays it is requested to show. But FSUIPC interfaces directly into SimConnect within P3D4 and needs no other SimConnect installs. Pete

Depends on what else LINDA needs. Best to ask the LINDA folks. I know it uses lots of Lua plug-ins, and not all Lua functions are avaialble via WideClient. Pete

Radar Contact doesn't use SimConnect! Are you sure you haven't turned off information text in the P3D4 options (bottom right on one of the screens)? You only want to do that if you are using WideFS to display it on another PC. Pete

Very puzzling to me -- the Log shows EXACTLY the same loop I was sure I was preventing! So, sorry about this, but I need the extra bit of logging doing, which I added in 5.10. as well as what you have already, please add: LogLoopActions=Yes Turning into a bit of a saga! Comes of me not having the hardware any more, I'm afraid! Pete

Yes, of course. you just read it via the FSUIPC interface. Details are in the FSUIPC SDK. Or else use Pault Henty's .NET DLL -- that makes it muuh easier! See the dedicated subforum above. Pete

Can do. But with Saitek I think sometimes their install messes the registry entries up. You should really disable controllers in FSX If you assign in FSUIPC, because unbeknownst to you it can automatically reassign. For a POV with panning you can assign in FSUIPC as an axis -- assign to Pan view. Pete

The only thing which would have changed between v2 and v3 is the number after the RX in the macro. Try making the macro again, and note the value is shows. then you can edit your v2 macro. Not sure what you mean "the green bar disappears"? It should await either an ESCape press or an ENTER -- unless you moved the mouse, in which case it may have moved over another switch. Pete

That seems to tell me what is going on. The TankSelect switch is one of many which, having been set in a position and the appropriate offset changed in FSUIPC, needs that offset monitored in case it is is changed by another action (eg reload the aircraft, or using the mouse on screen). The scanning of such switches allows PFCHid to restore the actual switch setting so that the console switches always match what the sim has set. Unfortunately, that can't be done with macros. BUT it tries! In other words, it is repeating the action forever in the hope that the normally assigned offset will be set to what it is programmed (normally) to be. In other words, it seems to be an original flaw in the logic with the macro implementation. I have a test version for you to try: PFChid64_510_TEST.zip Please let me know. If that is good, I shall make the same changes to the 32-bit version. Very odd no one has come across this before! Pete

Unfortunately, for most of its systems, PMDG do their own implementation and ignore the controls that this Sim offers for those. You don't say which flight simulator you are using, nor which version of FSUIPC. Both are essential details without which it is difficult to help fully. The PMDG aircraft do install an SDK folder, within which there is a file with filetype".h". At the end of that there's a long list of all the controls you can possibly need, and more. They are listed by name and given a number, which has to be calculated by ading an actual number to a base value, given at the top. Those numbers are then used in FSUIPC assignments by selecting <custom control> and entering the number. Some may also need a parameter, eg to turn off or turn on. That parameter is actually a mouse action code, a list of which is also given. For more about using PMDG controlsyou might find more detailed help on the PMDG support forum. I don't actually have or use any of their aircraft. Pete

Uninstall rather than disable. Then Windows will put the appropriate ones in place. Pete

That shows al three devices detected properly, and correct JoyDs of 0, 1, and 2. The INI file produced must also have been fine, and all three would have been okay in that session. You had controllers enabled in FSX as well as expecting them to work correctly in FSUIPC? That's a non-no. Either assign in FSX or in FSUIPC. If in FSUIPC, disable all three controllers in FSX. You have the yoke playing up too? You are using Saitek software and drivers? That's probably part of the problem! My advice is to uninstall all the devices including drivers: Do this in Windows Device Manager. Make sure you uninstall drivers there too. Then re-boot the system. Windows will find them and use the default drivers, which work fine and with far less trouble in the long run. Pete

I've fixed a bug in the new RudderBlendLowest option. FSUIPC 5.141e is now available in the Download Links subforum. Pete

I've fixed a bug in the new RudderBlendLowest option. FSUIPC 5.141e is now available in the Download Links subforum. Pete

The PFCHid64 Log shows that, somehow, the macro for the "RIGHT" position is repeating forever within PFCHid. I cannot find anywhere which could explain such a difference between TankSelect0/0, /1 and /2. So, I'm sorry, I need more logging. This time just the PFCHid log. But first make sure LogDecode=Yes LogMacroNames=Yes LogIPCwrites=Yes The third one is an addition. This will halp me narrow it down, after which I may have to add extra logging and send you a test version to narow it down further. Shame that I have no way here to debug the issue. I might try to figure out a way to fool the driver into thinking it has a device with a TankSelect switch, but it is very difficult. so many parts of the code to bypass somehow. Pete

Well, it does on the ProSim Lower DU during control checks. If you had it showing with 5.123C but not 5.14 then that is completely inexplicable. Currently both tiller and rudder give full operation at groundspeeds less than RudderBlendLowest if both are assigned Direct and Calibrated. The fact that the tiller does is an error which I will fix. If you want 5.14 to behave like 5.123c in this matter just set RudderBlendLowest=0, which will disable the new facility altogether. However, I believe that with 5.123C you must have been assigning to the sim controls, not direct. I don't use PMDG aircraft, but I know some of their actions depend on seeing certain controls, and those won't be seen if you use FSUIPC Calibration. Look at the dentry for 3110: 3110 8 Operates a facility to send any ‘controls’ to Flight simulator. This works with all versions of FS & CFS. Write all 8 bytes for controls which use a value (axes and all _SET controls), but just 4 will do for ‘button’ types. This is really two 32-bit integers. The first contains the Control number (normally 65536 upwards), as seen in my FS Controls lists. The second integer is used for the parameter, such as the scaled axis value, where this is appropriate. Always write all 8 bytes in one IPC block if a parameter is used, as FSUIPC will fire the control when you write to 3110. See that it is 8 bytes -- 2 x 4. 4 bytes is 32 bits. The recommendation here is to write the 8 bytes as one block, but that is not so easy in Lua if you are a beginner. The Offsets document is really aimed at programmers writing programs to interface to FSUIPC. This is why I described gfor you exactly what do to. You didn't need to look up 3110 or 3114. The ZIP for a 3 line file is a bit cumbersome, isn't it? Why not just paste, thus: rudscale=ipc.writeSD(0x3114, 0.5) ipc.writeSD=(0x3110, 65696, rudscale) end Lots of odd things about this. First what is the "end" the end of? If you only want those two lines executed, just have those two lines. end is used to bracket a chunk like a function or a conditional or a loop. You are trying to write 0.5 to 3114. 0.5 will be set as 0 because the 32-bit number is an integer (rudders go from -16384 to 16383, as surely you've seen during claibration?). Controls either don't use a parameter, or take an integer. What do you expect "rudscale=" to do? You are writing not reading. In the second line, what to you expect rudscale to do as the third parameter? The function doesn't use 3 parameters! Pete

There was no RudderBlendLowest action in earlier versions. That was added so that you would be able to check the rudder on the Lower DU during your pre-taxi checks. Still, I will try to stop the tiller operating when the ground speed is lower than RudderBlendLowest, as this is certainly what I intended. Pete

I'm afraid there's still too little information! 1. The warning says "ready I stop working"? I don't think so. Please state what the warning actually says. 2. If you continue after the warning, how far does the loading of P3d get before it "stops"? Tell me what is happening on screen. 3. Is the "stop" just a stop -- i.e. a hang, a freeze? Or does it crash and disappear? If it crashes I need to see the crash details from the Windows Event Viewer. 4. I asked what the version number of FSUIPC4 was, but you still haven't told me! 5. Version 3.0 of P3D3 is not good!!! It is probably that which is the problem. Please update P3D. You should be on version 3.4 which is the current one supported by FSUIPC and by Lockheed-Martin. 6. If there is no FSUIPC4.LOG file then FSUIPC4 has never run, so it cannot crash! But more likely you do have a Log and an INI file, but have Windows Explorer set to hide filetypes. So FSUIPC4.LOG will look like FSUIPC4, and so with FSUIPC4.INI! If you change that option you will probably see the full names. If you still get problems after updating to P3D 3.4 do let me know. Otherwise I cannot really help. Pete

I use P3Dv4 so my ActiveSky is ASP4, and the installer for that certainly doesn't mess up the previous DLL.XML. When I used P3D3 I used AS16, but back then it was okay too. So I can only presume it is a recent bug. Have you reported it to Hifi Simulations? If not, please do so. Pete

When you are stationary, yes, both move, because both control the rudder. If you don't want to see the rudder movement when using the rudder and don't want to see it in the LowerDU, set RudderBlendLowest=0 in the [General] section of the INI file. Please see item 13 in the History PDF installed with FSUIPC 5.14. That explains it. If you want to separate the two you need to use the P3D controls for Steering and Rudder. The FSUIPC method only deals with the blending, the gradual transfer, when both are assigned Directly and then both operate via the sim's rudder control. If you mean you don't expect the tiller to also move the rudder when stationary, I can look to see if I can stop that. I see I did describe it that way. Pete

What did you assign to? You need to assign "direct to FSUIPC calibration" and actually calibrate in FSUIPC for its blending action to work. Also, in the latest FSUIPC5, if you are stationary the rudder is allowed to operate too so you can see the rudder is ok on the lower DU. Pete