Pete Dowson

If you don't understand the concept of "bits" in computers, why not just stick to using the ipc.testbutton function? y and z are two values -- numbers or variables containing numbers. "And" is a logical operation which gives a 1 bit in the result where both numbers have 1's, and a 0 otherwise. Please use Wiki to find out more about computers, bits and logic. Or refer to my article "About bits, numbers and hexadecimal " in the Announcements in this Forum. Or, if all that fails, stick to using the easier functions. (But you really do need to learn a little about computers if you are going to try programming, so it would be worth an effort). The decimal number 00000000000000000000000000000001 is exactly the same as the number 1. Why bother with all those leading zeroes? Page 1 of a book is easier known as page 1 than page 00000000000000000000000000000001, isn't it? The value 1 will represent Button 0, because 2^0 = 1 (i.e 2 to the power 0 = 1). The decimal number 00000000000000000000000000000100 is the same as 100 (one hundred). In hexadecimal that is 0x64, which has 3 bits set, bit 2 (worth 4 = 2 squared), bit 5 (worth 32 = 2^5) and bit 6 (worth 64 = 2^6). Notice that 64 + 32 + 4 = 100. So here you are testing for buttons 2, 5 and 6 all together. I'll let you figure that one. Suffice to say you are testing for 6 buttons there! ;-) Pete

No, Squawkbox 3 worked with FSUIPC and WideFS, but Squawkbox 4 is a pure SimConnect application, and communicates via SimConnect, not via FSUIPC nor WideFS. I don't know vasFMC. You don't install FSUIPC4 on any client PCs, only on the FSX PC. The only component of mine you need on the client PC is WideClient, the part of WideFS for client PCs. WideClient talks to WideServer on the FSX PC (the part of WideFS built into FSUIPC4), and that talks to FSUIPC4 (obviosuly, it is now part of it. ;-) ). Regards Pete

The BGLs actually contain the values 128.699999 for both of these. I don't know what program the author used to build the BGLs but that's the first time I've seen even slightly inaccurate frequencies. They will be stored like that in FS and probably read like that in FSUIPC offsets too. I assume they still work in FS with the rounded 128.70 values? To make"MakeRwys" consistent with FS I've fixed it by rounding the value too. Download version 4.43 from the Updates announcement at the top of this Forum. This update also makes it consistent with what FS does when it finds two definitions for the same airport both with taxiways and gates and no intervening "deletion" command. Previously the later set would have been used by MakeRwys, whereas FS seems to keep the first set and ignore further definitions (unless a "delete" occurs, of course). This occurred recently with a bad EXCLUDE file supplied in Aerosoft's Schiphol for FSX (but quickly fixed with a replacement EXCLUDE file on their Support Forum). Regards Pete

Thanks, received ok. I'll check them out. Pete

Sorry, your message arrived whilst I was on holiday and I did not notice it had not been answered. Reading the questions in your message I'm afraid i don't fuly understand them. Are either of them related to FSUIPC at all? Have you done this in FSX, or are you using FSUIPC? Is this just a yoke, no throttle quadrant? Does the throttle respond to either aileron or elevator movement? If so you most certainly have a dual assignment -- i.e. the same axis assigned for two different purposes. Maybe both in FSX and in FSUIPC? If the throttle merely moves to a fixed place with any yoke movement, and stays there no matter what you do with the yoke, then what is likely happening is that your yoke is "asleep" until you move it, then wakes up and sends signals to FSX. One of those is probably a spurious throttle signal -- if so you need to contact Saitek support and ask their advice. It may just be a Saitek driver fix you need. To stop USB devices sleeping when not used, go into windows Settings-System-Device Manager. Find the USB hubs and turn off power management on every one. That's because you are using saved or supplied flights which have the engines running. Just stop them (cut fuel, set mixture to full lean (Ctrl+Shift+F1), turn everything off (battery, alternator, lights etc), then save the flight and mark it as your default flight. You can do this with any aircraft and situation. These sorts of general FSX questions are really best directed to the FSX Forum, where I am sure you'd have received a more immediate response. This Forum is really only concerned with the software I produce like FSUIPC and WideFS. Regards Pete

