[which offset for turbulence by weather trigger]

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)

[which offset for turbulence by weather trigger]

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

TriggerWeatherData

This element is used to specify a weather setting for a trigger. Weather triggers can be used to create thermals and ridge lifts for gliders and areas of turbulence. This element is not allowed to contain other data and must be terminated with ‘/>’.

<TriggerWeatherData

type="THERMAL"

heading="270.0"

scalar=".70"/>

Attribute Description Acceptable Values

type Type of weather data THERMAL

NONDIRECTIONAL_TURBULENCE

DIRECTIONAL_TURBULENCE

RIDGE_LIFT

heading Heading vector applied to weather data 0.0 to 360.0 floating point value

scalar Scalar value applied to wind speed that is used to generate lift and turbulence. Floating point number between 0.0 and 1.0.

So, I have setup a type=turbulence trigger; I presume that as the trigger comes in action (I.e. the aircraft enters the area and turbulence is generated), some offsets' values must be changing. But I cannot find these related offsets.

I have monitored all offset in the list in OP, but none of them seem to change value entering or leaving the area (please note that turbulence is indeed generated within the area of the trigger as witnessed by aircraft motion and aircraft instruments fluctuation).

I would be obliged if you could point me to the correct offsets.

[which offset for turbulence by weather trigger]

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 ?

[No SimConnect events]

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).

[No SimConnect events]

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?

[threshold coordinates]

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 :???:

[threshold coordinates]

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

[threshold coordinates]

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/)?

[threshold coordinates]

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?

[Previous Flight files]

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.

[Previous Flight files]

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.

[Previous Flight files]

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.

[Previous Flight files]

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)?

[Previous Flight files]

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.

[Previous Flight files]

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.

[Previous Flight files]

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

[ATR IdleGate and Landing data]

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:

1. Save TOD.txt in your Modules folder as TOD.lua.
   
2. Assign a key or joystick button (whatever suits you) to run the script.
   
3. 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.
   
4. 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.
   
5. 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

[ipc.setowndisplay]

thanks Pete

[ipc.setowndisplay]

I'll have a look, but if I can't squeeze it in over the next few days I'm afraid it won't be till late January. If you don't hear from me before the end of next week, remind me after Jan 15th in case I forget (though I wil write it down in any case).

No problem, thanks a lot for taking it over.

PS:

The thread is not closed when there are events being awaited, it is simply suspended awaiting them.

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?

[ipc.setowndisplay]

The "own display" is part of the Lua thread itself and cannot continue to exist when that thread no longer exists.

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

[ipc.setowndisplay]

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)?

[ATR Idle Gate (dual throttle axis modification)]

Hi Chakko,

glad it is ok for you.

Since now is tested, I will later update the original post.

Thanks for testing.

[ATR Idle Gate (dual throttle axis modification)]

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:

1. 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.
   
2. 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

[ATR Idle Gate (dual throttle axis modification)]

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

[Wind components]

The smoothing is acting on the CHANGE in that wind over time and space. i.e. as the aircraft is flying, climbing or descending it is moving through different weather areas and different wind layers. Without smoothing these changes can act rather too fast, and the smoothing smooths those changes, so that one area and layer blends smoothly into the next.

That's clear now.