MrBitstFlyer

Download here - AutoHaze Lua Script I would really appreciate feedback from Mac or Linux users as I do not use those OS's.

The quality of the ortho may have been set low on purpose to focus on the autogen.

Left home at 5am and got home at 8pm - not that worrying😁 To be more accurate as far as Dryden is concerned - Dryden shaped gust core with XP12 specific response shaping. Currently the gust channel sigma is accurate between 0.9 to 8.3%. Testing continues. Maybe this isn't currently close enough in your book, but I have been very aware of working the script to the numbers, rather than it feels right (even though it is feeling great). I'll get it as close as possible, but I would imaging Laminar would need to put this in the base sim to be 100% accurate to Dryden.

Yes, single at the moment for development to a stable state - which I'm at now. Currently L, sigma but going to Lu, Lv, Lw sigma_u, sigma_v, sigma_w

That is why I realised the way to go is add/remove effects to XP12's own turbulence. Normal force, Roll/pitch/yaw. wind speed and direction, live/cockpit wind behaviour, used as a gust proxy, XP12 turbulence value where available, airspeed, altitude / AGL, aircraft mass and inertia, roll, pitch and yaw rates, bank/pitch/heading-type state, whether the aircraft is on the ground.

The script is not checking aircraft height, verticle speed and trying to force those to match Dryden - this is what I tried to do in my first attempt and realised this wouldn't work. The script is generating its own Dryden based gust values internally which are logged in a CSV. The gust values go plus and negative, so the script is measuring the size of the movement (gust). A force/moment is added to XP12 effects to improve how that turbulence feels. An 'observer' constantly evaluates how the aircraft responds so it can increase or decrease its added turbulence effect to what XP12 is producing itself. By specification I mean expected behaviour of the generated gust signals. I am mainly checking Dryden based gust signals but also using MIL-F-8785 gust gradients as a small additional rotational cue for roll/pitch/yaw disturbance. It is blended into XP12, rather than replacing XP12's own turbulence model.

Development is going well. I have now included MIL-F-8785 gust gradients. into the calculations. Essentially this is what the script does. Analyze the turbulence XP12 is injecting into the sim. Analyze the turbulence with The Dryden model and MIL-F-8785 gust gradients. Inject the forces required to shape the turbulence to match the model specifications. Feeling very good - the turbulence is +-5% to the model specifications.. I am nearing an initial release as a LUA script only.

Well, this is a very interesting project. All my testing so far has been reading datarefs, including the aircrafts mass, wing dimension, flap settings etc, and injecting the data into the Dryden filters then changing the forces on the aircraft. I am now entering a second round of testing. XP12 obviously knows the aircraft data and is injecting the turbulence. This time I am analysing what turbulence XP12 is injecting into the sim, putting that data through the Dryden filters and then adding/or removing control forces as required to better fit a Dryden response. The script is learning each aircraft and noting what additional/less effects are required to fit the Dryden filters. This may be a better way to go.

I answered that - I was excited at the possibilities and thought others would find it interesting - maybe some people may have experimented themselves. Again, you just ignore what I said and continue hinting I am not be truthful with my reply. Why? Raise eyebrows in a constructive way I can accept, but several of your statements have been anything but. Which is why I just posted my methodology for testing the data, but you haven't commented on that at all. Maybe because the tone of your earlier posts didn't exactly inspire engagement? Yes, you did. Well, I just stated my methodology and the data I am testing with. I am more than happy with questions, not the negativity you continually aim at me.

I'll jump back in just to correct some assumptions made here. Yes, I am a little emotional at times - in my mid sixties I am not interested in conflict, especially on a hobby website. I posted a little interaction with AI because I was enthusiastic at what it was helping me produce, and I just felt others may find it interesting. That is it. Your statement above shows exactly why I didn't like the way you were taking the discussion. I approached this in several ways. I Had an initial discussion with another forum member privately about what I wanted to achieve, including input from several reports he pointed me to that are available on the web. I was given very good information on what I had in mind after the basic turbulence script was completed. The script itself has a built in test mode. Each test (seven in total for each round of tests) is shown on screen as a test card showing the required XP12 weather setup. I have individual tests for calm air, crosswinds, gusty crosswinds (with and without XP12 turbulence), circuit flying and approach. Each test writes a CSV spreadsheet while I fly. The file records wind, gusts, XP12 turbulence input, Dryden gust components, injected roll/pitch/yaw moments, vertical forces, bumps, roll snaps, bank angle and many others. After each flight the AI analyses the data, rather than relying on my feelings. The aim is to tune the script so the underlying turbulence behaves as close to Dryden as possible within the XP12 environment, while shaping how that turbulence is applied to the XP12 flight model. The script at V1 will be a LUA only script, but my plans are to expand this with following versions. Again, it is this tone I am not interested in engaging with. I'm approaching this project as a flight sim enthusiast who feels XP12 turbulence is a little predictable. I'm using the Dryden model as the reference point to see if I can get the turbulence in XP12 more believable. I couldn't create a script with the required technical knowledge, so I am using AI to crunch the numbers and analyse the testing CSV files. Each successive round of tests and tuning gets me closer to the Dryden specification.

