FalcoGer

I don't get where you get these statistics from. Either way, I play mostly online. A decent ATC would be enjoyable for everybody, not just those who play one way over another. Even in "that" flight sim with a functioning ATC I sometimes just screw around for some "airquake" if I feel like that on that day (though that is rare). Taxiway takeoff, landing without clearance, cutting people off in the pattern, the works. And what does "their" ATC do? they have to deal with it, and they actually kind of do. If you cut them off in the pattern, they will adjust speed or abort if it can't be saved; if you incur on the runway, tower will tell them to go around, and they will. My point is that a better ATC doesn't mean you can't just not use it, ignore it, and play airquake if that is what you want. The state of DCS ATC - and comms procedures in general - is atrociously clunky, unrealistic and unhelpful - both to humans and AI, both online and offline. Having a real person doing ATC is great, but you don't always have that luxury, and more often than not they don't know what they are doing, or they are doing something else (GCI instead of ATC). And even with a dedicated controller, they can quickly become overwhelmed, managing multiple airports, and all aspects of every one of them, with AI not listening to a word of theirs. Meanwhile ED works on swapable pilot patches; something that people won't ever see except with free camera on the stand. They literally see it once, think "oh cool", and then it's inconsequential for them for the rest of their lives. And even if it were the coolest thing since wing flexing, it has no gameplay value. They promised improvements for over a decade and we got nothing at all. It's still the same as when I first started back when every module had it's own executable and if you switched you had to restart. I wanted an update on the progress. Want to know why nothing is delivered when it can be rolled out incrementally. Ground, tower, departure, approach, area, awacs are all distinct and can be implemented and released separately. we got exactly 0 of these items. Are you telling me it's so infinitely complex and complicated to do even one of those things in 10 years, when it has been proven that a bunch of volunteers with day jobs can do a very decent approximation of ATC in their free time - as a mod without the original source code? Said mod also has a solution for that problem. You get to pick what you want. Fully vectored approach, overhead break landing, or the do-whatever-you-want approach, where they just shut up and let you land - while still making sure that nobody is coming onto the runway while you are on final. Also oh god - they made you fly an approach the proper way without shortcuts. the horror. Of course ED may not do it that way, but it still can be done. This is a combat flight simulator. We won't get departure windows, we get departure times, and if we are delayed we get pushed in behind the flight the went in front of us. Of course this particular issue will have to be worked around somehow if you are in a setting where respawning is a thing (like online). As for offline missions and campaigns, this is fairly straight forward. You get slotted in some time before your departure, have some time to prepare the aircraft, and then it's go time. Or again, you can just ignore everything and just go, same as before. ATC should never say that, as someone stepping on the "unable" part would result in the pilot understanding "clear for take-off". instead they'd say "hold position" or "hold short". I disagree. Competition pushes innovation. ED might disagree and say there is no competition - which I find ludicrous. Even a book is competition for DCS, competition on how people spend their money and free time. Another modern aircraft combat flight sim much more so. Either way, at the very least it shows what is possible and can provide inspiration on how to improve or find solutions to problems by looking at how other people solved those same problems - like people not wanting to fly "pointless full procedures" all the time. DCS prides itself on it's realism, but what we have right now is neither realistic, nor helpful. In fact it is annoying and dangerous. Getting cleared to land on a runway with traffic on it, or getting yelled at "hold position" because some guy is taxing around on the other side of the airport, or struggling to ask permission to land for the 7th time on final before being responded to is bad UX and bad realism. The way it is right now is basically no ATC. if you prefer that, don't tune your radio to that frequency and just land however you please, and you get exactly the same experience - exactly the same way you experience pilot patches if you don't get in real close with the free camera. ATC should handle all aircract, player and AI, in a reasonable, realistic manner. Give us the english ICAO standard first, use that everywhere at first - yes even in a 1940s scenario in syria, because that is clearly better than the buggy mess we have now. Then add your weirdo ATCs and procedures in different languages if you care enough at that point.

As soon as someone does it. I don't have it, so I can't do any testing. I made the interface rather straight forward, so it's not that hard. Make a pull request.

