Rissala

Hi, The transition to STT in these modes should be pretty much instant when the scan sees the target (this is a subjective statement, but read this as comparable to F16 etc). Many updates ago, the ACM was very snappy and comparable to other modules in DCS, and I did not see this "track box" drifting off target at all before STT. Some of the examples I posted here are a bit extreme, but in the first video, the second to last example (at 0:15) has me dragging the boresight circle at just under 2g over the target and failing to lock it since the track box moves away with the aircraft. I'd like to see some ACM lock-on tuning, but I can't (obviously) give you anything else than videos and tracks to support this issue. It is pretty much your call to where you want to go from here. Thanks.

Here is a more dogfight style example. I wonder if this is related to CPU performance. I am running a 2017 7600K @ 4.4 GHz and 32 GB of RAM. Here the radar attempts to lock on 4 times in vertical ACM scan. ACMdogfight(2).mp4

Hi, This is what I see in the original track. I did do this with vertical scan as well but the video file is too large to post here. ACM locking.mp4

Hmm. I used boresight and vertical modes to demonstrate this in the track. I'll try to make another one.

ACM mode has lockon issues when having any angular velocity with respect to the target. STT lock is very slow compared to other aircraft in DCS. The initial "track box" which is created drifts off target before a lock can be achieved. This causes issues in a dogfight. ACM lockon.mp4 ACMlockon.trk

At supersonic speeds, the plane feels almost dangerous to handle since pulling over 10gs without touching the paddle switch happens very fast. Here is a track where I do maneuvers at medium A/C weight and then at very light A/C weight. With some fuel and stores onboard and at supersonic speeds, the plane exceeds the G limit of 6.6 by ~4g with smooth aft stick. With very light weight, the exceedance over the limit is almost ~3gs with smooth aft stick and ~6g with oscillations . The controls indicator is shown in the track. Max G pulled at supersonic speed was 13.2g. I am aware that it is easy to go past the limiter, and that is completely understandable. This is IMO just too much. It takes the FCS around 1 to 2 seconds to catch up with the new state of the A/C and only after that can I pull full aft stick without having to worry about structural damage. overG.trk

To add to this, the flaps refuse to aid in roll when in AUTO mode. Flaps move in opposite directions: No movement at all: flapsauto.mp4 This is a checklist item to move the controls left and right before departure.

+1 for core 0 toggle. The difference is smooth 62 fps and unplayable stuttering. I have to do this every time I launch DCS. I have the the excact same processor and RAM amount as you.

If this is true, I take my word back. @Urbi your point makes sense. Can we have someone absolutely smash the gear and provide a track here :D? I think that would be sufficient evidence if it truly is only the left MLG.

Someone needs to produce a track for this to move forward. This does not happen to me when landing under the max landing weight. Your plane in the pic has a full missile load with a drop tank. Check your aircraft weight (checklist page) before landing, and if needed, dump fuel. The limit is not a suggestion. And with the new suspension model, you cant ignore it anymore.

Yes I am aware that this is a superbug. The cockpit lighting is the same in the legacy Hornet (which the superbug is obviously based on). I could not find pictures of the legacy Hornet cockpit with lights on, so I used that as an example of what it should look like. I already discussed this with BN sharing my insight. This topic is here since I don't know if the US Navy retrofitted their entire Hornet-C fleet with green backlights before 2004 and also because this is not really a bug. The true answer could be that some were retrofitted and some were not.

I already PM'd @BIGNEWY some evidence. Thats all I can say.

Those are not console panel lights, those are instrument panel lights. That is what I tried to make very clear on my first reply. Your photo shows the instrument panels. The instrument panels do have a green colour and that is correctly represented in the game.

I found 1 picture online of a simpit that has the correct lighting.

