Eihort

While I agree SA-10 is supposed to work somewhat like this, where you only get a tracking warning, however even the bugged implementation is working incorrectly as you don't get even that reliably. Not to mention that it's doing this with systems it has no right to. Conversely, "balance" for the sake of it at the cost of realism doesn't belong in a simulation. This isn't War Chunder. Acheiving any kind of "balance" is the job of the mission designer, in determining every relevant aspect of the enemy forces from TO&E to skill levels and engagement zones to triggers etc. This bug isn't adding anything "real" at all. It's a bug and should be squashed. You want to fly with less sophistcated RWR equipment, there are platforms in the game that model this already.

I can confirm this as well with the SA5. Currently unplayable in Multiplayer.

I seem to only be getting track warnings, no launch warnings in both F-16 and F-18. Can confirm for SA-8, SA-10, and SA-11. Haven't tried air to air yet.

Okay. Seen this happen on multiple maps, in multiple circumstances, across multiple aircraft. No idea what's causing it, either dedicated server or client hosted. Some of us will be flying along just fine, and then it's like the Kraken/Klang/The Worm will come find us and just erase us from the sky in some exotic turbulent fashion. Tacview and trackfile included in this case. And it won't be all of us. It'll bop some in formation and not others. It'll happen at different times into missions. We have no clue what this could possibly be, and a few of us have been trying to isolate it. I thought it might be something weirdly exotic like the carrier hitting a waypoint, but there's no carrier in this mission. I'm in an F-16 and Tacview caught my last frame at an AoA of 50deg at 0.7M. Anyone else literally running into this bug? Tacview-20230223-195234-DCS-Client-TThurs0223.zip.acmi TThurs0223-20230223-195219.trk

Update: The RWR in the EE is also exportable as LEFT_MFCD

Sorry about the delay. Went on vacation there in the middle of that. Aaaaaaand.... That... didn't seem to make a difference...

Update: The server being empty might be irrelevant. Perhaps load times, as when I first enter, it takes longer. When I back out and reenter, the terrain is loaded. I'll try the "mission editor map preload" trick before joining religiously and see if it occurs again and report back.

.... I think you're onto something. It looks like if the server is set to be paused when empty, the first person to get on after someone has already been on, registers as Tacview as not being installed. The very first user after DCS mission start or every user after the first that unpauses it won't see the 10 minute delay. I did your login/out solution with an empty dedicated server, and it wouldn't register as running. I just logged on again for party time with the boys, and I got the 10 minute delay as I was first. Others popped on. None of them reported the delay. Then I tried your login/out solution with someone staying in the mission, and it worked.

Line in question seems to be at 2022-08-11 01:23:21.678 INFO TACVIEW.DLL: Tacview is not installed on the host. Reconnecting never seems to fix it for me. Only restarting the server does. dcs.log

We set it to pause when it's empty. And just happened again. Other players are fine, but yet I'm on a 10 minute delay. serverSettings.lua

Pardon the subject line, but wanted to be absolutely clear. This seems to be directly tied to how "busy" a mission is with objects. In single player with a nearly empty map, the bug doesn't seem to be there at all hardly, until I hit the TEL switch, then I drop down to about 2-3 FPS for about 5 seconds, then it stabilizes and everything is fine in the simulator. I can switch away and back with no FPS drop at all. During a multiplayer mission with a lot of objects however.... The moment I put the radar into Standby it's a slide show of about 1 or less FPS for about 10-20 seconds, but then the same behavior. Once it stabilizes, it's fine. I can switch away and back, even shut it down, and start it up again without this problem. However once I go to another mode, such as with the TEL switch especially, I get the slide show again for the 2-3 FPS, this time for about another 8-10 seconds before it stabilizes, then I'm fine. I can do this on the ground before I take off to minimize the impact to my gameplay experience but... this is making the aircraft nearly unusable for anything other than ground attack for me, as when I do lock onto an enemy aircraft, it seems to consider it a different "mode" and it does the slide show routine again. I've got an i7-5930K @ 3.5ghz with 32GB of RAM and DCS running off an SSD. DxDiag attached, and a Google Drive link to the trk file of the large multiplayer mission follows. I only have this kind of problem in the F1, and I own and fly damn near everything. Viper, Hornet, F-14, MiG-21bis, Mi-8, Mi-24.... https://drive.google.com/file/d/15kOS2NSAKp9DVWaOUBo6KlichqIDUrp0/view?usp=sharing It almost seems like you're hit-scanning everything in the mission or something in every state, then throwing out the irrelevant stuff. DxDiag.txt

