pilotjohn Posted October 29, 2011 Report Posted October 29, 2011 I have some questions about NWI, specifically whether certain fields are used and their meaning by/for FSX: _NewWind.Variance: Is this +/- for variable wind? Is it used? _NewWind.SpeedFract: What is it used for? How? _NewCloud.Deviation: What is it? _NewTemp.DayNightVar: Is this an amount subtracted from Day temp when night falls? Dew point is unaffected? Will this simulated fog if T/D converge at night? Is it for FSX? It this used only for surface or all altitudes? Will clouds form when T/D converge at upper altitudes? _NewPress.Drift: What is this for? Your comments say "? Maybe" I'm planning on writing global weather generator (which seems to work, at least I can clear through Lua using vstruct), but if I chose to add location based variation, do you have any insights? If I write a different weather at 1 degree lat/long intervals, does FSX try to interpolate between them? For example, if I generate two MVFR conditions 60 NM apart and vis/clouds are different, what happens. Or, do I need to write weather only to ICAO locations?
Pete Dowson Posted October 31, 2011 Report Posted October 31, 2011 _NewWind.Variance: Is this +/- for variable wind? Is it used? Yes, it is used. It can only be positive (it is declared unsigned as you can see). _NewWind.SpeedFract: What is it used for? How? It it the factional part of the wind speed value, as stated. You wouldn't use it when setting, it would only be seen on certain types of weather reasouts relating to ambient speeds. _NewCloud.Deviation: What is it? Cloud base variation, but not actually used by FSX which does its own thing. It works in FS9,. _NewTemp.DayNightVar: Is this an amount subtracted from Day temp when night falls? Dew point is unaffected? Will this simulated fog if T/D converge at night? Is it for FSX? It this used only for surface or all altitudes? Will clouds form when T/D converge at upper altitudes? Sorry, on idea about any of that. you'd need to experiment. I suspect it is ignored in FSX. _NewPress.Drift: What is this for? Your comments say "? Maybe" Again, no idea. I don't think it is used in FSX. Unfortunately many of these are questions for the FS team, which no longer exists. I'm planning on writing global weather generator (which seems to work, at least I can clear through Lua using vstruct), but if I chose to add location based variation, do you have any insights? If I write a different weather at 1 degree lat/long intervals, does FSX try to interpolate between them? For example, if I generate two MVFR conditions 60 NM apart and vis/clouds are different, what happens. Or, do I need to write weather only to ICAO locations? FS has only ever allowed weather to be set at weather stations. It interpolates between. FSX does have facilities for programs to create temporary weather stations -- optionally used by Active Sky, for instance, for variable ocean weather -- but this facility is not supported in FSUIPC, you'd need to use SimConnect. Regards Pete
pilotjohn Posted October 31, 2011 Author Report Posted October 31, 2011 Thanks... a few more questions. So far setting temperature layers works great, and so does setting visibilities with one problem. The NWI.Vis (the surface visibility) is set but then immediately starts to change on its own (visibly and viewed in WeatherSet2) to a higher value, about every 3-5 seconds or so, until it reaches the limit I set in FSUIPC. This happens even if I disable the limits in FSUIPC (and then it changes to 60). The upper level visibility layers I set appear to be untouched. This is regardless of whether I use NW_SET or NW_SETEXACT and ensure that dynamic is set to 0 prior to any of the changes. It also happens if I change he visibility with WeatherSet2. Any ideas?
Pete Dowson Posted October 31, 2011 Report Posted October 31, 2011 The NWI.Vis (the surface visibility) is set but then immediately starts to change on its own (visibly and viewed in WeatherSet2) to a higher value, about every 3-5 seconds or so, until it reaches the limit I set in FSUIPC. This happens even if I disable the limits in FSUIPC (and then it changes to 60). The upper level visibility layers I set appear to be untouched. This is regardless of whether I use NW_SET or NW_SETEXACT and ensure that dynamic is set to 0 prior to any of the changes. It also happens if I change he visibility with WeatherSet2. Any ideas? Sorry, no. I always thought the visibility control provided in FSX was faulty, which is why the visibility options tab in FSUIPC4 is optional and only appears is an INI file parameter is changed (with such warnings). I don't remember now what exactly all the problems were (it was 5 years ago), only that I did find it unreliable. Microsoft were certainly aware of it but said they couldn't fix it before FSXI. Was this using a global weather mode, or setting weather at a single station? If the latter it could simply be the normal interpolation i suppose, When setting station weather you need to set it at all surrounding stations, or use Global (not 'global mode but the 'GLOB' id) to populate them first. Recently I have had this reported to me -- maybe it will help? If FSX loads with a situation that is not at sea level, this will be the limiting height for the setting of any visibility and also the cloud layers. To use an extreme, if FSX loads in Denver, several thousand feet above sea level, and you then re-position to say Miami, then it will not be possible to change those things and have them reflected in the simulator. If you load a situation file in EHAM or KMIA upon startup, no problem. Regards Pete
pilotjohn Posted November 1, 2011 Author Report Posted November 1, 2011 Was this using a global weather mode, or setting weather at a single station? If the latter it could simply be the normal interpolation i suppose, When setting station weather you need to set it at all surrounding stations, or use Global (not 'global mode but the 'GLOB' id) to populate them first. Yes, I'm in global mode. I placed FSX in global mode and write the weather for "GLOB" ID. The only way I seem to be able to "fix" visibility is if set NWI.Vis to -1 to 0 for altitude, and then use UpperVisibility layers from 1..whatever to set visibility. It seems only the NWI.Vis settings behave oddly.
Pete Dowson Posted November 1, 2011 Report Posted November 1, 2011 The only way I seem to be able to "fix" visibility is if set NWI.Vis to -1 to 0 for altitude, and then use UpperVisibility layers from 1..whatever to set visibility. That sounds like it may be related to the business I said was recently reported, about the start-up ground altitude. Maybe, once you really have things working okay, you could kindly tell me exactly how you did it and I can add a write-up to the documentation, to help others? In fact if I knew there was a good way of making it all work correctly I'd have another stab at getting all of the options on the (optional) visibility tab working correctly -- including, in particular, the graduation option which was always very popular in FS9 and before. It seems only the NWI.Vis settings behave oddly. They are being converted into FSX SimConnect "METAR" strings and sent to SimConnect. FSUIPC is only the intermediary here. You could, if you wished, experiment more directly by creating your own METAR string, in FSX's rather extended format, and send them via FSUIPC's offset B000-B7FF. The format is defined in the SimConnect SDK, part of the FSX SDK installed from the FSX Deluxe edition and updatable from the web. You could also use weather logging in FSUIPC or SimConnect logging to see the strings being sent and received (different formats in detail though!0. Regards Pete
pilotjohn Posted November 1, 2011 Author Report Posted November 1, 2011 They are being converted into FSX SimConnect "METAR" strings and sent to SimConnect. FSUIPC is only the intermediary here. You could, if you wished, experiment more directly by creating your own METAR string, in FSX's rather extended format, and send them via FSUIPC's offset B000-B7FF. The format is defined in the SimConnect SDK, part of the FSX SDK installed from the FSX Deluxe edition and updatable from the web. You could also use weather logging in FSUIPC or SimConnect logging to see the strings being sent and received (different formats in detail though!0. Is there no way to specify cloud height and/or tops? I notice the NWI has structure for it (UpperAlt), but logging shows no such data being sent since it's not part of the extended METAR. Also, I turned on logging and noticed that there are constant reads and writes for weather. I turned off all FSUIPC "weather" options and writes stopped (they were writes to nearby stations even though GLOB mode was active) but the reads continue. Is there anyway to tell what might be using FSUIPC to request the reads, or whether it's FSUIPC itself?
Pete Dowson Posted November 1, 2011 Report Posted November 1, 2011 Is there no way to specify cloud height and/or tops? I notice the NWI has structure for it (UpperAlt), but logging shows no such data being sent since it's not part of the extended METAR. There's no way, as you've found. The structure in the NWI was devised for the facilities in FS9, where you could control both heights and top styles. In FSX the height is not even readable either, really annoying when trying to detect whether you are in cloud or not. I think FSX uses some sort of algorithm based on cloud type and base altitude to determine the heights and tops. Also, I turned on logging and noticed that there are constant reads and writes for weather. I turned off all FSUIPC "weather" options and writes stopped (they were writes to nearby stations even though GLOB mode was active) but the reads continue. Is there anyway to tell what might be using FSUIPC to request the reads, or whether it's FSUIPC itself? FSUIPC reads the weather all the time in order to populate the weather offsets. How else could it do it? It reads all sorts of things from FSX all the time. That's it's prime function, to be an information supplier for applications. Pete
pilotjohn Posted November 1, 2011 Author Report Posted November 1, 2011 There's no way, as you've found. The structure in the NWI was devised for the facilities in FS9, where you could control both heights and top styles. In FSX the height is not even readable either, really annoying when trying to detect whether you are in cloud or not. I think FSX uses some sort of algorithm based on cloud type and base altitude to determine the heights and tops. FSUIPC reads the weather all the time in order to populate the weather offsets. How else could it do it? It reads all sorts of things from FSX all the time. That's it's prime function, to be an information supplier for applications. Pete Ok, another question. I'm trying to write to B000 (instead of using the structs) but it's not working for me. I'm setting dynamics 0, global mode, and clearing via NWI, then write "GLOB ..." to 0xB000 via ipc.writeSTR(0xB000, "GLOB ...") but FSUIPC show only this: 5498536 NW_DYNAMICS command, setting weather dynamics = 0 5499457 NW_GLOBAL command, setting weather to global mode 5500377 NW_CLEAR weather command received 5500377 NWI weather clear actioned 5500377 External weather discarded 5500424 Weather Mode now = Theme 5500424 Weather Mode now = Global 5502187 Setting Metar: "" Any ideas? Writing to B000 seems to trigger that "Setting Metar" log message, but regardless of the string I send, it's shown as blank.
Pete Dowson Posted November 1, 2011 Report Posted November 1, 2011 Any ideas? Writing to B000 seems to trigger that "Setting Metar" log message, but regardless of the string I send, it's shown as blank. Show me the string, not part of it. I can't tell what is happening with partial information. Regards Pete
pilotjohn Posted November 1, 2011 Author Report Posted November 1, 2011 Show me the string, not part of it. I can't tell what is happening with partial information. Regards Pete I turned on IPC write logging: ipc.writeSTR(0xB000, "GLOB 011907Z 00000KT&D609NG 100KM&B-1500&D6072 8ST010&ST500FNVN000N 4CU020&CU010FNVN000N 15/05&A0 Q1013") 12860317 WRITElua B000, 104 bytes: 47 4C 4F 42 20 30 31 31 39 30 37 5A 20 30 30 30 GLOB 011907Z 000 12860317 30 30 4B 54 26 44 36 30 39 4E 47 20 31 30 30 4B 00KT&D609NG 100K 12860317 4D 26 42 2D 31 35 30 30 26 44 36 30 37 32 20 38 M&B-1500&D6072 8 12860317 53 54 30 31 30 26 53 54 35 30 30 46 4E 56 4E 30 ST010&ST500FNVN0 12860317 30 30 4E 20 34 43 55 30 32 30 26 43 55 30 31 30 00N 4CU020&CU010 12860317 46 4E 56 4E 30 30 30 4E 20 31 35 2F 30 35 26 41 FNVN000N 15/05&A 12860317 30 20 51 31 30 31 33 00 0 Q1013. 12860317 Setting Metar: "" It logs blank regardless of what I try to write.
Pete Dowson Posted November 1, 2011 Report Posted November 1, 2011 I turned on IPC write logging: Okay, thanks. I'll check it out -- but it will be tomorrow now. Can you just tell me which version of FSUIPC4 it is you are using, or, better, make sure it is the same in version 4.743 as that's where I'm at. Pete
pilotjohn Posted November 1, 2011 Author Report Posted November 1, 2011 Okay, thanks. I'll check it out -- but it will be tomorrow now. Can you just tell me which version of FSUIPC4 it is you are using, or, better, make sure it is the same in version 4.743 as that's where I'm at. Pete Updated to 4.743, but the behavior is the same.
Pete Dowson Posted November 1, 2011 Report Posted November 1, 2011 Updated to 4.743, but the behavior is the same. Yes, and I've found it. It is reading the "read" area before it is copied over, instead of the "write" area as it should. It must have always been that way. Evidently no one has used this facility before! I'll upload 4.744 tomorrow, or maybe even later tonight. [LATER] I've got some other things to do before making a new release, so please get 4.744 using this link: FSUIPC 4.744 Pete
pilotjohn Posted November 2, 2011 Author Report Posted November 2, 2011 Yes, and I've found it. It is reading the "read" area before it is copied over, instead of the "write" area as it should. It must have always been that way. Evidently no one has used this facility before! I'll upload 4.744 tomorrow, or maybe even later tonight. [LATER] I've got some other things to do before making a new release, so please get 4.744 using this link: FSUIPC 4.744 Pete The METAR now updates correctly, thanks! But something broke in this version or somewhere between what I was running last. My throttle updates are incorrect. FSUIPC shows 0 being output at idle, but 0x3330 is updated with 8192 instead of 0 (direct to calibration, NRZ, filtering or not). This happens in both 4.743 and 4.744, but not the original install of 4.70 and certainly not what I was running last, which was 4.731.
Pete Dowson Posted November 2, 2011 Report Posted November 2, 2011 My throttle updates are incorrect. FSUIPC shows 0 being output at idle, but 0x3330 is updated with 8192 instead of 0 (direct to calibration, NRZ, filtering or not). This happens in both 4.743 and 4.744, but not the original install of 4.70 and certainly not what I was running last, which was 4.731. Offsets 3328 and so on were always wrong before (no one cared to report it till very recently), but now they are fixed to work correctly. If you want to use the old broken values you need to change a parameter in the INI. Please see the list of changes included with the 4.743 update. Regards Pete
pilotjohn Posted November 2, 2011 Author Report Posted November 2, 2011 Offsets 3328 and so on were always wrong before (no one cared to report it till very recently), but now they are fixed to work correctly. If you want to use the old broken values you need to change a parameter in the INI. Please see the list of changes included with the 4.743 update. I'm not sure why these were wrong before, they made sense before as they matched up with what the GUI was showing for out, and what you would expect the correlation to be between the raw joystick input and potential output to the simulator. On a joystick with a raw range of -16384 to 16384, direct to calibration and NRZ, it would set this value to 0 when the joystick was -16384, and to 16384 when the joystick was 16384. Now it's setting this value to 8192 when the joystick is is -16384 even though the GUI output is showing the correct value of 0. Mapping -16..16k to 0..16k with NRZ seems like the right move (that seems like "post calibration" to me), but that's not what it's doing anymore.
Pete Dowson Posted November 2, 2011 Report Posted November 2, 2011 I'm not sure why these were wrong before, they made sense before as they matched up with what the GUI was showing for out, and what you would expect the correlation to be between the raw joystick input and potential output to the simulator. They are documented as providing calibrated values -- so, for instance, a forward only throttle input of -16k to +16k should calibrate to a range of 0-16k, as required in the throttle offsets, but there were not. The idea for those offsets is that you could disconnect the throttles using other offsets and copy the values directly from those into the throttle offsets, but you could not do that without making correctins because the range was wrong. On a joystick with a raw range of -16384 to 16384, direct to calibration and NRZ, it would set this value to 0 when the joystick was -16384, and to 16384 when the joystick was 16384. Now it's setting this value to 8192 when the joystick is is -16384 even though the GUI output is showing the correct value of 0. Mapping -16..16k to 0..16k with NRZ seems like the right move (that seems like "post calibration" to me), but that's not what it's doing anymore. Ah, really? I don't think I saw that here! If what you are saying is true then that is wrong. [LATER] Ah ... found it! It works properly for UNCALIBRATED axes, but only for calibrated axes if certain other controls are also calibrated -- it is using the wrong index to access the calibration table! :-( The reason it worked in tests is that i had all the possibly affected axes either calibrated or uncalibrated, because of the amount of testing needed. I should have checked each separately with all the others uncalibrated, but of course there are so many possibly interactions when the wrong index is used that it is difficult to spot that. I've just done such a test and found the bug. It'll be fixed in FSUIPC 4.745 and 3.998g later today, in the Download Links subforum. Regards Pete
pilotjohn Posted November 2, 2011 Author Report Posted November 2, 2011 They are documented as providing calibrated values -- so, for instance, a forward only throttle input of -16k to +16k should calibrate to a range of 0-16k, as required in the throttle offsets, but there were not. The idea for those offsets is that you could disconnect the throttles using other offsets and copy the values directly from those into the throttle offsets, but you could not do that without making correctins because the range was wrong. Yes, that's how I was using it for my reverse throttles, and they were working correctly. Here are the results in -16k..16k, showing the value for those extremes at 0x3330: 1. assigned in FSUIPC direct to calibration, but uncalibrated 0..16384 2. ditto calibrated, not NRZ 6144..16384 3. ditto calibrated, NRZ (but i think this is the case you are using?) 8192..16384 4. assigned in FSUIPC to FS control "AXIS THROTTLE1 SET", but uncalibrated 0..16384 5. ditto , calibrated, not NRZ 6144..16384 6. ditto , calibrated, NRZ 8192..16384 I unchecked Exclude/nSet (otherwise it would nothing) 7. assigned in FSUIPC to FS control "THROTTLE1 SET", but uncalibrated 0..16384 8. ditto , calibrated, not NRZ 6144..16384 9. ditto , calibrated, NRZ 8192..16384 10. assigned in FS, uncalibrated 0..16384 11. ditto , calibrated, not NRZ 6144..16384 12. ditto , calibrated, NRZ 8192..16384 Looks like all the calibrated ones are incorrect. And, as I said before, the Joystick Calbiration GUI "OUT" value shows the correct value, not the incorrect one written to 0x3330.
Pete Dowson Posted November 2, 2011 Report Posted November 2, 2011 Looks like all the calibrated ones are incorrect. And, as I said before, the Joystick Calbiration GUI "OUT" value shows the correct value, not the incorrect one written to 0x3330. Yes, thank you for your testing. I've found it! As you saw, It works properly for uncalibrated axes, but only for calibrated axes if certain other controls are also calibrated -- it is using the wrong index to access the calibration table! :-( The reason it worked in tests here is that i had all the possibly affected axes either calibrated or uncalibrated, because of the amount of testing needed. I should have checked each separately with all the others uncalibrated, but of course there are so many possibly interactions when the wrong index is used that it is difficult to spot that. I've just done such a test and found the bug. It'll be fixed in FSUIPC 4.745 and 3.998g very soon, in the Download Links subforum. I'll making new Installer builds too. Regards Pete
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now