Aernov

Also, to add to the missing features list: - RWR filter modes besides LIM are missing (Offset is especially needed); - EHSD overlays are missing some information (the one that currently displays AAR zones should also show SAM ranges as F-18's SA page does); - Engine life count dissipation with corresponding performance decrease if the pilot is "mistreating" the Pegasus and not maintaining JPT/RPM ratings and their time limits; - IFF/ACNIP panel - at least limited functionality, or something like JF-17 has, please; - Self-protection jammer (the built-in one); - Ground power panel.

So, what is the purpose of these pumps? Just prevention of immediate shutdown at near-zero or negative Gs?

Is MiG-21 supposed to start and run it's engine with fuel pump switches off? Real procedure requires (or advises?) at least feed tank pump on before engaging starter, with enabling two other pump switches soon after engine idle RPM stabilization and AC generator becoming operational, in DCS engine can start and operate with all pumps off.

I have noticed several similar issues over the years. It seems that there is only one "screen" modelled for both MFDs, and sometimes symbology "gets out" of correct MFD and shows on the other one. It happened with EHSD stuff like AAR zones (if those were designated in editor) and waypoint sequences, especially if auto scaling is in use. Also, similar stuff happens on UFC, small elements of display symbology sometimes are visible among the keypad buttons.

Yes, I am talking about the knob that controls UFC displays (and maybe ODU, I don't remember) Other BRT knobs (MFDs, engine panel, HUD and HUD video, panel and instrument backlight and floodlights) are working correctly.

These control MFD screen parameters, and SYM changes symbology brightness. I was talking about UFC and BRT knob to the right of main UFC display.

UFC Brightness knob currently works as "on/off" switch, without the ability to gradually adjust brightness of UFC displays (panel lighting works fine). Attached screens show that UFC displays maintain max brightness regardless of BRT knob position. Also, there are little glowing bits of display symbology visible on UFC keyboard (one is marked on screenshot, there are others, appearing in different places on keypad, but they appear only in specific UFC modes, which I do not remember/use often enough). And one more question - should EHSD map mode symbology color change be applied to all MFD pages, or just to EHSD page itself? If it should, is there another way to change MFD symbology color (without going to EHSD-MAPM-color and back)?

Fxo and metashaders were deleted by me countless times, last time - after latest update a day ago. Also, after cleaning metacache and shadercache, repairing and launching DCS without PC reboot the issue did not occur. I somewhat doubt it's the end of it though. We'll see. Thanks for suggestions.

I have tried repairing, but I'll do it again for good measure. Should I delete metacache and then repair, or it will be created automatically on in-game terrain load?

Sometimes (usually when relaunching DCS or after playing something other) I get consistent and pretty significant frame drops (28-38 from usual 57-60 with VSync), decreasing graphics settings does very little (only decreasing preload radius seems to have slight effect), while GPU usage sits at around 40%-50% and all of VRAM (11 Gb) used up completely, regardless of map and number of objects in the mission. Also during such framerate drops I have noticed a significant increase in disc usage from DCS (high write rate and total write volumes of around 200 Gb after a few hours of flying). Attached is a log file from last occurrence of this "anomaly", and it contains this line: "2021-01-29 09:43:39.112 ALERT DX11BACKEND: Error: Can't find precompiled shader for effect enlight/radar.fx:DIRECTX11=true;USE_DCS_DEFERRED=1;. Recompilation process will take some time, please wait (this situation should not occur on end user PC, if there is no manual shader editing)" All shader editing I did was deleting "fxo" and "metashaders2" folders (and I have launched DCS a lot of times since this deletion, first launches had no issues), now "fxo" folder contains less than 2 Mb of stuff and metashaders2 is empty. This framerate/disc usage behaviour is fixed by reloading PC, just restarting DCS helps inconsistently. dcs.log

For startup, taxi and different types of takeoffs and landings, Harrier NATOPS is actually usable in DCS. There are some things that don't work or don't make any difference (especially since you can't damage aircraft systems with wrong procedures, and some checks and tests don't work), but in general you can use real life manual for general flying in DCS. For weapons employment and onboard combat systems it's probably better to use in-game manual, since those procedures are still not matching real ones completely.

The text is sure easier to see on, for example, EHSD page with map overlay (no need to decrease gain now), but actual readability of that text is decreased by thick black outline, which flickers slightly when pilot is moving his head relatively to MFD. There is no such effect on A-10C MFDs.

What about Harrier HUD issues that appeared after it's rework? (Sidearm lock marker is placed not even close to the locked target, DMT HUD marker is displaced lower and to the left while slewing the DMT, DME shows distance in meters)

When entering LAR with GBU-38 in TOO mode (haven't tested other JDAMs and target acquisition methods, but I would assume it's the same), accuracy readout (or LAR percentage, as it is called in Chuck's guide) begins to count towards 100 and reaches that at about 9 o'clock position of HUD range ring, which seems pretty normal. Then the percentage goes down and gets to zero at 6 o'clock range indicator position, which, I would assume, should be optimal release range. And then it goes back to 100 at near 3 o'clock position, very close to minimal release range. I'm not sure if first 100 readout is correct or too early, but zero in the middle of LAR and 100 at the edge of minimal range seems wrong. I have reported the same behavior earlier, but the issue (?) remains. Attached are three screenshots with described "stages" of LAR percentage readout. Track file is too large for the forum to upload (9,5 mb), but it is not necessary, this behaviour is consistent.

Is it possible in real aircraft to remove RWR contacts indication from HUD without turning RWR off? Or it is a kind-of compensation for lack of dedicated head-down RWR display? Also, when can we expect remaining RWR modes? At least Offset, please. Radar-rich environments make threat rings unreadable and Limited mode often hides things I still want to see.

Is turbine supercharger behavior correct in it's current version? I have noticed that during climb it just keeps manifold pressure at a set value without moving boost lever, increasing turbine RPM on its own. I have started climbing with turbine off (boost lever full aft), until max throttle was not sufficient (MP fell below 40'') Then I have advanced boost lever to set MP back to 42'' (turbine RPM rose slightly). And that was it, during climb to 20 000 ft I have not touched the boost lever, manifold pressure remained at 42'' (it even rose to 43-44'' near 20 000 ft) and turbine rpm was rising as well (throttle was maxed out whole time, only thing I did is closing intercooler flaps). I thought (based on "experience" with P-47 by A2A Simulations) that you would need to continuously advance boost lever to keep desired MP during climb (just like throttle with geared supercharger). And at 20 000 I have tried to decrease throttle without touching boost lever, and it had no effect on engine instruments readings. Also, shouldn't it be possible to reach takeoff MP (52'') with throttle alone? Now it maxes out at around 47'' at airfield elevation of 105 ft.

Log file from that crash is attached.

A1-AV8BB-NFM-000 NATOPS: "...When the lever is moved aft to the hover stop the nozzles are set for hovering. The position of this stop gives a fuselage hovering attitude of about 6 1/2°; i.e., the nosewheel slightly higher than the main wheels.The engine datum is at 1.5° to the fuselage datum. The nozzle angle for hovering is therefore 82° from the engine datum. A nozzle braking position, at 98.5° from the engine datum, can be selected by lifting the nozzle lever over the hover stop and pulling it back along a ramp." I have read somewhere that hover stop nozzle deflection may vary from 81 to 84 degrees. Do you ever hit your tail when landing at 81 degree? Or this is for moving surface landings?

Yeah, I won't actually try to mess with regedit and change user name, too much risk of messing up a lot of things. I'll wait for a soluton from HB. Thanks for the help with identifying my problem.

So, I have created new user creatively named "Test user", and Viggen worked fine... DCS_AJS37 folder was created automatically, and was empty. Attached is the log file with correctly identified Saved games folder. dcs.log I'll try to change my main user name to latin-spelled one. dcs.log

Well, this leaves two possible solutions: changing system language (which I do not want to do), or changing user (which will mess up a lot of things)... What bothers me is the fact that Viggen worked without an issue a few months ago, and there were no changes in user name, language settings and soft/hardware.

So, I'm getting some kind of error even before the game reaches for that folder?

Good nozzle angle for landing on stationary surface - 83 degrees. It may be a little easier to control the plane at 82 degrees, but touchdown attitude will be slightly more nose-up (not enough for tail strike though). When landing on a moving surface (ship), I usually do not try to maintain horizontal velocity with pitch alone, and set my nozzles at an angle that allows to match speed with the ship with minimal use of pitch-down (usually around 80-82 degrees). Angles more than 84 are used for jet braking, usually after conventional landing or FNSL. Also, in my experience, it is easier to control and stabilize with "preventive" corrections: if you feel that AV-8B is going to bank left in a moment (maybe after too strong previous correction, or when stopping lateral movement or using yaw), make early adjustment, with experience you will notice that you are already making these preventive corrections at the moment of an undesired oscillation occurring. On takeoff with 82 degrees there is no backwards momentum, in fact, I usually apply some back stick to stop forward pitch.

In that example, special characters were not in the user profile or Saved games folder name, but in-game, in someone's username in multiplayer, and his name were used in custom F10 map markers on server. My folder name is being recognized by the system, all other games (and all other modules in DCS, even by the Viggen prior to the last few updates), and searching for "Saved games" directs me to correct folder too, even though it idisplays the name "Сохранённые игры" for me. Can this issue be caused by the fact that my DCS_AJS37 folder is empty? And after reinstalling it this folder was not created automatically, even after game launch attempt.

This occured in multiplayer, I was trying to get a lock with Mav-F in evening (during the day it somewhat reliably locks targets at 5-6 nm, in twilight I was unable to lock anything even from 2 nm, but this is known and reported already), was unsuccessful and jettisoned two Mavericks I had on inner pylons (via STOR mode and manually selecting pylons 3 and 4 on ASCMI), continuing my attack with one remaining Sidearm. I haven't noticed that SOI was still set to IRMV, and tried to slew DMT TV camera on target, and DCS crashed immediately after I moved TDC stick. Attached .png is the last thing I saw before the crash. dcs.log-20201025-110007.zip