abax2000

Thermals are mentioned in SimConnect, as in SimConnect_WeatherCreateThermal and SimConnect_WeatherRemoveThermal as turbulence is also (as you rightly say) both in winds extension and cloud extension (as in SimConnect_WeatherSetObservation). Anyhow, I was expecting that the results of a turbulence weather trigger would be manifested in some offsets, and most probably in 0e98, 0e88, cd04, ce88. But this not the case, and it seems very strange. Please note that "heading---> Heading vector applied to weather data---> 0.0 to 360.0 floating point value" refers to the wind heading that will permit the turbulence effect (i.e. turbulence is induced when ambient wind is coming from this heading - if the wind heading deviates the turbulence gets smaller and at wind heading +-90degrees it gets zero - but all this is not documented and this is exactly what I am trying to verify through experiment). I will try to monitor the winds also (although I think that turbulence does not manifest in wind offsets)

Just to avoid naming problems, see in FSX SDK: BGL Compiler SDK\Compiling BGL\Scenery Objects\TriggerWeatherData.

I try to monitor the results of a weather trigger I have setup (nondirectional turbulence). As the turbulence induced by the trigger should update some offsets, I use FS-Interrogate to monitor various offset values while flying; but it seems that I cannot locate any offset that gets updated when entering the trigger area (the turbulence itself is working when entering the area, but no sign of it to any offset). I have watched the following offsets with no luck: C904 CA88 0E98 0EF4 0F76 0F08 0F8A CD04 CE88 0EFA 0F6C 0F02 0F84 C104 C288 0E88 Is there any idea which offset should show the turbulence generated by a weather trigger ?

Thanks Pete for advise. For the time I suspect a beta version of AS2012 I am using (provided by HiFi trying to troubleshoot some weather problems). So, I'll first look there, as it seems to happen periodically (as in weather updates).