I can not understand that. what do you mean?

That system was put in place before I knew how to read the MFDs (thanks to the complete lack of any documentation). I'll fix it eventually.

Just flew. works for me. You have to use the TEDAC grip weapon action switch, not the cyclic one.

Try putting clutter/grass to 0. Sometimes that just murders framerate. (and other times it's perfectly fine, idk why)

When asking for controls as CPG and this is rejected by the pilot the cyclic stick still is unfolded as if it were accepted. To reproduce: Set up mission with Pilot responsible Enter AH-64 with PLT and CPG CPG requests controls PLT rejects request Expected result: Nothing changes Actual result: Cyclic stick unfolds Note: If the stick is already unfolded, rejecting again does not fold it.

Of course. Feel free to implement it and make a pull request on github.

I made a tool for that. https://forum.dcs.world/topic/333704-coordinateconverter-alternative-to-theway if you get your coordinates from the F10 map, you can also use LAlt + LMB to bring up a window of the coordinate where you clicked in every format. As a bonus that window even stays open if you go back to cockpit view.

@papaz @Antix70 And everyone else. This will be fixed shortly in SRS. If you can't wait for the next SRS patch, you can download my patch from here. Put the file into Saved Games/DCS/Mods/services/DCS-SRS/Scripts/DCS-SimpleRadioStandalone.lua If the file is unavailable, it has been merged (ie. it's fixed in SRS).

When entering a multiplayer server the new slot selection screen freezes every few seconds for a few seconds. Once you manage to get into an aircraft performance returns to normal.

ED's update broke the display IDs. It also broke my tool. I already updated my tool. I made a pull request to fix it for SRS. https://github.com/ciribob/DCS-SimpleRadioStandalone/pull/716

Writing some code takes some amount of time. Whatever amount of testing you are planning seems to always be at least 50% off the mark. Usually testing, fixing and retesting takes about as long as it takes to write the feature or project in the first place. I do agree though that code that does not affect other code changes should be written such that it can be tested and merged in independently using some form of version control software. And then when patch day comes, you just release what is ready, instead of what seems to be happening now, where a single problem or two hold up the entire process, and the rest of the team might even have to twiddle their thumbs because anything new they do might break things even more. That is why version control software exists to begin with. To incrementally put in changes, concurrently work on different parts of the project by different developers, to reference commits and have reasons behind each change in the form of commit messages, to have accountability, to have code reviews, to compare different versions and why things might work differently now than before a change was made, and to have something to roll back to in case the poop hits the ventilator.

@Lord Vader As seen here The helicopter is within range (2500m) and yet george still refuses to fire because the range readout does not say he is in range because he does in fact not periodically lase the target again. I even provide a track with a stationary target. The easiest solution would be to simply have him activate the laser range finder when ordered to fire, and then make the decision to shoot or not. When in free fire, just keep the laser on.

Previously labeled as not a bug and closed, I was able to reproduce the issue when the target was clearly within gun constraints, not moving and on the ground. Related: To reproduce, same as before: have george was gun have george track a target far away and wait for the range to stop updating move closer have him fire Expected result: george re-lases the target and shoots, because he's clearly in constraints Actual result: george says "Can't shoot now" without further explanation because either the computer says elevation limit or ballistics limit. Additional note: after having george lase manually, he shoots from the same position just fine, so it is the range/safety constraints. Also it would be nice if genuine bug reports weren't closed. george_stale_laser_range2.trk

I wanted to check in to see if there have been any updates or discussions on this suggestion from the developers' end. It's been about six months since I first raised the issue, and I'm still hopeful for some progress or at least some feedback on whether this suggestion is being considered. Your thoughts and any updates on this matter would be greatly appreciated! Thanks

I've had similar experiences, the shot at cues sometime even appearing in the air and several tens of meters away from the target.

