Pete Dowson

I didn't think so -- both gusts and variance (fluctuations in wind direction) should be operating normally, I *think*. The smoothing for FS2004 is different to that provided in previous versions, but it has remained unchanged for the (more than) two years since FS2004 was released. It is a little strange to be thining of changing it now -- I will consider what may need doing for FS200x as and when. Regards, Pete

I don't think it does. You should face the aircraft into the wind and read the fluctuations on the airspeed indicator. Regards, Pete

The problem was only in one or two versions (3.45/3.46), where the classification of landing AI aircraft was incorrect -- they were still in the Airborne table after touchdown, until they finished "landing" mode. This was fixed in version 3.47, as described in this item of the release details (above and in the History document): It's been okay since then -- i.e. in both 3.47 and 3.48. The classification of a "Landing" aircraft is now decided according to the "On Ground" flag operated by FS. When the state changes to "Rolling out" they are always in the Ground table. The earlier problem with FSHotSeat was because it only checks the Ground aircraft so didn't see Landing aircraft till the "rolling out" phase, which is either too short for it to see or which it doesn't look for in any case. If you are still having a problem with FSHotSeat you should ask their support. I'm afraid I don't have the program and I really don't know what it is doing. I fixed the original problem as soon as I was notified of it (it didn't affect any other program, as the effect of being in the "wrong table" is so transitionary). Regards, Pete

Ah, yes. Some programs do use features added to new versions of FSUIPC from time to time. Good. Glad everything is okay. Regards, Pete

No. As you can see from the Announcements at the top of the Forum, version 3.48 is still the current and supported official user release. There is a later Beta version there available for testing, and this will become released formally as 3.50 in due course. Why? What is concerning you that you want an new version? Regards, Pete

Well, if you have a user-registered FSUIPC then you could try doing it via FSUIPC -- it is certainly possible to assign keystrokes for alternate presses, but as I said it isn't part of the "normal" assignment facilities and you'd need to refer to documentation. Regards, Pete

I don't know. I don't think anyone else has ever used those facilities. I thought they were okay, but I have no programs which use them so a thorough test hasn't been possible. If you have a small program which I can use to test it, I'll trace through the code. Possibly the direction in the variable I'm setting is the "to" direction not the "From" for some reason. If so, I'll fix it in the forthcoming version 3.50. Regards, Pete

Default FS aircraft don't have both modes on the default MCP. Is the GoFlight MCP able to control the LDS767? Sorry, I don't know GFKeys -- it is a product of GoFlight I think. Have you tried GoFlight support? If you want to use FSUIPC button programming instead the two keypresses could be programmed for alternate button presses by using FSUIPC's button flags to switch between them. This would need editing in the FSUIPC.INI file and it uses faclilities described in the Advanced User's guide. Regards, Pete

Where are you getting "horrible windshear"? All FSUIPC is doing is preventing the prevailing wind speed and wind direction changing faster than to specified (user controlled) amounts. There's a separate weather setting each for gusts (wind speed changes) and variance (wind direction changes) which FSUIPC doesn't touch -- they are the prerogative of the weather source, part of the parameters, just like prevailing wind direction and speed. Well, I think you misunderstand the function of smoothing. The idea of the smoothing is to ease transitions between CHANGES in the weather, eg over time or over distance, which arise incorrectly simply because there are some errors in the way FS blends weather from difference sources. Simply not having smoothing enabled, or set "less" will not actually generate gusting or variations. What you want is really part of any weather control program's function. The sort of conditions you want should be easily possible with the correct weather settings, controlled by gust and variance settings for each level. I think programs like Active Weather and FS Meteo do a pretty good job on these. I don't know how much such detail the FS downloaded weather achieves. Regards, Pete

No idea, sorry. Do you have a protocol specification? I've never heard of it. All the stuff I have is for NMEA 0183. Regards, Pete

If the panel is not on screen, there are no mouse hotspots to be detected by the panel code, and therefore no way to activate the function. I am using the PMDG 737NG, but only for its flight and visual models. I have no panel and no PMDG DLL running. The cockpit functions are provided by Project Magenta (including pmSystems for APU, Fuel Pumps, Air Conditioning and so on), and the panels themselves are of course the hardware of the cockpit. There is a chance that some of the relevant parts of the PMDG panels may actually communicate via FSUIPC offsets. I know that some areas (mainly the MCP values I believe) have been "hacked" and published somewhere on the Internet. Maybe areas you are interested in are covered in that way. I'm afraid that I do not know any more and even if I did I couldn't publish it without PMDGs permission. They do not seem to favour cockpit builders using their programming and so do not publish details themselves. If you cannot find adequate details I really see so solution for you going down the path you have chosen. Sorry. Possibly more appeals to PMDG might sway them one day -- I have tried several times to no avail. Regards, Pete

I would think there was absolutely no relationship between any aircraft and FSUIPC for NavData, bacause FSUIPC doesn't provide any. I suspect the same would apply to both aircraft without FSUIPC installed at all. FS gauges are well capable of obtaining radio settings directly, and always do, whilst for NavData they are usually dependent upon their own databases, installed with the aircraft. I'm afraid I know nothing at all about any PSS Airbus aircraft and I don't think they use FSUIPC for much at all -- probably only the TCAS display. Regards, Pete

You won't find it anywhere, it's not released. I provided it only to two folks so far to make their databases. I'll send you a copy, but it is undocumented and unsupported. Just place it in your main FS folder and run it. It makes several files -- a very large text file listing airports and runways, and several database files -- .rws in binary and some .csv (comma separated values) format files. Regards, Pete

Seems you are getting yourself rather confused. User registration of FSUIPC, so you can access all the facilities, is only posible if you purchase a Key. It is that registration you perform with your own name and email address. Registering an application manually is only necessary if two things are true: 1. You haven't registered FSUIPC as a paid-up user and 2. The application programmer hasn't bothered to make it easy for you by programming in the application key into his program. Most all commercial programs do this properly, and many freeware ones too. If both of hese are true then you would certainly need to enter the key manually. The button to do that with is the one bottom right on the first FSUIPC options screen. In the dialogue that brings up you'd have to enter the program name and the Key. Where did you get an FSUIPC.KEY file from? That's generated by FSUIPC when you register. It surprises me greatly that the author of the FS2ATCS program has not programmed this properly. It is his job to support his program, not mine. He was issued with a key back in April. The program name to enter is just "FS2ATCS" and the Key is QX6U CM36 PYQQ. Regards, Pete

Well, the known safe ones are those which were supported in FS2002 and FS2000 -- cirrus=1, stratus=8, cumulus=9. I think these are even the same codes as used in FS95 and FS98! ;-). Oh, yes, there's storm clouds too, 10 I think (cumulonimbus). I think, then, you get graphics variations based on things like altitude, thickness (top - base), cloud top shape (maybe?) and deviation. I don't know a lot about it but folks like Chris Willis who've done a lot of work on cloud types do know a lot about this stuff and what you can do. That's why the weather produced by programs like ASV looks so good. Regards Pete

