Pete Dowson

Well, that's never been true so I don't know where you read it. Certainly, I hope and expect developers to buy FSUIPC, in return for the programming support I provide (with the SDK and full interactive support when needed). You seem to have completely mixed up USER registration and APPLICATION registration. I think you forgot to read some of the documentation I supply? For all versions of FSUIPC3 up till 3.72 application programs needing access to FSUIPC did need either a fully registered install, or an application access key. This was explained in the User documentation (which you really should have read, at least the part up to and including applcation registration -- which no longer exists for reasons given below), and, for developers, the Access Registration document (inside the SDK), which you certainly should have read, as a developer needing access. The granting of an access key was always free for freeware programs, but I required (and still do require) an agreement for commercial or shareware use. Since version 3.72 of FSUIPC3, and for all versions of FSUIPC4, the application key checking is removed, so I no longer provide application access keys. If your program is freeware there is nothing for you to do except advise your users to make sure they use up to date versions of FSUIPC (I don't support old ones in any case). If your program is commercial or shareware then write to me at petedowson@btconnect.com. Regards Pete

Why? What is it in FSUIPC's user facilities is it that you need enabled? Surely you should be able to do all you want via the programmable interface supported by the SDK. You cannot give it to anyone at all. If you are doing so you are breaking the conditions and your own license will have to be revoked and keys stopped. It seems extremely unlikely that you need this. I don't know of any other application program which need "the full version" to operate. You tell me which user facility it is that you need enabling and I'll advise acordingly. Regards Pete

Hey, you're right! It isn't appearing here either! :-( Sorry, this is most certainly a bug. I'm not sure what happened thereno one else has mentioned it, and having all my settings they way I want them already of course I've not re-visited all of the pages. I'll work out what is wrong and put up a fixed version as soon as I can get to it -- probably tomorrow (Monday), or Tuesday latest. Check in the Other Downloads announcement above. Regards Pete

I am pretty sure that you don't actually need to run the Installer "as administrator". It is only needed for the Registration itself, which accesses the Registry. Isn't there a message above it advising you to run as administrator? It sounds like you missed this important part (about the olny part dealing with Vista differences): Regards Pete

Okay. I've now checked this. The problem is in the old FS2000 Advanced Weather Interface (AWI) which WidevieW is still using. In FS2000 and before there was only the possibility of a single visibility setting, and it applied from the surface up to a specific level above which the default "unlimited" or "max" value would apply. The AWI therefore arranges for the visibility to start at ground level. It used to set 0 feet, but this gave weird problems at Schiphol and other areas below sea level, so it was set to a much lower altitude, as you have observed. I am not sure what was possible in FS2002 (my memory is failing due to old age and too much wine and beer), but I am pretty sure it was much the same. Certainly FSUIPC still only supported the one visibility and the AWI was as good as it got. For FS2004 a lot more was possible, and I introduced a new interface to take advantage of it all. This is the New Weather Interface (NWI). Of course, for compatibility I still had to support the AWI too (and even the old FS98 interface), but I didn't enhance it at all Unfortunately, WidevieW is still using the FS2000/Fs2002 facilities, which explains why the lower altitude is getting overridden by the assumptions the FSUIPC AWI makes for FS2000/FS2002 compatibility. The good news is that it is easy for me to change that action in the innards of FSUIPC's AWI, and I will do so. Please look out for an interim update (probably 3.742) in the "Other downloads" announcement above, early next week (probably Monday). Try it and let me know if it answers your problem. Regards Pete

Eryes. So? Why are you telling me about my own program? I don't understand. Please explain what your problem is and I will try to help. It sounds like you are simply not folowing the Installation instructions then the Registration. Regards Pete

FSUIPC4, you mean? What does "lock back" mean? What are you doing? What error are you seeing? Some information would be useful please. Did you follow the installation instructions. After running the Install_FSUIPC4 program, you run FSX "as Administator" (a right-click menu option). Vista has Administators with less priivileges than other Administrators. That's why you have to use the "run as administrator" facility. This is only needed for Registration. After that you can close FSX and run it normally next time. Regards Pete

I don't issue SDK updates for every minor change. I never have -- I just include the details in the release notes. For full releases (with the Installer) you'll find details of any offsets additions and changes since 4.07 (the version for which the SDK is applicable) in the relevant section of the FSUIPC4 History document, installed in your Modules folder. For interim incremental releases (eg just the DLL in the FSX Downloads announcement), I detail the changes in that announcement. Regards Pete

FSX Dowsnloads and Updates announcement, just above here. Regards Pete

Okay. The links are all fixed now. Regards Pete

Tht's odd. The file is still there on the Simflight FTP site along with all my other downloads for other announcements, but the link is not working. I'll check it out. [Later] I don't know what has happened, but none of my files, listed in any of the Announcements, are accessible here at present. Looks like something has changed at the Simflight server. I am trying to get it sorted now. Best Regards Pete

5 seconds is probably not a long enough gap for fS when it is really seriously busy loading scenery or something. I've known it take many seconds indeed for complex textured scenery on initialising or after a Flight load. Best to simply retry the current FSUIPC_Process at, say, 2 second intervals, for maybe 10 or 20 times before deciding to disconnect and re-connect in case of FS reload. I don't know the Client DLL for .NET -- perhaps you should post this in that sticky thread to be sure to attract the author's attention, but as far as FSUIPC is concerned a new FSUIPC_Open is indistinguishable from the previous one, so should work the same. Possibly something in the Client DLL isn't being initialised properly, but being assumed to be zero or whatever? Hopefully that will be something easy for the author to find. Regards Pete

It would probably have been available earlier in FSUIPC4 before 4.03, when this change occurred: On this: This is only coincidence. FSUIPC4 has no control over exactly when SimConnect information arrives. The path for the currently loaded aircraft is requested as part of the Initialisation after "SimStart", along with a multitude of other things, but when it then arrives is another matter. If you want to be sure your code works no matter what might be holding up SimConnect data, best to just test the first byte of 3C00 for non-zero -- it will read zero (null string) until the path is obtained. And of course always either operate a timeout or allow interruption, just in case! ;-) Regards Pete

Yes, of course. Program a key or button to set a Button Flag and use that in conditions when programming the buttons (or the other buttons). You can quadruple the number by using two such flags. There are even ways of programming FSUIPC offset values for any number of states which you could cycle through. These sorts of facilities do need INI file editing, but all of the details you need for this are provided in the Advanced Users documentation. Well, whilst that is also possible it isn't terribly useful, because once you press ALT you are in Windows Menu mode, so the rest of the processing stops whilst you manoeuvre within the menus. What do you use ALT a lot for? It really doesn't seem that useful except possibly as simply another shift, and I already support Shift, Ctrl, Tab, Menu and Window keys for keyboard programming. Since only you know when you've finished using them in such a way, only you know when to press such a function -- there is no "default" use for them, but if you mean the zoom setting for one of the 3D windows that is usually selected via the [ key, I think. Of course all of these functions are by keypress assignment in any case, so any and all may change if you reassign keys in FS. If you are using buttons they aren't really that relevant in the first place -- you can program the controls directly instead of using the keypresses which in turn are translated into controls! For instance. Far better than trying to use selections then + and - why not program these things using the FS control for them -- Zoom in/out, Sim Rate incr/decr, etc? All of the things you can use +/- keypresses for have direct inc/dec, in/out or up/down controls. To risk repeating myself, you seem to want to do everything via the key presses even though you have buttons. It is far more efficent and more obvious surely to assign controls. Just have a look at the drop-down list of controls you can assign (there's also a document listing them). Really the facilities for assigning key presses to buttons are there for those add-ons (cockpits especially) which don't use standard FS controls and can only be operated by keypress. Regards Pete

Log from client again please? I don't have WidevieW but I'll try to set up something which just copies the visibility here. Might take a while though. Maybe over the weekend. Pete

Thanks! Pete

Thanks. As I mentioned, the weather options aren't the same on both PCs. It looks like you've not selected minimum weather options on the client, where it is important so WidevieW's settings aren't changed. There is no harm in having options set on the Server (like the auto-taxi wind and extend upper wind, as you have set), but everything should really be off on the client to avoid interference. I'm sure Luciano's documentation tells you this some place. In your case the likely visibility interference is coming from this: ExtendMetarMaxVis=Yes which is from a checked item on the Visibility tab in FSUIPC. You also have: ExtendTopWind=Yes which will be on the Winds page and GenerateCirrus=Yes from the Clouds page. Please try again with minimum weather options ON THE CLIENT (it doesn't matter about the Server, as the weather there is being read, not written). Check the visibility option settings specifically. Let me know if you still have a problem and I'll try to set something up here. Regards Pete

Hmm. It works fine here. The AIR file details are read directly to that offset from SimConnect, and that hasn't been changed at all in any version. How about a Log file, please? The AIR file details are logged at the very same time as 3C00 is populated. Did you look? How are you checking this? Try FSInterrogate2. Here are relevant parts of a log I've just obtained, and also checked via FSInterrogate2 with IPC logging enabled: ********* FSUIPC4, Version 4.09 by Pete Dowson ********* User Name=... User Addr=... FSUIPC4 Key is provided WideFS7 Key is provided Running inside FSX ... 14043 SimStart Event: Initialising SimConnect data requests 14045 FSUIPC Menu entry added 14278 i:\my documents\flight simulator x files\738 at EGCC.FLT 14279 G:\FSX\SimObjects\Airplanes\B737_800\Boeing737-800.AIR 14806 System time = 13:12:18, FSX time = 13:12:16 (12:12Z) 15265 Aircraft="Boeing 737-800 Paint1" 16616 Advanced Weather Interface Enabled 140623 READ0 3C00, 256 bytes: 47 3A 5C 46 53 58 5C 53 69 6D 4F 62 6A 65 63 74 G:\FSX\SimObject 140623 73 5C 41 69 72 70 6C 61 6E 65 73 5C 42 37 33 37 s\Airplanes\B737 140623 5F 38 30 30 5C 42 6F 65 69 6E 67 37 33 37 2D 38 _800\Boeing737-8 140623 30 30 2E 41 49 52 00 00 00 00 00 00 00 00 00 00 00.AIR.......... ... 158886 G:\FSX\SimObjects\Airplanes\Extra300\Extra300S.AIR 159798 Aircraft="Extra 300S Paint1" 165816 READ0 3C00, 256 bytes: 47 3A 5C 46 53 58 5C 53 69 6D 4F 62 6A 65 63 74 G:\FSX\SimObject 165816 73 5C 41 69 72 70 6C 61 6E 65 73 5C 45 78 74 72 s\Airplanes\Extr 165816 61 33 30 30 5C 45 78 74 72 61 33 30 30 53 2E 41 a300\Extra300S.A 165816 49 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 IR.............. 178702 System time = 13:15:02, FSX time = 13:13:20 (12:13Z) 178703 *** FSUIPC log file being closed Memory managed: 56 Allocs, 56 Freed ********* FSUIPC Log file closed *********** Regards Pete

Excuse me, but how can it be done without Wideview ? I don't know, but that wasn't the point. I thought WidevieW was used to coordinate scenery mainly. I don't know how well it does weather -- it cannot match cloud images in any case, until FSX where it is possible, via SimConnect, to read actual cloud position data. Okay. Good. Now we know it is okay on the Server, and can be read by programs using FSUIPC, then at least we know that WidevieW should be able to READ it there, and therefore SEND it to the Client. Now we need to know what it does with it on the Client, so a weather log from FSUIPC on the client would be useful. From your original message it seemed you'd already done this logging but chose to only show 2 lines. Maybe the answer is in the lines leading to those? Let's see: Okaynow this is better information. We see that WidevieW uses the AWI, which is good, and tries to set GLOBal weather, with the correct visibility values. Good. But then FSUIPC converts the base value to -1500 feet. So, this seems like some options in FSUIPC are not correct. That, I need to investigate. I see the line WeatherOptions(Orig)=480036A7[480036A7] for the Server, but WeatherOptions(Orig)=40003605[40003605] for the Client, which certainly implies some differences in your settings. I'll need to analyse those bits to see what they mean. Meanwhile, could you show me the FSUIPC.INI file? BTW version 3.73 of FSUIPC is out of date and unsupported. 3.74 has been current for a while. Regards Pete

These are the logs from which you quoted two lines only from each originally? What logging options did you have enabled? It would be helpful to see what commands resulted in what you see. Why keep the rest a secret? It is possible the WidevieW reads visibility from FSUIPC in one and writes visibility via FSUIPC in the other. But there are three different interfaces through which it can operate, and the oldest one of these (the FS98 compatible system) doesn't support visibility layers. Even if it uses one of the other interfaces (AWI, FS2000, global only, or NWI, FS2002/4 with global and local support), I don't know how it might be using them. Using the WeatherSet2 (NWI) and WeatherSet (AWI) programs on the Server PC, as I asked, would allow you to verify that those interfaces were reading the visibility as you set it. That's why I asked you to try them. If they are reading okay, but WidevieW isn't, then that would be a WidevieW matter for sure. Alternatively, it could be that WidevieW is reading them okay but writing them incorrectly, so logging of the weather data on the client, especially the weather commands, would have ben illuminating too. It may also then show if it is a problem of actually setting the weather on that PC via FSUIPC. By releasing your information in little tidbits it is taking rather a long time and a lot of effort to not get very far. I don't mind helping here, but please see if you can do something when asked, and possibly supply more inofrmation. Also let me know what WidevieW support have to say. Considering both FSUIPC and WidevieW have been around for many years I am surprised this has only arisen just now, well into FSX developments and over three and a half years after FS2004 was released. Maybe no one has ever used WidevieW for weather transfer before? Seems rather unlikely? Regards Pete

No, you shouldn't publish or send copies of bits of FS. But you could publish instructions for other users. I think they knowand I checked. It is already bugged. I think it just hasn't risen high enough in the long list to get fixed yet. I think they've had too much to do with all the performance problems and other more serious bugs. Regards Pete

OkayI'm not actually sure how WidevieW reads and sets the weather, so your question will really need to be put to WidevieW support. Are FSUIPC's weather settings set to minimum? Are there any visibility options set, such as graduated visibility and so on? I thought that was obvious. I mean that, having set the weather in FS's weather settings, as you described, did they apear to operate the way you set them in FS on that specific PC. Forget the other PC, we need first to check that it is working on the first one. [sorry, I don't really know how else to say it -- I don't understand what is so hard about the way I worded it in the first place]. Sorry, I don't know what those are. I don't know WidevieW and I've not used it since FS98. No, see below. And what about my point that visibility is NOT cloud, as you seemed to assume? Other questions: 1. Are you using local or global weather? i.e. is the weather you are setting specific to a weather station? I am not clear how you are doing this. 2. Do you clear all the weather first? Please, try using my WeatherSet2 program to read the weather on the PC on which you set the visibility. Read both the global and the weather at the weather station. See what visibility data is being set there, as readable by program. WeatherSet2 reads FS9 local and global weather. I do not know what WidevieW reads. I get a strong feeling that your question is really aimed at WidevieW. Let's just check that the weather is setting correctly on the prime PC first. If it is and it is readable, then it becomes a question of how WidevieW is reading it there and how it is writing it at the other end. Regards Pete

Er .. questions arising immediately include: 1. In FS98, FS2000, FS2002, FS2004 or FSX? 2. Are you using FSUIPC at all? Or WidevieW? 3. If FSUIPC, which version, and what settings have you got? 4. How are you setting the visibility? By dialogues in FS, or by program, or what? 5. Is it being set that way on the computer on which you are setting it? 6. How are you having it transmitted to another computer? 7. What is running on the other computer to receive it and act upon it? Without at least some information, I can't really help much can I? Note that until FS2004 multiple visibility layers were not supported -- only a surface visibility is available. I don't think multiple visibility layers work correctly in FS2004 or FSX -- when attempted they've been very problematic. Generally the one and only working visibility layer, which is the surface visibilty layer, is set to begin at -1500 feet so that it reaches the ground all over the world. What has cloud got to do with it? You need to set a cloud layer if you want to break out of cloud. The visibility effects from cloud layers are not the same as those produced by the visibility layer. Regards Pete

Yes, confirmed. I'll bug it with Microsoft directly so it gets fixed one day. I doubt that it would be a priority job, even though it is probably only a minor editing exercise in the XML panel data -- even a clever user could fix it, but it needs to be properly listed. Perhaps you could also please report it via tell_fs@microsoft.com. Regards Pete

Please scan down the Announcements and sticky threads at the top of the Forum. One of those addresses this very point. Regards Pete