Sounds like you have multiple assignments. There's no other way such mix ups can occur. You don't give me enough information to advise more. I need to know: 1. Version number of FSUIPC 2. Are your axes assigned in FSX or in FSUIPC? 3. If assigned in FSUIPC have you disabled all the joysticks/controllers entirely in FSX? You'd need to re-check because if you disconnect and reconnect, FSX might pick them up again and make new default assignments. 4. If assigned in FSUIPC, are they assigned "direct to FSUIPC calibration" or to the FS controls? 5. Possibly showing me the [Axes...] sections of the FSUIPC4.INI file* might also speed things up, though there's no way I can check here for any assignments you have in FSX itself. If all your assignments are in FSX, not in FSUIPC, then what you are experiencing cannot really be related to FSUIPC4, but only some incorrect assignments in FSX itself. Regards Pete * The FSUIPC4.INI file is a text file found in the FSX Modules folder. All of your FSUIPC4 settings are stored there.

Sorry, I do include Gauges in this context -- I already have to determine gauge presence for the mouse macro facility where I'm executing calls directly into their code. In fact checking DLLs present in the current process is a bit easier than determining what processes are running. Regards Pete

I think the default blending time is around 30 seconds. But I'm not sure. That is a read almost immediately after your write. The one for interpolated weather at the aircraft was correct, as I highlighted for you: FSUIPC decodes this METAR thus: did you miss that part of my last reply? FSUIPC is doing what you ask, and, as far as I can see, so is SimConnect. Whether the FSX weather rendering system does as well is another matter. I have no idea how to correct its idiosyncrasies I'm afraid. Folks like Damian (Active Sky author) know far more about the fiddles one has to endure than I. Regards Pete

Is it possible to correlate the differences? Or does it appear random? It sounds very much as if FlightKeeper is reading the wrong value, or the altimeter, not the altitude, assuming it is always in feet or metres even though the FScargo program might change the altimeter option. Possibly it is also using the pressure read-out to compute the altitude so it can tell what flight levels you are flying and the FSCargo application is setting wildly incorrect pressure settings. I can't see any possible valid correlation between 15000 feet (4572 metres) and -355 (or more likely 65181, the positive equivalent in a 16-bit value). Considering that and the fact that it was okay in FSUIPC 3.7 strongly suggests that FK is reading some incorrect offset in FSUIPC that just happened, by coincidence, to contain the altitude but which offset has since been used for something else. Information on what FlightKeeper is actually reading would tell us. But I think, even when we know this, it would need a fix in FlightKeeper. I'm not surprised! Version 3 has been available for a while now and fixes a lot of things. I'd recommend that you upgrade. Equally I cannot support FSUIPC 3.7. Regards Pete

The log looks better now. so far, so good. GLOB weather mode is in effect and set at the nearest WX station too. Your setting: has been sent, as that FSX-style METAR string, to SimConnect, and a few seconds later reported as such: FSUIPC decodes this METAR thus: So I can't see anything wrong. Mind you, I've not decoded the data you are sending to the C8xx offsets to determine whether FSUIPC encoded them correctly in the METAR. It would be easier to see if it was correct if you told me the weather you were setting too. Cause what? It seems okay. It might take FSX some time for the weather to be promulgated to all the weather stations. I notice that although you set the "seconds" filed to zero: you don't set the flag in C802 to tell FSUIPC to apply that non-standard blending delay. In fact you clear all flags instead: Regards Pete

I cannot really support GFdisplay any more. If your unit is on the same PC as FS then you'll find the Lua GoFlight facilities much easier to use (like simple Basic programming instead of complex parameter formats), and a lot more powerful. For your questions: I've not worked with GFdisplay for years, but I'm pretty sure that is simply something like: L1=X5300 U8 =1 However: is not at all possible in GFdisplay because GFdisplay only handles displays. It does not read switches nor write to offsets. To do what you want to do you can simply assign that toggle in FSUIPC, to "Offset Byte Set" with parameter 0 or 1 respectively. Regards Pete