okay, here's the file. It's a bit long, but at the end of it, starting around 2022-08-06 01:57:15.78 I connect, and it told me that it wasn't installed. I disconnect, manually remotely restart the mission (just a stop-start. I didn't restart DCS dedicated server process, or reboot the server), reconnect, and then it said everything was fine. If I had to guess, this seems to be connected to long server runtimes. dcs.log

Well I didn't want to show that I don't have a password, but on the real server config it is blank. Still happens. Some clients connect no problem. Some connect and receive a warning that tacview isn't installed on the server and imposes a 10 minute delay, which is of course patently false.

Okay. I'm at my wits end. I've seen the other threads in here about it, and tried the fixes, and they work for a while, and then suddenly don't. I have a dedicated server, and for some clients, they have a 10-minute delay, and some do not. I want no one to have a 10-minute delay. Options follow. ["Tacview"] = { ["tacviewDebugMode"] = 0, ["tacviewRemoteControlPort"] = "42675", ["tacviewFlightDataRecordingEnabled"] = true, ["tacviewRealTimeTelemetryPassword"] = "xxxx", ["tacviewMultiplayerFlightsAsHost"] = 2, ["tacviewTerrainExport"] = 0, ["tacviewAutoDiscardFlights"] = 10, ["tacviewRemoteControlPassword"] = "", ["tacviewSinglePlayerFlights"] = 2, ["tacviewBookmarkShortcut"] = 2, ["tacviewRemoteControlEnabled"] = true, ["tacviewRealTimeTelemetryEnabled"] = true, ["tacviewRealTimeTelemetryPort"] = "42674", ["tacviewMultiplayerFlightsAsClient"] = 1, ["tacviewModuleEnabled"] = true, }, -- end of ["Tacview"]

Any word on this one in particular? I was really looking forward to this part of it myself. Not that any of the items in the previous posts don't pique my interest!

signed

Disregard. I can't reproduce this now.

Multiplayer, Syria, Cold-start. After startup and airborne, I could see the text subtitles for communicating AI units, but I could not hear any of the audio even with the radio knobs turned up. The AI responded to me (tanker) and I was able to refuel just fine, I just could not hear them or the AWACS, only see their text when they transmitted. When I switched aircraft (to F-14A), without disconnecting, I could hear them fine again.

I believe this is "working as implemented" at this point. The problem is you can't have two things mapped to the same control in DCS. The VoIP category is used across all planes, so when you map it in one plane, it wipes out that mapping across all others. The only solution to this is what Heatblur and Dekka have implemented in their planes, which are dedicated mappings specific to their aircraft just for using VoIP functions. Heatblur especially has had one in there for SRS for a while now and implemented DCS VoIP as well. ED needs to have this done in all of theirs, and frankly, should have had it done when they released this feature for this very reason, even with a generic mapping for FC3 aircraft. I don't think you're ever going to get the native ability to have two functions fire with one button press inside DCS (both VoIP and Radio Menu open). You'll have to use some kind of 3rd party joystick software to program it into the buttons themselves. The closest I've gotten is using SRS and having SRS map itself to the same button as the DCS Comm functions of the aircraft I'm flying. However, since I like taking screenshots during flights, which uses the F-keys a whole lot, having that menu pop open and close all the time is a pain in the rear. Your only solution is to remap these every time you switch aircraft.

Same thing I've tried damn near everything. I'm very computer literate and very amateur musician so I've messed around with audio on my system front to back and helped others setup streaming PCs and banana meter. Short version: I know what the **** I'm doing. 1. Windows Exclusivity for audio devices - no effect 2. Disabling all audio devices save the one - no effect 3. Multiple Reboots between changes - no effect 4. Changing default comms devices - no effect 5. Swapping devices after DCS loads - no effect 6. Changing the volume of the mic before/during/after then rebooting DCS and/or system - no effect No matter what I do, I cannot hear anyone in VoiP. I can connect, see the green light come on, hear the canned static, but I cannot hear anyone. I also get the volume lowering bug. Rather sporadically, they can hear me from time to time, but I can't hear them. SRS, Discord, any other game and it's VoiP works just fine.

