Pete Dowson

Ground steering by rudder is mainly dependent on speed. What aircraft are you talking about? What sort of taxiing speeds are you using, and what winds? In my 737NG cockpit I use a steering tiller to emulate nose-wheel steering rather than rudder effects. Of course it still uses the rudder (that's the only steering input available in FS), but the effect has to be exaggerated enormously over the rudder effect, which on a larger aircraft is negligible at taxi speeds (5-25 knots, always less than 15 when turning, and much less for tight turns). This is, of course, the exact opposite of "reducing sensitivity"! Well, in my opinion, if you want realistic steering you certainly don't want LESS sensitivity, but much more. I don't know what you mean by "difficult to control accurately", but if it is a light aircraft with wind or more than a few knots, it IS actually quite difficult in real life. You have to very careful with the throttle, and differential (proportional) braking helps too. In an airliner you try to avoid using brakes because you don't want them overheating just in case you need them fully efficient for an RTO. However, the wind has far less effect, so your control then is the throttle, keeping the speed low and anticipating the needs for turning. For a really tight turn a dab on the appropriate brake does help, of course, and even use of asymmetric thrust too, but at correct speeds neither should be necessary. If you do decrease sensitivity in FS, what you are really doing is reducing the range the axis provides and also reducing the number of different positions on the rudder which do anything different. This is almost the same as using a much cheaper set of rudders, and in the end doesn't give you as much relaxed central control as simply choosing a flattened slope in FSUIPC. But why ask me, when you can try it? Nothing you change in these thnigs need be permanent so you can excperiment to your heart's content! Regards, Pete

Software. Do not confuse switches you connect to the EPIC with what the EPIC can signal to the PC via the EPL programming and the HID definitions you can make. Even way back in the days of MSDOS and ISA Epic cards I was using EPL to program many "software" buttons. It is one of the major advantages and flexibilities of the EPIC -- the interface the USB version presents to Windows is all software definable in your EPL. I don't know if Ralph ever extended the USB version to 16 joystick devices -- the EPL and firmware I have only does up to 8. The old ISA card did 16, but that was via my own driver. On each device you can have 6 axes, 1 (or maybe 2 now, on directinput) POVs, and 32 buttons. Even if you can only define 8 joysticks, that still gives you 256 buttons to play with. Same with axes. The ISA EPIC only allowed 16 hardware axis attachments, but you could have 16 x 6 total axes recognised in Windows -- the other 80 were "soft axes", programmable in software to send any values you liked. This is again usable in FS2004 now that I've added axis assignment with "Raw" mode capabilities to FSUIPC. I think Ralph now calls the "soft axes" something else. Maybe he calls the software buttons something else too. Sorry, I certainly cannot help with modern USB EPIC programming in any way. Last time I messed with that was years ago. but there are EPL users forums and groups around. And Ralph is helpful when you ask him these things. Regards, Pete

1. Why "spot plane" view? Surely you have a cockpit window through which you see the outside world without having to actually get out of the aircraft? 2. There seems to be even more confusion. If the menu bar disappeared whien you clicked "Hide Menu", then it wasn't actually checked already. The workaround I found states: Do you see the word "uncheck"? If it was already unchecked, that means the menu was not already hidden. In that case the FSUIPC options should have worked okay. The problem only arises (at least on mine and most others systems) when the menu bar is hidden. If you are finding that it doesn't work with or without the FS menu showing then I am sorry, but I really have no answer. FSMeteo makes its own weather settings. Unless you've paid for and registered FSUIPC (which seems unlikely if you can't get into the options), then there won't be any "weather settings" to set to minimum. None of the FSUIPC user options are available to you. Well, it isn't my trouble so much as yours, sorry, but you do seem to be revealing one little thing at a time. Now it's FSMeteo. Before it was RC. Which of these are you having trouble running? Have you actually TRIED them? Please do so, I'm sure they'll be okay -- though many of the new features in RCV4 do depend on using FS2004, I must say (because of the AI traffic interaction). Surely you have no need to visit FSUIPC options at all, yet. If you have, please tell me what it is you want to do there and maybe we can find another way. As far as the crash is concerned, I am very sorry but I'm afraid it is far too late for me to find the time and resources to fix problems which affect FS2000 alone. The work-around does work here and on other folks systems. I don't know why it doesn't on yours. The problem is deep down in DirectX and I suspect it is related to changes in DirectX in the last seven years. Regards, Pete