You need to apply SP1 before SP2. The latter did not include it, unlike Acceleration. Regards Pete

Okay. Thanks. Okay. One question, though. I assume the event name strings are the only identification -- to SimConnect and to each registering application? Isn't there some concern that different applications might choose the same string names for subtly or even wildly different purposes? There's no central register of names after all. That's often simply not soluble without the hardware being changed to supply the switch states even when they are not changed. My PFC hardware, for example, only scans and returns a small proportion of its switches. I believe many other switch-connecting boards are the same (e.g. cpFlight controllers appears to work without any regular returns). The only way I ever do it is to do a complete pre-flight check, scanning all switches and toggling those in their incorrect positions compared to the flight I am loading (normally "cold and dark"). You could make that work with standard joystick device types, or those emulating them, because they are polled for their switch and button settings. But it won't work in general. And doing this in FSUIPC rather reverses the way it is designed -- it reacts to button/switch/axis changes, finding the action to suit the change. Operating the other way around, finding the button for each user-assigned action would require a different structure for the tables, or a duplicated one. I'm not sure I want to go that far. However, I'll give it some thought. The easiest thing to do would be via an added control to reverse the most recently Joystick button memories so that the next joystick poll would cause all of them to 'fire'. However, that would press all joystick-scanned buttons, not just toggles, and could do more harm than good, don't you think? At that level I have no way possible to determine whether a button is acting as a momemtary or a toggle or part of a multi-way switch. In fact I haven't that information even in the action tables, only actions on press and optionally on release, which applies to all types of buttons and switches. FSUIPC always sends events at normal priority. It also traps and logs at highest maskable, but only masks those needed to meet its user's needs of course. I'd prefer the lists to be supplied or created as files ready to read by FSUIPC, like Macro and Lua files. I really don't like complicating the user interface further -- it isn't an area I excel at, for sure, and it has got to the state now where it is nearly saturated and would need a good re-working. I suppose such a file would merely contain a list of names, 1=XXXX, 2=YYYY and so on. When I was mentioning how to check if the recipient application was running I was thinking of using the file's name "MYAPP.EVT" (EVT = Event list) to identify it, so the controls were only added to the dropdowns if the file was in the Modules folder AND the App was running. The controls would be: MYAPP:XXXX MYAPP:YYYY etc, to highlight this, even though the event name used would still be just XXXX or YYYY. However, if the app running isn't particularly important as you say, the filename wouldn't really matter. I'd just read all .EVT files. Regards Pete

There's the real problem -- you've not yet updated your copy of FSX. The original version was VERY buggy, and most of the weather facilities in SimConnect did not work. You need at least SP1 installed. Try that and let me know please. Regards Pete

