Blackdog

Using fade as a second variable to fine-tune visibility does seem the obvious solution, and shouldn't be hard for them to implement. Seems like ED has pretty much been served a fix to a major shortcoming of their simulation on a silver platter here -- hopefully they choose to partake.

Thanks Flappie!

Hi Flappie, this is clearly distinct issue from the other bug, and is not related other than they both happen to involve a setCommand callsign change. The other issue is multiplayer only, existed before 2.8, seems to be client-sync related (different clients can 'see' different things), and impacts the actual function of the unit (in that the callsign change doesn't happen) for the client experiencing it. This issue is specifically to do with the new 2.8 F10 labels, happens in both single player and multiplayer, and isn't related to the actual function of the units and their callsigns. It is a much more straightforward issue that other one: The F10 map callsign labels don't change (single player or in multiplayer). It is unrelated to the function of the units themselves. To put it a different way: The other bug is a problem involving the actual callsign change, this bug is specifically an issue involving the new 2.8 F10 map unit labels. I was the one that provided the .miz and details to reproduce the other bug, so I'm very familiar with both If I can elaborate further please let me know. -Blackdog

dcs.log Since the reply was not 'we are aware of this' I will second the observation that render layer and/or texture load in times are definitely much slower for me in 2.8 as compared to 2.7 when jumping into a 'Client' slot cockpit (and in mission editor and in-mission maps for that matter). Anecdotally I'll note that folks in my wing complain about this too. For whatever reason it does not seem to happen with a 'Player' slot (perhaps happens in the background). DCS log attached (freshly repaired unmodded DCS Open Beta, normal shader cache locations had been cleared out after latest update -- deleted dcs.log, launched DCS, loaded the map in the ME, launched the map, slotted into the F-16 client slot and waited for the image to appear normal, exited game, attached the dcs.log). This was done on a mid-range machine, but it takes about the same amount of time to fully render the cockpit image on my 'beast' machine that I normally fly with (4090, m.2 gen4 SSD, etc). (screenshots were taken on a subsequent run as not to influence the logs, but demonstrates what is happening on screen during the 5 seconds that render layers / textures are loading in)

The callsign name displayed on the new map labels don't change from the callsign that the unit had in the ME when the unit callsign changes (either pre- or post- Activation). This is very unfortunate for anybody trying to make sense of the map (especially if they are trying to GCI) for complex missions. Callsign 'changes' frequently happen in mission scripting where late-activated groups/units are used as templates for dynamically spawning many groups -- as a result, dynamically created units created from such templates all stuck with the callsign map label of their template. I've attached an very basic example .miz to demonstrate the problem. The 3 tanker units are placed in ME to late activate with "Arco" callsigns. At 5 seconds setCommand is used to change their callsigns to "Texaco" just before activating them. You can click through the units and see that even though their callsign has changed to "Texaco-X-X" the map label still shows "ArcoXX". At 15 seconds setCommand changes them to "Shell" callsigns, and as you click through the 3 units you can see they have "Shell" callsigns but the original label has still not changed. The labels don't update even if you start in, for example, a jet slot then switch to an observer role after the callsign change has occurred. TankerSetCallsignTest.miz

If you want kind of best of both worlds, might check out the IceGiant ProSiphon Elite -- kind of big, but cooling as good (or better) than a big AIO without the pump using gravity/thermosiphon, so only moving parts are the fans. FWIW 5800X3D can be overclocked via a couple different methods to as high as 4.7+ GHz with certain motherboards (ASUS X570 Crosshair for sure, possibly others).

Well, this explains a thing or two

Just bumping on behalf of a discussion on the Varjo Discord, this would still be of very much interest to Varjo headset folks.

Thanks Flappie!

Sorry for the delay, I got onto other things and somewhat forgot about this thread. Here is a dead simple example .miz that I was able to reproduce with on our wing's server. Loaded .miz on server, connected, slotted into the F-16, waited a bit for the trigger with the 'time more' to fire, then pulled up the Tanker radio menu and they were all 'Arco 1-1', same bug as described previously. TankerSetCallsignTest.miz

Are there plans to update the SA-15 intercept capabilities? It seems currently whether or not an incoming munition can be targeted is based on whether or not DCS categorizes the target as a 'missile'. While different revisions of the real-life Tor have different capabilities, the real-life limiting factor of any particular version is likely the radar cross section of the target, and in that regard, if it can intercept a Hellfire (which it can in DCS), then it should also be able to address an incoming free-fall bomb -- and public information seems to support that (some versions anyway) can target free-fall weapons. In my experience (in the context of a virtual wing), the current situation creates bizarre artificial-feeling weaponeering meta during mission planning, artificially favoring free-fall bombs vs anything classified as a 'missile' vs SA-15 defended targets.

@Flappie I've been digging into this a bit more, I believe it is the same bug as this: Also on the MOOSE Discord, I came across this -- in retrospect, I believe this matches (and definitely fits in the case when I generated the trackfile):

Same DCS recenter VR keybind -- hit it once and you're good to go. Not sure what you mean by the OpenXR menu, but Aero uses SteamVR for tracking, so that's why you see the OpenVR pop-up.

To be clear on the reproduction rate, it doesn't happen 'most' of the time, but we do see it fairly frequently. Frequently enough that it happened the first time when I tried to reproduce it to make the track file, and our pilots report it fairly often.

Hi Flappie. The .miz from the track file has been added to the OneDrive link at the top of my post. Reproduction is not all the time for us but fairly frequent. To reproduce, connect to the server, slot in, and give it a bit for the scripting to load everything in. If things are working correctly you'll see Texaco1 and Texaco2 flights in the tanker comms menu, if you are reproducing it they'll show up (and communicate as) Arco 1-1, but only to your bugged client connection. Texaco1 is on 251.0 and Texaco2 is on 252.0. Thanks, -Blackdog

Track files too big for forum software, available here: https://1drv.ms/u/s!An0uZhCNQrORedfA9AS0aZqQ2Ng?e=PIbCbV In our missions, we use the API to spawn and set up callsigns for tankers via setCommand/setCallsign API call. Our pilots are intermittently but fairly regularly experiencing a bug where all tankers have callsign ‘Arco 1-1’ regardless of their real callsign, both in the comms menu and during the actual comms with the tanker(s). Simultaneously unbugged clients will have the correct callsigns. Unbugged clients tuned to the tanker frequency overhearing comms with the bugged client will ‘hear’ the correct callsigns. A re-slot does not fix a bugged client, but a re-connection generally does. We set up a ‘control’ tanker (Texaco9) created directly in ME, and it seem unaffected. In the attached tracks, the longer track file is a ‘bugged’ client connection. The shorter track file is from a wingmate who joined and recorded a track from his client. At about 09:48 mission time in both tracks, you can see the same tanker comms where the ‘unbugged’ client ‘hears’ the correct callsigns, while the ‘bugged’ client hears ‘Acro 1-1’. Attached screenshot crops from ‘bugged’ and ‘unbugged’ clients connected to the same server. Blackdog (51st VFW)

Was reminded of the term 'diurnal crossover' -- would be awesome if thermal simulation in DCS accurately reflected the IR visibility of 'passively' heated/cooled objects including vehicles in relation to a (plausibly) realistically modeled thermal environment, regardless of mission start time. The already mentioned (by ED) future ability to set thermal state of a vehicle at mission start in ME would be great as well. I very much enjoy having to make mission planning choices around HMCS/NV, and having to adapt and make hard choices about TV vs IR mavs, for example, because diurnal crossover during the course of a mission would be awesome.

I originally submitted a report because I thought there had been a WHOT/BHOT regression -- Turns out that I was just unaware that non-moving units started 'cold'. However, I've been playing with it, and something doesn't seem right with regard to ambient vs unit temperature with these 'cold' starting units. Screenshots all taken same NTTR mission with just the time/month/temperature changed, screenshots taken immediately after pushing AG/CCRP and zooming pod at mission start -- everything (including TGP settings, which I didn't touch other than to zoom in on the target) is the same. The 'day' image is July, 3pm, temperature as hot as ME will go (50 degrees C). So far so good, the ground would be very hot, and so would a unit sitting out in it baking -- I wouldn't expect a ton of contrast. The night picture on the other hand is taken at 4AM in January with the temperature set as low as it will go in ME (-1.3 degrees C)... and doesn't pass the smell test for me. During cold clear nights, ground temperature is generally colder than the air temperature -- I can't think of how a vehicle would become significantly colder (stark FLIR contrast) than the surrounding ground. It looks to me like the 'cold' vehicles need to have their initial temperature set in a way that more closely reflects ambient conditions -- especially in the night/cold. Hopefully this is taken in the constructive context in which it is meant. -Blackdog

Thanks for the info, that's awesome.

In today's patch, TGP WHOT/BHOT appear reversed again. Addendum: May be more nuanced --- just saw a wingmate's screenshots, and his WHOT/BHOT appear as I would expect -- perhaps day/night?

Should be able to de-saturate each axis until max ministick deflection is the 'fastest' you want it to slew, then add some curve if you need more fine adjustment near middle.

Tested 16.2 with the current patch -- appears to have fixed the left-eye NVG/TGP issue. Thanks! (Sorry it took me to long to test!)

Appreciate it!

I will when I have a chance.. don't fly either, would have to D/L and look up how to bring up the TGP.

So, love the NVG part of this with the Viper (though would love some up/down adjustment). However as soon as I bring up the TGP on my MFD, the left eye NVG image starts flickering and goes double (second NVG circle to the left, and it appears that maybe it flickers back and forth between the two on the left eye). I'm using OpenXR on the Aero, so realize I'm a bit of a corner case, but if anybody else has come across this and has any tips to workaround this, that'd be awesome.