Pete Dowson

Sorry, there's no way it will work as it stands in CFS3. CFS3 was an oddity in the FS sequence and seemed to have bore no relationship to any of the others. To start with it had no way of loading a third party module. When I looked at it there was no code parts I recognised at all -- I think a different team of programmers were responsible, maybe even something bought-in from outside. Regards Pete

It may be the fuel selector. Sorry, I don't know. Determine the correct control using the logging as I suggested. I think the fuel valves you originally referred to are part of the airliner much more complex fuel systems. Pete

By "fuel cut off" do you actually mean fuel tank valves? What aircraft is this for -- jet, prop or turbo? The fuel idle/cutoff levers on airliners are operated in FS by the "mixture rich" and "mixture lean" controls, with also separate ones for each engine. On most props the fuel selector switch has an "off" position as well as "right", "left" and "both". If you know the switch on the screen panel, and can operate it via the mouse or whatever, you can find out which FS control it uses by enabling Event logging in FSUIPC. With FSX you can have the log displayed in a Window next to a Windowed copy of FS, and see the control logged with both number and name when you operate the switch. Pete

They must be jittering badly then, because FSUIPC, like FS, only forwards throttle controls when the value changes sufficiently. You could try increasing the Delta in the Axis assignments tab if the jitter is the problem. The Throttle Manager lua code appears to use offset 310A to disconnect and reconnect throttles, which is exactly what the FSUIPC added controls do. So, yes, it will override those controls. But I would assume it disconnects them for good reasons, maybe the same as yours. However, I haven't examined the whole program, so I'll have to defer to its author to advise you. It should be noted that many NGX users manage okay without using the Throttles off or toggle controls. Those are really a last resort. Regards Pete

by saying I didn't know what "click spots" were? What an odd interpretation. Defensive? i simply said that FSUIPC wouldn't do such things and asked you to check other aircraft, and also expressed ignorance about click spots. You are very strange to say the least, and evidently read a lot between lines which aren't even there in the first place. I suggest you just read what is written in future. I don't think I'll answer anything else from you, ever. It's a bad experience and i really don't need them at my age. Pete

Hmm. I'm glad, but i would have thought it should be [Macros] 1=AntiIce=C66810 C for "Control" as opposed to K for "Keypress". Maybe I made FSUIPC assume C if nothing was present? not sure ... or perhaps this is enough to fool PFCHid into doing nothing with that switch? Is that what you needed? Regards Pete

I've been experimenting, and found one way of doing it with the previous versions of FSUIPC4 (before 4.867, just uploaded to Download Links subforum), and the way I originally thought you were using but made to work by a change in FSUIPC 4.867. The way which will work in any case is to assign to "Heading bug set" then add the scaling thus: *0.0109863,+180 The multiplier is actually derived from 360/32768 which converts the 32768 range to the 360 range needed for this control. the +180 makes it 0-359 instead of -180 to +179, which the control doesn't accept. The second way, using offset 07CC as I thought you were doing, will not work correctly unless you update to 4.867, just now available in the Download Links subforum. The reason a change was needed to FSUIPC is that the post-scaled values were being limited still to the range -16384 to +16383, because that's the standard axis range. In 4.867 i've relaxed that restriction altogether for axes assigned to offsets. So, with this version you can assign to Offset Word Set, then add this scaling: *2,+32768 The entries for both methods in my INI file are: 4=CY,256,F,66042,0,0,0,*0.0109864,+180 5=CZ,256,F,x020007CC,0,0,0,*2,+32768 and they both work fine provided your input from the axis consistently provides -16384 to +16383. Regards Pete

Okay. The reason is that, unlike the indices for all the other parts, the one for the state is the index x 16. No idea why. The end result was that only the state with index 0 in the state list would ever be found if there were less than 16 states, and if more then the states found would be wrong in any case! Fixed in version 4.63 now available in the Download Links subforum. Pete

You use an editor, like Notepad, and actually type the contents using the keyboard, then save it. It is just a text file. The format is shown. The Control numbers you will need are shown in the List of FS controls document, and the macro names you need are shown in the macro list provided with PFCHid -- the file called PFCmacroindex.csv, which is also a text file. Pete

Advanced User guide (as I said), the section headed "Macro Controls", round about page 36. That is the actual chapter which also deals with Mouse macros and L:Vars in macros, but those are later parts of that chapter. Pete