After a flight, The FSUIPC4.log has entries like 2318799 **** No SimConnect events or states being received! Re-connecting now ... **** 2318924 SimConnect_Open succeeded: waiting to check version okay 2319704 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0) 2319704 Initialising SimConnect data requests now 2319704 FSUIPC Menu entry added 2321295 C:\Users\Lounge\AppData\Roaming\Microsoft\FSX\Previous flight.FLT 2321295 C:\Users\Lounge\Documents\Flight Simulator X Files\EFB_current_garmin.PLN 2321311 C:\Users\Lounge\Documents\Flight Simulator X Files\EFB_current_garmin.PLN 2322013 System time = 29/05/2013 15:05:31, Simulator time = 15:01:06 (13:01Z) Last time I found 4 instances of this set (with different times of course). The flight concluded successfully. Is it something normal (I can't remember if I have seen it before) or is it something going wrong?

Thanks a lot Pete for advising. I'll dig into it and hope for the best. In the meantime, I'll keep my day job :???:

Copy the tips on the files. If you have any advise for reading material regarding file handling with Lua (more elaborate than the manual) please advise (sorry that I reiterate this, but I know almost nothing about programming, so I would need some kind of "human readable" material). vbr

Pete, thanx for the input. I was afraid that MakeRunways files would be the only option. I'll get around the maths, but I am at a loss as for which MakeRunways index file to use, and more importantly on file handling with Lua. Could you point to the right direction? For example, the relevant reading for file handling would be paragraph 5.7 in Lua Manual (http://www.lua.org/manual/5.1/)?

I would really appreciate some help on the following: What would be a way of getting the coordinates of the threshold of the runway you are on? If there is no direct way (via offsets etc), but MakeRunways must be used, how this could be exploited using a Lua script?

hmm..I usually monitor things via Process Explorer and I am nowhere near a OOM (all my flights for the last week were in a "light" environment and a "light-medium" aircraft). Anyhow I'll keep using ASE (with all other parameters same) to see what happens to ctd's.

This is not a OOM; message is different and Event viewer logging also. Each type of ctd can easily be identified; the problem is to get over it ,lol. As for 64bit,of course you are right, but it will have to wait for the next computer.

Pete thnx again for input (even for a non-FSUIPC issue). Default's flight wx file is deleted for some days now. I also do not load saved flights, but every time begin from scratch. Despite all this, I still experience the crash. In the meantime, I opened a ticket in HiFi attaching some of their log files. I'll try again with ASE (instead of AS2012) to verify if ASE is crash-free.

I replaced wxstatiolist.bin as advised but unfortunately still experienced a weather.dll ctd. I suppose that would leave corrupted wx files to be blamed, and that would mean something is wrong with my AS2012 (this what I used and not FSX real weather)?

Pete, thnx for helping out. I had already deleted the default flight .wx (got the tip from an old post, but still lots of ctd's. I never load flights; just start from scratch. I will try to replace the Users\user\AppData\Roaming\Microsoft\FSX\wxstationlist.bin with the original in Program Files\Microsoft Games\Microsoft Flight Simulator X\Weather\wxstationlist.bin. I'll report back by tomorrow. PS. if wxstatiolist.bin is the culprit (so it randomly produces ctd's), I guess that I will have to wait several flights after changing it to be sure that the problem is solved.

I just tested "end flight" and then "exit" (I guess this is "close the sim down properly"), but no "Previous Files" were generated. Anyhow, the underlying reason I am asking is: some days ago I updated to AS2012 sp2 and FSUIPC 4.869. After that, I experienced a series of ctd's attributed to weather.dll (and one to util.dll). I think that these ctd's do happen when these "Previous Flight" files are present; if there are not there (by manual deletion or because they were not generated) the ctd do not happen. I also think that when ASE is in use, ctd's do not happen. Any help on that would be great.

I (sometime) find in Documents\Flight Simulator X Files three Previous Flight files (.flt, .fssave and .wx). In the .flt one is stated that is created by FSUIPC, although I have AutoSave unchecked. Is this possible? The setup is FSX sp2, W7 32b, FSUIPC 4.869

TOD plugin (TakeOff Distance)TOD captures data during take-off. Works with any aircraft (not tested with floats).Among other things, it records take-off distance, pitch rate, IAS at rotate etc (see attached Appendix.doc for all details).As with the other scripts, it logs all of the captured data (and more) in FSUIPC.log, for post flight debriefing (but before your next flight).Note: Save TOD.txt in your Modules folder as TOD.lua. Assign a key or joystick button (whatever suits you) to run the script. It must be activated (press the assigned button or key) when stopped at take-off position. If for any reason the aircraft changed position or simply the button was pressed at the wrong moment, just press again when ready. When activated, a popup window comes up for the user to enter the "Obstacle Clearence Altitude"; just enter the appropriate number (in ft) and press "enter". This is just optional (intended for departures with certain gradient requirements up to specific altitude). If not needed, do not enter anything and just press enter. When above 1500AGL or "Obstacle Clearence Altitude"-200 (if used), the window seen above will popup and remain in view for 5 minutes. If desired, it can be closed at any time by right-click as usual. TOD_Appendix.doc TOD.txt

thanks Pete

No problem, thanks a lot for taking it over. PS: By that , I understand that if all events in a thread have been cancelled (and even if ipc.exit is not used) the thread is "closed". Is this so?

Just to clarify that the "own display" goes away with no ipc.exit issued; nevertheless, the script is "idle" (nothing more to do, and the events cancelled.) The solution you propose seems that it would serve the purpose just fine, if I understand correctly (monitor this new event (as done for event.offset), and when it takes place just issue in the code an ipc.exit (or whatever) - or something along the lines). If it can be "easily" implemented, please do. vbr

It seems that lua windows set with ipc.setowndisplay, stay on screen for the time that the lua script is iterating; after that the window goes. The only way to keep the window on screen is a ipc.sleep command just after ipc.linedisplay. On the contrary, communal lua windows (set by ipc.setdisplay etc) stay on indefinitely (until closed manually by the user or the script reset). Is there any way to keep the windows created by ipc.setowndisplay visible indefinetely, until the user closes them (right click)?

Hi Chakko, glad it is ok for you. Since now is tested, I will later update the original post. Thanks for testing.

ckovoor, please try the attached script. It must be working ok. I took into account all Pete's comments and recommendations (it is practically the same code he proposed in the first place). After a "quick and dirty" test, please take note of the following: disable the script, and using FSUIPC on-screen Logging facility, monitor offsets 3330 and 3332 (both type S16). Make sure that when both 'Power Levers' are at 'Flight Idle' mark, the reading is 3200 and the Torque (in aircraft gauge) is appr. 14%. If not, make a note of the reading when your 'Power Levers' are exactly at 'Flight Idle' mark and Torque at 14%. Use this figure to replace "3200" wherever it appears in the script. While the Flight Idle setting above gives more realistic readings, better spoolup and better flare, there is one caveat. If you do a hi-speed approach (e.g. descending on ILS and decelarating using the "Decelaration Height=IASx10ft" rule) you will probably not decelarate on time. In order to overcome this, you have to assign in your FSUIPC GUI, a "LUA value". To do this: locate a suitable switch in your joystick (best choice would be a spring loaded, toggle switch) Go to "Buttons/Switches", check "Profile Specific", "Select for FS control" and select the switch you decided to use at its up position. At "Control Sent when button pressed", select "LuaValue ATR_Idle_Gate", with "Parameter"=3200 (or whatever the number you came up with in point 1) Repeat above two steps for your switch at down position, with "Parameter"=1 So now, before starting a hi-speed approach descent, just move your switch to the down position (in which you assigned "Parameter"=1). In this manner, you are using a lower Flight Idle, that will permit deceleration as predicated by the "Decelaration Height=IASx10ft" rule. Still, just before threshold height, Flight Idle will revert to the higher value (without your intervention) and will help in flare. Simulating turboprops in FSX has known weaknesses, and ATR is no exception. It seems that Flight1 could not find a way to have all things right at the same time. Newer turboprop models probably found better workarounds. Note: After making sure that the script works for you, if you decide that you don't care about the double "Flight Idle" setting and the complexity, we can easily modify the script. Please notify on your progress. ATR_Idle_Gate_v_3.txt

Hi to all, I am the author of this script. I attach the most recent version of it. You better start working from there. I cannot readily check Pete's feedback, but the script is working just fine without any abnormalities recorded in FSUIPC.log. So, maybe its suboptimal but works fine. I am really sorry that I cannot provide any substantial help on the spot, but it has been some time since this was written, and I am far from fluent in programming. I would need some time in the weekend to "reverse-engineer" my own script and dig into FSUIPC offsets. I will also check some related detail regarding ATR handling (this is surely somewhere in my notes) and get back soon. Regards ATR_Idle_Gate_v_2.txt

That's clear now.