abax2000

You at least have to give the courtesy of understanding that in an erratic communication both parties can have a share of responsibility. Rest assured that I read very carefully what has been written.. If you see that I didn't undesrtand something, you can just explain. Variance (as shown in files attached and send) maxed at 300. This I really don't understand and need some explaining. What is "stable conditions"? why would you need smoothing in stable conditions? What I thought, is that "wind smoothing" limits any kind of direction variance, regardless of source (FSX or AS). I've bothered enough to send a quite detailed file with all this info attached to #5, which unfortunately seems that was out of specs.

What I am saying is that, although "wind smoothing is enabled and set at a value of "2", I have seen: wind direction shifts of 60-90degrees per second (as displayed by "shiftZ" lines) the aircraft (default Cessna) was constantly heading left to right That has happened under the special circumstances documented in previous posts. With "wind smoothing = 2" I would expect that wind direction shifts would not exceed 2degrees/second (on or about), what is what actually happens under normal conditions, regardless of what AS is injecting or FSX is trying to do by itself. I again underline that the normal/usual operation of "wind smoothing" is perfectly fine. What I described above is a rare occurrence (under specific conditions), which I cannot explain. I do understand (thanks to FSUIPC manual) that when FSUIPC "wind smoothing" is enabled, all turbulence, variance and gusts are manipulated by FSUIPC; that is with "wind smoothing" enabled you will get somewhat different results for these attributes compared to std FSX. And that is perfectly fine with me (and a lot of other users). I sent FLT and WX files zipped as requested.

I understand that ActiveSky is setting the parameters, so I am taking the inquiry with them. The changes in direction are ultra rapid, so the FSUIPC-related question is, if "wind smoothing" set in FSUIPC should prevent changes larger than the setting (Smooth wind changes near aircraft with changes limited to this many knots or degrees per second = 2) (see attached the Winds page).

There was no turbulence set, only Variance (see that attached doc with WeatherSet screenshots) Yes, DWC in use (forgot to mention that). No problem at all; I didn't even expect a reply on a Sunday! .kmz is a Google Earth file. Just doubleclick it and, if you have GoogleEarth installed, you will see the flight test path. I have depicted the whole test flight there, so you can see the exact geography, distances etc., along with the exact locations where the WeatherSet screensots were taken. Please see the attached doc file for all other parameters (METAR and how to get it from AS2012 etc). Location is LGAV rwy03R. Fly the runway heading for appr.9nm, then reverse and align rwy21L (same runway opposite direction). Continue appr 11nm after airport and reverse heading back to rwy03R. Sorry for any inconvenience.

I didn't realize I was on unknown territory. I edited a little my previous post to be sure that is clear. Perfectly clear, thanks for explaining. Let's say that hex calculus is not my strong point :oops: But with your input I figured it out :idea: All data from 0658 is accessible and readable. Thanks for pointing me to WeatherSet, made my life much easier (another fabulous tool). I see an unexpected wild reported variance. Please see attached files: the .doc has WeatherSet screenshots and some brief comments, the .kmz file has the flight path and the locations of each WeatherSet screenshot. Wherever you see extreme Variances reported in WeatherSet, the in-sim winds are all over the place. I was under the impression that FSUIPC smoothing would work even if internal FSX interpolation or external weather injection result in wild fluctuation. PS: I just realized that I cannot attach the .kmz file. I am sending this with email. Very best regards weathersetLGAV.doc

