Wet/Contaminated Runway test PC (Non visual) Beta

  • This was just a bit of fun, before I am off on holiday. All main mods are now fully Beta compatible and will be released when AF4 comes out of beta. In the future, I will still update the A350 and smaller buses for any future Beta compatibility that might break the mod again. The great thing about this beta is it has taught me a huge amount about the DLL

    This was a METAR test. The sim reads the METAR files based on ICAO, and sends data I'm feeding from my flight plan in SimBrief.

    Here's a list of what it can do in the post below (NO WET RUNWAY, RAIN OR ICE VISUAL EFFECTS!)


    Btw -I paid around £80 for another A350 simulation, and this FS4 version is now more detailed than that add-on (system-wise), except FMC and OIS)


    46923-5d98a7b3ed01755feca46b686f1d3b543e3ee69332ea319ca6c3167ae642a608-variant.webp

    Landing distance and braking action telemetry

  • Feautre List


    Display Spoiler

    Live METAR Weather / Visibility

    The external weather controller interprets current METAR conditions and modifies Aerofly visibility dynamically.

    • Current-airport METAR acquisition.
    • Automatic fallback to another reporting station when the local airport has no usable METAR.
    • Reporting-station fallback search up to approximately 250 NM.
    • Source can be shown to the user, for example OETN > OKKK 92NM.
    • METAR temperature and dewpoint parsing.
    • Airport/reporting-station elevation used to calculate cloud height AGL.
    • Different terminal and cruise weather-update rates.
    • Cruise weather transitions are smoothed rather than snapping instantly.
    • Approximately 10-minute cruise METAR reacquisition.
    • Approximately 10-minute cruise visibility transition.
    • Below FL200/terminal areas update much more quickly.

    Cloud representation with Aerofly clouds disabled

    Regional cloud ambience is reproduced using visibility:

    • OVC: approximately visibility STEP 25.
    • VV: approximately STEP 20.
    • BKN: approximately STEP 36.
    • Actual penetration of a BKN/OVC/VV layer can rapidly reduce visibility toward approximately 250 m.
    • Cloud-layer visibility can change at roughly 1.25 seconds per visibility step while actually penetrating the layer.
    • Leaving the layer progressively restores the regional visibility.

    Fog / Mist / Low-Visibility Effects

    • FG — fog.
    • BR — mist.
    • VV — vertical visibility.
    • Low BKN/OVC ceilings.
    • Low prevailing visibility.
    • Timed passing fog-patch simulation on approach.
    • Fog-patch eligibility is influenced by METAR visibility, fog/mist, vertical visibility and low cloud.
    • Typical approach envelope: within roughly 18 NM and below 3000 ft AGL.
    • Typical patch delay: approximately 30–90 seconds.
    • Typical patch duration: approximately 120–240 seconds.
    • Typical temporary visibility: approximately 600–1450 m.
    • A given METAR produces a stable/deterministic event rather than continuously random visibility jumps.

    METAR-Driven Icing Environment

    Four environmental severity levels are transmitted into the aircraft:

    • NONE
    • LIGHT
    • MODERATE
    • SEVERE

    Ordinary cloud icing uses temperature plus visible moisture.

    Approximate icing temperature range:

    • -40°C to +10°C

    Ordinary BKN/OVC/VV cloud:

    • Above 0°C through +10°C → generally LIGHT
    • 0°C and below → generally MODERATE

    Explicit freezing weather:

    • FZFG — freezing fog: MODERATE
    • FZDZ — freezing drizzle: MODERATE
    • FZRA — freezing rain: SEVERE

    Low-visibility moisture is also considered. If visibility falls to around 1 SM or less, the atmosphere is within the icing temperature range and the METAR contains suitable moisture, the controller can command at least LIGHT icing.

    Recognised moisture includes conditions such as:

    • FG
    • BR
    • DZ
    • RA
    • SN
    • SG
    • PL
    • FZFG
    • FZDZ
    • FZRA
    • BKN
    • OVC
    • VV

    Smoke, haze and dust by themselves are not treated as icing moisture.

    A350 Ice Detection

    Environmental icing and the A350's own ice-detection indication are deliberately separated.

    • Physical icing conditions may exist below 1500 ft.
    • The A350's fuselage ice-detection indication becomes active only above approximately 1500 ft AGL/RA.
    • This reproduces the real A350 concept that the ice detection system becomes operational above 1500 ft.
    • A-ICE DETECTED behaviour is linked to real weather input.
    • Severe icing can drive the corresponding severe-ice logic.
    • ICE NOT DETECTED is modelled after approximately 2 minutes without detected ice while anti-ice remains selected.
    • The environmental icing command is refreshed every 5 seconds, including an explicit zero state.

    Physical Pitot / Static / AOA Icing

    Icing is not represented only by an ECAM message. The Advanced system can progressively affect the actual air-data sensor paths.

    Independently modelled exposure includes:

    • Captain/pilot pitot.
    • Copilot pitot.
    • Standby pitot.
    • Pilot static.
    • Copilot static.
    • Pilot AOA.
    • Copilot AOA.
    • Standby AOA.
    • Fourth AOA.

    Probe heating is considered available when:

    • An engine is running, or
    • Manual PROBE/WINDOW HEAT is selected.

    Result:

    • LIGHT/MODERATE icing + normal probe heat → normally protected.
    • LIGHT/MODERATE icing + no heat → progressive blockage.
    • SEVERE icing + no heat → considerably faster blockage.
    • Sustained SEVERE icing can eventually overwhelm heated protection.

  • Icing → ADR → Flight-Control Consequences

    Sensor failures feed the aircraft rather than simply forcing an arbitrary ADR warning.

    • Pilot pitot/static blockage can invalidate ADR 1.
    • Copilot pitot/static blockage can invalidate ADR 2.
    • Standby pitot blockage can invalidate ADR 3.
    • AOA failure does not by itself directly invalidate an ADR.

    The resulting chain can become:

    Physical sensor icing → ADR faults → two ADR losses → ALTN LAW → three ADR losses → DIRECT LAW → BUSS → GPS ALT

    This means weather can eventually produce real aircraft-system consequences rather than just a cosmetic icing warning.

    Engine Bleed / Pack Loads

    Pneumatic demand now affects the engines.

    • Engine bleed responds to pack demand.
    • LOW / NORM / HIGH pack flow produces different loads.
    • One engine supplying both packs carries a larger penalty than two engines each supplying a pack.
    • Single-pack operation is supported.
    • Following an individual pack failure the remaining pack can operate at HIGH flow.
    • APU bleed can supply the packs without imposing the normal engine pack penalty.
    • Ground high-pressure air can also remove the engine pack-load penalty.
    • Bleed temperature is dynamic.
    • Engine EGT responds to pneumatic load.
    • Engine fuel flow responds to pneumatic load.
    • Pack controller failure scenarios are available.
    • Forward cargo temperature regulation is tied to available pack capability.

    Anti-Ice Engine Load — Separate from Normal Pack Load

    Anti-ice adds its own additional engine load instead of merely illuminating a memo.

    ENG A/I

    Per running engine with engine anti-ice active:

    • approximately +8 K EGT
    • approximately +1.0% fuel flow

    WING A/I — both engines supplying

    Per engine:

    • approximately +12 K EGT
    • approximately +1.5% fuel flow

    WING A/I — one engine supplying

    Supplying engine:

    • approximately +24 K EGT
    • approximately +3.0% fuel flow

    WING A/I supplied by APU bleed

    • No artificial engine wing-anti-ice penalty is applied to an engine that is not supplying that bleed demand.

    So normal pack demand, engine anti-ice and wing anti-ice are modelled as separate pneumatic/load cases.

    Dynamic Runway Surface & Braking

    Current METAR weather can now change the aircraft's physical braking authority.

    The numerical factor is internal and is not displayed to the pilot as though it were an official runway friction coefficient.

    Current calibrated simulator matrix:

    METAR / SurfacePilot-facing estimateInternal brake authority
    DryGOOD1.00
    Wet / Damp / RA / -RA / DZ / BR / FGGOOD-MEDIUM0.81
    Heavy rain / +RA / very wetMEDIUM0.65
    Slush / standing water / snow / SG / PL / -FZRAMEDIUM-POOR0.42
    Ice / FZRAPOOR0.35
    Heavy freezing rain / +FZRA / wet icePOOR0.20

    The runway factor:

    • Is supplied dynamically from the weather controller.
    • Is refreshed approximately every 5 seconds.
    • Defaults safely back to DRY if the weather controller stops.
    • Changes actual tyre/runway braking authority.
    • Does not fake a lower hydraulic brake-pressure indication.

    Recorded RTO Braking Telemetry

    Multiple high-energy RTO runs were recorded rather than choosing the runway factors by feel.

    Dry control

    • Aircraft mass: approximately 320 t
    • Reject ground speed: 161.6 kt
    • Reverse: none
    • Maximum brake/autobrake input: 1.000
    • Reject-to-stop distance: 1234 m
    • Reject-to-stop time: 29.3 s
    • Mean deceleration: approximately 0.286 g

    Wet / Damp — factor 0.81

    • Reject ground speed: approximately 161.0 kt
    • Reverse: none
    • Maximum braking
    • Reject-to-stop distance: 1469 m
    • Reject-to-stop time: 35.8 s
    • Mean deceleration: approximately 0.238 g

    Compared with the matched dry run:

    • approximately 19% longer stopping distance
    • approximately 22% longer stopping time
    • approximately 17% lower mean deceleration

    Heavy Rain / Very Wet — factor 0.65

    • Aircraft mass: approximately 322 t
    • Reject ground speed: 172.9 kt
    • Reverse: none
    • Maximum braking
    • Reject-to-stop distance: 2162 m
    • Reject-to-stop time: 49.6 s
    • Mean deceleration: approximately 0.187 g

    The 0.35 ICE/FZRA and 0.20 heavy-FZRA/wet-ice cases were also separately runtime-tested and accepted.

    Brake Temperature & Brake Fade

    Braking effectiveness also depends on actual brake temperature.

    Approximate current physical authority:

    • ≤600°C → 100%
    • 650°C → ~95%
    • 700°C → ~90%
    • 800°C → ~75%
    • 900°C → ~55%
    • 1000°C+ → ~35% minimum authority

    Additional behaviour:

    • Left/right brake fade can differ.
    • Fade uses the hottest brake on each side.
    • Indicated brake pressure is separated from actual braking torque.
    • A pilot can therefore see hydraulic pressure while the overheated brakes themselves are much less effective.
    • Autobrake depends on the appropriate normal/Green braking system.
    • Anti-skid dependencies are modelled.
    • RBCU degradation and compound RBCU faults affect available braking.
    • BRAKES CTL failures can remove automation while retaining appropriate manual pedal capability.

    Tyres / Fuse Plugs / Rolling Resistance

    • All 12 A350 main-wheel tyre pressures are independently represented on the aircraft display.
    • Wheels 1–8 correspond to physical Aerofly wheels.
    • Wheels 9–12 are simulated/display positions so the full A350 wheel set is represented.
    • Individual pressure variation prevents every tyre sitting at exactly the same pressure.
    • Tyre pressure changes slowly with ambient/TAT.
    • Individual brake heat can raise tyre pressure.
    • Thermal fuse-plug behaviour is simulated.
    • Severe brake heat soak can trigger progressive tyre venting.
    • Tyres deflate progressively rather than instantly jumping from normal to zero.
    • Low tyre pressure produces ECAM/amber indication.
    • Very low pressure adds real rolling resistance to physical tyres.

    Approximate near-flat drag map:

    • 50 PSI or more → no extra drag
    • 35 PSI → 0.040
    • 20 PSI → 0.100
    • Around 12 PSI or below → 0.160

    High-Speed Anti-Skid-Off Tyre Damage

    High-speed braking with anti-skid unavailable can cause progressive multi-tyre failure.

    Speed/severity tuning includes:

    • 160–174 kt: up to 5 physical tyres flat.
    • 175–189 kt: up to 6 physical tyres flat.
    • 190+ kt: all 12 displayed tyres can be shown failed.

    Severe continuous braking can also progressively spread the damage:

    • Initial severe exposure → two tyres on the more heavily loaded main gear.
    • Continued exposure → further tyres on the opposite gear.

    The resulting flat physical tyres then automatically use the low-pressure rolling-resistance model.

    High-Speed Parking-Brake Damage

    Applying/retaining the parking brake at extreme speed has its own damage model:

    • 160–174 kt: 6 physical tyres can fail.
    • 175–189 kt: all 8 physical tyres can fail.
    • 190+ kt: all 12 displayed tyres can fail.

    This is independent of the anti-skid switch.

    Hard Landing / Tyre Impact

    • Extreme vertical-energy landings can damage tyres.
    • Severe touchdown conditions can cause tyre failure.
    • Resulting physical flat tyres create rolling resistance.
    • Brake/tyre consequences continue after touchdown instead of existing only as a warning.

    Hydraulic System

    • Green and Yellow hydraulic-system dependencies.
    • Normal brakes tied to Green.
    • Alternate brakes tied to Yellow.
    • Parking brake tied to the Yellow accumulator.
    • Approximately 4–5 parking-brake applications available from a normally charged accumulator.
    • Accumulator recharge requires the relevant hydraulic pressure.
    • Loss of Green removes normal braking/autobrake capability.
    • Loss of Yellow affects alternate/parking braking.
    • Green/Yellow single and dual low-pressure ECAM logic.
    • Dual G+Y warning prioritisation.
    • RAT/emergency supply interaction.
    • Hydraulic failures propagate into flight-control and landing-gear consequences.
    • In-flight slow hydraulic leak scenarios can progressively remove pressure rather than failing instantly.
    • Hydraulic pump overheat/isolation scenarios are available for the engine-driven Green/Yellow pumps.
    • Timed hydraulic failures can occur during different phases of flight.
    • Landing-gear retraction is inhibited after applicable hydraulic loss.
    • Gravity extension requires the actual gravity-extension selection rather than happening automatically.

    Flight-Control Computers & Laws

    • PRIM 1 / 2 / 3 failures.
    • SEC 1 / 2 / 3 failures.
    • Real PRIM/SEC control-surface allocation.
    • Five-second functional reboot/unavailability period when a computer is cycled.
    • Spoiler availability linked to the appropriate computers.
    • Elevator/rudder command availability linked to remaining flight-control computers.
    • SEC backup paths.
    • BCM backup behaviour.
    • Actual alternate/direct-law control paths rather than an ECAM-only indication.
    • PFD protection-loss indications.
    • ADR-triggered law degradation.
    • Hydraulic-triggered law degradation.
    • Two ADR failures can produce ALTN LAW.
    • Triple ADR loss can produce DIRECT LAW.
    • DIRECT LAW removes normal protections and affects AP/autoland availability.
    • Complete PRIM/SEC loss can remove commanded primary-control authority.

    Flaps / Slats

    • FLAP SYS 1 / 2 failure logic.
    • SLAT SYS 1 / 2 failure logic.
    • Dual flap/slat system failures.
    • Partial and complete loss scenarios.
    • ECAM/STATUS consequences.
    • Severe overspeed-related flap/slat failure capability.
    • Approach consequences represented through the abnormal procedures.

    Go-Around Soft

    A functional reduced-thrust go-around mode has been added.

    Sequence:

    Approach → TOGA → both thrust levers returned to FLX/MCT → MAN GA SOFT

    • Requires both engines.
    • Uses the existing A350 GA SOFT rating path.
    • One-engine operation inhibits GA SOFT.
    • Moving the levers back toward CL exits it.
    • Touchdown resets it.

    Autothrust Failure

    • Dedicated A/THR failure capability.
    • Hard failure prevents simply re-engaging A/THR through normal lever logic.
    • Manual-thrust fallback.
    • Involuntary disconnect behaviour.
    • Appropriate ECAM/checklist consequences.

  • Almost all normal and abnormal checklists and memos have been added. There are thousands; it is time-consuming, as each system needs to be tested to match the FCOMs' behaviour. I can understand why the devs leave this stuff out; it would cost too much in man-hours



  • I keep thinking about a stripped down mobile version, since a large part of the Advanced Mod is now fully contained in the system.tmd.

    My two concerns are

    1. I dont think the devs want us modifying files on mobile
    2. Not even sure what the system.tmd and file structure looks like on mobile, it could be completetly different to PC


  • I keep thinking about a stripped down mobile version, since a large part of the Advanced Mod is now fully contained in the system.tmd.

    My two concerns are

    1. I dont think the devs want us modifying files on mobile
    2. Not even sure what the system.tmd and file structure looks like on mobile, it could be completetly different to PC


    I think the developers don't want people messing with files that could cause the game to malfunction.There are some people who work with mobile mods, like Zk Mods, etc. You can ask them more or less how this might work.