Aernov

It looks like a cutout because it casts shadow on itself but not on the ground making it look like it was pasted over clear terrain image (what's up with little "partial angular shadow" to the right of antenna - I don't know), illuminated side looks normal to me.

Screenshot was taken on Normandy map, with terrain object shadows set to flat. Brick shelter (left) casts a shadow while concrete one (right) does not, and it seems to hide radar shadow too. It has a proper shadow on grass, but none on terrain surface.

Here's the name of the file that it seems to be rewriting constantly: Similarly named files in that directory have a size of 1 kb, some of them have .txt file with the same name and "TXT" written in it )

For a long time I am experiencing strange disk write activity from DCS client: Normal parameters - disk write rate fluctuates from < 0.006 to 0.6 MB/s during gameplay, But sometimes (recently - almost every time) I get unusually high rate from 3+ to 6+ MB/s for entire time DCS is running a mission (increasing in cockpit and seemingly depending on scenery in view), returning to normal rates in menus and mission editor window. It usually has almost no effect on performance, but can degrade SSD lifetime if left as is for every flying session. Some time ago people recommended me clearing shader files (standard FXO and Metashaders2 in Saved Games folder, and from Mods/Terrains/[map name]/MIsc/Shadercache and Metacache) and running repair afterwards. This procedure used to help, eliminating the issue for seemingly random amount of time (from months to a couple of game launches), but recently (maybe from the last update) the issue has been occurring almost every time I launch a mission or enter a server, and clearing shaders + repairing doesn't help most of the time. I've tried client repair, full reinstall with registry clearing, disabling all addons (I have SRS and Tacview, disabling and uninstalling those does not affect the issue), and clearing shaders multiple times, with no effect, or sometimes, after PC restart, for one game session. I have no mods, and currently no custom liveries or kneeboard pages and such. RAM is 32 GB, no pagefile is present on this SSD. Below is my DCS Log from today attempts - none of them (3 or so attempts) were without the write rate issue. dcs.log

After some further testing, formation lights do this in NVG mode too, it's just too dim to see during the day.

