Pete Dowson

I suspect the data you are trying to send isn't valid. FSX ignores invalid values. Maybe your frequencies include the leading "1" and your references to characters [3]-[6] should really be [2]-[5], with the ignored "1"s in [1] and [6]? That's my guess. Please always use the IPC write logging facility to check what is happening. I cannot debug your code here, you need to try using the facilities provided to debug your own programs. If you don't understand the log, show it to me. Also enable Monitoring on the two COM1 frequency offsets, checking the "normal Log" option. this will then also log the SimConnect calls and responses. BTW if this is real code, not just some extracts you've put together, it is very inefficient to make three Process calls to do this. You should be sending all the commands (reads and writes) you want in a cycle with one process call. Regards Pete

I cannot really undertake support for SquawkBox, and in this case I don't think it is needed as I am pretty sure your needs are documented someplace in the SB website. Have you checked? I just Googled "Squawkbox Ident" and immediately got to the correct place in the Squawkbox Manual: http://www.squawkbox.ca/doc/sdk/fsuipc.php . Did you not think to refer to the manual? Regards Pete

FSUIPC4 is compatible with FSUIPC3 in all respects currently known to be required. Please refer to the FSUIPC4 Offsets Status document, part of the SDK, to see if the values you are using are still correct. The SDK also contains a program called "FSInterrogate" which makes it easy to compare FSUIPC3 results with FSUIPC4. Regards Pete

The installation instructions are in the User Guide, not any "read me". Please refer to the section jn there on Installation. It will be near the beginning. BTW the User Guide is provided in the ZIP and also it is installed into the FSX Modules folder by the Installer. Pete

Before we go any further, could you please expand on this a little, as I've really not much idea of what you are talking about? Do you mean by "3 axis" the aileron, elevator and rudder? And if so, why are you wanting to do this as if you are flying with a keyboard, which of course most certainly does use increments and decrements. Again I am afraid I fail to understand you. Sorry. "a generic axis with this to values assigned .."? I'm lost in your phrasing here. Can you possibly be specific, and then it might all become clear? If you are using a pot, why isn't this an axis already? Why use increments and decrements? Regards Pete

I think you'll find that what matters in a motion platform is not the actual angles but the CHANGE in angles -- i.e. accelerations. The body feels those. In balanced flight the only cues to angles are visual -- i.e. out the window and instrumentation. All you need to do is move the platform in the right directions, but by small amounts, at speeds commensurate with the accelerations. In balanced (unaccelerated) flight you'd then slowly level the platform again, imperceptibly, so that it is again ready. You can read velocities and accelerations in all 6 axes through FSUIPC, so all the information you need is definitely available. You need to download the FSUIPC SDK. All the information is there. Just look. What do you mean "add"? I'm assuming you do not mean normal arithmetic addition which surely you know is as easy in C++ as in any other language. Regards Pete

Sounds like a sound problem with Flight School. Check their support. I don't think it uses FSUIPC at all and FSUIPC does not play any sound files. Regards Pete

Do you mean Push To Talk (PTT)? I don't know TeamSpeak, but if the built-in Roger Wilco/Squawkbox compatible PTT control doesn't work you will probably have to program a button to operate whatever keystroke will work with TeamSpeak. Doesn't it have any instructions with it? That'll be some function in your ATC software. Again, you need to check its documentation. Neither of these functions are built into FS itself, so they are not standard for all add-ons. What does that mean? Regards Pete

The IE publisher lists are in the Tools - Internet Options menu. In IE6 it is in the "Content" tab, press the "Publishers" button. You then get untrusted and trusted lists and you can remove from them. IE7 will be similar, though probably not quite the same. Sorry? DX9 settings? As you wish I assume, or I don't understand the question. Regards Pete

