Pete Dowson

No, don't leave the excess commas in place. Actually, I've checked into this further now, and my suggestion probably won't work. I think it might just then miss setting the final two positions, not the positions you want to omit. So I think you'll need to just calibrate so that two of the detentes are very close -- i.e. my first suggestion. Pete

How would you expect the aircraft to behave for the two flap detentes you want to omit? If you simply don't want it to stop at those two, why not defined the detente points so close to the next that it is chosen by FS instead? You might even to be able to do it so you can still use all 9 but bypass on going up and the adjacent one going down. Have not not tried anything yet? The only other way is to calibrate for the 9 then edit the INI file entry for the calibration results to remove two. Pete

Yes, of course. Better in a sense, because it doesn't have to patch some of the FSX code which has now been corrected by DoveTail. Pete

Possibly it is to do with keyboard/mouse focus? I'm wondering whether the DLL, which needs to be active and present when the Mouse Macro is used, is not actually accessible when that Window doesn't have the focus. Most of the (successful) Mouse Macro usage is with actual Gauge code (.GAU files, which are DLLs by another name) for buttons on gauges situated on the main cockpit Window. Pete

I'm rather confused. Are you talking about a hardware cockpit which you plan to use with a Wilco add-on aircraft in FSX or P3D (or is this some older FS?), or just reviving and updating the code for that add-on aircraft? I'm not sure what you mean by "buttons not directly linked to fSUIPC" -- no buttons are directly linked to anything. You need to assign them in FS or FSUIPC to link them to an FS function. Or do you really mean that the cockpit has functions which are not simulated in FS and therefore have no equivalents already defined? I can of course allocate offset space for applications which need them. Are you planning to write a program to populate them or change the add-on aircraft code to provide them? Pete

On FSX and P3D the flash is set only by the SimConnect "Crashed" event The flag is cleared on a "CrashReset" event ad also when I'm notified of a flight being loaded. The events are obtained by request through the SimConnect_SubscribeToSystemEvent function. In FS9 and before, the crashed flag was an actual location inside one of the FS modules. I had some scenery for Rome Fuimicino once, which was fine on FS9, but someone did an adaptation for FSX. On FSX, one of the runways had some sort of invisible wall across the runway, right in the middle. I always had to turn crash detection off to fly there. My current version is the Aerosoft one, I think. Pete

The package is Zipped, which produces unrecognisable binary in the first place. But before that, the Installer itself is seriously compressed -- not by any ZIP type program, and in turn the FSUIPC4.DLL it contains is also similarly compressed. In fact it runs from its compressed form and only expands in memory. There is no way any of it actually looks like a real program. The occasional false positives notified by difference virus checkers with their different but ever-expanding catalogues of viruses are just that. The system on which I build my releases is kept thoroughly checked against any sort of malware. The proper thing to do when a false positive occurs is to submit the file to the company involved so that they can expand their recognition pattern for the falsely identified virus to eliminate such errors -- naturally, to keep their databases compact the many viruses are stored with the minimum differentiation they feel they can get away with. Pete

It might help if you actually mentioned the aircraft, then maybe others with the same one might be able to contribute. In fact it would be best mentioned in the title. There's actually no difference in what the "Tab" test keypress s doing compared with whatever key or button you assign does. Does the "TAB" test work both with and without the Window title? It may be that it needs a parameter value, too, as also discussed in the documentation. But I've never heard of a case where it works with the TAB test but not with any other key or button assigned. Nonetheless it might be worth experimenting. Very few add-on aircraft are these days written in such a way that the mouse macro facilitiy operates. It's a shame. When I first implemented it, for FS9, most did -- oddly enough, except for default FS aircraft. Microsoft didn't follow their own gauge making "rules" in the SDK. BTW please always post support questions to the Support Forum, not to one of the reference subforums. You are lucky I came across it. Pete

The Lua language is well documented on their website and in books. All FSUIPC adds are a set of libraries of functions to handle FS matters. There are lots of examples in your FSUIPC Documents folder as well on in the User Contributions subforum, and I think those are really the best way to learn. The Lua reference documentation for FSUIPC is also provided in your FSUIPC Documents folder. Pete