I'm going to bow out of this thread. I am excited to find a tool that I can use to create scripts for my enjoyment, scripts that I otherwise couldn't create. I'll release at the org for others to try out and use to see if it increases their use of our wonderful XP12. I am not interested in being psychoanalysed. Why do I need to justify my use of AI - maybe I should also say I use a word processor instead of a typewriter? I posed the question for some useful input from pilots to improved what I - sorry, what Claude AI can produce all by itself, just needing my feelings along the way.

Totally agree there! Sometimes the answers are completely odd. As long as you understand this it is an excellent tool to speed up development, but there is plenty to laugh about along the way!

Same here.

Eh? I was clear in the haze thread I was using Claude, so it was clear I was the source of the ideas. Claude isn't going to create a haze script or a turbulence one either, without a great deal of human input. Without Claude I wouldn't be able to create anything, even though I have ideas and motivation and a lot of love for XP12. For those that don't know much about AI, Claude AI is like having an expert in coding with little knowledge at all how I want XP12 to feel. All my time is spent shaping, correcting and giving guidance of what I'm after and Claude does the drudgery of typing the code and error checking (no insult intended, I loved coding when I was doing it!). I acknowledge your expertise in turbulence modelling and make no claim at all in that field. What I do know is how XP12 feels to me and Claude AI helps me get those ideas into the sim. This may be of interest to some - two examples of an interaction with Claude My input - feeling pretty good. Could you check the relationship between yaw and altitude plus the effect on roll. On approach the yaw amount feels good - floaty, not too sharp. as I climb (not exceeding 2000ft) yaw seems to have too much influence, with even a 45 degree bank seemingly not turning the aircraft for a while - maybe this is excessive yaw? Claude's response - Good observation — let me trace the altitude dependencies for yaw through the code. Found the problem. There are three compounding issues at altitude: gust_t has zero altitude fading — wind speed gust yaw is equally strong at 2000ft as on the ground bm increases with airspeed — climbing faster = stronger yaw moment coefficient w_t at altitude has a much longer time constant — at 500ft, L≈75m (2.3s gusts). At 2000ft, L≈213m (6.9s gusts). So yaw moments persist in one direction for 5+ seconds, which is what's fighting your turns The net result is yaw that's actually stronger and more sustained at 2000ft than on approach. Physically wrong — real surface-layer gustiness drops off rapidly above the boundary layer. Notice how Claude didn't just know there was a bug in the yaw formula? Claude AI does this error checking and bug fixing much quicker, but needs human input - saves a lot of time for us non coders 😁 Another example My input - should we use that second order dryden filter. Apart from the oscilation the turbulence is feeling really good now. Claude response - Good call, the second-order filter is actually the correct Dryden implementation per MIL-STD-1797A. The lateral and vertical channels are specified as second-order transfer functions: H(s) = σ√(L/πV) × (1 + √3·L·s/V) / (1 + L·s/V)² One could ask why Claude didn't just use that second order filter in the first place! I am testing mostly in manual so I can set known conditions, but then also test each version in live weather - it has to be tuned to what XP12 is doing itself, and that was another interesting challenge. If it feels good to me, maybe others will too.

Yes to everything you suggested. Claude is just a tool and can produce quite silly results at times, and as I haven't flown for many years input from you lucky pilots is a valuable input to iron out flaws in the model data/XP12 transition. Thanks for the input. Certainly the Dryden model does introduce a cyclic element to a turn which felt excessive to my past memories of flying. Yes, XPT is a recent release at the org and I have tried it, but it doesn't give me the feeling I remember from flying, especially low down on approach over undulating terrain. Obviously my script will use the same turbulence models (I am using some elements from the more sophisticated Von Karmon model), but the trick is how that data is used within the XP12 environment. I have flown hundreds of circuits while testing at flat, undulating, ridge top, coastal airports in XP12 using default XP12 turbulence and comparing that with what my script produces. I am very pleased with the results so far. When released I can tune it depending on input from pilots of different aircraft types/environments.

For the past couple of weeks I have been researching turbulence in XP12. We know XP12 has a good flight model, but I wanted to see if that could be enhanced by applying the Dryden Turbulence model MIL-STD-1797A — "Flying Qualities of Piloted Aircraft". This adds effects and texture to the turbulence in XP12. I haven't flown for many years, so I have a question - in a banked turn, can wind induced yaw actually stop the turn? Any comments on this would be welcomed.

Ah, thanks for spotting that, register at the two sites and use your own keys - file replaced in the download 🫣🤨

A few weeks ago I don't think I would have agreed with you. Autogen in XP12 is good, but unless you are flying very low there are no shadows, and that leads the autogen not looking connected to the terrain. Ortho shadows may be fixed, but all the autogen gain the shadows making them far more believable and part of the terrain. However, after the release of SimHeaven Pro demo, I am more convinced by the idea of no ortho. The new farmland polygons have gone a long way to close the gap to ortho in imho. I am eager to see what the next gen scenery has in store for us, but whatever it is, PLEASE give autogen shadows above a few hundred feet.

