Pete Dowson

There's a correction from Lee Swordy, the author. Here is a quote from him: "For those of you who downloaded AFCAD2, you may find it is not self-registering with FSUIPC. This is because the program was misnamed. It should have been named AFCAD.exe but was instead named AFCAD2.exe. I have corrected the name and uploaded AFCAD204.zip again, but for those who have already downloaded, if you have the AFCAD2.exe version then rename it to AFCAD.exe. Otherwise, the uploads are identical. Sorry for the inconvenience, Lee Swordy" Okay? Regards, Pete

I checked this, and it is not exactly as you say. If you don't program any of the yoke buttons in FSUIPC, they are all programmable in PFC. If you program any one of the buttons in FSUIPC, then you have to program them all in FSUIPC. I'll fix it this week. It is similar to the other problems (with the lights and a set of 4 jetliner console switches) which I'd fixed in 1.71 -- see the History. I hadn't realised it also applied to the yoke. It must have been like that since 1.62 -- was your previous version 1.61 or earlier, then? Regards, Pete

When you say "run the FSUIPC.DLL", how are you "running" it? It runs only when you load FS, it cannot run on its own. The error "Not correct FSUIPC installation" is not one from FSUIPC, so it must be from something else. What are you running which tries to use FSUIPC? That is part of FS's own "User Interface". It is nothing whatsoever to do with FSUIPC. I am not surprised. Many things cannot work whjen you remove parts of FS like that! Please leave it alone. What version of FSUIPC have you installed? The current version is 3.11. Please show me the FSUIPC.LOG file, which you will find in the Modules folder too. Same for TrafficLook and WeatherSet -- check their versions numbers by right-clicking on the files, selecting Properties and Version. It sounds like you are using old (pre-FSUIPC 3) versions of those utilities rather than the ones which are supplied with FSUIPC version 3, in the ZIP. Regards, Pete

