Ramsay

Just did a quick check - there's nothing fancy (or relative) here, it's just wrong. • wind to 90° is reported as 270° (correct) • wind to 118° is reported as 242° (wrong i.e. 118 + 180 = 298) • wind to 45° is reported as 315° (wrong i.e. 45 + 180 = 225) Looks like it was pure chance the Airboss's relative wind bearing of 242° in the OP's mission was in the same quadrant as the actual "relative wind" !!!

Apparent wind: Apparent wind is the wind experienced by a moving object, like a sailboat or an aircraft, and is a combination of the true wind and the object's speed and direction. Relative wind is the direction of the airflow relative to the moving object (carrier), rather than the true wind direction. Comment: AFAIK the Airboss screen's "relative wind" direction is only calculated at mission start and doesn't update when changing the carrier's speed/direction or switching to a new player slot. The magnitude of the Airboss's "relative wind" only considers the metrological wind component (perhaps adjusted for deck height) and doesn't include the additional component due to the carrier's own speed/direction. Dynamic weather adds cyclone type weather systems to DCS and metrological wind direction and speed can/will vary with the carrier's location i.e.

This is incorrect. The "Relative Wind" direction shown in the bottom left appears to be calculated at mission start? and won't necessarily be the metrological to/from direction i.e. the OP's mission has a 12 kts wind towards 188°T, yet the Airboss screen shows the direction as 242°

Yes, in this test mission 12 kts @ 33ft increases to 25 kts @ 1600ft (and I'm guessing the 72 ft deck height is responsible for the increase to 14 kt in DCS).

Unfortunately the Relative Wind direction and magnitude on the Airboss's screen doesn't update when changing the carriers speed or direction - so even if you bring the carrier to a full stop, you can't see the meteorological wind across the deck. Here, I've turned the carrier into the meteorological wind and adjusted the course so the crosswind needle is centered i.e. at 0 kts ... this is far from ideal, but I'm at a loss for what else you can do if the briefed wind direction changes and isn't updated in the mission brief (LALT+B).

It's the relative wind across the carrier deck i.e. a helicopter taking off into a hover or flying parallel, would fly 242° at 28 knots to remain stationary relative to the moving carrier. The relative wind across the deck is dynamic and will change with changes to carrier's speed/direction. The meteorological wind is usually static (in DCS) and/or slow to change - so matches the mission briefing. Not sure on the exact maths but I'd turn the carrier into the meteorological wind (305°T) and add a "fudge" factor to compensate for the angled deck, OTOH in DCS I general consider "into the wind" close enough when making missions.

Is that what is/should be displayed at the Airboss's "station ? Do you have a real life example/link for US carrier operations you can share ?

Not sure if everything is reported correctly on the "Airboss's Windspeed/Direction Screen" but neither 118° or 298° is close to the resultant wind across the deck due to the carrier's speed/direction combined with the meteorological wind in the mission. This diagram might help ? Comment ARCTAN (25/13) = ~62° so the wind direction from 242° in DCS is perhaps derived from the "measured ?" landing deck headwind/ crosswind components (and ED are modelling real life rounding errors, instrument limitations or similar ?) However, the magnitude (14 kts) of the wind doesn't make sense (to my eyes) as (from Pythagoras theorem) the landing deck wind components equal 28 knots i.e. • √ ( 25² + 13² ) = √ ( 625 + 169 ) = √ ( 794 ) = 28 kts but perhaps I'm misunderstanding what is being displayed in the bottom left of the Airboss's screen ?

The Kiowa MFD's (LEFT_MFCD and RIGHT_MFCD) will export (with a stretched ratio) using most? SimAppPro display profiles i.e. A-10C, F-16C, F/A-18C or similar. TL;DR: https://forum.dcs.world/topic/371974-radar-on-an-mfd/#findComment-5632094 Detail: Here is a Kiowa example using the WinWing F/A-18C profile. Monitor setup F/A-18C Cockpit Profile (CENTER_MFCD, LEFT_MFCD and RIGHT_MFCD) DCS Kiowa export to WinWing MFD's Copying WinWing's Export .lua ("DCS World\Config\MonitorSetup\wwtMonitor.lua") to "Saved Games\DCS\Config\MonitorSetup", allows the exported displays to be adjusted to a 3:4 ratio (the HSI, etc. isn't stretched but instead has black bars top and bottom). Custom Export .lua (positions require adjusting to fit your own monitor resolutions/arrangement) _ = function(p) return p; end; name = _('OH-58D_3xMFD_4x3_Aspect'); Description = 'Custom positions and sizes for 3x Winwing MFD.' --created 2025-04-10, Exported Displays given 4x3 Aspect, RB Viewports = { Center = { x = 0; y = 0; width = 5120; height = 1440; aspect = 3.5555555555555554; --32/9 } } UIMainView = Viewports.Center GU_MAIN_VIEWPORT = Viewports.Center --L2MUMS is mapped to CENTER_MFCD (and permamently displayed) CENTER_MFCD = { x = 8; -- 0+8 offset y = 1794; -- 1440+256 offset +20 for Kiowa +78 to centre width = 752; -- 768 - (8+8) height = 576; -- 4x3 aspect for Kiowa (was 732) } --Custom MFD sizes and positions to fit inside button bevels. LEFT_MFCD = { x = 776; --768+8 offset y = 1794; -- 1440+256 offset +20 for Kiowa +78 to centre width = 752; -- 768 - (8+8) height = 576; -- 4x3 aspect for Kiowa (was 732) } RIGHT_MFCD = { x = 1544; --(768x2)+8 offset y = 1794; -- 1440+256 offset +20 for Kiowa +78 to centre width = 752; -- 768 - (8+8) height = 576; -- 4x3 aspect for Kiowa (was 732) } More detail on viewport exporting can be found in this excellent Export FAQ OH-58D_Monitor(4x3MFDAspect).lua