Is that a severely edited version of the Log file? Because there are many critical messages missing. You have weather logging enabled, yet there's no sign of any weather being read. Have you turned FSUIPC's weather reading off? By cutting off the top of the Log you deny me knowing what version of FSUIPC4 it is you are using, and you don't state it. It also doesn't show me the version of FSX you are using. And it is a shame you did not include your Lua program, or at least a small one enough to demonstrate your problem. However, I made a very small one, without actually any weather being set, just to show you the Log entries I would have expected to see: Here's my test Lua: ipc.writeUW(0xC800, 5) ipc.writeUW(0xC80C, 0) ipc.writeUW(0xC800, 4) ipc.writeUW(0xC800, 3) Here's part of a default log, with no logging options selected at all: 894765 Weather Mode now = Global 894828 NWI weather clear actioned 894828 External weather discarded 895219 Weather Mode now = Theme 895219 Weather Mode now = Global See that the FSX weather mode changes are logged? They are ALWAYS logged (unless you are using an original FSX which was buggy and doesn't notify apps). See also that clearing all weather resets the mode to "Theme" (as it uses the "clear skies" theme", but FSUIPC restores Global mode afterwards? With weather and IPC write logging enabled too, as in your case: 1155594 WRITElua C800, 2 bytes: 05 00 .. 1155609 NW_GLOBAL command, setting weather to global mode 1155625 WRITElua C80C, 2 bytes: 00 00 .. 1155625 Weather Mode now = Global 1155625 WRITElua C800, 2 bytes: 04 00 .. 1155625 NW_DYNAMICS command, setting weather dynamics = 0 1155656 begin_of_the_skype_highlighting 0 1155656 end_of_the_skype_highlighting begin_of_the_skype_highlighting 0 1155656 end_of_the_skype_highlighting WRITElua C800, 2 bytes: 03 00 .. 1155672 NW_CLEAR weather command received 1155672 NWI weather clear actioned 1155672 External weather discarded 1155687 Weather Mode now = Theme 1155703 Weather Mode now = Global 1156640 Weather Read request (At Aircrft) to area 4: Lat=53.36, Lon=-2.27, Alt=147.1, Req=2 1156640 Weather Read request (Nr Station) to area 5: Lat=52.86, Lon=-1.43, Alt=0.0, Req=1 1156640 Weather Received (type 4 request, Interpolated): "GLOB&A0 271116Z 00000KT&D609NG 100KM&B-1500&D6072 CLR 15/05 Q1013 " 1156640 WX Received in 0 mSecs, WX request type 4, Lat=53.3600, Lon=-2.2723, Alt=147.1m 1160812 WX Error: timed out, WX request type 5, Lat=52.8600, Lon=-1.4344, Alt=0.0m 1160812 Weather Read request (Global set) to area 1: ICAO="GLOB", Req=0 1160812 Weather Read request (Nr Station) to area 5: Lat=53.36, Lon=-2.27, Alt=0.0, Req=1 1160812 Weather Received (type 1 request, AtStation): "GLOB&A0 271116Z 00000KT&D609NG 100KM&B-1500&D6072 CLR 15/05 Q1013 " 1160812 WX Received in 0 mSecs, WX request type 1, ICAO=GLOB 1160828 >Change: Pressure=1013.0 mb 1160828 >Change: Surface wind: to alt=3530ft, dir=0T, vel=0.0, gust=0.0, turb=0, shear=0, var=0.0 1160828 >Change: Wind layer 1: to alt=6530ft, dir=49T, vel=22.0, gust=0.0, turb=2, shear=0, var=0.0 1160828 >Change: Visibility[0]: range=62.1sm (100005m), from=-1210ft, to=8780ft 1160828 >Change: Cloud[0]: remainder cleared 1160828 >Change: Temperature[0]: alt=226ft, Day=15.0 C, NightVar=0.0 C, DewPt=5.0 C 1160828 Results: FS98 Pressure=1011.7 mb 1160828 Results: FS98 Wind0: ground (255ft) to 3280ft AGL, dir 0M, vel 0, gust 0, turb 0 1160828 Results: FS98 Wind1: 3530ft to 6530ft AMSL, dir=48T, vel 22, gust 0, turb 128 1160828 Results: FS98 AmbientWind at PlaneAlt=482: dir 0M, vel 4 1160828 Results: FS98 Vis: range =62sm, (raw value=6214) 1160828 Results: FS98 Tstorm: type=0, from 0ft to 0ft (+/- 0ft), cover 0, turb 0, ice 0 1160828 Results: FS98 Cloud1: type=0, from 0ft to 0ft (+/- 0ft), cover 0, turb 0, ice 0 1160828 Results: FS98 Temp0: to 256ft, Day 15.0C, NightVar 0.0C 1160828 Results: FS98 CurrTemp at PlaneAlt=482: 15C If you aren't sure why you are not seeing these things, please show me your FSUIPC4.INI file. Please check that your FSX is at least at SP1 level -- weather is still buggy in FSX even with SP1 and SP2, but a lot didn't work at all in the original release. Please also make sure you are using FSUIPC4 version 4.60 or later. If you want me to test further, please supply the Lua you are testing with. Regards Pete

No, there is no error. Hmmm, curiouserI need more information then. 1. Is the altitude the only thing missing in FlightKeeper's log? 2. Does it just omit it, or give it incorrectly? 3. Can you please enable IPC Read logging, in the Logging tab of FSUIPC, then reproduce the problem. Please end the session as soon as you know the FK logging is wrong -- the Log file will become huge quickly. 4. Save the FSUIPC.LOG file with a different name, and do exactly the same for 3.7, stopping it at about the same time. 5. ZIP up the logs and email as attachments to me at petedowson@btconnect.com. Please also report this to Flight Keeper support, because I think I'll need Simon to identify what it is which FK is doing differently. Regards Pete

The InitialButton facility is a list of buttons to be "pressed" by FSUIPC during initialisation. You aren't listing just a button so your format is wrong. The button will be pressed and released, so you won't get Listen On set unless you have a separate button for Listen Off. You could do that by specifying a button you don't have and adding its entry in [buttons]. However, it is quite likely that the Listen On will be sent before IYP has finished initialising and therefore won't be seen. If you want a facility in IYP to have listening on by default, you'll need to ask Robert. It shouldn't be repeated or you will be filling up IYP's message queue with unwanted messages. That shouldn't make any difference at all. The registered message system in Windows is the same in all versions of Windows, so it will be the same on any PC. Programs cannot "swallow" the message. Only programs also registering the message will recognise it in any case. If I were you I'd report this to IYP Support so Robert can see what is going on inside IYP. I really cannot support his program. I'm sure he's tested on a non-WideFS system. Almost all users run IYP on the same PC as FS, like you. What key have you assigned in IYP? Make sure it doesn't include Shift, just in case. FSUIPC uses a Windows facility for playing back recorded key presses. How that looks to other programs depends on the level they are detecting keys. If they are only processing standard messages it should look the same -- WM_KEYDOWN, possibly a WM_CHAR (but not just with Shift), and a WM_KEYUP. With Repeat on you'd get multiple KEYDOWNs and CHARs but only on KEYUP. Why not try a proper key or combination with TeamSpeak (assuming it doesn't support the almost-standard Roger Wilco message for PTT control)? Why would there be? IYP shouldn't be listening just because someone uses Shift. since it isn't doing anything, and is probably rejected in any case for being in the wrong format, no. I think you are speaking about the FSUIPC4 controls 1001 and 1002? I don't remember the numbers, you'd need to look them up. I'm talking about the long-standing standard PTT controls which work with Squawkbox, Roger Wilco, and several other programs I don't remember right now. "Implementation" is merely by assiging in FSUIPC. There's nothing else needed. That should tell you pretty quickly whether TeamSpeak supports them. No need for an extended period of research! Regards Pete