Currently the console lights are the same colour as the instrument panels. Don't know if this applies to all Hornets but in the F/A-18C, the console lights (not instrument) are this "Boeing amber" colour, the same as in any legacy Boeing airliner cockpit. This is the entire purpose of the NVG switch, as the amber colour is not compatible with NVGs. I don't know if the US Navy retrofitted the consoles with a green light filter but the base configuration has amber lights.

Happened to me again today. The missile instantly locks on to flares on my end. However, server side, the missile does not get fooled and I get shot down by a ghost missile. This happened after an hour of flying so not sure if this track will work. I hope the new replay system works. This bug, at least for me, instantly kills any fun I'm having in DCS, since it is literally like getting shot down by an object that does not exist on the client end. The way this bug happens is very similar to the first comment I made in this topic, but here it is even more obvious. As already stated, the bug only happens on multiplayer. Caucasus-20240203-160713.trk

It isn't even classified. This is just basic group shared data like fuel, armaments and so on. I think we might actually see some developments soon, as ED is implementing more DL features and DTC.

+1 on bad frame time stuttering after 2.9 i5 7600K with 32 GB of ram 1070 8GB

This video was taken on BF 80's server. My ping is around 20-30ms, so this is close to a best case scenario for the connection. I have traditional cable (not fiber) internet. My PC is connected over wifi. As you already know, this is a difficult issue to reproduce as it is rare, and only affects MP (AFAIK). MP trackfiles do not replicate well after maneuvering hard few times. I have similar videos of this happening with SU-25T and A-10A. My guess is that the server can somehow roll the countermeasures "dice" completely seperately from the client side. I have very little time to play DCS these days . I hope someone who has more free time to spend can take a closer look at this.

Still "correct-as-is"? To reproduce this issue: Spot any target at some range (preferably in TWS so alt is shown) -> open AZ/EL page on the left -> move antenna elevation so that the target is just about not inside altitude range -> observe that the AZ/EL page still shows the target inside the radar fov (yellow box) -> the discrepancy is that attack radar page shows that the target is outside the scan range while AZ/EL shows the target inside the scan range

Yeah, had to shine some new light on this old issue. The reason I created a new thread is that, as you stated, there were many incorrect conclusions made by different people in that other thread which caused it to become cluttered. This one is straight forward, focuses on one issue within the A-G radar, and is easy to replicate. We are soon going to have 2 modules (F15E and F16) that both get a functional and working implementation of A-G radar while the Hornet system has remained broken for years. So I politely ask anyone at ED: Are you able to reproduce the issue or not? It is time to take a few steps forward on this bug beginning with acknowledgement.

When scanning a target with EXP3 in the Hornet there are multiple issues with generating the EXP3 SAR map. The scan stops entirely at certain angles and is generally unreliable. The FRZ option does not freeze the frame as the map is glitching on its own. Videos & track below. vid2.mp4 vid3.mp4 vid1.mp4 AG radar issues.trk

This has been a long time issue in multiplayer. It is possible for the server and client to have different interpretations of IR missiles going for countermeasures. In practice this means that when you flare, you see the missile go for the flares and miss but server side the missile never went for them and you get hit. As this is a MP issue, I do not have a track available. Missile desync.mp4

ST First of all, nice update for the Viggen! There is a slight inaccuracy with the tertiary air hatch. When using reverse thrust, the hatch closes which should, according to my understanding, not close. (how would the exhaust exit forwards otherwise??)

I have been noticing that the AH-64 seems to be the source of many of my crashes. The crash logs state many errors relating to this module just before the actual crash happens. Here are a few examples: ERROR DX11BACKEND (9380): Failed to create shader resource view for /textures/AH-64D_balka_1_D_Normal.dds. Reason: ERROR DX11BACKEND (9380): Failed to create shader resource view for /textures/AH-64D_balka_1_D_map.dds. Reason: ERROR DX11BACKEND (9380): Can't load image '/textures/AH-64D_balka_1_FLIR.dds'. Reason: ERROR APP (Main): Error: Unit [AH-64D_BLK_II]: Corrupt damage model.