Well, what programs which need such data do is ask the user to run a database update (either a separate program or one built into the application) each time they update their scenery. It doesn't need changing otherwise. Regards, Pete

I think the only way is to build a database of runway positions and sizes and check against that. The data for this is contained in the airport facilities data part of the scenery BGLs (AFD files). I have a program ("MakeRunways") which compiles a database by scanning all the active BGLs in your particular FS installation -- it scans those sceneries marked as active in your SCENERY.CFG file. This produces the sort of file you will find in my FStarRC package (the .rws file is made that way). Programs such as Trafficboard and Flight Keeper make their own databases the same sort of way, but retain more of the data in the AFD files. Regards, Pete

Yes, the reason the FSUIPC_Process call is separate is so that you can build up a complete set of requests -- as much as 30k data (including overhead data, 16 bytes per Read or Write) can be accumulated -- for one transfer to/from FSUIPC. All the read/write stuff is actually in your program, and very fast. But every Process call requires a process switch to FS and a switch back to your program after. So each such call can be 100 or more miliiseconds. Compared to the time for the actual data that is huge. It is even worse of course over WideFS where you add Network latency. Ah, okay. I see that now -- I missed it on my quick perusal. Regards, Pete

That's pretty easy to do, since the NWI effectively gives you a clear interface directly into WEATHER.DLL functions. FSUIPC doesn't check your data nor place any restrictions on it, since I didn't want to restrict exploration. For example, there are only so many cloud types selectable -- if you try one which has no graphics defined for it, crash. There are probably more ways to crash FS with erroneous data than you can shake a stick at! ;-) Best when developing new software to test it on the FS PC first. That is most definitely a problem on your Network. The data is checked thoroughly on reception to ensure no rubbish is seen and obeyed. The crash is at 2112C218 which is in WEATHER.DLL, and just a glance at the weather you are trying to set shows the likely reason -- Cloud Type 3 isn't implemented in any standard FS at present. I don't know if it can be added by clever folk like those who do the cloud graphic replacements. Your main task is checking the data you are asking FS to obey. Yes, the entire method is different there, and FSUIPC will replace any invalid cloud types with valid ones. I knew FS2000 and FS2002 Weather implementations quite well and could therefore impose restrictions without qualms. With the whole weather engine in FS2004 being new, a complete re-write, I didn't want to restrict experimentation. The consequence is that you have to check the data because FSUIPC isn't babysitting you on this. Regards, Pete

