Pete Dowson

FSUIPC "BrakeReleaseThreshold" facility has not changed since it was introduced in FS9 days. I use it all the time, with ProSim. But I don't have a solenoid to release it, I have to operate the switch/lever too. FSUIPC simple uses the standard FS BRAKES control -- the same one pressing '.' does with default assignments in FS. Why don't you just enable FSUIPC event logging and see the events being sent. Surely, it's the pressing of the brake pedals which you need to check on, in ProSim. I think you are looking in the wrong direction. The difference is not in the brake release but in the trigger to release the brakes. Pete

The only offsets which MAY be populated for a GPS are those listed in the Offsets list installed in your FSUIPC Documents subfolder. Search on 'GPS'. If what you want is not there, then it isn't available via FSUIPC offsets. nor via FSX SimConnect. Pete

No. FSUIPC won't care if an external process it started is closed by you or even on its own, as some do in any case. Pete

You'd need a driver which made it look like a regular Joystick type device. Have you checked the support website for the device? Or you could write your own plug-in for FSUIPC using the Hid facilities in the Lua com library. Pete

That's only about 709 Mb. It seems rather low to me -- even at a busy EGLL I start with around 1800 Mb. Mind you, that's without a cockpit in my aircraft -- but the default Cessna shouldn't take much. Are there any near large and detailed airports? Maybe your LOD radius is set very high? Or other settings? You might ask this sort of question over in the FSX forum on AVSIM, where you are likely to get more answers. BTW, you posted this twice. Please don't. I've deleted the other one now. Pete

Following on from the above, I'd be interested in knowing WHY folks limit the AI Traffic by deletion. Is it 1. To stop it degrading performance (frame rates) or 2. To stop it using too much memory (VAS) In my case it is the former. I don't see AI Traffic using much VAS (or at least, not measurably). And the frame rate saving is something I really only need at or near major airports. So I think I'll add another parameter, to tell the limiter to only delete traffic to get down to the Traffic Limit if the frame rate drops below a certain defined value. This parameter would default to 0, so it wouldn't change current behaviour unless you set a higher value. In my case, since I limit the frame rate in any case to 30 fps, I'd set this parameter to 29. So, it would only actually remove traffic if the frame rate dropped (even just temporarily) below 29. Pete

There is a slight preference for keeping traffic nearer the aircraft, to avoid aircraft suddenly disappearing in view. But the preference for NOT deleting aircraft at your planned airports is much stronger. Just manipulate the numbers more. There's no actual comparison of distance between the ground candidates once more than 0.5nm away and up to 5nm away. Over 5nm the chances are a bit higher again for deletion, So between 0.5 and 5 nm the deletion should be pretty random. Well, with settings much less extreme than that (I have the last one set to 20 not 5), I still get a decent spread of aircraft throughout EGLL, which is my standard test airport. I'm wondering if that limit of 130 isn't rather too low for somewhere like EGLL? I set mine to 200 at least. with the FS slider to to 50% using Mytraffic6. If a full EGLL would use up almost all of that 130 and the mechanism runs out of candidates to remove when new aircraft are added, it will be just deleting the furthest ones no matter what your preferences. Take a look at the traffic list in the Traffic Explorer next time to see if there is a rreasonably distribution of traffic elsewhere, not just all at the airport. Pete

You said this before and I told you that the Installer does not delete anything, so something else is doing it. As Thomas says, check that you are actually looking in the correct folder and also that you don't have a virus checker which for some reason doesn't like any normal files in that folder! Pete

To use WideFS and enable WideServer, as you have done you said, you need a WideFS7 registration. For FSUIPC user facilities like button assignments you need an FSUIPC registration. So, yes, both. Pete

Enable event and axis logging in FSUIPC's logging tab, operate the booster, and see if an FS control is logged as being used. If so, you can assign to that. if not you would need to investigate other methods -- maybe local panel variables (L:Vars) or mouse macros (but the latter is less likely -- most recent aircraft add-ons aren't suitable for those). There are probably other users around solving these problems. i'd look for an A2A forum if I were you. Pete

Is the turbo booster an analogue control? In other words does it have a continuous range of settings? How do you control it at the moment? Is there any documentation for the A2A P-47 you can refer to, or a support forum? Pete

