pilotjohn

No, it's pre configured for the first two engines. If its not showing up in the section of the INI I mentined above tthen it's not in the Modules directory or it's not named .lua. You are not hiding extensions of known files are you, which could cause it to be named .lua.txt when you try to rename it?

In the FSUIPC GUI in FSX enable Lua logging which will create a separate log file for every Lua script. If it then doesn't create one for ThrottleManager (ThrottleManager.log) it didn't start it the script.. ThrottleManager.lua is in you FSX/Modules directory correct (and it is .lua not .lua.txt or .txt)? If ThrottleManager.lua were in there, this section: [LuaFiles] 1=ipcReady 2=linda would list it. That section gets updated with any new Lua scripts placed in Modules, so at least you can check whether FSUIPC sees ThrottleManager. That tells me it's likely that the extension is not correct.

You should turn on Lua logging in FSUIPC (GUI). That will tell you whether the ThrottleManager script is actually loaded and it should log changes in throttle behavior.

Yes, it has to be named .lua, not .lua.txt. You can right-click on it and rename. And in FSUIPC it should be: [auto] 1=Lua ThrottleManager You show "LuaToggle" which is for the Button+Switches assignment. And, yes, N is the engine number (e.g. 1 or 2) Everything after step 1, you do in FSX after a flight is loaded, since all the steps there are based on the FSX and FSUIPC GUIs. FSUIPC is accessed via Add-Ons->FSUIPC menu item. And just for the record, you do need a registered version of FSUIPC.

Correct... and place ThrottleManager and sounds in FSX\Modules. Then if FSUIPC is running you should have an Add-ons->FSUIPC menu entry and set everything else up there.

Found DIView... Apparently the noise is there on both raw and calibrated values. Does anyone know a good replacement source for the Saitek Yoke pots?