Hi Pete and thanks for helping out. It is FSX sp2 and FSUIPC 4.853 licensed. I didn't use offsets 2DC8, 2DD0 and 2DD8 in the first place because I didn't spot them (I was looking with other keywords). I did further tests and my take so far is as follows: Wind components Offsets 3470,3478 and 3480 seem to work. This goes for 3518 also, that gets updated instantly (no lag). These offsets give the wind components at the aircraft relative to a XYZ system bound to earth. The figures in these offsets interpret as: 3470 (positive values +) -> west wind component 3470 (negative values -) -> east wind component 3480 (positive values +) -> south wind component 3480 (negative values -) -> north wind component 3478 (positive values +) -> updraft 3478 (negative values -) -> downdraft Offsets 2DC8, 2DD0 and 2DD8 give wind components at the aircraft relative to a XYZ system bound to aircraft (so XYZ in this case are the pitch, roll and yaw axis of the airplane). The figures, relative to pilot's view) interpret as: 2DC8 (positive values =) -> right crosswind component (total wind component parallel to pitch axis, coming from the right wingtip) 2DC8 (negative values -) -> left crosswind component (total wind component parallel to pitch axis, coming from the left wingtip) 2DD8 (positive values =) -> headwind component (total wind component parallel to roll axis, coming from the aircraft nose) 2DD8 (negative values -) -> tailwind component (total wind component parallel to roll axis, coming from the aircraft tail) 2DD0 (positive values +) -> total wind component pushing vertical against the aircraft's upper wind surface (this includes up/downdrafts and winds parallel to earth) 2DD0 (negative values -) -> total wind component pushing vertical against the aircraft's down wind surface (this includes up/downdrafts and winds parallel to earth) So, these values depend on the pitch attitude and bank angle. For my purposes, and since/if these offsets work reliably, I have all I need: crosswinds from 2DC8, head/tailwind from 2DD8 (not exactly but close enough in level flight), up/downdraft from 3478/3518. up/downdrafts, thermals, turbulence and windshear simulation I thought that these are indeed simulated (successfully or not is another discussion). I imagine that a turbulence is nothing more than an oscillating vertical component, isn't that true? What would be interesting is what is the area that this simulation covers (by FSUIPC or AS for that matter). "nearest airport" offset 0658 Found it, but I would need some help on how to read it. In FSUIPC monitoring only ICAO is readable. What would be a proper Lua syntax (e.g. ipc.readxxxx) to read all the parts of this offset? I am particularly interested in airport elevation. wind smoothing going through these tests, I encountered again an issue I forget to ask you about for a long time: although wind smoothing is enabled in FSUIPC (2sec per knot or degree), it rarely happens that I get wild fluctuations in wind direction (most of the times, and not speed). This happens always at low altitude, this time was 1500ft, and it is consistently reproducable with the same METAR. In all other cases (in upper altitudes etc) smoothing is always working (you can actually tell when FSUIPC dampening is taking place). Any hints on this? Thanks a lot (again) for your help

Wind components I try to read vertical wind speed component using offsets 3478, 3518, but they are constantly zero (although ActiveSky injects up/downdrafts and thermals at the same time). (It also looks like 3470 and 3480 have strange readings (not as expected), but this not my immediate concern.) Which offset can give what I am looking for? Note: I am assuming that up/downdrafts, thermals, turbulence and windshear are simulated within FSX with a vertical wind component. Is this assumption true? Airport elevation Is there anyway to get the airport elevation of the airport that the aircraft is approaching (i.e. the nearest airport)?

The post by abax2000 is replying to the original post by EasyEE, just because I (abax2000) use the same a/c and I have done with FSUIPC what EasyEE is asking for.

Here is what I have done: 1. create controls through mouse macro functionality for 100%ovrd, Auto, feather (rght click). Doing so, you create a .MCRO file. Here is mine ATR.MCRO (only lines 8,9,10 are relevant to your question): [Macros] Module="F1ATRB.DLL" 1=notch=RX17970*X55cc,31 2=pwrmgt=RXe530*Xf7cc,31 3=pwrmgtLEFT=RXe530*Xf7cc 4=hold=RXc170*X6acc 5=AP=RX8110*Xa100 6=YD=RX8160*Xa1cc 7=TOGA=RX17e40*Xa1cc 8=100%ovrd=RX17e20*X56cc,31 9=conditionAuto=RX17e00*X56cc,31 10=Feather=RX17de0*X56cc,31 Note that I have not created a control for Fuel S.O. You may add this if you wish to. 2. In FSUIPC axis tab, assign an axis to "condition levers" and take advantage of the range facility, i.e. assign the above created controls to specific ranges of this axis. Here is the relevant part of my FSUIPC4.ini (lines 1,2,3,4 are relevent to your question): [Axes.ATR] 0=BR,256,D,36,0,0,0 1=BU,256 2=BU,B,-16384,-4811,M1:8,0 3=BU,B,-4811,2560,M1:9,0 4=BU,B,2432,16383,M1:10,0 Hope this helps a bit.

