Pete Dowson

Really? Not here, not often in any case. But then I am using MyTrafficX at 70% in Europe. ;-) I've put the request on my list and may implement something. I'd have to grey out the options in the miscellaneous tab too. you'd have to add an INI line after setting the options, and that line would lock the settings on the next session. Pete

What, exactly are you "toggling between NAV1 and NAV2?" Just saying that on its own makes no sense. If it is something FS can actually do (and i cannot tell from your 'description'), then you can find out what control instigates it, if any, by using FSUIPC logging -- enable the Event logging, operate this "toggle" and see what is logged. Pete

No, not as it is at present. It isn't really structured to work like that. It is possible to do, obviously, and i can put it on my list for consideration. but i cannot guarantee anything, nor any timescale. No. Currently the colouring is reserved for Toggle highlighting. The facilities are really as documented, no more and no less. If there were extra facilities i would have published them, not kept them secret. FS provides all of the controls you could possibly want. The standard FS controls certainly don't alter the Active directly, they alter the Standby (if there is one -- it depends on your radio stack). The facilities to change the Active directly are additional FSUIPC controls, not built-in FS ones. To work out what controls to use, please use FSUIPC's logging. Enable event logging, then use the mouse of keyboard to operate your gauges. Look in the FSUIPC log to see what controls were invoked. That way you find the correct names easily. Otherwise print out the full list of FS controls and refer to that. Regards Pete

Yes. Simply select the registration options in the installer when it asks, then fill in the fields. There's no other way, so there's no "best way" or "worst way". The version is irrelevant to registration, provided you use FSUIPC4 keys with FSUIPC4 and FSUIPC3 keys with FSUIPC3. There's also a much more recent, interim, update available in the FSX Downloads announcement above. Currently we're up to 4.323. Regards Pete

Idoesn't the on on the GF site include GF46 support? I'm sure i got my copy from there. I can't find the SDK file itself at present -- it's a long long time since I dabbled with GF stuff. But I do have the header file for it which shows the GF46 structures and so on. would that do? Do you program in C/C++? (I don't recall any documentation for this stuff in any case). Write to me at petedowson@btconnect.com if you want the files I have. Regards Pete

What does stepping on the base do? Are you saying they do not spring back to their normal position when released? Sounds like you need new springs? That makes no sense. I'm sure that you could make almost the whole operation "dead" by pressing down a long way before setting the minimum value to be used. Anything below that value will have the brakes off. If you are really saying that your brakes are only ever giving either full on or full off, then they are operating in "digital" mode, not analogue, and cannot be calibrated as axes at all. That will be a function either of your driver for them, or possible a switch setting the mode on the unit itself. Regards Pete

Yes, you could certainly go either way. I think it would be easier and probably more precise to use it as 9 buttons. just program each on as "AXIS_FLAPS_SET" with the appropriate parameter. i think that would run from -16383 for no flaps, in 4095 increments. Some experimentation might be needed to get the exact figures, but on the whole FS is pretty good at latching to the correct notch. Regards Pete

No, sorry i cannot see that from your picture! Surely they should be centred when released? Why would they not be except for poor calibration? You need to calibrate correctly so that the "neutral position" IS the position giving you centred rudder! If they are all separate axes then should all be calibrated to give zero when released. If the axes are all separately recognised in Windows, you can most certainly assign both, or all three, to the rudder in FSUIPC. The problem would be that you only have one rudder calibration, not separate ones, because there's only one rudder input to FS. If your pedals both operate in the same direction, this won't work because pressing one side should decrease a value below zero and pressing the other side should increase a value above zero. Furthermore if both axes are providing input values at the same time, the last one to change would "win" (though FSUIPC does have arbitration for the maximum deflection to win instead) -- either way, its use would be somewhat unpredictable. Maybe if the are both operating in the same direction you could reverse one of them by swapping wires around internally? Regards Pete

Why on Earth would you want independent left and right rudder? Look at a typical aircraft. It has one rudder. It is controlled by one rudder control? How would two different rudder inputs help? What would they do? What would both left and right rudder being depressed mean? Go both ways? Split the aircraft in two? :lol: No. There is only one rudder axis. There is no possibility of separating left and right rudder -- and no point. It makes no sense. Sorry. Your two other axes will be toe brakes, not rudder controls. There are separate left and right brakes. That makes sense because differential braking helps turning corners more sharply. It needs proper calibration then. It should be centred with your feet off. Regards Pete

Not sure why you think of FSUIPC specifically for this. Your first job is to get your contraption, however it is built, recognised as a joystick axis or a set of buttons by Windows. FSUIPC isn't a hardware driver -- it simply reads data from Windows. You'll need either a Game Port or USB interface, or possibly some other Analogue to Digital interface card or switch detector. Sorry, I can't really advise on building hardware and interfacing it to PCs in such a way that Windows can handle it. There are plenty of proprietary interface cards around which you could buy and program for this, and once you go down that route i suspect you'd find it easier to either use a regular pot rather then a heap of microswitches, or otherwise use the microswitches as buttons rather than emulating an axis with them. Regards Pete

If you have to step on the brakes to release them it sounds like they are revered. Select "REV" and re-calibrate. Also, you should always leave quite a reasonable dead zone -- press them a little before clicking on the "minimum" (i.e. brakes off) button. Otherwise you'll tend to get get some braking when using the rudders. Pete

Ah, the comma after the ) shouldn't be there. Sorry. I've just noticed that's a typo (in only two of the examples -- the rest are okay) in the manual. Odd no one has spotted that before! What you have will be read as 2=CP(F+0,11)0,0,0,C65640,0 and the Error 19 is complaining about the lack of a C before the third 0. I'll fix the typo in the documentation -- it's been like that for about 9 years now! If you are referring to the FSUIPC4 version, please also refer to Appendix 1 "Do more with your joystick" which has a lot of examples and no typos that I can see! ;-) Regards Pete

