_SteelFalcon_

does it say STBY instead of A-G or A-A? if so, press the OSB next to the STBY and unstow the pod by clicking the OSB next to A-G or A-A, depending on your master mode

This was already reported and affects all IAMs including gbu 38 @BIGNEWY

I avoid the gbu-24 as long as it‘s working like a gbu 10 in general. if you do some research about the gbu-24 you‘ll find some articles stating that lasing it too early can result in the bomb landing way short of target. So the current bomb in dcs does not work correctly, if the only way to get it to work currently is lasing immediately. i cant comment on issue 1 as i dont use the gbu-24 in dcs until it‘s working at least a bit like the real one

Immediately lasing contradicts probably the whole point of that bomb and does not reflect public information that can be found about this weapon.

No, OP refers to the effect HTS class selection has on the search timer of the HTS and if you can speed this up or if deselecting threat classes even has an effect in DCS at the moment

No. This is the problem of HAS mode (HARM As Sensor). HTS is not a mode, it‘s a system. Its data is shown on the HAD (HARM Attack Display) and on said HAD, the search time is longer the more emitter Classes you have active. By default, all classes are selected. Deselecting unnecessary classes significantly speeds up the search for emitters in the active categories. So if you know what you look for, narrow it down as much as you can. this principle can of course be applied to the HARM in HAS mode too

Dumb question, but did you check crosswind?

Yep

Based on what does the DCS RWR now assign the priority of threats if multiple emitters are in track mode yet none have launched? Proximity/signal strenght? Emitter type? Both? None? Is the position of the emitter within 1 area of the RWR always the same or, since it is an Area and not a fixed stage, does the position vary within said area based on any sort of information and if so, what‘s the criteria?

It is also to note that the M for the missile stays in the high threat area close to center even if it has been defeated long ago. It did not do that before. Before you could tell you defeated the missile if the M started „walking“ outwards on the RWR

You are correct, however 2 identical emitters doing the exact same thing at different distances should not show up on identical position on RWR simply based on distance and thus a likely difference in signal strenght. The device should react to that and classify a different lethality based on the difference in signal strenght due to different proximity of the emitter. the current implementation does not. Everything is basically critically lethal or absolutely harmless. this is not just irritating in the game but also unimagineable that an airforce would buy this and consider it an improvement over the previously used system. I seriously question the current implementations accuracy

It is impressive how this point is discussed from ED side, unless we can bring up the exact evidence for this specific device, it seems it is not being looked at. Even if basically anything one can find about even older RWR devices suggest that there was always some sort of range information displayed either directly or indirectly (based on lethality). Common sense would lead to this also being a key feature for the alr56m but here we are, talking to a wall that basically denies it all, but refusing to provide their apparently „public“ data on this implementation. If the display is like the alr 67 in the hornet and it‘s not necessarily displaying „distance“ itself, but instead „lethality of the threat“, why is everything classified as absolutely lethal and thus closer to center, yet nothing as „potentially lethal“ and thus less close to center of the rwr? If this is the general approach on all features going forward, it does make one question the accuracy of simulation of those systems in general and does not necessarily make me have a lot of passion or support for future modules. please reconsider this approach and look at the rwr again. Would the AF really buy such a thing if the older version gave the pilot much more information, providing a higher chance of survival?

The correct as is tag also contradicts the statements in wags video from january

to be fair, the cue is called MAX toss cue, not "ONLY toss cue"

I believe the rudder fix relates to this report, not the issue described by OP here about inverted values

I tried too and it didnt work at all. Tms aft, tms right, tms up… anything. SP didnt react at all. Couldnt move the pod anywhere. A-G mode with mavs in Pre as selected weapon, wanted to use thp in SP mode to quickly find something to BSGT the mav on, pod didnt move at all

From the video it looks like you dont nearly pull enough G for most of your pull-up. Try to hit 4G instantly and hold it consistently, as the toss is meant for a 4G constant pull. The longer it takes and the more vertical you become, you get slower and you never reach the parameters needed for the bomb to release. It does take some practice

Yeah they are boresighted when you have an air-spawn

it should return to center, it's a spring loaded switch

Can you post a track of the „issue“? I had no issues using gbus as of late

Thanks for the info, i was just curious if it‘s per screen or per page, since i couldnt find any info myself either. I‘m not suggesting it to be changed in one way or another

@Lord Vader is this per MFD? So if I adjust brightness of the TGP on my left MFD, should the brightness remain the same if I swap displays to the right MFD or will I need to adjust it on the right MFD on the TGP page as well? the current implementation requires adjusting it on both screens

Khasab ILS for 19 gives you localizer but GS drives you into the ground as example