The outside world, the scenery, the view out of the cockpit window -- that is where you will find the right-click options to show or hide the FS menu. I think Microsoft do document their program someplace, especially in FS2000 days. These days it is almost all in the help windows, though. I do find this stuff difficult to find in those. Regards, Pete

Erthis is the very first time you have ever stated this!!! You mean that all this time you've been able to load FS2000 and run it with FSUIPC 3.53 installed? It is only when you go into the Menu for the FSUIPC options you get the crash? Your previous messages implied that with FSUIPC 3 installed you could not use FS2000!!! :oops: :oops: :oops: :oops: I did point out, in an earlier reply to you, that "there is a problem which I am unable to fix, as documented in the User guide, but certainly none which stops it working". Did this not prompt you to take a look? Please PLEASE check the user documentation. Not far from the front there's a paragraph about this, and it tells you about a work-around, should you need to go into FSUIPC options. Incidentally, you do NOT need to go anywhere near FSUIPC's options in order to run Radar Contact in any case. Regards, Pete

Yes, that is so. But the documentation is free to read either way! :-) Ahthat's an upper limit of 30, not a minimum of 30. Sorry, I misunderstood. Yes, you can set a surface limit of 30 and have that "graduated" to an upper altitude limit of 30 too. But I think you might find it a little wrong when cruising at 35000 feet! If you only fly GA VFR then maybe a surface limit of 10-20 depending on the cloud density, and a graduated going up to, say 40 or 50 at 15000 feet. Try FSUIPC with the recommended defaults first, then play with them. That is exactly what the "graduated visibility" option is designed to avoid. Regards, Pete

"Connection refused" sounds like a deliberate block. Probably the Windows update has automatically enabled Windows firewalling, or maybe it is included in your "Anti Vir 7" (?). You'll either need to disable that, or at least tell it (somehow) to allow programs you trust to talk to each other between your computers. If you use a separate router on the Network for your Internet access the firewall it should provide should suffice -- I disable firewalls between my own PCs. They are nothing but a nuisance else. Regards, Pete