Even if FORM knob is turned OFF, formation lights are staying on with low brightness (but still visible in daylight) when NORM external lights mode is selected, as screenshots below depict. Formation lights in NORM mode with brightness knob in OFF position (I didn't touch the knob during cold start): Otherwise formation lights are working properly after one of the recent updates (in NORM mode they are way brighter than in NVG mode, this used to be reversed, but is fixed now).

[Not sure if this is a bug or just not implemented yet] As per tactical manual (NWP 3-22.5-AV8B volume 1) section 2.15.2.5.2, if multiple IR Mavericks are loaded and quantity selector on ACP is set to more than 1, after first IRMV launch (with normal procedure and manual uncaging) second and subsequent Mavericks (as many as QTY is set to) should automatically uncage and slave to designation. I was unable to reproduce this behaviour in DCS.

It was working last time I checked.

If I remember the modes correctly (and I learned what they do through experimentation) - S - single, P - program, M - Multiple(?) - single release from each selected dispenser with flares in it, G - Group(?) - program from each selected dispenser loaded with flares, R - Reserve(?) - looks the same as Single. By "selected dispenser" I mean the position of EXP switch (UP or DWN), all modes will release from selected ones.

My usual setup - Chaff: BQ 3 BI 0.3 SQ 2 SI 1 (or just 1 salvo with 6 rounds and 0.3 sec interval, and I usually load 4 blocks of chaff if I'm going to be flying around SAMs), and for Flares: BQ 4 or 6 and BI 1 second for "P" mode (to prevent overspending, just remember to repeat release command during the attack. If you see a launch, you can quickly press flare release a few times, each press will release a flare and the last press will release a full program (well, each press commands a program, but previous ones get overridden by subsequent ones)). Sometimes, when I'm sure I'll be under IR missile attack, I use "G" release mode, which releases your program from each dispenser filled with flares (so, in default loadout - 4 flares per burst).

There are P JAM and CW JAM advisory lights that indicate DECM pod emission in any mode (RCV or RPT).

Won't current "RWR" be completely replaced by a proper EW page?

Evreux, weather was mostly default, some broken clouds preset, 29.92 InHg, little to no wind and turbulence and +20 deg. C.

In multiplayer mission on Caucasus it worked fine for me too just now. The mission that had this issue was made in mission editor, Normandy map, there was a single P-47D-40 (cold start on the ground) and about 10 trucks (Opel Blitz), I didn't save it.

As title says, neither the actual knob in the cockpit nor keybinds change altimeter pressure setting. Test was conducted at Normandy, singleplayer.

You can move existing point (waypoint/markpoint/targetpoint) in EHSD DATA subpage in INS mode with TDC. You can't make a point by pointing at the map with a cursor ('cause there are no cursor).

In TPod HOTAS mode I have created T0 on the target vehicle (TPod designation + WInc long). Then I pitched the plane down until velocity vector (or probably TPod boresight axis) crossed the imaginary line from TPod to target, and Litening camera head did a 360 rotation, during which the tracked point/area shifted continuously and stabilized on the new location slightly away from the initial designation (or quite far away if the altitude is low and distance to designation is high, or if mountains are in the way). And because T0 updates automatically after the first WInc long with TPod designation, I had no way to easily return the TPod to previous designated point. AV-8B TPod T0 shift.trk Also, in multiplayer on Syria map I have encountered a continuous TPod designation drift while doing a 360 turn to re-attack after the first LMAV launch. Turn was made at <1000 Ft, with no more than 2 G, and when I rolled out hot on target, I found my T0 who knows where, but not where I have left it before the turn. Also, during the next turn I observed a constant designation coordinates change on TPod page during the turn. I was unable to reproduce it on Persian gulf in singleplayer, so no track file.

AV-8B LMAV uncage.trk Seeker pattern kinda slaves to existing designation and returns to "default" elevation if no designation is present. But changes in elevation are happening only during caged periods, if seeker is uncaged it will stay at a fixed pitch regardless of designation position and can't be slewed with TDC no-action. Also, search pattern width can't be changed with OSB on the LMAV page (this function works on DMT LST screen - Wide-Narrow-HUD, but on LMAV this button does nothing).

"On Radar and Night Attack aircraft, the formation lights operate in the visible mode when the exterior lights master switch is set to NORM and in the covert (NVG) mode when the exterior lights master switch is set to NVG" - A1-AV8BB--NFM--000, 2.11.1.3 "Formation Lights"

Is it even possible to get such ranges from what is pretty much a Mk.82 with extra stuff (which doesn't help it glide or makes it more aerodynamic)? Dropping it from like 30000 ft at Mach 1.5?

It is like that for a long time.

I never questioned this cooling drop on TPod activation because of how TPod is wired like a Maverick ) So, IRMVs should cool down all the way after first selection regardless of following page changes?

Currently LMAV page returns to TPod feed automatically, so I didn't try SSS press twice. Auto-return works fine and lasing doesn't stop, LMAV hits intended target.

When looking into the canopy lock latch viewports on the sides of the cockpit (or by looking at the latches with canopy slid backwards) one can see that locked and unlocked positions are reversed (function is correct, just the model error). Reference - AV-8B A1-AV8BB-NFM-000, Figure 2-25. From the viewports: From the outside:

If at the moment of pressing CM Flare or Chaff commanded release was impossible (either because required expendables are not present - spent or not loaded, or if EXP selector knob is inhibiting release from the only group of dispensers that contain required CM type (for example, UP selected and no flares in upper dispensers)), that release command gets "stored" and is executed at the first chance in the future, either when needed CM type is loaded or EXP selects correct dispenser group. AV-8B CM release command stored if inhibit.trk In the track - quick start "Ready on the ramp", standard 120 flares 60 chaff loadout (chaff is only in the two of the UP dispensers). I made chaff release program (burst 4 interval 0.3 salvo 1) to easily see the release. With EXP in ALL or UP program releases immediately, in DN - no release, but when knob is returned in UP or ALL - program releases immediately, no matter how long the interval between the command and release possibility. Only one last command is stored. Also, should EXP knob straight up prohibit release from unselected dispensers? Shouldn't it just set priority to the selected ones? If I have flares in top and bottom blocks, select upper ones and spend all the flares in them during attack run, I will be unable to immediately continue flaring until I remember to turn the knob, even though I still have 60 charges on the bottom? How does it work in the real plane? In my opinion (that is not supported by anything except my guess), this EXP selector logic would allow release from unselected dispensers if required CMs in selected ones are spent, just to prevent life threatening issues in emergency situations.