Jump to content

Ahmed

Members
  • Posts

    405
  • Joined

  • Last visited

Everything posted by Ahmed

  1. That's ALR-69 though. For 56M check: and:
  2. It really depends on what suite you are talking about. CONFIG/IDENT 92A and up should display critical, lethal and non-lethal threats in the HUD EW. Currently in DCS we have an incomplete and inaccurate mix of things from different suites (missing flashing long stem, "stt symbol" from older suite, different length stems from 92A, wrong interpretation of what lethal/non-lethal and critical mean, missing status change tone when moving from non-lethal to lethal due to the previous misinterpretation, etc...).
  3. If it is always .01 mmHG lower it is not sense of realism but a bug. While real life METAR or ATIS may give you an outdated altimeter setting, ATC do give you a current reading. It would be a different thing if your altimeter is slightly miscalibrated internally (tolerances irl for this are surprisingly high).
  4. There is a concept called TUC (Time of Useful Consciousness) that addresses this through tables, for example found here: Time of Useful Consciousness | SKYbrary Aviation Safety I quoted 30 minutes from these tables on my post above. However, as people above are commenting, a healthy individual won't suddenly pass out at these numbers.
  5. Good point, I submitted that clip among others several times that got added to an "open" bug report about the RWR having mixed features from before and after CONFIG/IDENT 92A and thus being wrong both ways, but didn't think about mentioning stabilization.
  6. Wasn't this reported recently?? We are getting a lot of mixed information lately.
  7. I recently had TOT indications being wrong and disagreeing with the WPT ETE in the HSI top-right, that was correct. So, it is not working correctly in all situations at least. Still have to reproduce and record a track to report that one.
  8. It's not exactly the same issue, as he reported AWACS BRAA being true (a core game issue) and I reported that several hornet displays report true bearings instead of magnetic for various indications that should be magnetic (Hornet ATTK/SA systems issue), but I'll assume that the team took note despite this ending up merged.
  9. An E/F module would offer the best to DCS. I'd particularly love to see it developed by HB or RB, but both have their hands full right now. Also there may be obstacles to get a contract to develop that particular airframe.
  10. Hi, The A/A WPT bearing and range indications (both ownship and cursor), and the BRA indications in the ATTK format are showing in TRUE instead of MAG. The A/A WPT bearing and range and the cursor bearing and range in the SA page are also showing TRUE bearing instead of MAG (BRA curiously is correctly showing MAG here) Regards, true_aawpt.trk
  11. @BIGNEWY thanks. Now that a logic was added to the non-SC carriers, would it be possible to pass the team the idea of having the same logic to be used in the SC so that ACLS lock-on is simulated from 5.5nm/1200ft/5º when only calling Inbound on the SC without following the rest of the CATCC script? This would allow the same logic of the Stennis to work too in the SC for the many online squadrons that want to use ACLS but don't want to use the CATCC F10 commands and want the simple Stennis logic to work on the SC.
  12. The aircraft manuals state that the PITCH switch in the ALT HOLD position generate command that result in the aircraft maintaining a constant altitude. If you need proof stating that it will continue doing that in a 20 to 30º AOB or any other sensible aircraft state, then you are not going to find it explicitly written as such, because we in the aviation industry give for granted that when something is labeled altitude hold it holds altitude and don't need specifying that kind of information.
  13. This, together with the current state of the AMRAAM, makes me wonder if the whole logic behind all of this is the good old trying to force players to the WVR arena thing. Nick said long time ago that they were no longer pursuing that avenue, but I can find no other logic to these issues being kept correct-as-is.
  14. This is still marked correct as is without any apparent response from any ED representative. Can we get a clarification? Because not only real SMEs are confirming the obvious, but one can also prove that A/A mode is used in multiple documents over the net (especially F-16 docs).
  15. What he said.... The KC-135 cannot provide bearing, and A/A mode needs to be used. No idea why ED is lately changing things that worked right into working wrong, and then marking them as correct as is.
  16. Hi, While ED staff are probably not aware, A LOT of the DCS online virtual squadrons don't use the AI CATCC. This may be due to immersion reasons preferring SRS to AI comms, having a human controller, or not liking some of the inconsistencies. However, ED seem to have implemented this as only working with following the whole script of AI comms. Can you at least consider making the lock-on work after only making the initial AI marshal check-in, so that the online virtual squadron community can also use ACLS? Ideally it would work even without that, but at least gives us the option to use it after only entering the F10 menu once.
  17. No, I wrote clearly that there are bugs, but asking for only the target to receive those indications is not the solution for those issues. The solution is properly modeling beamwidth.
  18. Probably more of a feature request than a bug ,but the setCallsign, setFrequency, transmitMessage and stopTransmission LUA scripting commands and associated ME selections, are not available for naval units. They are available for planes, helicopters and ground units but not for naval units, and it would be really useful to have them working on them too.
  19. Hi, The STOP RADIO TRANSMISSION trigger action in the ME, and the corresponding trigger.action.stopRadioTransmission scripting function work... but with a delay. The audio keeps playing and the DF indications remain present until some time after the function is called. See attached track where the function is called 15 seconds into the mission but the looped transmission keeps playing until past 60 seconds. radiotransmission.trk
  20. The RWR is not a magic device that can tell you you are the target. If you are within or close enough to one beamwidth, you will get mud and singer indications even if you are not the target. While newer radars will have a bemawidth of <= 1 degree, some old SAM radars like the Fan Song can have a beamwidth of up to 10 degrees, that is a 5 mile area at 30 nm range, where a whole formation should get a mud/singer indication. So please document yourselves before asking for the RWR to operate in magic ways that a real one does not. There are two bugs here currently that are not what has been reported: 1) The area within which players get lock indication is too wide (~90º) 2) Players who get mud indication don't get launch indication This is fixed by having DCS model different beamwidth values for different radars, and everyone within a beamwidth should get both lock and launch indications. Asking for the RWR to magically only get those indications if one is the target is asking for DCS to turn into Ace Combat.
  21. Yeah, it's not that this needs much more than enabling the "COOP" option and the manual TTV option. The only thing that it needs DCS-wise is that the missiles are properly synced, channels shared between players instead of hardcoded to weapon station (that is a DCS-ism anyway) and that control can be transferred between players. Nothing "sensitive" about it.
  22. IRL pilots have also confirmed that the G-limiter in DCS is much worse than the real. It should be possible to over-g, it should definitely NOT be as easy as it is in DCS. In close connection with this report, the G-limiter in DCS also doesn't allow the aircraft to achieve the G-limit in the FCS page (i.e. will cap sustained G at 7.1g when the FCS page states 7.2g) under many different conditions.
  23. If you can reliably detect a contact you can track it. The thing irl is that there is no such thing as a hardcoded maximum range to detect a specific RCS target, this will vary due to a wide variety of factors, and can be modeled as 50% probability of detection range, 99% pd range and so on, and in the lower %pd ranges consistent detections will be unreliable and thus tracking may break too. That's why a certain 3rd party has done a great job bringing that radar model to DCS, and that's also why the current ~83% hardcoded limit in ED's modules (while you can perfectly track in TWS) is really inaccurate.
  24. Thanks for the response. Sorry for the confusion, the mention of priority was just that the video is also a good example of how those 6 most priority threats are shown, it wasn't intended as to insinuate that it has any relation with the overlapping. What is visible in the video is that no 2 symbols overlap (probably, as you say, because offset is on, even though we can't know this for sure... but in DCS even in offset mode they do overlap under certain conditions). I'll take the opportunity to say it also shows some of the missing symbology such as the flashing long stem ("critical threat with special lethality conditions" in the book), and should also help illustrate the whole lethal/non-lethal/critical misinterpretation we currently have in DCS. So many things in such a short clip!
  25. Yep I tried to reach you on Discord with the same comment. Alternate symbols are mippling or other enhancement symbols (e.g. SH in the old times), not some anti-overlapping logic. In any case, symbols, at least in offset mode, should not overlap and they do in DCS. The short video scene linked below has a very good example of the priority logic and how symbols don't overlap. In DCS under certain combinations of lethality they still do overlap, my suspicion being that because the source text ED used for that logic comes from the "old" suite where the thread rings were reversed and that refers to the azimuth indicator logic.
×
×
  • Create New...