No no no. Keypresses and buttons are alternative ways of doing things in FS. The PFCHid facility for overriding its built-in actions is by having it call Macros in a Macro File (something named appropriately with filetype .mcro. Macros are described in the Advanced Users guide to FSUIPC. A macro is a sequence of one or more control or keypress actions given a name. A macro file can contain many such macros. The name of the file is related to the PFCHid.INI file by a parameter there, and the macro names are pre-defined according to the switch(es) you want to change. You'll find a list alongside the PFCHid program and documentation.That's how it all ties together. Pete

You do not by a specific version, other than FSUIPC3 or FSUIPC4. Version 4.80 is now 14 months old and was superseded in July last year and has not been available anywhere official since then. Not an Offset control? What was all that about 07CC and DWORD, earlier then? I'm confused. There's no control "AP Heading Bug". Did you mean "Ap panel heading set"? I can't make that work at all with an axis assignment. "Heading bug set" works, but for that you need values 0-359 only. Until you tell me exactly what you've done I'm afraid there's no way for me to help. If you don't understand or can't find it, show me the [axes] section of the INI so I can see what you've done. Regards Pete

What do you mean by the "FSX Buttons" dropdown? What was the name of the Lua file you copied into the Modules folder? Was FSX running at the time? If so you need to press the "reload" button in the FSUIPC Buttons & Switches tab so it will rescan the folder for files. They need to be files with a short but recognisable name, and filetype Lua. For example B377 reverse.lua. The entry in the drop down would then be "Lua b377 reverse". Pete

You do NOT need to use "mouse macros", just basic simple macros, which are just ways of having actions like keypresses and controls in files and referenced by names. Mouse macros are more advanced formas used on some panels which cannot be controlled by key or control assignment and only apply to panels written in a specific manner. Regards Pete

GPSout will work if it is given the correct port number. If not, then it won't. I can't really be any clearer. Sorry. Pete

Hmm. Strange. I'll check. Pete

I can't really support PM -- it isn't my product -- but I don't think PM simulates the backlight, it not being an aircraft function, in the same way it doesn't simulate internal lights in general. Wouldn't you just link up a switch? I think there's one somewhere in the PM offsets. Have you tried going to the PM website and checking the Offsets List? Regards Pete

Correct. That's the only read-out I'm aware of. It comes from the SimConnect variable "PITOT ICE PCT". I don't know of any way to create ice yourself. You'd have to try to simulate the results of ice instead. Writing to a read-only offset, you mean? I don't actually know what that does, if anything at all. I really think you have to simulate the results, not try to be a cause. Check the fail mode offsets starting at 0B62. I think you'd fail the ASI and Pitot, though I don't know if the latter works. Regards Pete

You still haven't told me what you assigned the axis to!!! That is the MAIN information missing all the way through this. There's no point at all in adding 16384. That merely moves the 0 position. You can adjust that afterwards if you need to. The value IS positive, why should it be negative? If you want to regard it as -180 to +179 instead of 0 - 359 as most folks would prefer, then you can easily interpret it that way. A 16-bit value in the computer represents 65536 values, and can be interpreted almost anyway you like, from 0-65535 or -32768 to +32767, or even some fixed point decimal value with some bits being fractions. If you log as U16 it is shown Unsigned (U=Unsigned), if you log it as S16 it is shown as signed (S=Signed)! Wh? To start with, 65536 doesn't fit into 16-bits. It is 0. 0 = 0 degrees. 90 is a 1/4 of 360, and as the whole 360 is divided into 65536 parts, and 16384 happens to be 1/4 of 65536, it is surely obvious that 90 is represented by 16384? I was NOT asking what "offset" (I KNOW it is 7CC), I was askking which Offfset CONTROL you were using! The one you select from the dropdown list. There are many! Sorry, I had not realized you were using such an old, unsupported version of FSUIPC. Please update before going any further. Pete

No, there's nothing useful there because you didn't enable the axis logging. It was the input values for the axis which are needed. But, on second thoughts, when assigning to an Offset control it may not go through the logging for axes ... I'll check that now. If so there's some sepcial debug logging which we can enable instead. S8 means "signed 8-bit", which is onviously completely wrong for an Unsigned 16-bit value! So the logging is not of any use for that reason too. U16 is unsigned 16-bit, same as Unsigned Word (UW). I'll now look at the subsequent posting ... Pete

Ah, you mean places on the screen where you click the mouse to do something? Sorry, I thought it was some specific device or switch on that aircraft. Why not describe it as "when using the mouse it works ..." instead of such an unusual technical term? And, actually, I am completely unfamiliar with mouse usage or on-screen cockpits as I've always used hardware cockpits, the screen only ever showing external views. Why are you using mouse clicking when you have a hardware throttle to do the job? Thanks for the sarcasm, by the way. Doesn't exactly make my day. Pete

How could it? It does what you ask of it, no more no less. Do your throttles worrk with other aircraft? Sorry, I don't know what "click spots" are. Pete

Sorry, I don't understand. You found the problem, and now you have a connection, but you don't? What do you mean by "interactive mode"? Pete

Please refer to the WideFS Technical document, look in the RARELY CHANGED PARAMETERS section. I think it's the first one listed there. You should also set the Protocol requited using that parameter. Yes, as already discussed -- the one to stop broadcasts, obviously, if that's needed. I still don't know why your system gives an error on Broadcasts. It's the first time ever I've heard of such a problem. Regards Pete

Doesn't matter either way if it isn't registered. In the latter case, after registering, you'd have to enable it on the main options tab. Pete