LandingSnitch captures data from 500ft till touchdown (and bounce if any!), including of course the vertical speed at touchdown. It works with aircraft with retractable gear only. The script auto-calibrates depending to aircraft weight. It is also displaying the correct power readings depending on engine type (manifold pressure for piston, torque for turboprop, N1 for jets). The script also logs most of the captured data in FSUIPC.log, for post flight debriefing (but before your next flight). NEW!! Actual Landing Distance and Ground Roll measurement When the aircraft slows down below 40kts, a semitransparent window pops up at the left of your screen, with all the details. The atttached Word file ("LandingAppendix.doc") explains the contents of the popup window. Note: Save LandingSnitch in your Modules folder as LandingSnitch.lua. Add in your FSUIPC.ini this [Auto] 1=Lua LandingSnitch LandingAppendix.doc LandingSnitchv3.txt

thnx for clarifying cheers

All files are for FSX and you need a registered version of FSUIPC. The "ATR_Idle_Gate" Lua script makes Idle Gate of F1's ATR72 operational, so while airborne PLs go down to FI and not GI. This also improves landing performance (i.e. more effective flare and softer touchdowns). "ATR_Idle_Gate_v_2" is for single throttle joystick axis, while "ATR_Idle_Gate_v_3" is for double throttle. The critical value in the script is "3200" (wherever it appears). disable the script, and using FSUIPC on-screen Logging facility, monitor offsets 332E (single throttle) or 3330 and 3332 (double throttle) (all 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. Many thanks to Pete for his advice in coding and to Chakko for testing the "double throttle" version. The other file, "LandingSnitch" can really be used with any aircraft, as long it has retractable gear. It logs and displays various data at final approach till touchdown point (see details in next post). So you can monitor your landing skills through a detailed profile from 500ft height to the threshold through flare and touchdown. Keep on going for the perfect landing (and capture it in a screenshot) ! Both Lua's can be set to run with any of the ways that FSUIPC offers. I think Auto is best, using the [Auto} line in the FSUIPC.ini. ATR_Idle_Gate_v_2.txt ATR_Idle_Gate_v_3.txt

Following your guidance, everything is set and working fine. Just two points for my better understanding: when throttle joystick axis is reconnected to controls (so 310A is reset to 0) it seems that 088C and 0924 (twin engine) are "stuck" to the last written value and do not immediately get the current value from joystick axis (and equal 322E). That is in the case the joystick axis is perfectly stationary at any position. A slight "nudge" gets things back to normal. So, best is just after 310A=0, write the content of 322E to 088C and 0924 and let them roll. Is this expected ? 089A and the like offsets for other engines are always at 0 value (as displayed by monitoring). For which use are they for exactly (I have been through the Offset doc, but I expected them to be updated as 088C et al) ? vbr

Thanks a lot for clarifying and for guidance on using proper offsets (saved me a lot of time). Yes, you have understood precisely what I would like to do. PL=Power Levers "full stop" read "throttle back stop" (idle) Latest FSUIPC (4.745) already installed ... ooops, I am going for the 4.746.