Yes. Actually, Microsoft tried to address that by placing a very thin layer of cloud on top of the visibility layer, but only when that is 10 miles or less. Unfortunately it looks very odd from above and most folks would prefer they hadn't tried! FSUIPC's graduated visibility facility does provide a more realistic graduation of the visibility -- with that, the layer effectively extends all the way up, but increases in range according to parameters you set. By the time you get to an altitude which has, say, not unlimited, but possibly 50 or 60 miles, the ground below is suitably blurry in any case simply by virtue of altitude and, often, clouds. Well, it certainly wouldn't always be realistic in my part of Northern Europe! ;-) A visibility of 30 miles is certainly quite common, once you get above the murk, but it is often much less that that, and sometimes (especially at this time of year) at lot higher. From my own experiences flying a light aircraft you often get a distinct boundary above which the visibilty is good (yes, even looking down) and below which it is murky. I suppose it is the angle through which you are looking when above this layer -- in most aircraft you rarely if ever are able to look straight down (unless you are in trouble or performing aerobatics of course). ;-) It sounds like you want to set a MINIMUM visibility of 30 miles, not a maximum. Yes, FSUIPC does offer a minimum (normally set to zero), but obviously if you use that you will never get mists or fogs. As for the maximum, FSUIPC offers surface maxima related to clouds/rain and graduation to an upper altitude maxima. The only maximum it cannot override is the drawing distances for clouds and scenery which you may have set in Options-Settings-Display. Why search? Don't rush to buy anything. Before you buy, please download the FSUIPC ZIP (http://www.schiratti.com/dowson) and read through the user documentation. That really is the definitive source for the description of what it can do. I don't want you rushing and spending money then regretting it. There is also a new version available for testing, with new facilities as well, but none concerning the weather. Details of these are placed in Announcements at the top of this Forum. Regards, Pete

Yes, worth trying, but if, as I suspect, FS treats the file as a Windows "Private Profile" file, as it does most all the other CFG files it uses, then I don't think it'll work. With the Profile API the program doesn't use normal file access in any case, only Section names and Keys. It would be asking Windows to get keys corresponding to each of the DirectInput-reported axes and buttons within the Section with the title relating closest to the device name reported by DirectInput. I think it would get the same negative response back whether there was a file there or not, it only depends on whether the section+key is there. I have been thinking of ways to try to defeat its default assignments and came up with assorted thoughts about special arrangements in the Devices.CFG file, but I think they are all doomed because of the way the Profile API works. But it is worth experimenting, still, as you say. Regards, Pete

You are not doing anything wrong. That is fine. The outside view will actually be correct, not stretched. The only reason the cockpit is stretched is that it is designed with bitmaps to suit 4x3 screens. But you just resize it. Drag one edge over so the main panel fits on one of your screens. All of FS's windows can be sized to suit you. Except for the outside world they stretch and compress as needed to fit. The outside world maintains the correct proportions no matter what shape the window. You can use the space left where you shrunk the panel back to one screen to place other views, other cockpit parts which you didn't have room for before -- like Radio Stack, GPS, Kneeboard, whatever. When you've got things as you like, save a Flight and mark it as default. Then always start from that flight, make new ones from it if you like, so you retain your window positions. With most (not all) aircraft there's also a "virtual cockpit" mode. Pressing the 'S' key will cycle from 2D cockpit to Virtual (3D) cockpit and two outside views. Try the 3D one. I don't think you need to stretch or compress anything then. Again, when you are happy, save the flight. Regards, Pete

Can you do this again, then close FS down. Zip up the FSUIPC.LOG and FSUIPC.KEY files from the FS Modules folder, along with the Wideclient.LOG file from the same folder as WideClient on the Client PC, and send them to me at petedowson@btconnect.com. It is sounding like an FSUIPC or WideFS key problem, and I can check that with those files. I don't know what you mean by that, but i assume you are talking about replacement cloud textures. For that it will be using normal Explorer style filesharing, not WideFS. No. The problem appears to be that for some reason ASV6 does not like what it is seeing from FSUIPC. You may need Active Sky support to help there. But let me see those files first. Regards Pete

Fair enough, but that does seem a complicated way to do it when EPIC and EPL has methods to send button events, and in FSUIPC you have all the flexibility you need to program any such event to action any FS control. In fact you can program button events to write to FSUIPC offsets too -- see the FSUIPC documentation. You simply send the numeric value for the control LANDING_LIGHT_SET to offset 3110. But it isn't 16-bit, it is 32-bit. So you'll have to send the upper half (first) to 3112 then the lower half to 3110 (the "actionable" offset is always the one stated in the SDK). If it needs a parameter, that too may be 32-bit, so before touching 3112 and 3110 you'll have to send the upper half of the parameter to 3116 then the lower half to 3114. The numeric equivalents of all the FS controls are given in the List of FS2004 Controls included in the FSUIPC Zip file. The list of the numeric equivalents of all of the Added FSUIPC controls is given in the Advanced User's Guide. But I still think it would be far easier and certainly more efficient for you to use the facilities intended for this sort of thing, i.e. the buttons. After all, EPIC has access to 16 x 32 = 512 of them! Surely you've not used them all up? Regards, Pete

None of that is actually anything to do with FSUIPC I'm afraid. Why FS should crash when loading one version of FSUIPC but not another I do not understand (though one is much larger than the other), but it certainly looks as if there is something wrong either with your FS2000 installation (and possibly with that annoying CD protection system, for that it what the module FS2000.ICD is all about), or, maybe a problem with the Windows installation. As for "NT" as opposed to "XP", I believe (but I'm not sure) that NT5.1 is actually WinXP first release. Have you not updated WinXP to SP! or SP2 level? I would recommend you get XP up to the latest revision level in any case. As for FS2000, I attach a replacement FS2000.exe which you can use which removes the CD checking, in case that is the problem. Microsoft of course would not like this normally, but I think in the case of a 7 year old product not currently on sale it won't matter. If this doesn't help then I'm afraid there are only two other steps you can take: reinstall FS2000, and, failing that, reinstall Windows XP. But let's hope it doesn't come to that. Regards, Pete FS2000 nocd.zip

