Pete Dowson

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

VAFS support needs to help you. I am not so sure that your problem is the same as the previous one reported in this thread, which I think may well be down to an illegal registration of FSUIPC (the submitter never came back, after all). You have not registered FSUIPC, and the log shows everything is fine as far as FSUIPC is concerned. The VAFS folks will need to debug their program from their end. One point. It looks like your FS2004 installation takes a full 3 minutes to load upor was that merely you leaving it that long on the initial menu? Then another minute to load your selected flight. And then, when FS was ready to fly, you only left it for 6 seconds before closing it. surely you didn't manage to load VAFS and see it fail in that short interval? Or else, it may be that you are starting this "VAFS" too early, before FSUIPC is ready. You should probably wait until you are fully ready to fly. Regards Pete

Hmmm. i'll have to check that. My algorithm should still be able to match it. [LATER] Found it! It's a very very (very) long-standing bug. All versions of FSUIPC4, in fact. I'll fix it in FSUIPC4 in the next increment uploads. Good catchthanks! (Just shows, not many folks share by drive instead of path). It doesn't apply to FSUIPC3 -- in that it simply uses the first PATH it can find which fits. So if the Drive is listed first, it uses that and doesn't search for a folder match at all. But I improved it for FSUIPC4 by making it search them all and choosing the one which made the UNC path the shortest (and hopefully thereby the neatest). Unfortunately, in the process, I messed up the drive-only matching case. Regards Pete

The only time i've seen that is when the path isn't shared at all. FSUIPC looks up the shared paths lists in the registry and runs a comparison against the path it needs to find the longest match, then uses that. So, for instance, if you shared the FSX path itself with the share name "FSX", then the UNC path would be \\\FSX. The registry entries containing the share paths are found in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares For each shared path or drive, the shared name will be a parameter key, and the data will contain a part called "Path=..." which is the one I will be attempting to match. Check this with Regedit. If you think it looks right, and FSUIPC4 is getting it wrong, I would need to see the whole section. Either export it and ZIP the exported file, or take a screenshot (provided all the shares and all the Path= parts are showing). The exported file might be best. If its too big to past as text here, ZIP and send to me at petedowson@btconnect.com. Alternatively, try sharing the folder as, say, FSX. You'll find using short specific share names far more convenient. Same for the My Documents FSX files folder. I always share-name that "FSPLANS" in any case, as Project Magenta needs it so. Regards Pete

There are examples, and the T8 and P8 LEDs are the easiest -- just one line for each LED stating what lights them. You'd need the FSUIPC Offsets list (in the FSUIPC SDK) to find the values the LEDs are supposed to be indicating. Regards Pete

Sorry, can you expand more on how you are doing this? Is it by program, over the IPC interface, using some offsets? Do you have a log of this? Have you tested using FSInterrogate? Regards Pete

Hmmm. you might be able to do it by assigning keys to virtual buttons, then processing those with conditionals, but I think it would turn out less than satisfactory -- everything will be going through too many steps and Windows messaging, slowing it down. You need to be able to turn in fast enough to adjust frequencies in a reasonable time, and I think with keypresses you'll probably have to hesitate between each click. not nice. I assume that type of rotary must be cheaper, or easier to obtain? Those I have are definitely easier to program. Regards Pete