No idea about 1 and 2, but, yes, all you need for the FSUIPC side is included in FSUIPC.ZIP and the SDK. You should also scan the Announcements above for later updates and notes. No. The user license provides additional facilities, some of which may well be useful to you but not essential. The SDK covers the application interface, which is free for freeware. The user guide for FSUIPC will tell you about the user facilities which you can pay for. Yes. C or C++ is actually the best language to interface to FSUIPC as it is all written in C/C++ (well, with some ASM too), and the LIB file is aimed at C. The source of the LIB is also provided if you prefer your own integrated code. There are some basic examples provided, but for a C++ programmer it should all be pretty easy to work out in any case. This will have to be my last message till October 1st or so, as I'm leaving on holiday in a couple of hours. Regards Pete

My PFC drivers (PFC.DLL for FS9 and before, PFCFSX.DLL for FSX and ESP), are operating-system independent. They work closely with FSUIPC (or ESPIPC), which needs to be installed too. I have no idea what "program" you had before, I don't supply a separate program to drive any PFC equipment, only FS modules, and they work in FS not in the operating System directly. I am running them on FSX with Vista64 in fact. Whatever 'program' you were using should still work fine. Regards Pete

What have you changed? Have you uninstalled or re-installed the GoFlight drivers or something, or Windows? The only thing FSUIPC is dependent upon to recognise these is the Goflight third-party driver, GFDev.dll, which is normally installed by the GoFlight driver installer. It goes into the same folder as GFConfig -- FSUIPC finds it through the Registry via this entry: "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\GFConfig.exe" On my system it always got installed (by the Goflight installer) to C:\Program Files\Goflight. I also try reading it from the same folder as FSUIPC, so you could try putting it in there if you are completely lost. There are some versions in the Other Downloads announcement above. Regards Pete

Hmmm .... FSUIPC4's own turbulence emulation only comes into operation if you have wind smoothing enabled. It was added because, unfortunately, FSX's own turbulence gets smoothed out by FSUIPC's smoothing otherwise. If you think you have everything in FSUIPC turned off then it cannot be FSUIPC's turbulence emulation. Perhaps you need to let me see your FSUIPC4.INI file. If FSUIPC4 is doing anything at all you certainly must have something enabled. In FS9 the wind smoothing in FSUIPC effectively removed all turbulence completely, so i thought that I would make things better for FSX by adding correct simulation. The algorithm follows correct small Gaussian pattern random changes in both wind speed and direction, proportional to both wind speed and degree of turbulence. There are two sources of turbulence -- cloud and wind, (clear air turbulence), both separately suppressible. FSX's cloud turbulence is actually more likely to upset aircraft than FSUIPC's, but its CAT seems hardly noticeable. The algorithm used was tested by the real 747 pilot PMDG use to test their models, and he did confirm that FSUIPC's emulation was better than FSX's default. If it is FSUIPC's turbulence which is doing this to you, you should see the wind indicator flickering slightly about its average direction, and the airspeed also flickering a bit. PMDG may smooth those out, but you can see it in the on -screen Shift+Z display. FSX's own simulation doesn't register on these things at all. Really? There were some very long discussions exactly like the one you've started now. It went through quite a few iterations before fully working nicely to everyone's satisfaction. Er, what does that mean? If you want to see FSUIPC4's computations in action you can log them. If no smoothing/turbulence actions are being logged then you know it isn't that. To enable such logging do this: Add to FSUIPC4.INI [General] section: Debug=Please LogExtras=768 Note that the log can get very big. I don't want to see it, but you can use it to see what is going on. Once you've set "Debug=Please" you can change the LogExtras number in the Logging TAB in FSUIPC options. For turbulence only change it to 256. For no extras logging change it to 0. Regards Pete

Those are standard FS functions, assignable in FS already, so there's no need to do it in FSUIPC. But of course the same controls are assignable there too. Yes, the FS names for the controls you need are Heading bug inc and dec. I think the Level D 767 autopilot implementation does its own thing, not using FS controls or the FS autopilot at all. Please refer to the Level D help or documentation to see which keypresses to assign instead. For FS controls please always test on a default FS aircraft. If an add-on then does differently, it has its own arrangements which may or may not be documented. Regards Pete