This situation is frustrating and unfair to Linux users, especially when this is not even looked at. Here are some points to reconsider this decision: Texture Format Issue: The textures provided are in a broken format, which even on Windows is technically incorrect. DirectX may tolerate these errors, but it doesn't mean the textures aren't faulty. Community Solution Ignored: A community member has already fixed the textures, demonstrating that the solution is simple and effective. However, using these corrected files breaks the integrity check, preventing online play. Community Engagement: The community has demonstrated both the willingness and ability to fix the problem, which is a valuable resource for developers. Ignoring such contributions not only wastes this resource but also alienates a dedicated user base. Linux Support Hypocrisy: While Linux isn't officially supported, the Steam Deck, which runs on a Linux-based OS, is supported. This inconsistency is confusing and frustrating for users. To drive the point home: Meaning technical support staff is willing to look at error logs for Steam Deck users (aka Linux users). How is this "Not supported"? Why honor the promise of looking at the log when the root cause is already identified and a fix is proposed and implemented? All that is needed is to copy the corrected files. This response feels petty and dismissive. It's almost as if you're saying, "We know you fixed the issue but we don't care. But we promised to look at the useless log, so we are happy to do that for you." Minimal Effort for a Significant Impact: Replacing the broken textures with the corrected ones is a trivial task—literally a few minutes of work. This small effort could significantly improve the experience for many users. Economic Sense: Addressing this issue could even be economically beneficial. A user has offered to buy the game if this bug is fixed. Spending a few minutes to fix the bug for a potential sale makes financial sense. Future proofing: You are planning Linux support down the line anyway with Vulcan support. Might as well take small steps now, especially when they are trivial and literally involve replacing a few files. Addressing this issue would be beneficial not just for Linux users, but for the community as a whole. It demonstrates responsiveness to user feedback, commitment to product quality, and a willingness to support a broader range of platforms, all of which can enhance the reputation and success of the game. Instead it is immediately dismissed as "Linux not supported", which demonstrates a whole lot of other things.

Add this to the list as well. all routes were completely filled with WP 1 (which didn't exist)

I don't know how I managed this, and track is multiple megabytes as usual. But I got stuck with TADS symbology as pilot. No matter what I did to resolve this, I couldn't get it back to flight symbology. I tried symbology select, and even turning off IHADS in the WPN/UTIL page. I also had the gunner chance sights and symbology, but that didn't help either. I know that a display processor failure would duplicate the HMD, but I don't think that's implemented? Also we just took off from the airfield and I'm pretty sure there was no damage.

There are some major desync issues apart from the TSD issue noted in the changelog, making multicrew barely workable. ACQ doesn't sync properly, CPG may be on PHS and PLT sees it on FXD for CPG Slaving at that time causes the camera to jitter rapidly between the actual tads position and towards the point it is trying to slave to TADS camera is extremely jumpy on PLT side, even when perfectly smooth for CPG Especially in Slaved (even when both sides agree on what the CPG ACQ is) Also especially on image auto track on moving target Waypoints don't match Pre-made points when selecting aircraft, such as targets may be missing or different CPG slaving to pre-made point doesn't slave to the correct location (both CPG and PLT see the slave to the same wrong location), even if they both agree on the point's position When looking over CPG shoulder to see what his screens are like, all 3 (MFDs and TDU) appeared black. Disagreement between pilot client thinking CPG got autopage and CPG not actually getting autopage on his end and then happily pressing buttons can lead to FMC disengage desync. None of these issues were as frequent or as bad before the last update, though they did exist now and then. Some, like the slaving to a point are new. Other's like the waypoints not matching between cpg and plt were/seemed fixed but now regressed to a broken state. I'll upload a track when I get to it. The track I got now is 45 MB and very long.

I can think of a few reasons: Because you don't know if something is in range or not until you actually check the range. And because you might want to get an idea of when to expect the thing to become in range. And to keep the LMC accurate and not jumpy if it is in use, as sudden range shifts cause sudden rotation speed changes on the camera. To make decisions you need information. And the range to a target is crucial information, not just for shooting the gun, especially if the target is moving quickly or if you need to stay outside a certain range, say an air defense system.

when you have ground override on and rearm with master arm also on, the missiles are "safe". you have to cycle master arm off and on again to make them fire. maybe that is your issue?

Already reported this. Supposedly "Not a bug". In my worthless opinion, george should periodically lase anyway even if it were an elevation issue (which it is not, or not only).