Sorry if I wasn't clear in my feedback, I wasn't seen the the inverted F-16 localiser when using a modified beacon.lua file. Thanks, I'll copy and paste your changes to my copy to fix the non-working glide slope on 25L.

When the localiser is "inverted" in the F-16C - it means you are flying a "back course" i.e. the wrong localiser direction is activated. This is similar to when the glide slope is "missing" and only appears after overflying the far end of the runway. Although I don't have "inverted" localisers for 25R and 25L, I'm still working out how to configure a working glide slope for 25L (wrong end/frequency is activated) - so cannot offer a comprehensive Frankfurt config yet.

Attached are two of my own (the zip includes a track file). A few common lines in the log prior to the CTD. 2025-05-24 01:44:27.458 WARNING EFFECTS2 (Main): OParticleSystem: preset 'missile' not found in 'volumetricPointLight.lua', using default 2025-05-24 01:47:19.786 WARNING LOG (9368): 20 duplicate message(s) skipped. 2025-05-24 01:47:19.786 ERROR GRAPHICSVISTA (Main): Can't open model AV-8BNA-OBLOMOK-ELEVATOR-L. 2025-05-24 01:47:19.787 ERROR GRAPHICSVISTA (Main): Can't open model AV-8BNA-OBLOMOK-ELEVATOR-R. 2025-05-24 01:48:14.306 INFO EDCORE (Main): try to write dump information 2025-05-24 01:48:14.641 INFO EDCORE (Main): # -------------- 20250524-014815 -------------- 2025-05-24 01:48:14.642 INFO EDCORE (Main): DCS/2.9.16.10523 (x86_64; MT; Windows NT 10.0.26100) 2025-05-24 01:48:14.643 INFO EDCORE (Main): H:\Steam Library NVMe\steamapps\common\DCSWorld\bin\DCS.exe 2025-05-24 01:48:14.644 INFO EDCORE (Main): # C0000005 ACCESS_VIOLATION at 00007ff6cb3836f3 00:00000000 2025-05-24 01:48:14.645 INFO EDCORE (Main): SymInit: Symbol-SearchPath: 'H:\Steam Library NVMe\steamapps\common\DCSWorld\bin;', symOptions: 532, UserName: 'Ramsay' 2025-05-24 01:48:14.646 INFO EDCORE (Main): OS-Version: 10.0.26100 () 0x100-0x1 2025-05-24 01:48:14.647 INFO EDCORE (Main): 0x00000000007b36f3 (DCS): SW + 0x19BC73 2025-05-24 01:48:14.648 INFO EDCORE (Main): 0x000000000078bd6a (DCS): SW + 0x1742EA 2025-05-24 01:48:14.649 INFO EDCORE (Main): 0x000000000071285f (DCS): SW + 0xFADDF 2025-05-24 01:48:14.650 INFO EDCORE (Main): 0x000000000000461b (World): wSimTrace::CommandsTraceDiscreteIsOn + 0x3EB 2025-05-24 01:48:14.651 INFO EDCORE (Main): 0x0000000000004c42 (World): wSimCalendar::DoActionsUntil + 0x262 2025-05-24 01:48:14.651 INFO EDCORE (Main): 0x0000000000a4eeba (DCS): SW + 0x43743A 2025-05-24 01:48:14.651 INFO EDCORE (Main): 0x0000000000a4eb91 (DCS): SW + 0x437111 2025-05-24 01:48:14.651 INFO EDCORE (Main): 0x0000000000a74032 (DCS): SW + 0x45C5B2 2025-05-24 01:48:14.651 INFO EDCORE (Main): 0x0000000000a28d04 (DCS): SW + 0x411284 2025-05-24 01:48:14.651 INFO EDCORE (Main): 0x0000000000a2a3c3 (DCS): SW + 0x412943 2025-05-24 01:48:14.652 INFO EDCORE (Main): 0x00000000025abc5f (DCS): AmdPowerXpressRequestHighPerformance + 0x10C0C5B 2025-05-24 01:48:14.652 INFO EDCORE (Main): 0x00000000010ad99e (DCS): SW + 0xA95F1E 2025-05-24 01:48:14.652 INFO EDCORE (Main): 0x000000000002e8d7 (KERNEL32): BaseThreadInitThunk + 0x17 2025-05-24 01:48:15.413 INFO EDCORE (Main): Minidump created. 2025-05-24 01:48:15.413 INFO Lua::Config (Main): stack traceback: 2025-05-24 01:48:15.419 WARNING LOG (9368): 3 duplicate message(s) skipped. I tested the original Portuguese .miz and also an edited version with English text - the track file has a lot of wasted time (on the runway) as I refamiliarised myself with the JF-17 / assigned control bindings, however it does CTD on replay in the current version of DCS 2.9.16.10523, so should serve it's purpose. Looks like the CTD may be related to the HQ-7 shooting down an AI AV-8B ? dcs.log-20250524-0248.log dcs.log-20250524-014815.zip