Now you have confused me. I thought you were a programmer, otherwise why did you say "this would be possible if I find an ofset"? Now I gave you an offset you don't know how to program it? Why not just program a button or switch for the controls you need instead. It is much easier than writing a program! If you use EPIC, just use the button programming in FSUIPC for the controls you want. Why? If you cannot program to use the offsets? I don't understand. Regards, Pete

Version 3.53 works with FS2000 here. What exact error message are you seeing? Well, it is getting increasingly difficult to support such old versions -- after all, it is now, what, nearly 7 years old? There is a problem which I am unable to fix, as documented in the User guide, but certainly none which stops it working -- UNLESS, that is, you have an un-updated FS2000? wasn't there an update to FS2000? I think you need that. What "shows Windows NT"? What is the actual message? I have FS2000 installed here on WinXP and FSUIPC runs okay. Regards, Pete

Are you SURE that the copy of FS9 you are actually running is the one which corresponds to that modules folder? I know it sounds like a stupid question, but, believe me, it has happened before. Folks have clicked on a shortcut to FS and later found that it was running one from a different folder, not the place they were thinking of at all! To be sure, run FS9 by going to the parent folder of the Modules folder you have been talking about, and doubleclicking on the FS9.EXE file there. If that gives the same result, please show me a listing of the Modules folder directory. You can get one of those either by taking a snapshot (ALT Prt SCR) and including the picture, or probably easier by unzipping the BAT file from the attached ZIP into the modules folder in question, then executing it by a double click. It will make a little file "dir.txt". Just include it in a message here. This shows all the DLLs in that folder. Regards, Pete ListDir.zip

But it won't, as I've not changed anything yet. As I said I need some idea of what sort of changes you see without touching the levers. i.e. how much jitter you are getting. I must say it does sound extraordinarily excessive. Why should it be? FSUIPC is only asking the Windows joystick interface to supply the fiures it is being given by the joystick driver. FSUIPC cannot do anything to make your joystick or its driver more "sensitive". Well, it's pretty crowded in any case, and what would you add in any case. I've no idea why your joystick input is playing up so. i would ned to understand that before changing or adding anything. Well the commenting and line number retaining methods provided in the buttons section (surely not Keys? Dis i do it there too?) was because of the amount of extra programming you can do via INI editing -- multiple entries, conditionals, and so on. There's none of that for the axis assignments. I see no need to ever edit the entries and therefore no need for comments. Why would you want them? It's quite a lot of extra code for no real good reason as far as I can see. Regards, Pete

Those controls (there are others for moving the light beam all over the place) are actually intended for use with helicopters on search and rescue operations and the like. They are really steerable spotlight controls. No. I have only translated some controls into offsets -- to be precise, those which were operable via offsets in previous releases, especially FS98. This was for compatibility. You should understand that with many of the offsets, in FS2004 (or even earlier), FSUIPC has to react to your writing a value and send the appropriate control to FS on your behalf. That is all that is happening internally. FS has become increasingly procedural like this, with tightly protected black-box style C++ classes and private data. This is very very different from when I started, in FS98/FS2000 days, when most of its operations were dealt with by real offsets and real values in the GLOBALS.DLL! You can still use any FS control you want, via an offset. Just write it to offset 3110, that is why that facility is provided. Regards Pete

When was this created? Was this created just, when you tried to run FS again, or is this just an old one from your recycle bin? Please delete the Log and INI file from the FS Modules folder, then run FS, see the fact that the Modules menu entry is missing, close FS, THEN look in the FS modules folder to see if there's now a newly created Log and INI file. If there isn't then the file named FSUIPC.DLL which you say you have in the FS Modules folder is not FSUIPC. Best thing to do is delete it and download a new copy. Or even try the 3.536 version available above. Regards, Pete

Oh dear. You shouldn't restore them. They aren't installable. They are two files which are always automatically produced when FSUIPC runs. If FSUIPC is loaded by FS, those two files will be created. If it isn't being loaded then those two won't be created. It was a way of trying to determine if FS was loading FSUIPC! Regards, Pete