FSUIPC doesn't do anything on its own. It acts as an interface to other programs. Check your add-ons. There are also options in FSUIPC if it is use registered, which can do things for you, of course. Please scan the many many threads and discussions there have been on this very topic, for the last six months at least. Not for a while now though. You must have missed them all. The PMDG 747 test pilot has tested FSUIPC4's simulated turbulence and found it realistic. An autopilot cannot fully cope, in reality, with turbulence above "moderate", so if you find yourself in such turbulence you should, as real pilots do, seek a higher or lower flight level to avoid it. if you don't care to do things realistically, please just disable turbulence. Note that if you use ASX and also have it set with certain options it can exacerbate things. You should not try to have both simulating turbulence. Pete

Yes, I can reproduce that. I think it confirms what I said. I'll look at this example under debugging when I get time. It looks exactly as I said. I will look to see if there's a way I can prevent the "TAB" test working in such cases, so that you aren't misled into thinking you've created a working macro. If the tables are reconstructed from scratch each time, there's really nothing i can do -- I can't find them as they are usually on the stack, which will be different every time. In fact that's a good clue. I'll see if the address i get relates to the stack, and if so refuse to make it work for the test, or even come up with the option. Thanks for the examples i can use. I'll be looking at that on my return from holiday on the 1st October. No, it isn't anything whatsoever to do with versions. It is to do with how the particular mouse-rectangle parameters are being set up. The example you provided should enable me to stop folks trying to make unusable macros. I'm not sure I can do this, but i have a few ideas. From the user's point of view all i can do is avoid the confusion you got into about FSUIPC appearing to forget things. That isn't happening here. It is just that what you want it to do can't really be done except by using the mouse to teach it every single time. That's not acceptable, so I will try to stop it looking as if it might work. Regards Pete

Well, until you mentioned autoflight I would have suggested that it might be sudden wind changes, so switch on wind smoothing, but such things should affect autoflight too. My PFC driver has a filter for poor power supplies incorporated, and that might cope also with iffy hardware, but that's only usable with PFC's digital controllers. I take it you have a normal USB or Game Port device? Not really. You could try logging the Axes (see FSUIPC logging tab) to see what values are actually being input to do these things. If they are extremes then possibly the spike elimination on the Miscellaneous tab would work. Have you tried that? On the other hand, if they are just sudden jumps to incorrect values, then I don't see any way FSUIPC can help. It may not be the pots of course -- a poor power supply can do it, or a bad connection somewhere, or even possibly a problem with the port being used on the PC's motherboard. Try a different cable. If it's USB and you are using a hub, try a direct PC connection. If you are using a direct connection already, try another. Try to avoid two frequently-used devices being on the same pair of sockets -- USB ports come in pairs working through one internal hub. For a dirty pot a spray with something like Servisol might help. any non-conductive grease and dirt repellent should do it, but check that it isn't also a solvent. I use Servisol for electrical cleaning myself. Of course, before doing any of this do make sure you have no conflicting assignments for the affected controls. Regards Pete