An easy solution would be for the calling program to provide you with an offset number which you could change to signal the event. Then, if in a loop, the plug-in could simply test the offset value from time to time, and/or use event.offset. If you need to feed back more information then I could instead allocate your DLL some offset memory space for fixed use. But I'm not sure if the DLL needs to be capable of multiple simultaneous use. Pete

That's exactly what the FAQ subforum if for. There's also the User Contributions subforum which is less for problem solving than additions made by users. Well, depending on how you want them displayed you could either simply use the FSUIPC Logging facilities. On the right-hand side of the Tab there's a "Monitor" section and there you can monitor up to 4 different offsets, to screen or title bar (or both) optionally. You'd need to find the correct offsets in the Offset List (one of your FSUIPC Documents). The other, more sophisticated way is to write a small Lua plug in to act on COM1 and COM2 offset changes (via event.offset) and format and display the results in any desired fashion for display using the ipc.display function. Pete

If you are assigning that axis to a surface control with a "middle" (centre), such as Aileron, Elevator or, Rudder, then you just define the zone around that area to be unused (all values set centre). Look at the calibration sections in the FSUIPC options screen. See values you can set for "Minimum", and "Maximum", and TWO Centre values. They delineate the area you want all to be centre. The numbered step-by-step guide in the User Guide does cover this quite clearly You must have missed a whole chapter, then? The process is the same. For any control which has a centre, there are 4 values to calibrate, not just the 2 you seem to have understood! You just set them in order, left to right. If your faulty axis is not being assigned to a control with a centre, you are stuck -- such control surfaces need a continuous change as you move the lever. I suggest you try to get the joystick repaired -- but try cleaning first. I always found electrical switch cleaner very effective on pots. Pete

Hmm, I don't think you can. You'd need to open a new account with the new email. That shouldn't be a problem. You could still log into the old account to get updated products and keys. I think the only way to talk to SimMarket admin is to raise a problem ticket on your account. Pete

Sorry, there are conflicting statements there. You seem to say in one paragraph that you program keystrokes in FSUIPC, but in another that you do this in KeyMapper. If you mean you use keymapper to send keys to FSUIPC and then program those to send FS controls, then I need to ask whether the keypresses from KeyMapper are seen in FS itself. Have you checked? For keypress programming FSUIPC can only interpret what it sees, and if what it sees is not recognised as an assigned keypress, it lets it through to FS. Try using the same keypresses on your keyboard. Maybe your "KeyMapper" is not Win10 compatible? You can of course also use FSUIPC's key/button logging to check into this further yourself. Pete

Well, I use Google Chrome all the time and it certainly is not so signalled here! Pete

There is only ONE MakeyRunways, irrespective of the FS version. It is not version dependent. Your link works perfectly well! Pete

If the virtual joystick entries are still recognised even after disusing "vJoy", then the DirectInput system in Windows still believes these are there. it seems you need to do more than not run the driver. Pete

You post seems to say two different things: First, if you have areas on your levers where the INput values do not change, then (obviously?) FSUIPC can't do anything with them. Second, if you really mean you want to eliminate parts of your joystick axis range, then you can easily do at both lower and upper ends, and of course in the centre (where there is a centre -- as in Aileron, Elevator and Rudder cases), by simply calibrating after moving the levers to the positions involved. Please do refer to the Calibration chapter in the User Guide, where you will find numbered steps to proper calibration. It it important NOT to mess with "slopes" till you have calibrated properly. Pete

The button/keypress throttle controls are all called "throttle_xxx" or "throttleN_xxx" where N is the throttle number, and "xxx" is Decr, Incr, Cut, or Full. The default assignments for the F1 - F4 keys are Throttle Cut, Decr, Incr and Full respectively. So F2 actually invokes Throttle Decr. There is no specific reverser control supported by any version of FS. F2 just decreases the throttle setting a tad, no matter where it is. FSUIPC not only supports all those controls, but also dedicated reverser axes in the axis assignment section. This is actually more support for reversers than offered by FS itself. If FS default keyboard shortcuts do something you want to program on a button, just enable Event logging in FSUIPC, use the keyboard short cut, and view the resulting event in the FSUIPC Log. It'll give you the correct name there. With FSX in windowed mode you can even use the FSUIPC console log option so you can see the results in real time, whilst you press the keys. Pete