Okay, it is there now. Pete

I don't take changes out once they're in unless they don't work or are not required. anything in and working in 4.311 will be in and working in any version > 4.311 too. Ah, sorry. I might have forgotten to mention it. It was a pretty trivial change and didn't change the way things worked for anyone else. I'm really not sure what either of them do in this area without ploughing through the code. Are you saying you want FSUIPC4 to add 1 to this is the precipitation type is set for rain or snow? What about setting the rain or snow? Is that consistent? I have to decode/encode the METAR reports for FSX, so it isn't a simple matter for me to look at without more data. Nevertheless i will take a look. It might help if you have so METAR strings (from the relevant FSUIPC4 offset) and the corresponding Cloud records to compare. A weather log extract (Weather logging in FSUIPC's Logging page) would be adequate. [LATER] Okay, forget the logging. I see what you mean. It IS actually consistent reading and writing, which is what matters most, and why it's done no harm to date. The problem arises from the fact that the FSX METAR extension coding for Clouds has a 5 precipitation level sequence starting with "V" for "very light", but no rate value for "none". Weird. Here: P - Precipitation, one of: V (very light), L (light), M (moderate), H (heavy) D (dense) Q - Type of precipitation, one of: N (none), R (rain), F (freezing rain), H (hail), S (snow) The precipitation type encoding does have "N" for none, so I'll use that to re-encode/decode the zero precipitation case, moving the real ones up one. Note that the type encoding goes up to 4, but for FS9 compatibility i encode N= 0, R = 1, S = 2, F = 3 and H = 4, rather than the order FSX gives them. The rate value will be fixed in 4.323, uploading later today. Regards Pete

No. I did experiment with this years ago (using EPIC and my EPIC driver), but for most purposes it wasn't really a good idea. The latency made control of the aircraft much more difficult. It's surprising how a delay of 20-100 mSecs can affect your control. You tend to overcontrol. It's a bit like what happens when the FS frame rate is too low. The only reason I investigated it back then was because, before USB, the only way to connect analogue axes was via the Game Port. Except by purchasing a dual game port card (not always supported by programs anyway), you were limited to the one game port on the motherboard (or more usually on the sound card, oddly enough), and that supported up to 4 axes -- enough for simple simulator requirements, but no more. These days there's no practical limit to the number of USB-based devices you can connect to the main flight PC, and USB operation on the local PC is far more efficient that having the PC service calls on a Network for every small change in each of your axes even without worrying about the queing and latency in processing these. You can't even really argue that the wire isn't long enough to reach, because USB connections can be really quite long. some of mine are 20 feet. Regards Pete

Isn't VB.Net a managed language, not even native code? If so I think you'll find it next to impossible. FS is all native code. You might be able to make some sort of wrapper for it, but I think it would be horrendous. And you'd be severely risking the performance of FS . I'm not sure why you'd want to run internally to FS in any case. It limits options (like you then cannot run it on a separate PC, to alleviate the load on the FS PC, or provide much more screen space or peripheral access). And you have to program very very carefully to make sure you don't impinge upon FS performance. Your skills at efficient programming with a mind to time-slicing and use of threads has to be top notch. I'm not even sure you can do much of what you'd have to do in VB, let alone VB.NET. Regards Pete

No. Really? That's odd. I don't know of any! What are they? 40 nm is, i think, the TCAS instrument range, isn't it? Maybe that's why I, as an AISmooth user, have never noticed it changing it. To lock it to the user's choice, which should be 40nm for most purposes, surely? So how would that help you? These programs that change it. How often do they do this? Couldn't you simply change it before reading the tables? Of course you'd need to wait a while to allow them to populate. And don't forget the capacity is limited to the nearest 96 (airborne). You won't get ALL aircraft even with "unlimited" range if there are more than that. Regards Pete

I've also made sure that there are no joystick assignments in FS for flaps. I should mention that I'm using the PMDG 747-400 in FS9 and haven't tried any other aircraft with this new configuration. ALWAYS test on a default aircraft first. It may be a problem or a difference with the add-on. If it works with default aircraft it must be the add-on. You could of course also see if the normal FS flap inc/dec keypresses work -- i.e. F7 and F6. Regards Pete

Unless you can read it from the AIRCRAFT.CFG file or extract it from the AIR file (which is identified in FSUIPC offsets), I don't think so. You might want to ask in an aircraft designers forum, if there is one. I think the value is a relative one because that suits AofA indicators. Regards Pete

Yes, the explanation is that GLOB weather is only sent to weather stations which have not already got localised weather. GLOB weather is just the default weather for stations which don't have their own. When you clear all the weather, no WX stations have any weather, so when you set GLOB this populates all of them. The only way to set weather without clearing it first is to set all of the local WX stations as well as setting GLOB. this is what WX programs do (ActiveSky, FSMeteo, and some others). Worse, with your method, within about 15-30 minutes, all of the local stations will become localised, so further GLOB weather updates again won't affect them. This occurs even with dynamics at 0, because the weather is always changing slightly, as it is in reality. After lots of complaints about this and requests for local controllable weather for Instruction purposes, Microsoft fixed it. In FSX you can set a GLOBal weather mode (via FSUIPC4 or SimConnect) and if this is used before any updates the GLOB weather overrules the localised weather. Regards Pete

That's the FSUIP4 Log. Please show me the Install log -- that'll be there too and contains more about your FSX installation. Meanwhile, the FSUIPC4 log shows that you have a problem with the SimConnect part of your installation. You haven't moved anything called "Simconnect" around have you? There must not be a SimConnect.DLL in the FSX or Modules folder at all. The only place they should be are in Windows own "WinSxS" folders. Is there any reason you haven't updated FSX to SP2? For SimConnect applications like FSUIPC4 it is much better, as well as fixing quite a lot of FSX bugs, and installing it may fix your SimConnect problem. This problem: has occurred before and it has been reported to Microsoft, but never resolved. One possible cause is having a rogue copy of Simconnect.dLL loading from someplace other than the Windows SxS system, but this hasn't always explained it. As you can see, FSUIPC4 does try to take corrective action, but that doesn't work, so in the end the error prevents anything of FSUIPC4 working, including being able to add the Menu entry. I think, as a first step, you should try updating to FSX SP2. Regards Pete

Installing the same version more than once is a waste of time. Why did you do it countless times? And registering is irrelevant. What makes you think you can fix a problem by repeating things or not registering? If you have something wrong, you have something wrong and that needs fixing first. What is very relevant is the Install log. When you ran the installer, didn't you notice it displayed full details of what it was doing? Those details are certainly relevant. Luckily they are saved for you. If FSUIPC4 is installed at all there will be a Modules folder in your FSX installation, and inside there will be at least one Log file -- the Install log. Show me that. If there is also a n FSUIPC4.LOG file, show me that too. If there is no Modules folder, then you'll need to run the FSUIPC4 installer again, and before finishing when you get the registration option, save the Install log using its menu facility. Then show me it. Pete

Ok. Confirmed. Actually the slew controls work fine through FSUIPC too (i.e. vertical slewing via offset 05E8). Looks like a peculiarity or bug of SimConnect / FSX. I suspect it's related to the "on ground" status -- that doesn't change either, so maybe it is overriding the attempt to set the altitude directly. You may want to report it to Microsoft via tell_fs@microsoft.com in case they don't know about it and feel like fixing it in FSXI or ESP2. I could look at trying to work-around it automatically in FSUIPC by using 05E8 to get it off the ground before immediately than re-writing the altitude. Not sure if this will work as a tight sequence though. Is there any real problem if it isn't fixed? [LATER] The work-around I suggested does work. Here, you can easily test it for yourself using this Lua program: ipc.writeSW(0x05E8, 0) ipc.writeSW(0x05E8, 16384) ipc.writeDD(0x0570, ipcPARAM * 65536 *65536 / 3.28084) Save this in the Modules folder as, say, "set slew alt.lua". Go into Key or Buttons tab in FSUIPC options, Reload buttons or keys (to get the new plugin recognised), and assign a Key or Button to the new "Lua set slew alt" control, with the altitude in feet as the parameter (e.g. 3000). Then, with the plane on the ground in slew mode, try your new control. Incidentally, you do need the latest version of FSUIPC4, from the FSX Downloads announcement above, for Lua plugins to work -- they were supported only since version 4.311, and have just been added to FSUIPC3. Regards Pete

No, that on its own doesn't fix the problems in ATC.DLL. The object of that is to remove most of the inbuilt ATC stuff so you can use Radar Contact okay. i assume it should be okay with PFE too. But I think to avoid some of the crashes in ATC.DLL you have to leave some of the ATC options enabled in FS -- the RemoveATC was to simply allow you to do that without seeing the effects. Does the FSUIPC Log say FSUIPC has patched ATC.DLL? And have you updated to FS9.1? There are at least 4 serious bugs in ATC.DLL, places in the code where a crash is inevitable if they ever get executed. I really have no idea how MS let them through, but mostly they only happen in two cases: 1) when you try to suppress any of FS's ATC facilities (which is why "RemoveATC" is added), and 2) when a COM frequency in your neighbourhood is the same as one at the limit of FS's checking, maybe 80 nm away, and you tune that frequency. I think one or the other has to be an ATIS. With Radar Contact some folks changed some of the frequencies in RC's frequency file to get around that. There were some ATC.DLL crashes which we never got to the bottom of. Microsoft acknowledged these bugs, but by then they were deep into FSX and were simply not going to do anything else with FS9. Regards Pete

Ah, thank you very much for clarifying. You really should never have to run FSX "as administrator". If you do run it "as administrator" but then run an FSUIPC client program like VAFS without such privileges, you will certainly get the error you mentioned. Vista does not allow programs of different level of privilege to share memory (which is how FSUIPC interfacing works). It sounds like you were running VAFS "as administrator" and not FSX, but you shouldn't need to run either that way. Regards Pete