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