Help what? I can easily get the number of miliseconds count. I use it all the time -- see any FSUIPC Log, for example. But that is NOT the same as FS time. FS time is simulated time, it isn't necessarily closely related to the real elapsed time at all. The GPS data output is supposed to be the simulated time of the simulated position, not any real time. I don't know where the NetPipes gets its time "between frames", but I also do not know when a "frame" occurs, so even if I knew it, what would it mean? So how do you propose using this NetPipes idea? You seem to have misunderstood my previous explanations. The milliseconds I am using to fill in the fractional seconds IS accurate, at the time I stamp it. It is just that is it the time from an arbitrary zero fractional moment which I cannot pinpoint since I cannot detect exactly when the second count increased. The other inaccuracy from the receiver end is the unpredictable delay from when I stamp it to when you receive it. If you think Netpipes has the answer why not write your own GPSout program using NetPipes and see if that gives you more accuracy? From what I've heard about that FS facility it is anything but. Pete

Help what? I can easily get the number of miliseconds count. I use it all the time -- see any FSUIPC Log, for example. But that is NOT the same as FS time. FS time is simulated time, it isn't necessarily closely related to the real elapsed time at all. The GPS data output is supposed to be the simulated time of the simulated position, not any real time. Pete

I've had a brief look. First thing -- your code will be EXTREMELY inefficient. You are reading all 96 slots for both ground and airborne traffic, all individually. This involves 192 separate Process calls, which is 192 separate Process switches between your program and FS!!! Please think about that and compare it to a method which has two arrays of 96 TCAS structures and does one read of 96 x 40 bytes for each, and then one Process. That will take about the same time as just one of your 40 byte reads -- i.e. 192 times faster! Then your loop to read strings reads them for every slot, even empty ones (Id == 0). Furthermore, you are writing the Signature to D00C, immediately overwriting the Aircraft ID you just wrote. The proper signature offset D000 is never written, so no command is ever obeyed. Please consider debugging code before thinking FSUIPC is in error. If your own compiler's debugger isn't any use, at least use the tools FSUIPC provides - checking the actual sequences of writes and reads in the Log would tell you everything. Finally, please note that this method of reading all the strings is grossly inefficient for what you wish to to. It was implemented to help programs like Radar Contact name the *one* aircraft in front of your own in a queue for take-off, and things like that. For your purposes, why not use the Aircraft ATC ID string which is provided in the TCAS tables already? If you want a specific one, read the current settings from E068/F068 areas, then set the ones you eant, read all the TCAS tables (in one Process), then restore the previous settings. I know the strings you get that was are rather abbreviated, but I'm sure you could work it to your purposes and end up with a much more efficient program. Regards, Pete

What's an "FSVPI" custom licence? Please always refer to the latest version, which is dated 25th April (it is the one which matches FSUIPC 3.48). Of course it will be zero initially, before anything has read anything. The timestamp is set to indicate some data has been made available. Until an operation is performed on it to read something, it won't be set. Can you not see that is perfectly logical? Why would you want to skip any steps? Instead of trying to explain in words here, please use FSUIPC IPC read/write logging. That is what it is for. From the logging we can both see exactly what is being written and read and can analyse what is going wrong for you. I don't know how you'd want to get the "visual information". The type and model won't tell you the livery, for instance. The string which is used to actually SELECT the aircraft in FS, the string which is saved in the FLT files for this purpose, it the aircraft title, so you may want that. It could be anything, but if you have the same aircraft installed in both systems it is the string which conclusively points to a particular model and texture set in the installation. All the strings are from declarations made in the Aircraft.CFG files, so perhaps you can look at some of those to see what you need? Not without more information. Please try using some of the tools provided. In this case a short part of the FSUIPC Log with IPC read and write logging enabled would explain everything. That's because the SDK was only updated after the facility was added (in 3.48 ). You could check the History documentation enclosed with the FSUIPC package, or just look at the "Recent Release Changes"announcement near the top of this Forum, which shows the same data. I think you'll find it as item 8 in the 3.48 changes. But the best thing is to always keep your SDK up to date. Regards, Pete

Though there haven't been many (considering the number of registrations), I can assure you that in 100% of cases like this, so far, it has been an error on the part of the user not entering the data correctly. As it says in the email you would have received you must enter the name, email and key EXACTLY as in the email. It is surprising how many ways folk have of spelling their own name. Computers don't understand all that, they need the exact data. It is best to cut-and-paste from the email so you make no mistakes. If you believe you are doing it all correctly, please send me the details (preferably the actual email you received) to petedowson@btconnect.com and I'll check it here for you. Regards, Pete

AhI don't think the actual intervals will be more accurate. As I said, I cannot tell when FS increments its seconds counter. The only accurate intervals will be from the readout with zero fractional seconds to each subsequent one in that second -- the interval from the last fractional value to the next whole second will be inaccurate because the latter is just when I see it as changed. Furthermore, I can only time it when I deliver it to the Windows buffered file system for the attention of the serial port driver. I suspect the time between then and it actually going out could vary by more than the interval iyself. Regards, Pete