Crystal clear. Besides learning what is what, I also realised that this will not do the trick I am after. What I am trying to do is: while airborne when PL go lower than a certain point and until full stop >>> keep Flight Idle (the Ground Idle is at throttle back stop). That would be for F1 ATR. 1. As far as I understand, this could be done EITHER: a. through Axis Assignment and setting 3 ranges (using the Key_Throttle_Set control with a parameter suitable for FI for the middle one), OR b. through Lua sript. 2. A macro would not be an option for this purpose. I would prefer 1b a. so I don't have to deassign throttle from FSX, and assign it for each one profile in FSUIPC. b. range setting can be a little awkward for that use. Anyhow, could you please confirm that above points 1,2 are valid so I can start working in the right direction? Thanks again for your support.

I see in ESP docs that there is a "Throttle Lower Limit" control (Aircraft Engine Data, Simulation Variables). I can't find something like that in the "List of FSX controls" or in dropdown selection boxes of FSUIPC. Does it come with a different name?

ok, thnx again Pete. vbr

I did a lot of reading in documentation and forum, but finally could not be 100% sure, so I ask the question. Assuming that: there are profiles defined (e.g. LightGA, Turboprops, LightBoeing, HeavyBoeing) and aircrafts are assigned to them for these profiles, only some of the four available sections are defined (e.g. only Buttons and Keys, but no Axes and Calibration sections) then aircrafts assigned to these profiles will follow the generic part for the other sections, that have not been defined as profile-specific (e.g. whatever is defined in the generic [JoystickCalibration]) or not (i.e. revert to whatever is defined in FSX) ?

Your comments were a real eye opener for me and thank you for that. Most important: I was under the false impression that LuaSet, Clear and Toggle can also start a plugin. This misunderstanding was the cause of the whole frustration about starting the plugin. Just realised that starting a plugin is a different thing from triggering a function in it via events. Everything clear for me now on this front. I was just thinking that monitoring a control that changes values continuously (and not just between two values like 0366 two times per flight) would keep calling the function continuously, and thus add an unwanted load to the system. I now understand from your input that this load is not noticeable, so we press on. I did that but I was overwhelmed. I would need hard studying of a month to get me going, considering that my only hands on experience in programming was some 30 years ago in Fortran (no comments please) and a little of VisualBasic 20 years ago for office use. All other points taken and understood. Pls note that 'FSUIPC Lua Library' refers to 32 flags at ipc.testbuttonflag, ipc.testflag, and event.flag descriptions. All other flag references of the documentation correctly state 256 flags per plugin. Thank again for clarifying all for me. Hope you had a great weekend.

Yes, just that. I monitor radio altitude to drop to 52 or less so I can record IAS. I used a flag just because it was the only thing I could think to trigger the code at a user-defined moment (e.g. at short final), and avoid having the loop going on for the whole flight. The sleep(50) is just there to "lighten up" things a bit, still giving an acceptable accuracy of appr 0.6ft. In fact, I do not know how a conditional event.offset can be used (e.g. in plain english "trigger the routine when radio alt drops below 52ft"). Certainly this would be a much more straightforward and simple solution. Could you pls give an example? As for the flag event: I tried to trigger the [event.flag(0,"recordvref")] via LuaSet (parameter 0) or LuaToggle (parameter 0). For some reason, both didn't work for me. It must be something I don't understand about flags and the syntax of the flag events in Lua code. Since I failed to use LuaSet or LuaToggle, I assigned to a key Lua (when pressed) and LuaSet-parameter0 (when released). Doing so I managed to get it going. To be more specific on what I am not sure of or do not understand clearly: I guess LuaSet sets the named flag to TRUE, LuaClear to FALSE and LuaToggle just toggles the two values. Available flags per .lua are 256 (0-255). Each flag can be either true or false (1 or 0). What is exactly the purpose and the result of the red line in .lua code (pls see edited initial post)? Why the syntax in the green line of the .lua code islike this and not {function recordvref(0)} (pls see edited initial post)? note: I used red and green lines following the example Baro in "Lua Plugins for VRInsight Devices". That does not mean that I fully understand their purpose. vbr