You seem to have posted the same questions twice in different threads. I've answered in the other one. Pete

You can undock windows, or open more windows, and move them onto a second, third or more monitors. That's not a problem. the problems only arise in two cases: 1. If you want more than one outside ("3D") view, the frame rate of FS really suffers. 2. If you run in full screen mode (ALT + ENTER) -- the mode with no title bar -- then depending on the video drivers it can be difficult to move undocked parts of panels and other windows onto other monitors. It can be done, but it is usually easier to do it in Windowed mode, then change to "full screen" mode. One other problem with FS with multiple undocked windows is that even if you then save the flight, it doesn't seem to always remember all their positions, so it doesn't always reload the same way. The best way to run FS with multiple monitors on one PC is where you treat the monitors as one big screen. nVidia drivers allow this mode. You can then either stretch the FS window over both the monitors, or possibly just maximise it. Full screen mode may also then occupt both monitors, but I think that depends on the drivers -- certainly full screen mode works on Matrox Parhelia cards oer three monitors. Does it say that? Where? When you say ASV6 "saves the weather to the FS9 system", that does actually mean it is connected. ASV6 dynamically sets the FS9 weather using WideFS, it doesn't "save it" to FS. I don't know what you mean exactly by "dual view", but, yes, as I said above, FS9 windows can be undocked and moved where you like. I still think you are better off setting your video drivers to give you a single wide screen mode, utilising both monitors as one large window. Things get much easier then and FS runs better. You seem to be saying on the one hand that it does connect, as it sends the weather to FS, and on the other that it doesn't. Can you be a little clearer, please, about how you come to the conclusions you are stating? Tell us the symptoms, not your conclusions please. There is an ASV support forum as well, by the way. You may want to ask for specific ASV support there, being the correct place for it. Regards Pete

This would indicate that the axes you had to "ignore" are providing some noticeable jitter. I only take note of changes which are quite large -- unless you are using RAW mode (you aren't are you? There's no need except for precise numerical setting, as I say in the doc). Perhaps you could view the input numbers for one such previously "ignored" axis, without touching the lever responsible, and let me know what sort of changes you are seeing it perform all on its own? The problem really is that if I set the minimum difference I recogise too high, it can be difficult to get an axis noticed at all. This is especially true of those little rotary thumb throttles on some game pad type controls. Well, you'd need to do the last thing there first, and the rest with FS not running! Unfortunately, whilst I did recommend those steps, I did also say, right before the steps listed: and after the steps listed I added: Perhaps this all explains why some of what we are both trying to do here seems futile? Well, I think you just missed, or misunderstood, the preliminary warning before the list of things to do, and the conclusion afterwards that really says exactly what you've reported to me. You don't need to read the manual again as I've quoted the two parts you missed above! ;-) I'm not sure. It may be worth experimenting. However, you can't use erroneous assignments as these will simply be ignored and default ones entered. I don't know if empty sections would work, but it doesn't seem likely. The only safe thing to do at present seems to be to check, now and then (and especially if odd things start to happen) that the joystick is still disabled -- i.e. that the Options-Controls entry is still there for you to re-enable and the other joystick entries are suitably grayed. Regards Pete

The most obvious place in in the INIDIALOG call in the dialogue procedure, surely. That's when the dialogue window handle is first valid and it is called just the once, when the dialogue is created. Well, not as efficient as a genuine FS gauge, of ocurse, which is using all of the ready built-in graphics stuff in FS and is getting called when its variables change no matter what the frame rate. If you are closing the FSUIPC link in the dialog, you should be opening it there too (in the INITDIALOG). If you open the FSUIPC link upon Module_Init, then close it in Module-Deinit. Symmetry is wonderful, isn't it? ;-). Bearing in mind that all the FSUIPC_Open2 and FSUIPC_Close are doing is providing and removing (respectively) a fixed address of an area in which you will pass requests, I would have thought the simplest thing would be to do it on Init and Deinit. Regards, Pete

The VB version had a special "FSUIPC_WriteS" foor that. I don't know VB or C# so I can't really help directly, but Pelle Liljendal is working on a revised C# section at present. You might like to write to him. See the FSInterrogate announcement above for his address. Regards, Pete