Sorry, none at all at present. :( Can you try changing some of the recently introduced options, as a process of elimination? For example, in the [Connection] section of the PFC.INI file try: SyncInit=No AutoRestartTime=0 You could also enter the PFC "Test" page and see if you get the crash when operating the axes then. This could separate the area of code. Additionally, on that test page enable the Also, as you are running Win98 the DrWatson dump would likely tell me everything I need to know, so could you check the section "If FS crashes ..." in the FSUIPC User Guide and get me a DrWatson -- ZIP it and send it to me at petedowson@btconnect.com. Please also include your FSUIPC.INI file and your PFC.INI file. Thanks, Pete

But which Idle is the FS idle? They cannot both be zero if there's no additional control being used! So how does FS differentiate between the two idles? I keep asking the same question in different ways but not yet getting a usable answer I'm afraid. :cry: It sounds as if your "flight idle" is in fact just a specific throttle setting ABOVE zero, else you wouldn't be able to use it to taxi? Isn't this measurable on some dial similar to N1 or N2 or EPR or RPM or something? Regards, Pete

Not simulating the pilot closing down at the end of his trip, then? just some cheat? Why not do as I've always done -- create a Flight with everything switched off and load that when I want to start off with everything switched off? After all, for many complex add-on panels this may be the only way, as they have many private subsystems which are not part of FS itself and therefore not accessible to FSUIPC. Regards, Pete

Does it say "you can attach files"in small print at bottom right of the Forum? If so, when you compose a message, at the bottpm there should be a button you can press to attach files. However, there is a low limit on size. If one of your files is a JPG it may be too big. In case of problem you can email it to me at petedowson@btconnect.com. Regards, Pete

Another thing which may be worth trying, if you are using an nVidia-based video card -- the latest drivers (52.16) are said to fix some (not all) black screen problems, and are faster too, so worth a try for sure. Regards, Pete

You would really do this by switching everything off, switch by switch. Simulating all that with one switch or button seems a bit odd. Why would that be needed? Pete

It will do. I was not suggesting that it would report zero frames or anything. but normally I'd expect it to be changing all the time when the simulation is running, and frozen when it isn't. So you need to check for changes. I'll look at other things tomorrow, not had time this weekend. Regards, Pete

There doesn't appear to be an attached Zip file for me to look at, but black screen type crashes are a known hazard with FS204 (and other programs using DirectX9, it seems). I cannot hold out much hope, but I'd like to see the Log please. The access violation it is trapping certainly sounds very odd. Regards, Pete

The reasons will be best found by checking the WideServer and WideClient.Log files. These will be found in the same folder as WideServer and WideClient, respectively. This tells me nothing useful, I'm afraid. It is best to ask PM questions at the PM support place. But show me the Log files which I can understand and we'll take it from there. By the way, please always use the latest versions -- FSUIPC is 3.11 and WideFS is 6.101. Regards, Pete

Ah, but I don't! :wink: What is the difference in terms of throttle value between "flight" and "ground" idles? They cannot both be zero, else how is the difference seen? Are you sure the difference is not a button press or switch instead of a throttle value? Regards, Pete

These are simply "centre" positions, just like those necessarily provided for Aileron, Elevator, Rudder, et cetera. Centre values are always 0 so there's no ambiguity, no problem. But how can I have two different types of zero? And there are no "stops" or "detentes" in FSUIPC at present, that is the problem. There are only Maximum/Centre/Minimum. I can apply those to any axis, that is not a problem. The maximum, centre, minimum values are self-evident and determinable. What is the value of a "flight idle" compared to a "ground idle"? They cannot both be zero I assume? So which one is zero, and then what is the other? Without knowing these things I can do nothing. And at present I do not want to start extending the current FSUIPC facilities by adding a new feature for "stops" or "detentes" when the time would be more beneficially be spent doing things more generally and in a less error-prone way. The stuff in FSUIPC has really been stretched further than was originally intended in any case and I fear to stretch it further may break it in too many places and cost much more time to then fix, for much less return. Regards, Pete

Do you know precisely how I can do this? I can understand full forward = 16384. Full reverse = -16384 * percentage reverse available (defined in AIR file or CFG), and idle = 0, but where do these other values get defined? How would I know what values to set for "flight Idle" relative to "Ground Idle"?, or "Min Prop" relative to "Startup/feather"? Aren't these very specific to the individual implementation by the aircraft maker? How do I find out? In any case it is too big a job to change the current axis facilities in FSUIPC. I do have on my list a big project to undertake which will certainly include such facilities, assuming I can understand them. It will probably be a separate optional module which works with FSUIPC and replace the Joystick pages therein. It will assign the axes too -- bypassing FS's facilities altogether, and so allowing full calibration and detailed "stops" (detentes), response curves, and maybe even button-mapping from specific axis positions. I will try to make this compatible with the current facilities, and therefore may still use the FSUIPC.INI file values where applicable, but add many new parameters. Unfortunately, trying to make time to fit this in is proving more difficult than I had hoped, so I don't see it being done this side of Christmas. I shall try to make space by denying some of the many other requests for a while. Regards, Pete

No, sorry. I really hoped that developers would be kind enough to purchase a full FSUIPC key. After all I do not make any charges for all the work I do on the SDK nor for the support I offer (though the FSUIPC user documentation does actually imply that support is for registered users only). If you have a personal FSUIPC key then you do not need keys for anything else. To simply test your own application's access key you can temporarily remove the FSUIPC.KEY file. Regards, Pete

I don't know them. Are they merely the EFIS displays? See FSUIPC offsets 0E5A to 0E68. All that stuff used to work with FS2000 but it's never been verified with FS2002 or FS2004. Let me know please. Regards, Pete

The complete source is provided for FSUIPC_Open2, so you should be able to see what is happening. You will see that the error "FSUIPC_ERR_NOFS" is only reported when the call to: FindWindowEx(NULL, NULL, "UIPCMAIN", NULL) fails. Since FSUIPC always creates a window with this class name, it should not fail unless your module is initialised before FSUIPC -- in which case another attempt later should work. Check your FSUIPC.LOG. There should be a line like this: ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E This shows the Window Class names created or supported by FSUIPC. The first one listed should always be "UIPCMAIN", as this is used by both the internal and external library. Regards, Pete

I'm not realy understanding all of this. Are you using the FSUIPC facility to load a flight? (i.e. offsets 3F00 ff). If so, I assume you then wait for the count in 3F02 to change. Is that right? There's also an AIR file change counter at 32FC which will also change. The problem may derive from the fact that FSUIPC detects these events by intercepting calls to read the files (AIRCRAFT.CFG and *.FLT), I don't know any other ways. After the files are read I expect there is an unknown number of seconds whilst scenery, cockpit and weather data is read and set up. I don't know when that part has finished I'm afraid. One thing you could check is the frame rate (0274). I suspect the frame rate might "freeze" for a period whilst this occurs. Maybe detecting when it starts changing again will help? In fact I shall make some checks on the Chained calls I get from FS. Possibly the frame-rate determined ones will tell me. If I can detect it directly I will certainly provide a flag or something. Let me know if you find something before me, please. Regards, Pete

No it is not right. You do not have to delete anything. Best, in fact, to keep back-up copies of all INI files so you never lose your settings! FSUIPC makes any minor changes itself if they are needed (deleting old parameters now not applicable and adding new ones), and WideFS settings haven't needed changes for ages. Also, if you've registered FSUIPC or WideFS or any applications manually, then save a copy of your FSUIPC.KEY file too. All you need to do for any new version is copy in the DLL. It will overwrite the previous one. That's it, done and dusted! If you get inot any problems and suspect any settings, by all means remove the INI file and try again, in case a parameter is responsible (unlikely), but keep a copy. Regards, Pete

By the way, the registration access system is not a problem with older versions of FSUIPC (pre version 3) -- they'll just ignore it (well, they will write to offset 8001 and you can probably read it back too! But the area isn't used for anything else). So you don't need two versions or need to remove code to test. Regards, Pete