Well, you have 4 X-55 devices listed -- two X55 throttles and two X55 sticks. Does any button on any of them cause the crash? You only have two buttons assigned on one of the Throttles, and you have axes assigned on that same throttle and on one of the sticks. Do you have controllers disabled altogether in P3D? You should do if you are assigning in FSUIPC. From what you say it seems to me as if it must be a problem of P3D, but just try an experiment first -- rename the FSUIPC4.KEY file in your P3D Modules folder. That will make FSUIPC temporarily unregistered so it won't even scan any joysticks, let alone respond to any buttons. See if P3D crashes then. Try enabling controllers in P3D, see if it then crashes. Apart from scanning for changes on any joysticks you have assignments for (only the 2 of them out of the 4), FSUIPC only takes action on assigned buttons, of which you only have the two. Also, I noted from the L-M forums that Saitek released new Win10 drivers for the X55 back in September. Have you checked that you are up to date? ftp://ftp.saitek.com/pub/software/beta/Windows10/ I think you might need to report the problem on the L-M forum. Pete

FSUIPC recognises up to 8 axes and 32 buttons per device. This is for normal easy user assignments. Using the user plug-in facilities,with Lua program scripts you could handle any number of either, using the COM/HID library built in, but that requires some programming in Lua. Pete

All of the FSUIPC applications interface is available whether the installation is registered or not, and that includes program access to all of the offsets. Pete

No need to SHOUT. Of course you can map views to buttons, but I assume you don't want them all on one button? I use a hat and assign its 8 directions to the 8 views, View Forward, View Forward Right, ... and so on. I do this in FSUIPC's button assignments NOT in the axis assignments which is where you'd assign it as a POV for panning. That's the FS mouse look. You don't need to use that. FSUIPC has the same facility, a check box in the Miscellaneous tab. Are you another who never reads documentation? The FSUIPC one also supports the centre mouse button, like EZCA and unlike FS. Pete

I can't be sure without checking the FSUIPC4.LOG file (which is a text file you will find in the P3D Modules folder), but this sounds like something is causing SimConnect to stall -- it is taking longer that 1 second to supply data which should actually be supplied on every frame. In that event FSUIPC decides something is wrong with the connection and does a full re-connection, which is probably what is causing the pauses. If you paste the contents of the log here, or at least part of it till the first stall (it will be obvious in the log), I'll check. Generally this could simply mean that you are overloading P3D and SimConnect cannot keep up. If this were the case, and the stall is merely occasional but then unrecoverable because the reconnection takes too long with other applications also running, then you could try increasing the "SimConnectStallTime" from the default of 1 (second). That's a parameter in the [General] section of the FSUIPC4.INI file. Try 10, and if that appears to fix it, reduce it till it just starts happening again, then increase it by 1. It isn't good having to do this, though, as it means anything dependent on FSUIPC data is getting irregular or infrequent service. Really you should seek to solve the underlying problem, that P3D's SimConnect simply isn't getting enough time, or is getting held up from time to time by excessive demands. Take a look also at your average frame rate. If that is quite high, put a lower limit on it so that P3D allows more time for other things. If it is rather low then it is a matter of reducing the load -- sliders down, less AI, simpler weather from ASN (and less frequent updates), and so on. Pete

Access hasn't needed registration for years now, so, no, I don't. I you are writing something with the intention of selling it for profit, then we need to come to an agreement over payment. But if it will be for your own personal use, is freeware, or you only want it to pay you the cost of developing it, then it is free to use. There's no one license for commercial application, it is decided individually. User registration provides user facilities, including the Lua plug-in option. The application interface is all an unregistered installation provides. Details are provided in the documentation. Pete