Whole set for me too. I like the new ground polygons they are using for farmland - makes no ortho more tolerable.

Looking forward to this😋👍

Could you check... 1.. Right click AHHelper.exe/Properties/Unblock/OK 2.. Launch XP12 as administrator for the first launch only 3.. Add the Scripts folder to your anti-virus exclusions. Let me know if that fixes it because I do not see this. I'm not sure if I am breaking forum rules by answering tech issues here, maybe better if these queries are on the AutoHaze page?

Thank you so much for your incredibly kind words, and what a validation coming from someone with 31 years at the Met Office working with ECMWF data. That means a great deal. You've understood exactly what AutoHaze set out to do. My goals were straightforward and modest: To better simulate the atmospheric boundary layer, keeping haze consistent from the surface up to the BLH top, then clearing realistically into cleaner air above it — something X-Plane doesn't currently represent. To provide more physically accurate visibility using real satellite aerosol data from CAMS, rather than relying on METAR reports that are capped at 9999m regardless of actual conditions. To simulate the dramatically reduced visibility when flying into heavy rain, and the equally rapid clearing when flying out of it. The science behind the values written there such as Koschmieder's extinction formula, Linke turbidity scaling, CAMS AOD at 550nm, Open-Meteo boundary layer height, is the same physics used by professional meteorological services. Laminar have always said they would only consider suggestions backed by science. I have genuinely tried to do that, so I was, I'll admit, a little surprised by the response. I have enormous respect for what they have built in X-Plane 12, it is a remarkable simulator, and I mean no criticism of the team. Perhaps in time the approach AutoHaze demonstrates will find its way into the simulator itself in a supported form. That would be the ideal outcome for everyone. On the subject of AI involvement, yes, I use Claude as my coding assistant, and I'm entirely open about that. My background is as a software engineer, but that was over 20 years ago before redundancy took me in a different direction. I'm in my mid-60s now, and while the logical thinking is still there, the idea of getting back up to speed with modern Lua, Python, async architecture and X-Plane's SDK from scratch felt genuinely daunting. I simply wouldn't have attempted this project without that assistance. What Claude has allowed me to do is concentrate entirely on what I do have, the research, the atmospheric physics, the data sources, the ideas about how boundary layer behaviour should actually look in a simulator. I describe what I want physically and scientifically, and Claude translates that into working code. Every decision about which formula to use, which data source to trust, what the boundary layer transition should feel like, what precipitation visibility should look like in a thunderstorm — those are mine. I think that's actually a healthy model for this kind of project. The physics doesn't care whether the code implementing it was written by a 25-year-old developer or assembled with AI assistance by someone in their 60s who used to write software two decades ago. What matters is whether the output is correct, and a Met Office professional with 31 years of experience suggesting the methodology is sound is a rather better validation than the tools used to implement it. AutoHaze wouldn't exist without Claude. But it equally wouldn't exist without the research, the testing, the user feedback, help on this forum and the persistence to get the atmospheric physics right. Both parts were necessary. Thank you again.

Version 2.2 is available with much better rain effects and increased haze levels for the areas in the 'red' band on the CAMS charts.

Thank you for the candid feedback. I'm happy to address each point directly. On incorrect assumptions about X-Plane's weather engine: I'd genuinely welcome specifics here. AutoHaze writes exclusively to sim/private/controls/scattering/override_turbidity_t. If there are aspects of how this interacts with X-Plane's rendering pipeline that I've misunderstood, I'd be very grateful for the correction. On arbitrary outputs: The turbidity values are derived from a documented physical chain: CAMS satellite AOD at 550nm → Koschmieder extinction formula (vis = 3.9/AOD) → Linke turbidity scaling (turb = 1.0 + AOD/0.1 × 0.5) → boundary layer altitude correction via Open-Meteo BLH. These are the same equations used in atmospheric optics research. The precipitation effect uses an exponential curve matching published rainfall-visibility relationships. Nothing is arbitrary — every value traces back to a physical measurement or established formula. On qualitative vs quantitative feedback: Agreed — and that's exactly why AutoHaze uses CAMS satellite data rather than subjective judgement. The Copernicus Atmosphere Monitoring Service provides validated hourly aerosol measurements used by ECMWF, national met services and the aviation industry. Flying over the Indo-Gangetic Plain with AOD 1.65 producing 2km visibility isn't a subjective choice — it's what the physics says. On AI involvement: Correct — I use Claude as a development assistant, which I'm entirely transparent about. The physics, the data sources, the validation against real conditions are mine (and the grateful help given here on the forum). The AI accelerates implementation but the science is independently verifiable. The weather engine in X-Plane 12 is spectacular, which is why I moved over from MSFS 🙂, but there were just a couple of things I thought could be improved - climbing out of and descending into the boundary layer to better simulate haze, and Improved rain visibility effects where the visibility will increase and decrease based on rainfall rate hitting the aircraft. 1,700+ users downloading it suggests the community finds real value in the enhancements I have made.

Ah, I only have one monitor so didn't come across this. Maybe the AutoHaze window is opening but off screen. I'll have a test version for you shortly to see if I can fix this.