It's incorporated into the [WideServer] section of the FSUIPC4.INI file. However, KeySends are a function of WideClient and are placed in the WideClient.INI file on the Client PC, exactly as described in the WideFS documentation. Use KeySends by making assignments to them in FSUIPC itself, assigning in the keys or button.assignments tab. Please refer to the WideFS documentation. Check this section in the WideFS Technical document (page 9). I've highlighted the important part. KeySend parameters These are still incorporated into WideServer for backward compatibility with users’ existing set-ups, but new users please use the FSUIPC Buttons page instead and assign buttons to the KeySend control in the drop down controls lists. The KeySend number (1–255) is entered as a parameter. You can also assign keys to KeySends in FSUIPC. And, yes, this is out of date in that they are no longer incorporated into the FSUIPC version of WideServer. but you should notice that there is no longer any documentation for KeySend parameters in WideServer, and in fact it was withdrawn many years ago. Sorry, if there is still remaining confusion. Pete

Right.. And the best way to do that is to use the FSUIPC controls specially added for that very purpose -- one of these: 1070 Key Press and Release (param is Keycode + 256*Shift code, or JsBk) 1071 Key Press/Hold (param is Keycode + 256*Shift code, or JsBk) 1072 Key Release (param is Keycode + 256*Shift code, or JsBk (as listed on page 33 of the Advanced User's Guide). You can send any control, FS or FSUIPC-added, via offset 3110. But why, if you are using FSUIPC? You said earlier you were using keybd_event which is nothing to do with FSUIPC, but is an obsolete Windows API function, not used by FSUIPC for many years! If you are bypassing FSUIPC and trying to use Windows functions directly with P3D and they do not work, your recourse is Windows or P3D support, not FSUIPC support. There are lots of Offset updates since the SDK was published. Each new FSUIPC Install includes an up to date Offsets list, installed into your FSUIPC Documents folder -- that's your prime reference for the use of Offsets -- and interim changes are always listed in the "Changes" documents included with the Installer. The SDK contents just form the base. However, none of this seems relevant to your implementation because you seem to have explained that you are not using FSUIPC for this. Pete

Yes, that's by far the better option. You'd use INCs and DECs to achieve any required valid value. Pete

No, it is not calibratable. That's only done for normal analog controls. The VS is a digital value, specific numbers.. Analogue axes do not give specific values, and they increment at a rate dependent on the resolution of the medium used -- graphite, wire windings, marks of optical disks, or metal through sensors. They are thoroughly unsuitable for use in the way you intend. One way of getting very specific values would be to use the right-hand side of the axis assignments tab to set zones, and assign a different AP VS SET + parameter to each one. That would only give you 10 (I think) values though: maybe --2500 to +2500. If you needed more, and the axis values were predictable enough, you could instead assign the axis to a Lua plug-in you could construct, and have a table in that plug-in which converted smaller ranges of input values to specific VS values for sending using AP VS SET. For a continuous change of values, the only possible way you might do it is by using the arithmetic scaling options you can add to the axis assignment lines in the FSUIPC4.INI file -- details are in the Advanced Users manual. You can add values and multiply them, to make them behave more like the way you might want them to. but it wouldn't be easy and you'll probably never manage to find the correct values to give all desired inputs. You might also need to set "Raw" mode in the assignment tab to avoid interference in the values from normal Windows pre-processing of the input. Finally, I'm not sure what units the AP VS SET control uses. Have you tried with some specific values? Pete

The Installer NEVER deletes anything. It only copies files in. so what you say is actually impossible. There's no code in it to delete files! So, I think you must be deleting files, or running something else entirely which does so! All registration will do, if you enter all the correct details, is create a "KEY" file in your Modules folder containing the keys, which FSUIPC uses when loaded. There's nothing using the registration details until FSUIPC is loaded. So it follows that there's nothing about registration which will stop it loading -- a bad registration will simply make it show as unregistered. Pete

The install log doesn't help, as the install is okay. You need to see if FSUIPC.DLL was ever actually loaded and run. If it was then there would be an FSUIPC4.LOG file in the FS Modules folder. If there is one then I need to see it. I also need to see the Windows crash data, as that tells me where it crashed and why. You'll get that from the Windows application logs collected in the windows Event Viewer. The possibilities, from previous experience, include corrupted Weather files (.WX and wxstationlist.bin) and an out of date BGLMANX.DLL loading before hand. if you use anything from DreamTeam, like GSX and their sceneries, try downloading and running the latest AddOn Manager to make sure it is all up to date. Pete BTW ALWAYS POST SUPPORT QUESTIONS TO THE SUPPORT FORUM, i.e. here. You posted it to the reference subforum, FAQ. You are lucky I saw it.

Saitek device installation often seems to give rise to odd and wrong registry data. That's why I usually suggest a complete uninstallation and then simply plugging the device back in and letting Windows sort it out. But I guess also, sometimes, uninstalling doesn't remove everything in the registry. Pete

Files are not designed to be changed all the time. the only way to do that easily is to create a new file every time, as I said. Please look back to my earlier message where I clearly explained this. You appear to have completely ignored what I said. Here, I'll repeat it now: Did you even bother to look for the "open" function? Are you really not wanting to help yourself and do any investigation yourself? And as I asked earlier, why are you trying to create some file if you don't know what you are doing? What is using this file? Anyway, just look at the script. I think the "open" is in the very first line, after the comments at the top. There you can change the filename (from "FSrecord.csv") and the way the file is opened (from "a+") The "open" function is part of the Lua io library, which is documented in Lua reference books and on the Lua website. Here, I've even found the right page in their documentation section: https://www.lua.org/manual/5.3/manual.html#6.8 and here's the part on io.open: io.open (filename [, mode]) This function opens a file, in the mode specified in the string mode. In case of success, it returns a new file handle. The mode string can be any of the following: "r": read mode (the default); "w": write mode; "a": append mode; "r+": update mode, all previous data is preserved; "w+": update mode, all previous data is erased; "a+": append update mode, previous data is preserved, writing is only allowed at the end of file. The mode string can also have a 'b' at the end, which is needed in some systems to open the file in binary mode. Do you think you can understand that? It is pretty clear. Change the mode to whatever you want to happen to the file! I shouldn't have to do all this searching when you need to be perfectly capable of looking for yourself. And if you ignore me again I may not bother replying. I don't see any point in answering the same question all the time. Pete

I'm not surprised. The PMDG aircraft will need special programming to work with any external hardware. They are really designed to be completely self-contained, operated via mouse on the 3D virtual cockpit. Don't VRI provide any drivers at all? I only built in recognition for the devices available from VRI many years ago. Later I think they started doing their own software. I've not seen any VRI stuff for a long time. I think there's a separate support website run for VRI users. Have you tried there? Pete

Sorry, you need to be more explicit. What values did you put in where? What are you now trying to do? I can't help you with no information at all! Why are you trying to create some file if you don'tknow what you are doing? Pete

The file created is intended to be a log. If you need the file to be replaced every time by a new one then you need to change the parameters in the open function call. I suggest you use the reference documents supplied. The file access library has its own document. Pete

There's another thread here somewhere mentioning "HOBHR4", and in that case it was a Lua plug-in apparently using it as a Global variable without even reading it beforehand. The user reporting it sent me the ipcinit.lua responsible for this, and I did a Lua trace on it to see that at no time did it ever read the Global it then used, which is why it turned out to be "Nil" and gave the failure. I could not investigate this any further because the init.lua plug-in was compiled and inaccessible, not the normal text type of Lua which I could examine, so i had to send him back to the source of that plug-in. I've not heard from him since. I suspect it's a matter of timing. Any plug-in called "ipcInit.lua" is actually loaded soon after FSUIPC is loaded, and long before you are ready to fly. This might be needed for some things, but not very many. I suspect that you are just lucky with the timing in the older version of FSUIPC. Please do ask the supplier. They can get in touch with me if necessary, of course. If the want to keep it private tell them to use email petedowson@btconnect.com. You could also, as an experiment, try renaming it to ipcready.lua, which would ensure it was only loaded when FS is ready. Pete

Of course FSX and P3D are different! But you misunderstand. I still do not understand how you are sending keystrokes. Doing what? If you are not using FSUIPC for this, then why are you here? If you are not sending krystrokes, what is and what is your question about? You misunderstand Windows documentation. Superseded in NT means SINCE NT -- i.e. in all versions of Windows since then! NT was just when it was changed. All versions of Windows since then were based on NT code, not on the older Windows 16 bit versions! Pete

Are you assigning in P3D as well as FSUIPC? hat is really not a good idea. Try disabling controllers in P3D and check again! And on the one hand you say you don't see why, and on the other say to calibrated in Game Controllers and in P3D. But why, when you said that axis was okay in RAW mode? RAW mode is bypassing any messing about that Game Controllers and/or P3D may be doing. Pete