It may be a timing problem in IYP. I think there's a small delay enforced in any case. You might need to talk to Robert (IYP Support). There's no flags involved in the FSUIPC side of things. If you are using the FSUIPC added controls for IYP then they are all dealt with by sending Registered windows messages. That occurs immediately you press/release the button. Doesn't TeamSpeak support the same messages as Roger Wilco, so you can use the FSUIPC PTT controls? You appear to have made some errors there. To start with you have them all repeating whilst held down. You most certainly don't want that for any of the IYP controls. You are probably flooding IYP's message queue with "Listen On" commands which will understandably make it slower to see the Listen Off. Whether the keypress for TeamSpeak needs repeating I've no idea, but if it works I'd assume so. Secondly you have multiple actions for Y,1, but in a strange order. Look: 1=RY,1,C1117,0 ; IYP ComeFly Active 5=RY,1,K16,9 6=RY,1,C1116,0 ; IYP Listen Off You should surely get the Listen Off sent before making others active. Just renumber the lines to get the correct order.

Yes, though I think Enrico made changes to fix it in the later versions of the MCP application (at least for the 737NG, which is what I use). Strange as that fixed it pretty well for me -- it now only happens if I engage APP mode too early (before levelling out and intercepting the glidepath from below) and too fast. Are you sure you put the parameter in the correct section ([General])? -- don't simply add it to the end of the file. The fiddle in FSUIPC was definitely to counter a very specific bug in PM's MCP program, which I'm pretty sure is fixed. I think you should check the exact conditions which are applying when you get this problem, because it may well just be that you are exceeding one or more of the conditions needed for a stable entry. Of course, it also maybe due to incorrect AIRCRAFT.TXT parameters (those provided to the CDU for the aircraft you are using) or a bad aircraft model (i.e. the AIR or AIRCRAFT.CFG). I use the PMDG 737-700 from FS9, with no panel of course. Otherwise I'm afraid it is over to PM support. Regards Pete

