Pete Dowson

Just further on the original question, about mouse macros, I am pleased to say that the new P3D4 facilities to trap and reproduce mouse clicks on gauges work very well, and reproducing them when the panel isn't even present on screen also works well. So, I am implementing mouse macros now, ready for the next release. Oh, also, better than FSUIPC4 and before, mouse macros should work with all switches and buttons on ALL aircraft! Pete

Yes, that's what I tried first and was pleased when it worked well! Pete

Yes, exactly! Just use the options in the FSUIPC dialogue you don't need to create or edit any INI files directly. Pete

Yes, correct. The operation of Profiles is part of FSUIPC. You use FSUIPC for assignment instead of PFC, that's all! Please do take a look at the User Guide documentation for FSUIPC. Profiles form a very important and much praised part of the facilities offered by FSUIPC and one which justifies its purchase for many users. Ah, so you do know about FSUIPC profiles! Sorry, it sounded as if you were confusing PFC functions with those in FSUIPC. Ah, sorry, the confusion is still there I see! You disable PFC control in the PFC options. Please read this part of my previous message: Pete

Ah, yes. I remember that one now. Doesn't it also apply to the AXIS... SET controls? There's another way around it though. Just do it like this: 20=CP(+3,2)2,1,C65706,10 -{ELEVATOR_TRIM_SET}- 21=CP(+3,2)2,1,C65706,0 -{ELEVATOR_TRIM_SET}-22=CP(+3,2)2,3,C66731,10 -{AILERON_TRIM_SET}-23=CP(+3,2)2,3,C66731,0 -{AILERON_TRIM_SET}-25=CP(+3,2)2,5,C66732,10 -{RUDDER_TRIM_SET}- 26=CP(+3,2)2,5,C66732,0 -{RUDDER_TRIM_SET}- (or, of course, with other unique line numbers)

I've now implemented an FSUIPC5 offset method of getting the altitude at a given point. It also returns the surface type, condition, and whether its a platform, moving or not moving. It'll be in the next interim release. Pete

Try enabling Button & Key logging, and also Event logging -- Axis events, because those are axis assignments. These options are on the left in the FSUIPC options logging tab. If you (temporarily) run the Sim in Windowed mode, you could also enable the "Console Log" option on that tab so you can see what happens in real time. Otherwise you'll have to refer to the log file in an editor. Pete

Checking back the function seems to have been added some time in the life of P3D3, or perhaps even earlier (I no longer have older SDKs). I see the function returns a grid. For the basic purpose of returning altitude at a single point, do you specify a grid of 1 x 1 point? Min altitude 0, max, what, 30000 ft+? (I'm not really sure of the purpose of specifying min and max altitudes). I'd just like to clarify this as it would be useful to have a simple FSUIPC function for the altitude at a specific point. I don't really foresee implementing an arbitrary matrix -- such a return doesn't suit the offset methods and there really isn't any flexible offset space available to suit the size of matrix which would be needed for something like the Boeing ND terrain displays. Those are usually generated from databases in any case. Oh, and back to your real question, sorry, but I'm only talking about FSUIPC5 and P3D4 here. I'm afraid I've no idea about FS9. Pete

Yes, just disable the elevator and aileron in the PFC options, in the Flight Controls tab -- uncheck the enabling check marks -- then enable your T6000 assignments in FSUIPC. You can also still use your PFC one as the PFC axes are also still seen in FSUIPC, as joysticks 16 and up. So you can use Profiles to assign one control for some aircraft and the other for other aircraft. You can have them both assigned together provided they have good defined central dead zones in calibration or a very stable and left untouched. Otherwise the axis with the more extreme deflection "wins". Pete

I honestly hadn't noticed that! Was that in the original 4.0 or one of 4.1 / 4.2. I'll need to check back through my SDK collection. In that case I will consider adding a facility in FSUIPC5 to also access such data through the FSUIPC interface. Pete

I am pretty sure these are from the PMDG aircraft. It sends the Sim lots of controls this way. Just don't worry about them. If there are so many they obscure what you are looking for, you can use a facility in the FSUIPC5.INI file to flter controls out of logging -- "DContLogThese" (see the Advanced User guide). They are simply default assignments which you can change if using a third party program for these actions. don't worry about those. Pete

By way of clarification, and to add to Thomas's reply, yes, ALL versions of FSUIPC support "Macro" files (with filetype .mcro), and have for a long time. What isn't currently supported in FSUIPC5 are "mouse macros" which are types of macros created to simulate mouse clicking on switches or buttons. Generally, "mouse macros" rather "went out of fashion" for all but a very few aircraft. Most recent aircraft use XML and local variables (L:Vars), or have their own control system. Even the others often are not written in a way allowing moue macros to operate (they depend on a particular method of implementation, originating with the Gauges SDK in FS2004 or before). Thomas referred to the better way with the 737NGX. The PMDG 737, 747 and 777 all support a complete set of "custom controls" assignable in FSUIPC. As Thomas said, you need to see the list in the PMDG SDK (a sub-folder in your PMDG 737 folder) -- the .h type file lists them, towards the end. You have to calculate the control number (just adding two other numbers) then assign in FSUIPC using the <custom control> selection. L:Vars can be written, again using Macros, but you need to construct those macro files yourself. PMDG don't use them to my knowledge. Mouse macro implementation in FSUIPC5 is planned, using new facilities provided by L-M in its "PDK". As yet there's no timescale I'm afraid. As I said, they have less application now. When they are implemented they will deal with ALL aircraft panels, but sadly, at present, it seems only if the panel is visible on screen which might rather spoil the point for those trying to implement a hardware cockpit instead of using the screen one. Pete

The one you say is the INI from the failure is bereft of any user settings at all. Do you delete the INI file each time you start? There's no need to delete anything! Even the "unregistered" INI (which would be identical to a registered one if you didn't delete them every time) seems incomplete. Don't you use FSUIPC for anything? Without any settings it seems it wasn't worth purchasing!? The log for the failure finishes after the Saitek Pro Pedals are discovered and logged, but before the part where it should log the acquisition for use. This suggests there's some sort of problem in the software installed for those pedals. Could you see what happens if you load up with them disconnected? If you have Saitek software installed for them it would be best to uninstall that. Don't you have any yoke? Throttle? Seems odd to only see pedals listed. Pete

