Pete Dowson

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

Actually, the "run ready" facility doesn't work that well in FS2004. I have quite a lot of difficulty from inside FSUIPC knowing when it is safe to access aircraft paramters in SIM1.DLL simply because there's nothing clearly obvious to tell me when a previous flight is deleted nor when a new one is completely loaded and initialised. And it isn't only Flights, simply loading or reloading an aircraft is the same problem. All the data structures are deleted then re-built for the new aircraft in both cases. And different structures are built for each aircraft type -- prop, jet, turbo, helo, glider. It's a nightmare in fact. In FSUIPC I take some precautions to simple avoid trying to access areas which are not valid at any time, but it isn't foolproof. I use pointers in other, more general structures, and before accessing those I check for validiiy by APIs like "IsBadReadPtr". If I do ever find a foolproof way, I can certainly provide some sort of indication. It could be useful for my other modules. But it might help for me to actually understand why an application (rather than FSUIPC) would need to know. Can you explain? Regards, Pete

I think it would be easy enough to do this, but it has not been requested at all before. I only added what was specifically requested there. I can add it to the list of things to do in the next version, if you wish. Regards, Pete

I think Elite do their own thing, probably writing direct into FS. I know nothing about them and they've never contacted me. I think your only recourse is to contact their suport. Regards. Pete

Delete your FSUIPC.INI file then -- if FSUIPC is assigning buttons for you it is because you have told it to at some time. It does not touch joystick buttons at all of its own volition, those are all user facilities. If you dete the INI file it will delete all such erroneous assignments you made before. Regards, Pete

A 64-bit (8-byte) floating point number, also called a "double" in C/C++. There's no easy way you can generate those directly in EPL, and there's no 8-byte data transfer facility in any case. You can do it through EPICINFO which has facilities for dealing with these things, but I don't know FSCOMM. Maybe you could ask the author? Regards, Pete

It should work, but there was a bug in some versions of FSUIPC where the button repeat action didn't work. Make sure you are using the latest version (3.11). Regards, Pete

You need to send both emails you got from SimMarket and also tell me which one you have used or want to use. Send to petedowson@btconnect.com. Regards, Pete

The problem is two-fold: 1) Depending on what you do in "doSomethingwithData", your program is not relinquishing the processor and this will affect performance. Certainly, the call to FSUIPC_Process will cause a process switch, but doing this possibly very fast is actually only wasting much processor time switching unnecessarily. 2) The loading on FSUIPC, processing the end-to-end requests, is a loading on FS itself, which isn't a good thing. Since the most if not all of the data you are using cannot possibly change faster than the FS frame rate, most of those calls be will just an overhead and doing nothing useful. The solution depends on what else the program is doing. If it is actually doing NOTHING except when it gets new data, and you don't mind it being rather unresponsive to user interventions, then simply try inserting a "Sleep" in the loop, say for 15 or 20 or more milliseconds -- experiment and use the biggest value which works well. Alternatively, trigger this section of code on a windows timer call -- either by WM_TIMER messages or using the TimerProc facility in SetTimer. Using the loop in a separate thread with a Sleep would also work, but is probably an unnecessary complication. Certainly do not have it in a thread with no Sleep, that could be worse (especially, as I found out recently, on Pentium 4 HyperThreading processors). Regards, Pete

Since AFCAD is freeware I have made a freeware key for it to access FSUIPC. Please see the Free Key list which is a Sticky message up above. Regards, Pete

Sorry, but FSUIPC has no relation to anything graphical whatsoever. In fact by itself it isn't even doing anything., unless you've set some options. There's something else going on there. I'm not sure how you can go about determining exactly what it is, but start by removing all add-ons and re-installing one at a time. Regards, Pete

Check the "module users" part of the FSUIPC SDK. Whatver you do, do NOT use the normal external interface. It is fat and inefficient for use withing the same process. The module users method is a simply message passing system with you maintaining the data area. Regards, Pete

That's odd. I don't know of anything that would change that. What was the previous version of FSUIPC you were using? Regards, Pete

Sorry, I don't know any way to do that "on-the-fly", only through the menu. Regards, Pete

As documented, it is available as freeware for its true original purpose -- as a successor to FS6IPC for interfacing external programs to FS. I have merely put a price on the additional facilities. I am afraid that, if the default FS and Windows facilities for joystick calbration are not sufficient for your needs, then there are only two alternatives: either write a driver for them to interface to FSUIPC (for freeware I provide a free key), or purchase a user key for FSUIPC so you have access to all the optional features. Regards, Pete

Sorry, I know zero about FF and it isn't an area I want to get tangled up in. You'll need to report it to Microsoft. It won't be anything to do with FSUIPC at all. Regards, Pete

Ugh, really? I'll have a look this weekend. Sorry. Regards, Pete

I don't understand. GPSout is intended to make FS effectively look like a GPS to an external map program, normally running on another PC. Sending GPS outpput data to another GPS sounds rather odd. I have a Garmin GPS and the only input it can take is feed from an external GPS receiver/amplifier, for more accurate or sensitive operation. The format for that is not NMEA. If your GPS can read NMEA output from another GPS, then presumably there's some appropriate mode for this. I think you'd need to determine this from its handbook. Regards, Pete