Pete Dowson

No idea at all, sorry. It could be an error in either the Aircraft.CFG file, for specifying strobes, or in the modelling of the aircraft for not having them animated. Or, alternatively, if they are not specified in the CFG file and not incorporated in the model, then there's a bug somewhere in FSX's innards or in SimConnect for reporting this incorrectly. Please send an appropriate report to tell_fs@microsoft.com. Regards Pete

OkayI cannot make FS crash by setting any sort of values in 3478, and continuing to set them, even with my aircraft parked on the ground. I really don't see anything else in your button programming which could crash FS -- the rest is all simply concerned with basic FS controls and virtual button manipulations. Something is evidently wrong somewhere, but I don't really know how to find out what, as you say it crashes to desktop with no error message. Maybe I need the whole of your otherwise working solution to try here. You'll need to supply the Buttons section and tell me exactly what is supposed to do what and which aircraft, etc. I can do the whole thing in debug mode and trap the error as soon as it happens, wherever it happens. Pete

Yes, but isn't this the pilot's job? If you are on autopilot shouldn't the A/P cope? Ah .... there's something seriously wrong then. You shouldn't be able to make FS crash. It understands decimal -- it will output in hex for those controls if you are using the Buttons dialogue in FSUIPC options, and generally for bit masks hex is more obvious. Sorry, let me get this clear. Are you saying that applying a Y component ambient wind change whilst the aircraft is on the ground causes an FS hang? All the time? This should not be soI'd need to reproduce this. This line, line 12, doesn't touch the wind of course. Incidentally, you seem to be switching on 14 buttons in Joystick 65, not 64, yet all your tests in later lines are on 64 (in 3340). You realise you aren't setting joystick 64 buttons now? Is it the action of setting a negative value to 3478 which crashes FS? Or is this the line which crashes FS? Or thisor one of the others changing the Y ambient wind? A process of elimination -- comment out each of the Y-affecting lines in turn -- might help. Won't this final Y-effect continue forever (well, for my 14 second or whatever timeout) after touchdown. You said doing this on the ground crashes FS, so isn't this the possible problem in the sequence? I'd like to know why FS crashes when changing ambient winds on the ground. It cannot do with the X and Z cojmponents as I use those to deal with Taxi wind facilities. This is the part needing investigating. No, I don't know anyway to get that information. Best to read the RA before takeoff! ;-) Regards Pete

I don't really understand you here. Can you explain please. What is "automatic trim" and how are you hoping to work it? So you really mean the sim (i.e. FS itself) crashes, or just the aircraft? There's quite a difference! The byte at 3340 is just the first of 36 offering 288 "virtual buttons". To set a button 'on' or 'pressed' you'd use Offset Byte Setbits, with a parameter with only the approrpiate bit set (1, 2, 4, 8, 16, 32, 64, or 128 in 3340 for buttons 0-7). To set a button "off" or "released" you'd similarly use Offset Byte Clrbits, with a parameter with only the approrpiate bit set (1, 2, 4, 8, 16, 32, 64, or 128 in 3340 for buttons 0-7). Or of course x01, x02, x04, x08, x10, x20, x40, x80 if you use hex. If it "makes no difference" to what you are doing whether the buttons are pressed or released, then there's really no point in using them, is there? ;-) They are actually buttons 0-7 and 0-5 respectively (you have 6 bits in the second line's parameter), and you are using Offset Dword Setbits, not Byte, though if you don't care about the other 50 buttons being changed too then I suppose it doesn't matter. Why are you setting all 14 buttons "pressed" or "on" when you press Joystick 0 button 1 and the aircraft is airborne? If you only need 14 buttons, I'm not sure why you don't just use buttons 0-13 on the first joystick number, with Offset Word ClrBits/Setbits. First, just a little suggestion: it would be easier to see what was going on here if you used the radio altitude in metres at W31E6 instead of *65536 in D31E4. All multiplying by 65536 does is shift the integer part up 16 bits (65536 being 2 to the power of 16), so it resides in the 2nd 16-bit word (31E6). The 16 bits in 31E4 are the fractions of a metre (eg 32768 there would be 0.5 metres, being 32768/65536). Second, it looks most intreresting and I expect I could spend a few pleasant hours working out exactly what you are doing (or trying to do), but I really have too much else on at present. Do you think you could present the same code, with line-by-line comments on what you think is accomplished by it? This would make it a doddle to check for you. I've not seen anything quite so, er, complex on this Forum, and I am lost too but mainly because I really don't know what you are trying to achieve nor how. If you'd like to annotate it, as I said, I will take a further look. Okay? Regards Pete

You won't find any reverser in any list of FS controls, because it isn't FS which supports a separate reverser but FSUIPC. Please see the section Assignment of additional controls (Reverser, Aileron and Rudder Trims, and Cowl Flaps) in the FSUIPC4 Advanced Users Guide for details. You need to de-assign the axis altogether in FS assignments and instead Assign it in FSUIPC's Axis Assignments. Select the Send direct to FSUIPC Calibration option checkbox in the Axis Assignments, then choose the Reverser from the drop down controls listed. You then need to go to FSUIPC's axis calibrations, find the reverser and calibrate it. Regards Pete

Right. The current version is 3.74. I don't support old versions. There's no way you lose your key unless you delete the key file, and then you'd need to find the backup you made (of course). As the installation instructions say, installing FSUIPC is only a matter of copying the DLL into the Modules folder. As for problems, since each update for FSUIPC is intended to add new facilities and FIX problems, why should it introduce any? In the unlikely event that it changes something you are using, just let me know and I'll fix it. Pete

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