Pete, I'm having some issues with a BU0836X... perhaps you have some input on it (I tried to contain Leo several times, but haven't heard back - maybe he's away as well). I bought a BU0836X a few months ago to replace the controller in a Saitek yoke. Everything was working great, but recently I noticed some issues. I observed some noise in the elevator control (Y axis) around the center position. As I move the yoke, there's considerable "jumping" around, which smoothes out at the extremes of the axis. This is visible under the "Control Panel" "Game Controllers" "BU" "Test" tab (the + cursor exhibits this behavior) but it is not apparent during calibration (with the option displaying the raw data). That is, the raw data seems to increase smoothly regardless of axes positions, but after calibration it's "jumpy". It seems odd that the values during calibration do not exhibit any noise (no "jumping" as I smoothly pull or push the yoke through the center) but do in the actual use/test area. So there appears to be raw data coming from the device which in my setup ranges from around "600" to "3600" in both axes, which is then linearly interpolated after calibration to -16k to 16k by Windows. Is this assumption correct? The raw 600-3600 doesn't seem to exhibit the noise (assumed around 2100), but the -16k to 16k does (around 0). Can FSUIPC be setup to use these raw values and have it do it's own scaling/translating or does it only see the Windows calibrated values? Would you happen to know of a way to log these two simultaneously with some application, so that I could graph them and verify the behavior and try to figure what might be causing it? Since the raw values appear fine, it doesn't seem to be a hardware issue, but I have no idea what might cause the noisy behavior in software (it doesn't make sense). Regards, John

I saw that and had the issue, but re-read the documentation which stated 2 bytes, so I didn't complain. :)

Seems to work... thanks!

Ok... so /64 for wind and /72 for cloud. Perhaps these transforms can be added to the offset documentation. Merry Christmas to you too.

I have, and the same issue is present. The aircraft altitude above was on the ground at 66 meters. I don't have a quick NWI Lua to check with, but using WeatherSet2 a similar problem appears. When turbulence is set to Heavy, WeatherSet2 shows 0 for Turb, even though the METARs (Interpolated, AtStation, and GLOB) in the logs show the H turbulence value (weather using GLOB or "" ICAO). Severe appears to show in WeatherSet2 but not the offset. The values for Turb in WeatherSet2 seems to be off by 1 below H (they show up as 0 for None, 2 for Light, 3 for Moderate, 0 for Heavy and 4 for Severe). The offset shows 0 for anything above Moderate. The cloud turbulence offset value does not agree with the the wind values. Moderate cloud shows 216 instead of 192, and light shows 144 instead of 128. It seems there's something quite screwy going on. The progression 128 192 224? 240? would seem to make sense for L M H S, but I'm not sure how 144 216 252? 270? would be used for cloud.

I was trying to determine the values for LGT, MDT, SVR, EXTRM turbulence as read at 0x0E98. I launched at KTTN, and simply changed the turbulence setting on the default wind layer with a 10KT wind. Reading the values at 0x0E98 worked for LGT and MDT (128, 192 respectively) but would return only 0 for SVR and EXTRM, despite all weather readings showing the H and S for the setting. Any suggestions as to why? And what those values are? Can these be relied upon? 1711611 Weather Received (type 4 request, Interpolated): "????&A0 201638Z 35910KT&D609MG 100KM&B0&D4572 CLR 14/04 Q1013 1714794 Weather Received (type 5 request, Nearest): "KTTN&A64 201628Z 35910KT&D609MG 100KM&B-64&D4572 CLR 15/05 Q1013 " 1717961 Weather Received (type 1 request, AtStation): "GLOB&A0 201628Z 35910KT&D609MG 100KM&B0&D4572 CLR 15/05 Q1013 " 1719521 LUA: Cloud Type: 0 1719552 LUA: Cloud Cover: 0 1719583 LUA: Cloud Icing: 0 1719614 LUA: Cloud Turbulence: 0 1719645 LUA: Precipitation Rate: 0 1719677 LUA: Precipitation Type: 0 1719708 LUA: Wind Speed: 10+0 1719755 LUA: Wind Direction: 358.40148925781+0 1719786 LUA: Wind Turbulence: 192 747650 Weather Received (type 5 request, Nearest): "KTTN&A64 201628Z 35910KT&D609HG 100KM&B-64&D4572 CLR 15/05 Q1013 " 750988 Weather Received (type 1 request, AtStation): "GLOB&A0 201628Z 35910KT&D609HG 100KM&B0&D4572 CLR 15/05 Q1013 " 763172 Weather Received (type 4 request, Interpolated): "????&A0 201632Z 35910KT&D609HG 100KM&B0&D4572 CLR 14/04 Q1013 " 763562 LUA: Cloud Type: 0 763593 LUA: Cloud Cover: 0 763624 LUA: Cloud Icing: 0 763656 LUA: Cloud Turbulence: 0 763687 LUA: Precipitation Rate: 0 763718 LUA: Precipitation Type: 0 763749 LUA: Wind Speed: 10+0 763796 LUA: Wind Direction: 359.00024414063+0 763827 LUA: Wind Turbulence: 0 839113 Weather Received (type 4 request, Interpolated): "????&A0 201633Z 35910KT&D609SG 100KM&B0&D4572 CLR 14/04 Q1013 " 842296 Weather Received (type 5 request, Nearest): "KTTN&A64 201628Z 35910KT&D609SG 100KM&B-64&D4572 CLR 15/05 Q1013 " 845603 Weather Received (type 1 request, AtStation): "GLOB&A0 201628Z 35910KT&D609SG 100KM&B0&D4572 CLR 15/05 Q1013 " 861484 LUA: Cloud Type: 0 861515 LUA: Cloud Cover: 0 861546 LUA: Cloud Icing: 0 861577 LUA: Cloud Turbulence: 0 861609 LUA: Precipitation Rate: 0 861640 LUA: Precipitation Type: 0 861671 LUA: Wind Speed: 10+0 861702 LUA: Wind Direction: 359.00024414063+0 861733 LUA: Wind Turbulence: 0 A similar thing seems to happen for cloud turbulence as well. Also, do the values between cloud and wind supposed to be the same for the same level of turbulence? FSUIPC 4.749f

At least it's in the right area, which is what I'm looking for. I just want to have a record of roughly where I flew in my Flight Critic logs. Perhaps you could add a weather ICAO read to the existing direct offset weather areas (0xE..) that gives you the nearest weather station? That seems more reliable and that's really what I'm interested at recording (location/weather). But it doesn't matter much.

I didn't have it enabled... it works, mostly, as you said.

Is 0x658 still available for use despite it's documented issues? Can I simply use ipc.readSTR on 0x658, 0x66C, ... or do I need to read the individual bytes and concatenate into a string? I haven't been able to get any ICAO IDs yet, despite trying to read in all sorts of flight phases and areas.

Yes... <FSX>\Modules. Then open both FSUIPC.ini and ThrottleManager.lua in Notepad and follow the instruction in ThrottleManager.

Updates... Better landing/takeoff detection on large/long bounces Pseudo Gaussian distribution of scores (50% = average) Perception weighted scoring (worst part of a score gets the most weight) Category deductions shown for each score New sample output: Analyzing... 15394 records. In Flight: 00:25:19, 65.7nm, 156kts Takeoff/Rotation Ground Roll: 00:00:12, 1110ft, 103kias To 35 Feet: 00:00:14, 1544ft, 114kias To 50 Feet: 00:00:15, 1643ft, 116kias Comfort: 78% (R:-0%, S:-3%, X:-1%, Y:-5%, Z:-13%) Skill: 87% (H:-0%, T:-1%, S:-12%) Climb/Enroute/Descent Min./Max. IAS: 100kias, 170kias Min./Max. TAS: 104ktas, 189ktas Min./Max. GS: 104kts, 204kts Min./Max. VS: -1226fpm, +2013fpm Min./Max. Altitude: 1792ft, 8246ft Comfort: 94% (S:-4%, X:-0%, Y:-1%, Z:-0%) Approach Path Angle/IAS/VS: 4.0deg, 99kias, -639fpm Comfort: 96% (S:-3%, X:-0%, Y:-0%, Z:-0%) Skill: 87% (I:-1%, V:-9%, T:-2%, S:-1%) Landing/Flare From 50 Feet: 00:00:25, 2717ft, 93kias From 35 Feet: 00:00:23, 2414ft, 92kias Ground Roll: 00:00:13, 1040ft, 72kias, -94fpm Comfort: 85% (R:-0%, S:-2%, X:-0%, Y:-3%, Z:-10%) Skill: 85% (V:-12%, H:-0%, T:-1%, S:-3%) R:Runway, S:Skid, X/Y/Z:Acceleration, H:Heading, T:Track, I:IAS, V:VS FlightCritic.txt

I posted my Flight Critic script in the User Contribution area, here: http://forum.simflig...gradingscoring/

EDIT: Update version attached. See changes in the post below. Attached is a script that will automatically record and analyze your flight, providing statistics like takeoff and landing distances, and provide a comfort and skill grade/score for different phases of flight (think of comfort as how the passengers feel, and skill how the check airmen - or DPE - will rate you). It correctly identifies takeoffs and landing points on rough terrain or bounces (event multiple bounces). The raw data is saved and can be fed through the script via the command line for re-analysis. The final output is also saved as a text file. Here's a sample analysis: Analyzing... 5059 records. In Flight: 00:08:25, 16.6nm, 118kts Takeoff/Rotation Ground Roll: 00:00:20, 1543ft, 91kias To 35 Feet: 00:00:23, 2044ft, 94kias To 50 Feet: 00:00:24, 2135ft, 94kias Comfort: 85% Skill: 82% Climb/Enroute/Descent Min./Max. IAS: 94kias, 189kias Min./Max. TAS: 91ktas, 187ktas Min./Max. GS: 90kts, 179kts Min./Max. VS: -672fpm, +1586fpm Min./Max. Altitude: 94ft, 2147ft Comfort: 95% Approach Path Angle: 3.4deg Comfort: 97% Skill: 94% Landing/Flare From 50 Feet: 00:00:25, 2340ft, 96kias From 35 Feet: 00:00:24, 2124ft, 94kias Ground Roll: 00:00:17, 1148ft, 76kias Comfort: 88% Skill: 75% Rename the attached file to .lua and read the instructions at the top of the file. FlightCritic.txt

I should be able to post my script by the end of this weekend. Here's a sample output from it: Analyzing... 9427 records. Flight: 00:15:42, 41.0nm Takeoff/Rotation Ground Roll: 00:00:25, 2154ft, 120kias To 35 Feet: 00:00:27, 2526ft, 127kias To 50 Feet: 00:00:28, 2583ft, 127kias Comfort: 88% Skill: 86% Climb/Enroute/Descent Min./Max. IAS: 96kias, 215kias Min./Max. TAS: 86ktas, 208ktas Min./Max. GS: 75kts, 215kts Min./Max. VS: -2543fpm, +5577fpm Min./Max. Altitude: 172ft, 3939ft Comfort: 96% Approach Path Angle: 3.2deg Comfort: 98% Skill: 91% Landing/Flare From 50 Feet: 00:00:24, 2940ft, 114kias From 35 Feet: 00:00:23, 2790ft, 114kias Ground Roll: 00:00:10, 753ft, 95kias Comfort: 83% Skill: 76%

Ok... what happens when you ask for a very small area, like 0.5NMx0.5NM; is there granularity to that level?. Does it take into account the altitudes you ask for; that is, is there a difference if you ask for surface to 1000MSL (and there are no clouds there) vs, 3000-6000 where there are clouds?

Thanks... 32x32 is fine averaged.

Well, if you feel like trying it out, a 32x32 (either center subset, or averaged) array would seem like a good compromise. I think looking only forward is logical if I'm implementing a weather radar, but I'm looking more to try to use it as a predictor for failures and might want to look at where the aircraft came from, in which case forward-only wouldn't work. If you have the time, and want to hack at it, I'll play with the result.

How about reading it in two chunks with two consecutive reads? 1st 2k, 2nd 2k, or with something specified in the NWI struct. Anyway, no biggie. It'll likely not do what I expect it anyway. It was probably just going to be an experiment in futility.

I have no interest in writing full-fledged apps for FSX. If MS Flight offers similar capabilities I definitely have many plans for it, but no desire to venture into FSX/ESP/Prepar3D world right now. FSUIPC offered a quick and easy scripting platform. Since it seemed to be providing nearly everything that SimConnect provides, I thought this would simply complete the circle. The existing weather facilities/space could have been re-used for it. (e.g. write with a new uCommand and use some of the spares, and read the entire array from the METAR read/write string area which is 4k).