No, the details in your Version Information are wrong. These are the details you sent to me: > Program name: BOTA.EXE > Company: The Battle of the Airlines Trophy > Produkt name: BOTA You missed a "The " in the Company name! Computers are stupid. They do exactly what you tell them, not what you really want them to do! :) Regards, Pete

Seems that Visual Basic keeps too many odd things it does secret or just undocumented, since many VB programmers seem to have this problem. What the VB compiler seems to do is take your &H8001 and expands it into &HFFFF8001 -- i.e. it sign extends it. This is not a valid offset for FSUIPC, though the top 16 bits are used for control flags for special purposes, mostly to do with the Advanced Weather Interface. So FSUIPC masks the flags it currently understands and this gives it the F8001, which is of course illegal too. I've been told the the (stupid?) VB compiler even does the same if you explicitly give it as: &H00008001 which I think is really really bad! :? I've been informed that you can stop the sign extension by post-pending another &, i.e. &H8001& Alternatively decimal works too, for some reason (&H8001 = 32769). I just wish there was some logical consistency in VB and at least that such weird interpretations were well documented in the VB programming books. :( Regards, Pete

The only way this message can arise is when WideClient does not see the ServerName parameter. In all other server name errors it will actually try to access the Network. Here it is not even doing that. Though you show an INI file with the server name included, I think the only explanation is that either the WideClient.ini file is not in the same folder as the WideClient.exe you are running, or somehow you have got the INI file mis-named. It must be "wideclient.ini" and it must be in the same folder as the "wideclient.exe" which you are running. Regards, Pete

The Taxi Wind facility, as it's called, is still in current versions of FSUIPC. It applies to FS2000 and FS2002. I've not found any way to apply it to FS2004, that's all. There's quite a lot of stuff about it within the forum here -- look for Taxi Winds. I did follow through some hopeful avenues in FS2004 but they didn't work, and I've not found any others. I think the problem is nowhere near as bad in FS2004 as in FS2002 or earlier, and in fact seems pretty realistic. I suspect taildraggers are really pretty difficult to handle in a crosswind in any case. I'm sorry, but all I can suggest to clearing the weather or selecting weather with manageable winds until you can learn to control the yaw. Certainly I would have though rudder pedals to be an absolute must in such conditions. Regards, Pete