That shouldn't be anything like a "challenge". Install FSUIPC4 by running the installer, download PFCFSX.DLL and put that into the modules folder, and copy your FSUIPC.INI and PFC.INI files over. Rename the INI files and you are pretty much done. If you've assigned axes in FSUIPC, some of them might get changed - X,Y,Z are the same but for some reason the R U V of the old windows interface, used in FSUIPC3, don't equate the same in directInput. But all the PFC stuff is the same. For FSX it is PFCFSX and FSUIPC4, and for the latter you MUST use the installer. There is no FSX Modules folder by default -- how did you make it? No no NO! You do NOT need any "SimConnect.DLL". That's part of FSX and is installed when you install FSX. Where on Earth are you getting these wrong instructions? You just run the FSUIPC4 installer! What instructions? There must NEVER EVER be any SimConnect DLL in that folder! Delete it! It's all so easy if you use the FSX versions, not the FS9 ones, and simply follow the (almost) one-line instructions -- run the Installer, copy in the PFCFSX DLL! Regards Pete

Hi Si, That's useful. In that case it would have been really nice for all these complex aircraft makers to use that facility rather than expect folks to assign and use obscure key combinations. So what exactly do you propose providing FSUIPC so that it can add these to its assignments drop-down lists? Just a data file with a list of names? Shouldn't FSUIPC check that whatever it is actioning these is actually running, or doesn't that matter? And have you got anything I can use to test the facility with, once implemented? Best Regards Pete

That appears quite late on, when "ready to fly", and there are other variations. The WideServer Log file is the true indication of whether it is running and it will show any problems. Regards Pete

Why through FSUIPC? Those controls are assignable in FS itself ("increase autobrake control" and "Decrease autobrake control"). Ersorry, now you are confusing me. You are assigning a joystick button to press a key, and assigning the key to operate an FS control? Ugh! Why not simply assign the control to the joystick button in the first place? That's really terribly inefficient! Nothing in FSUIPC or FS is special to any add-on aircraft. Test always on a default aircraft. In your key assignments: lines 14, 28 and 26 will be ignored as "N" is not a legal code. The only one left is Tab+Ctrl+P assigned to toggling a panel with ID 10005. The keys assigned to the autobrake controls (66298 and 66299] have been disabled by your 'N'. Please try assigning buttons to controls, not buttons to keypresses to controls. That makes no sense. And for those controls assignable directly in FS, there's no need to use FSUIPC unless you want them aircraft-specific or Profile-related only. Regards Pete

It sounds like you are using ther "aircraft specific" facility, not "Profiles". By default, and because the facility has been in FSUIPC for many years, only the "aircraft specific" option is presented. In order to use Profiles, which are easieer to use but which were a much more recent addition, you need to edit the FSUIPC4.INI file and change "UseProfiles" from "No" to "Yes". Do this before running FSX. If you've already set some Aircraft specific settings you can simply let those convert automatically, but for clarity you may wish to delete the [JoyStickCalibration...], [Axes...], [buttons...] and [Keys...] sections already bearing an aircraft name, and start again. Sorry if this default is confusing -- I couldn't automatically impose the new Profiles method because there are many thousands of long-time users with established Aircraft Specific settings. It's totally independent of operating system which is irrelevant to FSUIPC. It sounds like you did not keep your XP FSUIPC4.INI file. If you still have it I'd advise you to copy it into the FSX Modules folder in your new installation. I think you forgot to change the UseProfiles option after reinstalling. Regards Pete

Don't ask for any support then. I cannot support old versions. There is nothing wrong with the latest one -- it is far better than any old versions. Just review the History documentation i always supply to see why. :-( Pete