The problem is that's kind of a losing proposition for them. Let's play the hypotheticals and say that these AI changes are going to fix those problems and back up 30 months to when they're planning how they're going to attack this issue of the GFM and plan it all out. They know the system they have right now, although flawed, works and that they have campaigns and products sitting in their store people have paid money for and 3rd party devs had spent development time and money on to get to work with that flawed system. None of us are privy to how those agreements work if ED decides to change something in the base game that could potentially break something in those missions that then causes those 3rd parties to have to spend their own dev time and money fixing them. They don't have a choice because their own paying customers now own a broken product. Regardless of what's in our EULAs, it's a bad image. So they have two choices. 1. Do nothing with the current system and put all dev resources towards the new AI and GFM effort over the next ~18mo. to complete it and just replace the old flawed system. As part of the testing process they can run it against the missions in-house and see how it performs and at least provide 3rd parties with estimates of what needs changes in their missions to get them to execute as they intended. In an absolutely perfect world, to quote an (in)famous RPG dev, "It just works" and the mission designers don't have to do much of anything, or ED writes a fancy "update script" they can just point at all the missions that does the necessary changes automagically. (I think the reality will be something between. A script to update the missions with potentially new AI parameters that then devs will have to go in and set, but should be straightforward and not labor intensive.) 2. Split part of the team and add the incremental changes to get the flawed system slightly better and potentially then get knock on and trickle down problems that they then have to go back and fix over and over, breaking the game and missions repeatedly as it's tweaked. You won't see the first of these changes probably for another 6-9mo. and then the "usual" 1-2mo. between to fix the small problems and then even longer to fix the larger ones, and then for what? To fix a system that's going to get thrown out the window down the road anyway? It's wasted time and resources and a headache for anyone that's built a mission and particularly antagonizing towards customers (theirs and those of 3rd parties) that paid for content that breaks repeatedly. You may have noticed that I said 18 mo. in that hypothetical meeting 30 mo. ago.... That might have been the original projection until the plague hit and screwed everything up. -------------------------------- On the topic of the AI changes themselves, I'm also looking forward to the day that we're not fighting F-5s with whackadoodle physics defying flight models. I will concede I don't know the definition, and thusly the limits, of trajectory based modeling of the SFM, but what we have now at times for the AI is hardly anything that could be called accurate. I certainly hope we're also not here a year from now getting another message about how it's delayed into 2023. I'm sorry but the track record just isn't that good and I don't forget or forgive that lightly. The high detail Kuz model was shown in videos for years, and not actually in game, and then put behind a pay wall. The SA-5 was teased for a year a half in screen shots before finally making it's way in game, and we don't even have the right EW radar for it yet (granted the actual implementation of the missile is AMAZING). And the Apache videos looked promising and things seemed to be "on schedule" to us on the outside and then we got the bad news. Of course that's understand able, as we don't want a repeat of the Viper release, however the fact the Viper release happened.... So on a scale from Kuz to Apache, I'm wondering where this is gong to land...

So when exactly can we expect the Hornet to get the capability to carry 87s and 103s?

It's in the Apache trailer if you look closely. Smart money says this drops with the Apache. (THIS IS PERSONAL SPECULATION)

It's all dependent on the command center and what types of radars they were meant to interface with and receive data (tracks) from and then distribute that information out from. If you play the SAM SIMULATOR game it's a bit more intuitive how it's supposed to work. A lot of these SAM systems have a switch to just forcefully "accept" the targeting info from the IADS network link that the HQ is sending them. Remember these all have telecommunication/network/data standards spanning decades and formats/speeds (wireless microwave, cable, telephone), so it's hardly "plug-n-play".

The 4/26/19 newsletter about developing an IADS didn't age well either. They must have had little/nothing at all done in house on it by August 2020, and didn't plan on doing so for at least the next two years or more to consider handing it off to another company, so all that waiting was in vain. The good news is that I've seen the above behavior exhibited by the SA-5 so far and it's one nasty [REDACTED]. I'm loving trying to fight it. Just still disappointed we don't have an appropriately ranged search radar to pair it with.