Since it doesn't happen when unregistered, I suspect there's something in the settings (FSUIPC4.INI file) which it is processing which is doing this, so I need to see that file. Please also show me the log resulting from your test with it unregistered. The Event Viewer crash data you provided shows a module offset of xCD993, which places it in a portion of a standard library, and doesn't help directly. The error x417 is a bit amorphous -- either a buffer overflow or sivalid parameter to a library function. Have you made any changes since you last ran it successfully? Pete

No, and I don't think there will be. L-M state categorically that (a) there should be no need to change these tables, and if think they implied that if something needs adjusting for an add-on it should be done in the modelling and (b) they don't want to provide programmatic access to the values because it will restrict development in this area in the future. I am not going to start hacking into P3D4 code as I used to for the 32-bit sims. I was asked not to by L-M and I don't want to in any case, as it makes FSUIPC very version-dependent. I know I always hacked into previous versions (right since FS98 days) but FSX and FSX-SE were not under continuous development, and it was easy to convert the FSX hacks for P3D1-3 because the code was almost identical in all the areas I was dealing with. P3D4 is 64-bit, and much more difficult (for me) to hack) and it is subject to continuous development, including up to 20 odd Beta releases to keep up with between regular user releases, plus the odd HotFix release. If it is so important I would have expected there to be more of a clamour for something to be done about it on the L-M Support Forums, but there has been very little. I think there was one thread about it which died long ago. L-M do take notice of feedback there, so that is how to get attention. Pete

There’s a section in the technical guide specifically dealing with TeamSpeak. Then you needed to set UseSendInput=Yes as I said. Let me know, please, if I need to change that text. Pete

You are misreading something. It is 16 to "press" and 24 to "release". As documented thus, on page 16 of the Technical guide:- Shift state + 8 to Press the key Shift state + 16 to Release the key Just above there you will see the code for the key on its own is 8. The program intended to receive this PTT may also need it sending in a different way. There are options for sending to a specific program (if that program was loaded by WideClient) and also UseSendInput=Yes (page 18), which, for instance, TeamSpeak needs (or used to, at least). I am using an F6 press / release system with WideFS for the PTT on Pilot2ATC and it works well without any sepacial options. Pete

Strange. They should be okay. Which P3D3, the last one, 3.4.something? I don't think I've got any addon-aircraft to use on that. Is there a default where it should work but doesn't? Mostly default aircraft don't support them. Pete

How are you doing it with FSX and P3D? Just via SimConnect? I'm afraid I don't know a way with FS9. If it is possible with SimConnect in FSX then it could probably be hacked with FS9, but I'm afraid I no longer develop for FS9 at all. It is nearly 15 years old, after all! Pete