Tacview 1.9.5 Beta 8 has added support for CWG, however you'll need to be licenced/registered user to run it (or else wait for the update to come to the open/free branch).

Because by default DCS will use "Preset C" i.e. the older, more performant CNN (Convolutional Neural Network) mode. Detail DLSS 4 has advantages and disadvantages. It is not a "no cost" upgrade for all graphics/stuations (yet?) i.e. temporal artifacts/ghosting. Choosing the "best model" is often a matter of personal opinion. DLSS 4 looks better in certain circumstances but has a negative impact on fps - this can be offset by choosing a lower quality upscale i.e. DLSS 4 Balanced -> DLSS 3 Quality, however this can have negative effect on MFD text, etc. in DCS and require tweaking using "sharpening" or similar effects. IMHO rather for user preference, improvements to temporal artificing in DCS with DLSS 4 - often seem to be a placebo effect, rather than "real". Nvidia continue to improve DLSS Super Resolution, so the "preset" default may change once ED feel DLSS 4 has "matured".

Correct, nether I or the ED store quote I made say the MiG-29A carries guided A2G weapons "the [DCS] MiG-29A is also armed with ... a 30mm cannon, and unguided bombs and rockets."

From the first lines of the store page - https://www.digitalcombatsimulator.com/en/shop/modules/fulcrum/