So, it isn't forgetting the programming, it is only that either the gauge isn't loaded at the time, or, probably more likely, that the table entries which the mouse macro facility needs are generated on-the-fly by the panel coding instead of being defined in static memory. You could probably check that by re-programming it (to make it work), then load a completely different aircraft, then reload that one and test. I suspect it will be pot luck whether it works again or not, depending on how it sets itself up. If the latter is the case (and I've not actually met one like that as yet, but I can see how it can be programmed) then there's really not much I can do -- the mouse macro facility can only work with standard SDK defined mouse rectangles statically defined using the SDK macros. I can check this if you like, but I'd need that gauge, assuming it works without the rest of the panel. What aircraft is it from, by the way. It's name (Gauge018) isn't very helpful. Regards Pete

No idea why either, but I am very busy at present (off on holiday on Thursday) and I don't want to spend time investigating if it is okay in the current version. In fact, because of that, please try the interim update 3.829. If it is still non-operative i will try to find out why. BTW why do you always refer to it in [] brackets? In the INI file only the Section names are so enclosed. The parameter should simply be EliminateTransients=Yes placed in the main [buttons] section, as documented in the Advanced user's guide. Regards Pete

I don't have that gauge so I can't test it exactly, but certainly the "1=88,8,M3:1,0" parameter works fine here. Is that the only key you've ever programmed, or have you simply removed the others for brevity here? Might there be other [Keys] sections in the file, maybe [Keys....] for aircraft-specific use? Can you do some logging, just to see what is happening, please? First, add the lines Debug=Please LogExtras=2 to the [General] section of the INI file. Then load FSUIPC, and enable Key/Button logging in FSUIPC's Logging page. This will show whether FSUIPC is actually attempting to action the key. You would either get a line saying: .. This key is programmed in FSUIPC4 'Keys' options in which case it is trying to action the macro, or like this: .. Key not programmed -- passed on to FS showing it has forgotten it, as you are suggesting. I suspect that the Gauge you are trying to access is not always loading into FS memory for some reason, so it seems as if the key programming is missing whereas really it just can't call the appropriate routine. Regards Pete

The main information missing, as usual, is the FSUIPC version number. There was a bug like that fixed a couple of weeks ago, so can you try 4.316 now please? Pete

I've not changed it. But I can't support old versions in any case. the current release is 3.82 (since mid-july, some two months ago), and there's a 3.829 available in the "Other Downloads" Announcement above. Please always check you are using the current version when asking for support. Regards Pete

I'm afraid this must be one part of PMDG cockpits which isn't amenable to the methods i use. If you cannot select and test using TAB that's it, it cannot be done this way. I cannot deal with screen coordinates in this method -- for that you'd have to use Luciano Napolitano's Key2Mouse and have the quadrant/pedestal on display. Surely there are regular FS controls (Mixture1/2/3/4 Lean and Rich are the normal ones) or assignable keyboard shortcuts in the PMDG software to handle these? Regards Pete

Well I've tried all of that and it all worked fine, 4/30. 4.306, 4.312, 4.316. I don't understand. I'd really need to see your Buttons parameters, as I think I said. There's nothing magic of clever about any of this, it is all very straight-forward, and nothing's been changed at all. FSUIPC cannot distinguish one FS control from another. They are simply numbers above 65536, sent to FS, that's all. If it affects one it has to affect all. I need to see what you have that's peculiar in your particular INI. Regards Pete

Good catch! Actually the button repeat rate in general slowed by a factor of about 3! This happened in a much earlier interim release I think, the first one after 4.30's release. I had changed the "PostMessage" method I used to a "SendMessage" which I thought would give a smoother response (not faster, but more regular), and in most circumstances it seemed better -- I just failed to notice that the repeat rate had plummeted! Ooops! Please get 4.316 which has this fixed. Now that I don't understand, and it isn't reproducible here. The only way it might not be saved is if the INI file wasn't accessible for some reason when you "OK'd" out of the Options dialogue. Please check the [buttons] section in your INI. In fact keep a copy of it, then assign the buttons, then compare the after with the before. The button data (in fact all changes) are written back to the file on an OK exit (not an Escape or Cancel exit, which reverts the parameters). Another possibility is that you set it in an Aircraft Specific mode without realising it, or, on reloading, were using an aircraft with a different aircraft-specific setting for those buttons. Again, checking the INI file will show what is happening. Finally, there is a remote possibility and that some sort of corruption in your INI file made the read-back fail. If you think that may be the case the best thing is to delete the [buttons] section(s), but by all means let me have a look first. Regards Pete