Pete Dowson

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

If you have just downloaded the FSUIPC 3.536 Zip, please do so again. I just found out the module I Zipped was corrupted and have uploaded it again. The cirrect one bears a timestamp of about 01:16 (AM). Regards, Pete

Could you check whether you still get that initial spurious value in 030C using the Beta release of FSUIPC (version 3.536, see Announcements). I added the check on "ready to fly", but I was unable to get the bad value in the first place so I couldn't test it. Regards, Pete

This is normal. Why do you think it is a problem? It all works doesn't it? The way aircraft specific settings work is NOT the same between the two sections. With the Joystick Calibrations, the specific section is used INSTEAD of any generic section you may also have. It is one or the other. Hence the checkbox shows that. In the case of Buttons it is much more complex. Only those buttons you have re-programmed to be aircraft-specific are aircraft-specific, but any others, defined for general use, will still have their programming action operational. Hance the Button programming is much more flexible (and as a result more complex, sorry). The Key Press programming is the same. I did think about making the Joystick Calibration similar, but couldn't think of an easy way to disable calibrations and assignments which you didn't want interfering, so I made the system do a straight swap in this case. Besides which, it is a much more likely need to have a 'core' of button assignments which are applicable to all aircraft. I did think this was documented somewhere, but maybe I didn't make it clear enough. Well, I haven't seen any that have numbered buttons at all. The Windows API numbers the buttons from zero, so it is entirely logical for me to do so too. It is a standard practice going back many years now. No, not at all. It would certainly cause confusion all round. Pretty much all the sophisticated gear used to build cockpits uses numbering starting from zero, and in any case suddenly renumbering everything in an update will mean everyone suddenly having unexpected problems needing re-programming in FSUIPC options! See the Announcements above. And be careful -- joysticks are numbered from 0, andfaxes are "numbered" with lettrers, X Y Z R U V, following the Windows API and general harware practice for the last 10 years or more. I doubt if any of your joysticks are numbered thus. ;-) Regards, Pete

Is there an FSUIPC.LOG or FSUIPC.INI file also in the FS Modules folder? If so, can you show me the Log file contents please? I've never heard of a case yet where, with FSUIPC installed, you don't get a Modules menu, containing the FSUIPC entry at least. Regards, Pete

None at all for the current versions I'm afraid. I'm guessing that it's buried deep in the graphics someplace. However, if it is correctly following the rules of place and date/time, surely all you need to do is follow the same ephemeris rules and calculate it? Or have look-up tables. It's probably too late by now for FSX too, but be sure to make a suggestion to Microsoft by writing to tell_fs@microsoft.com. Just ask for programmatic access to Sun (and Moon, and Stars?) positions, giving your reasons. Regards, Pete

A crash is something which stops Flight Sim from continuing to run. Simple really. That's what this thread was about, if you check back. folks using WidevieW are/were having the WidevieW clients crashing to desktop (CTDs). When you appended your message saying you had the same, I obviously assumed you meant you had the same. Sorry. It sounds like WidevieW is not setting the local weather for all the surrounding weather stations, so as the weather changes, as the wind blows, or as you fly, you run into areas of default weather -- which is clear sky, 1013 mb pressure, etc. Maybe Luciano has not appreciated the complete revision of the weather system which took place between FS2002 and FS2004 and is still using techniques which only worked back in FS2002 and FS2000 days. At least, that is what it sounds like. It doesn't sound strange to me at all. Have a read of the very last section of the FSUIPC user documentation. That explains problems with global weather setting only. With local weather setting, you have to actually set each of the nearby weather stations, as you fly. Those not so set will initially retain default weather onlybut even that isn't static: Once weather at a local station has become localised, setting new default weather, e.g. to keep up with changes in the weather on the Server PC, will have no effect except on distant stations whose weather has not been progressed yet, as they are out of range. Regards, Pete

There have been no changes in the weather facilities in FSUIPC for many versions now. You need to look elsewhere. Using the facilities for localised weather control added to FSUIPC for FS2004 it is extremely easy to crash FS in Weather.DLL. This is because I deliberately do not check the values being set—it is a direct route through to the weather setting parts of FS and is deliberately free for weather making programs to explore and expand upon what was known about the weather prior to FS2004. If these crashes are only occurring with WidevieW (which I don't use), you really need to help Luciano resolve it with clear reproducible examples. I really have no idea even what facilities in FSUIPC WidevieW is using, and Luciano has never contacted me about any problems. I'd be glad to advise him if he needs such advice, but there's no information and no evidence here whatsoever. Regards, Pete

It really depends on what sort of aircraft you intend to use it with. A fast response jet fighter would need a more responsive throttle than a modern heavy airliner, whose engines take a while to spool anyway and which really only take your throttle input as a guide and process it through assorted electronic and mechanical and even computerised control-check-change-apply processes. I am just finalising an interim update to FSUIPC which provides direct axis assignment and hence does its own joystick polling. I find scanning the joystick inputs at anything from 10 to 40 times per second appears more or less the same -- in other words, I can't see any difference in FS. A default based on the standard Windows "timer tick" (55 mSecs, or 18.2 cps) is certainly adequate for pretty much all purposes --- but why not make yours adjustable by parameter so that you can experiment yourself? To save a lot of time and unnecessary process switches, always compare the new value you are about to post with the last one posted. If they are the same (withing a specific "delta" value, either way), discard it, don't send it. Sending values for a difference of 1 in a range of 16384 is a waste of time. For 16384 try a delta of something like 256 as default -- again make it adjustable, and set it to the highest value which doesn't result in a loss of resolution on your engine settings. If you need ALL of the information in the larger block, then that is more efficient, because FSUIPC only has to process the one request in the data instead of looping arond doing lots of small ones. But the differences are probably not really measurable. If there are "gaps" in the large block -- information you don't need, but which may be changing -- then it would make it less efficient over WideFS because WideServer would be keeping a check on changes to values you don't care about, and generating Network traffic needlessly when they do change. But it doesn't make a lot of difference at all really, either way. When I designed stuff like the AI traffic "TCAS" tables, I provided lots of values and markers for folks to streamline their access and only read the parts that had changed, but after doing that I too found it didn't really make much difference to performance. My "TrafficLook" program just reads the whole blocks every second -- try it on the same PC as FS and also on WideFS. Of course, once a second isn't a big load in any case -- so that's another consideration. You might get better results, both in FS and in your program, if you do a lot less often than a little very often. But maybe that is less "smooth". There'll be an optimum somewhere between, but I'm not sure it is worth spending too much time looking for it, and measuring the differences may prove futile unless your PC is really overloaded in the first place. I don't really understand that question. There's no "memory" in FSUIPC as to what program wants what. Maybe you are thinking about WideFS? In that case your "Process" calls only talk to WideClient. WideClient only places requests for data not previously requested through to WideServer. WideServer remembers which Clients want which data, but only sends it after that when it changes, and it keeps sending it when it changes whether you ask for it again or not. Hope this helps! ;-) Regards, Pete