Zabuzard

Regarding the HUD color, you essentially "just" have to understand the code in order to edit it. Let me give you a hand (Im doing this from mobile, so I couldnt test it, but it should work [emoji3481]) Stuff that is dynamically rendered on in DCS is called an "indicator", they are defined in lua (accessible to you), the entry point is always in: DCS/Mods/aircraft/NameOfTheAircraft/Cockpit/device_init.lua. We can find the HUDs indicator for the Tomcat for example here: That then also leads you to the file DCS calls when this indicator is to be started, its init file in Scripts/HeadsUpDisplay/Indicator/init.lua. In that file you can find the "page setup", which corresponds to the sub-lua files in the same folder that DCS uses to render the individual pages of the indicator: The page of interest here is HUD_MAIN. Scroll up 10 lines and you can see the definition and which lua file is responsible for HUD_MAIN, its Scripts/HeadUpDisplay/Indicator/indication_page.lua. Thats the lua containing all the elements that are drawn on the HUD (the actual logic that plays these elements is in C++, not lua. Those are called "controllers"). Anyways, if you scroll a bit through that file you will see that all elements on the HUD use the material HUD_MAT: Materials are what defines the look and feel of these elements, including the color. Now you need to find the place where HUD_MAT is defined. If you scroll all the way up to the start of the file, you can see it including a lua file called materials.lua. So lets visit that file and check: HUD_MAT uses the color HUD_GREEN. Where is that defined? At the beginning of materials.lua, so scroll up aaaand: Edit that to your liking and it should hopefully work (the format is red, green, blue, alpha/opacity) [emoji106] (Btw, for indicator changes its enough to reload the mission, no need to restart DCS, just LCTRL+R or was it LSHIFT+R, sth like that) Cheers

Right, guess you have to bring that up with ED.

It should be modelled and I do remember testing it explicitly a few years ago. Could you send a quick track for the setup, would be useful, thanks :)

Odd, Jester code is not ticked when he is disabled. Thanks for the track.

Lemme drop this here just to show how much it is "not a laser beam" (sorry for the low quality, im on mobile. its from the radar video on the Heatblur YT channel) Pay attention to the "circular waves" around the main beam, especially the ones pointing down. Those are the sidelobes, they hit the terrain below you, reflect back and the system picks up their returns. Returns are displayed completely unfiltered based on distance on the screen, so they mix with your bandit. Also worth noting that the strongest sidelobe is going almost straight done, which gives you the so called "altitude line", any contact with a distance equalling your altitude is essentially impossible to lock. When a lock is commanded, the radar somehow has to know what you want to lock. And it has no idea what an actual target is, or what is just clutter. It more or less goes for whatever the cursor sits on. So if the target is sitting right between other returns, its very easy for the system to just lock one of the many other returns in the direct vicinity.

Well, you just said it yourself. There is a lot of clutter on the screen and the bandit is right in it. That clutter is from the terrain that is at the same distance to you than the bandit is, from the radar energy pointing downwards, as the radar does emit in pretty much all directions, its not a laser beam. Jester doesnt really play any role in the actual lock quality, he just hits the trigger while the cursor is over the bandit. Its the radar that performs the lock and in this case it locks side lobes because your bandit is right between clutter. (Also make sure you do not move much when attempting the lock, as the cursor needs to lead the target to compensate for the movement between sweeps)

Hard to guess without track but there is still plenty of energy going down on the ground, the radar isnt "pointy", you will get returns from almost everywhere, with different strength. Look at the terrain that had the same distance than the bandits, eventhough they arent close to each other the bandit will end up within that clutter because its at the same distance. Add gain-control into the mix and it becomes really hard to work with it.

Those are two different modes. CAGE/BST and CAGE/CAA. Latter isnt very reliable but is a vertical mode, while former is reliable but a boresight mode.

Yeah, those complains are all valid complains to the radar but not so much to Jester. A real WSO wont perform much better in these situations either. Need to adjust your expectations regarding that radar a bit.

yeah, known issue. ED needs to fix it, cheers

Im personally not much into the Tomcats history but what helps is to not think about the newly released A as "early A" but as the "standard A" while the existing A is a "late A". So its earlier than the existing, yes, but not early in terms of the As history at all. In fact, its the A as it was used for most of its time. Its the more representable A than the existing A, which is a late A rather.

Yeah, they arent "global" if done through code. The calls work slightly different than the ones from the DCS menu. Thanks for investigating.

Some guys on Discord reported that it works if the pilot radio is tuned to it. So this is now a known oversight that we will fix eventually.

It wasnt addressed in the hotfix. The hotfix was done and uploaded already before the original patch dropped. There is always like minimum 2 weeks or so between "we changed something" and "you can now download it", for stability and testing reasons.

Whose radio was configured for the tanker, Pilot or WSO?

Either case, it will be sorted out :)

Its just the sensitivity that needs tweaking after some engine changes and whatnot, it is now too low and hence you have trouble using it. We are on it [emoji106]

No. Maybe copy ur file when it was still good, as backup. What is the use case for that though? Like, what are you planning to gain from the persistence system if not the aircrafts current wear/tear? You can also always just delete the file or even disable the persistence system and you are back to a fresh aircraft.

It was rolled out 2 weeks ago, 4 patches ago https://www.digitalcombatsimulator.com/en/news/changelog/release/2.9.20.15010/

Did you land and fully shutdown the aircraft? The state is only saved when you do that. It is not saved when you crash or exit the mission in-flight or with a hot aircraft.

Yes. To me it sounds like you think we reject your request, but that is not the case. So please let me highlight: Your request is valid, good and welcome Ejection by pressing it 3x is the "norm" in DCS, we should and will offer it for the Tomcat Instant Ejection has valid use cases as well though, so we will keep offering that as well

I am a bit confused by your last message. Let me maybe rephrase my statement a bit: Thank you for bringing it to our attention and thank you for the efforts you have put into your report, including all the tracks! Yes, your observation is correct, it is currently a single press in the Tomcat It has been like that since day 1 of when the Tomcat released years ago (I know this is not relevant for this discussion but technically its not a bug then, as it is working as intended. It is instead a feature request - but again, this classification isnt really relevant for you, I understand.) Your request of having to press it 3x is totally reasonable, we acknowledge that The plan to move forward is to do it like it was done in the Phantom: to provide both binds - one for instant ejection and one for pressing it 3x. (For backwards compatibility reasons it might be necessary to leave the existing bind untouched and add a 3x ejection bind as new extra bind instead - will see, undecided at the moment.)

Its a known issue, was reported on Discord recently. Thank you

I dont fully follow your example. The system saves the entire aircraft state, all its 3000+ properties. That doesnt just include wear/tear but also literal state. For example if you turned the laser on or the position of the lense inside the Pave Spike camera or whether a lamp is currently on or not etc. Wear/Tear never reaches a state where something doesnt work anymore. That would be failures and those are decoupled from wear/tear and automatically repaired across missions. Your aircraft with maximum wear/tear will still work, it just will be a rough experience and performance of all components will deviate a lot from what they are expected to be (in both directions, underperform but also overperform). Details to the wear/tear system in the manual.

Uhm, but was it behaving differently beforehand? If not, I doubt this is a "bug" and probably more an intentional feature. Ofc the better approach would be to just offer two variants of binds: one for instant ejection and one for pressing 3x, as we did it in the Phantom. So thats a reasonable feature request