Bingo. I tried different sequences of the statements, but never thought the delay issue. As for documenting it, just my two cents ...having in mind novice/inexperienced users like myself: It is minor glitch because of synch issues between Lua code and FSX Always put 'getdisplay' and 'setdisplay' statements after a 'display' command. You will most probably need to add a time delay (ipc.sleep) between 'display' and ('getdisplay' or 'setdisplay'). Something more or equal to 20 millisecs is recommended. That is because 'display' goes through FSX, so there is a relative delay compared to Lua execution; so you need to give time to ('getdisplay' or 'setdisplay') to have something to read/edit (e.g. with no delay used, 'getdisplay' will return 0 values, as the window is not yet there to be measured) The first two figures returned by 'getdisplay' refer to xxx point of the Lua window, while the latter two to the size of the window (all in screen pixels). If you still have problems, reposition and resize the default Lua window manually and rerun the Lua code containing the 'getdisplay' and/or 'setdisplay' commands. I don't know if it is too many words, but I think is understandable by the non-programmer/occasional user. vbr

At the bottom of this post there is a short Lua script that records some basic figures at landing (Vthreshold, VS and IAS at touchdown). Being not even remotely a programmer, the code is more of a patchwork out of the "example Lua pugins" doc. FSUIPC great documentation allows even to cavemen like me to enhance their FS experience. I would welcome some comments/tips on the two following points: There is a "while do" loop used to capture Vthreshold. Is there any other way that slips me to do so avoiding loops and the possible resource penalty? The flag event used [event.flag(0, "recordvref")], cannot be triggered via LuaSet or LuaToggle, as I would expect (Lua and LuaSet on the same keystroke is used to trigger the event). Wouldn't LuaSet or LuaToggle be enough on their one to trigger it? -- must assign "Lua Landing" and "LuaSet Landing" (with parameter 0) ipc.setflag(0) --if ipc.testflag(0) then -- ipc.log("FlagVref Set") --else -- ipc.log("FlagVref Not Set") --end function recordvref(n) while ipc.testflag(0) do --if ipc.testflag(0) then -- ipc.log("Flag2Set") --else -- ipc.log("Flag2NotSet") --end ralt = ipc.readUD(0x31E4)*3.28084/65536 if ralt<=52 then vrefias = ipc.readSD(0x02BC) / 128 ipc.log("Vref = " .. vrefias.." at thr "..ralt) ipc.lineDisplay("Vref = " .. vrefias.." at ft "..ralt, 1) ipc.setdisplay(100, 250, 220, 150) ipc.toggleflag(0) end ipc.sleep(50) end end function logvs(off, val) if val ~= 0 then -- if on ground flag just set, get VS, convert it and log it vs = ipc.readSD(0x030C) * 60 * 3.28084 / 256 ipc.log("Vertical speed at touchdown = " .. vs) tdias = ipc.readSD(0x02BC) / 128 ipc.log("IAS at touchdown = " .. tdias) ipc.lineDisplay("VS at td = "..vs.."\nIAS at td ="..tdias, 2) end end recordvref(0) event.flag(0, "recordvref") -- set to call above routine whenever "on ground" flag changes event.offset(0x0366, "UW", "logvs")

So it seems. I made one run where the window poped up in the middle and I randomly moved+resized by hand, then exited flight. When I retested the window was properly sized and positioned (according to values in .lua). Thanx Pete.

OK, I will certainly survive till then. JFYI, I did a quick test in full screen mode but still unsuccessful (window pops but in default position).

Steps taken: 1. Deleted both lines of Window.Lua display in .ini file. I just left the section header [Window.Lua display]. 2. Fired up FSX. 3. Lua window pops up (as in previous tests), but again in the middle of the windscreen. 4. The .ini file now records: [Window.LUA display] Docked=7413, 3273, 3537, 2435 I run the same test deleting the whole [Window.Lua display] section (including the header) with the same results. The only difference was that the section was added at the end of the .ini file.