You don't need a blank page. Just reduce it to the title bar only if you want to see that it is connected, or you can edit the WideClient.INI faile and change the option for the Window there. You can have it minimised, or hidden as well as visible. Check the options for the Visible= parameter in the WideFS Technical guide (page 10). WideClient only detects buttons on standard Windows-compatible joystick type devices. If Windows detects it in its Game Controller app, then so will WideClient. Press and release button events are then transmitted to FSUIPC in the sim PC. So, where are you looking? You'll see them in the Buttons & Switches tab in FSUIPC Options, and that's where you assign them. Maybe you are thinking your existing assignments to the same device before you moved it would still apply, but that is not the case. The Joystick numbering a different for every PC. This is to enable multiple different functions to be assigned, maybe for Pilot and Co-pilot separately, for instance. it is the main advantage of having devices connected to client PCs. The buttons and switches, yes, but if it has displays then no, those aren't supported directly even in FSUIPC, let alone WideFS. You'd need a separate program, or possibly a Lua plug-in to WideClient. The Lua libraries support any HID device but you need to know a bit about programming or scripts. Pete

It may well be something changed in 4.2 which upsets what PMDG does when collecting data for the files it creates. I know that PMDG have lodged some problem reports with L-M for 4.2 and I've seen some folks hang back with 4.1 whilst awaiting fixes. Either way I'm sure both PMDG and L-M are aware of the problems. Even so it could be worth posting to the PMDG forum. First, just prove to yourself that it isn't FSUIPC, which after all merely calls SimConnect -- one line of code -- to ask it to save the flight. So try it manually: press ; and enter a name for the flight, and see how long it takes before you are flyable again. Pete

Yes. There are new facilities in 4.2 which I can take advantage of, but at present the facility L-M provided only seems to operate if the gauge/switch/knob concerned is actually on screen at the time. I'm seeing if I can work around that, but i think it might need more changes from L-M. Perhaps some folks have the cockpit visible on screen even when using a hardware one, so it will be useful in that case, so I will be implementing it either way. Not sure about timescale at present, but it will be withing weeks, not months. Mouse macros basically try to emulate what the mouse does, but only simple things. I'm not sure what you mean by "scrollup or down" though. The clicking on the left or right should be okay as they will be different "mousable zones". If the scrolling is by using the mousewheel, that might be possible but you need to find the correct mouse parameter to put in the macro manually. I really don't know -- FSUIPC merely calls the function it found with that parameter. It is probably a value derived from the same sort of mouse parameters used in PMDG aircraft "custom controls" and listed in their list of same. And they all appear to be related to Windows programming mouse codes. There might be one for "wheel up" and another for "wheel down" but I think not -- more likely "wheel has moved" with another parameter giving the amount (positive or negative for direction). I currently don't know how to get that part into the function. I think the P3D4 facilities provided are just for mouse button clicking, but i'll know more when I've investigated further. Pete

Okay. Or you could od as real pilots and have a Check List, of course. ;-) I need one with my 737, otherwise there's always something I've forgotten! Pete

That's good. Well, you probably need FeelThere support rather than FSUIPC support first, as you need to find a way to operate it with keystrokes or other means. If there are keyboard methods of adjusting it, then you can use those on your "knob". Or maybe they are using an FS control to control it -- use FSUIPC "event" logging (Logging tab) to see if any is logged when you operate it with the mouse. The only other possibility is using Local panel Variables ("L:Vars"). You can list all those for the curret panel by using the FSUIPC-assignable list LVar control. There's also a Lua plug-in provided in the Examples which will display them when they change. You can then see exactly what is being used and how, that way. If it is controllable by L:Var then you will be able to create a small FSUIPC macro to deal with it and assign that to act via your knob. Of course, since your knob is an axis it would be far tidier and easier if the panel knob was also an axis typre control (i.e. continuous) rather than a simple increment and decrement action. If there's a support forum covering this aircraft you'd do well to post there. Other users may have looked at this already, or you may even get help from FeelThere. Pete

No, but the question about what the control knob you intend to use remains. i.e "If your "knob" on your USB game controller is recognised in Windows, and therefore flight sim, as a joystick axis, then you can have a continuous adjuster. If it is a digital encoder with, effectively, two button inputs, then it can operate with small increments or decrements to adjust the results." To put it bluntly, I don't know what your knob looks like to the PC, whether it can be seen by FS or FSUIPC. That's the first question now. But your clarification does raise another question too: do FeelThere provide a way to operate that control knob, or is it only a mouse controlled item? Pete