This is how I also see which DLSS I am using. Which Nvidia driver are you using ? Did you re-apply the Nvidia Inspector changes if/when updating the driver ? This still works for me with an RTX 4070 using Nvidia Geforce 576.28, DCS 2.9.15 and NV-Profile-Inspector-Revamped 2.4.2.3

@Stehas78 I managed to create a script to log all the Cold War Germany Airfield ID's Unfortunately the getAirbases ID does go out of sequence with that seen in the SU-25T/FC3 (not sure if a bug or intended), however we can use the table index as a proxy and cross check with the already known ID's from in game testing i.e. in game Ramstein has ID 133 which maps to the getAirbases.ID 165 and getAirbases.Name Ramstein. Here is my script -- Runs once, prints to DCS log file -- Prints a table of all airbases with: -- Table Index -- ID -- Name local aerodromes = {} local bases = world.getAirbases() env.info("There are " .. #bases .. " Airbases in the World") for i=1, #bases do local index = #aerodromes + 1 aerodromes[index] = {} aerodromes[index].id = bases[i]:getID() aerodromes[index].name = bases[i]:getName() aerodromes[index].pos = bases[i]:getPosition() env.info("Table Index = " .. index .. " getID = " .. aerodromes[index].id .. " getName = " .. aerodromes[index].name) end env.info("All Airbases printed to DCS.log !") and is based off this post Sample mission, the data is written to DCS.log World Airfield ID's using Script (WIP), GermanyCW.miz

I believe you can use a script to get the data but haven't found an example myself i.e. using • AERODROME NUMBER - getAirbases > ID • AERODROME NAME - getAirbases > Callsign For the Caucause map the ID is offset by 11, so ID 12 (Anapa-Vityazevo) --> SU-25T/FC3 ID 1 (i.e. 12-11 = 1 ) But for Afghanistan and Kola the ID's are 1 to 1, so "getAirbases ID" = 16 and is also the SU-25T/FC3 ID Perhaps Germany is the same and you have better scripting skills ? https://wiki.hoggitworld.com/view/DCS_func_getAirbases

No, it just takes time. Place a few SU-25T around the map and cycle through the ID's in LANDING mode - record the • HSI's thin needle for bearing • HSI Distance for distance in km • Course for a runway cross check when identifying the airfield (and/or to discard heliports ? with a (000) course). Switch to the F10 map and use the ruler to map each ID (with it's recorded bearing and distance) to it's airfield name, rinse and repeat until done or hope @Minsky updates his excellent "Aerodrome Data and Frequencies" kneeboard pages to include Germany soon™.

Here's the SU-25T at Ramstein The thin needle on the HSI gives the bearing to the selected airfield and HSI Distance gives distance in Km. Unfortunately Western FC3 aircraft i.e. A-10A, etc. don't display a airfield ID in their HUD, so only the runway/landing course can be used to identify the selected airfield - while this was an "ok" work around on the Caucasus map, the 201 ID's of Germany probably make this pure guess work unless ED modify the modules to display airfield ID's like the Russian aircraft do. There are lots of ID's with course "000" - I suspect these are Heliports but haven't mapped/tested these. Example of other ID's mapped so far

There are 201 Airfield (Return/Landing) ID's that can be cycled through in FC3 aircraft i.e. SU-25T, etc. I've mapped about 60 of them so far.

Hardly seems fair as none of the sale price ATM goes to Razbam or the coders/artists who made the module(s).

AFAIK all of Razbam's modules have been removed from sale at their request (due to the dispute with ED they are not receiving their share from sales, part of which is then used to pay the coders and artists who made/maintain them).

AFAIK most of the RSBN and PRMG in the eastern zone are missing / wrongly coded. Only ED's L-39 uses the map's beacon.lua (MiG-21 has it's own definition files). Changes/additions required are discussed in this thread with an example beacon.lua that adds several missing RSBN beacons (Russian TACAN equivalent).