Jump to content

STT won't lock when target at 83-100% of max radar range.


MARLAN_

Recommended Posts

On 4/25/2022 at 7:22 PM, BIGNEWY said:

The team are happy with the current values based on the data we have and can use. 

thanks

Seriously?

Beamscanner has provided an incredibly detailed yet digestible explanation on radar theory, which clearly shows with modern pulse doppler radars, STT should actually provide better detection capably than broader scan patterns (provided you are pointing directly at the target to see it in the first place).

With all due respect, how can the ED team be satisfied with this current implementation, when it is unrealistic and opposite to basic radar theory?

  • Like 13
  • Thanks 1
Link to comment
Share on other sites

Obviously they cant just trust some dude on the internet. Nor would I want them to make changes because some dude on the internet said something.

 

That being said, I think the real solution is that ED needs to hire an expert in Radar/EW simulation. I get the feeling that this blanket rule stems from a singular radar they may have data on. For instance, the Slot back radar was a very oddly thrown together with a mix of analog/digital components. Its possible that it specifically had tracking problems. But this is not a blanket rule I would apply. 

  • Like 15
Link to comment
Share on other sites

Employment manuals are clear that you should wait for a second sweep before locking (as a technique) but that you absolutely can immediately lock a brick that's been displayed on the FCR, because it's been digitally filtered and processed by the time the pilot sees it.

Sent from my Pixel 3 XL using Tapatalk

Dances, PhD

Jet Hobo

https://v65th.wordpress.com/

Link to comment
Share on other sites

One way that ED could handle this is to say, OK, we know that at the unclassed level these light weight fighters have an expected contact range of 40-45nm against hot fighter sized aircraft as visible to the pilot in the cockpit. That means the radar is seeing (detecting) returns on those contacts further out, but maybe needs a little time to process those returns before displaying them to the pilot at 40-45nm. So if they want to leave this 85% targetable limit in, they need to extend the range of the radar by 15% and not display the brick at all until it is targetable. But, this just seems like a convoluted way to approach the issue.

What would be really great too, is if RCS and therefore expected contact range of a fighter sized aircraft changed based on the loadout they were carrying. Maybe that flanker would be visible a lot further out if it was carrying a full air to air loadout vs clean.

Sent from my Pixel 3 XL using Tapatalk

Dances, PhD

Jet Hobo

https://v65th.wordpress.com/

Link to comment
Share on other sites

It doesn't make any sense from a physics perspective that tracking range is inferior to reliable detection range. STT = lots of energy and frequent returns on a specific target.

I also doubt that any fighter fire control radars will ever stop the pilot from _attempting_ a track/lock on a detected target. It would be, tactically, immensely disadvantageous.

Also, the fire control radar doesn't know everything. The pilot may have radio information/visual on a contact and may want to attempt a lock because they know the radar should be able to pick it up despite not having a scan echo yet.

 

I'm very sceptical that fighter fire control radars won't allow the pilot to attempt a lock in _any_ point in space, despite not having a detected target. A detected return should not be a requirement for an _attempt_ to lock/track. Any such limitations would put the pilot at tactical disadvantage in many situations such as brief notches, where the pilot _knows_ the target is still there, and wants to force locking attempts in that volume of space.

  • Like 2
Link to comment
Share on other sites

It doesn't make any sense from a physics perspective that tracking range is inferior to reliable detection range. STT = lots of energy and frequent returns on a specific target.
I also doubt that any fighter fire control radars will ever stop the pilot from _attempting_ a track/lock on a detected target. It would be, tactically, immensely disadvantageous.
Also, the fire control radar doesn't know everything. The pilot may have radio information/visual on a contact and may want to attempt a lock because they know the radar should be able to pick it up despite not having a scan echo yet.
 
I'm very sceptical that fighter fire control radars won't allow the pilot to attempt a lock in _any_ point in space, despite not having a detected target. A detected return should not be a requirement for an _attempt_ to lock/track. Any such limitations would put the pilot at tactical disadvantage in many situations such as brief notches, where the pilot _knows_ the target is still there, and wants to force locking attempts in that volume of space.
You can attempt STT on a trackfile right now, either with the SCS or by depressing the TDC, that's not a problem. STT can fail, for various reasons, even IRL.

The problem (that you also discuss) is that:

1. Tracking range is always below the range where the radar can gather enough info to generate a brick/trackfile. Given that bricks (and even more, trackfiles) represent processed data already, STT should not be a problem on a target with resolved range, altitude and velocity (that a brick represents). STT should fail if the target does not match the parameters of the track (eg. is no longer there) or if the radar cannot generate accurate enough info to transition to STT.

(2. Not necessarily related to this thread, but related to your comment. We cannot attempt an STT on non-radar trackfiles with the SCS, because we don't have MSI. At best, we can try and match the DL track info manually and depress the TDC while in RWS. We should instead be able to designate and command STT on any MSI trackfile, with the MC taking care of pointing the radar to it.)
  • Like 2

The vCVW-17 is looking for Hornet and Tomcat pilots and RIOs. Join the vCVW-17 Discord.

CVW-17_Profile_Background_VFA-34.png

F/A-18C, F-15E, AV-8B, F-16C, JF-17, A-10C/CII, M-2000C, F-14, AH-64D, BS2, UH-1H, P-51D, Sptifire, FC3
-
i9-13900K, 64GB @6400MHz RAM, 4090 Strix OC, Samsung 990 Pro

Link to comment
Share on other sites

This problem right here is the single most aggravating thing for me in the F18. It makes me not even want to fly the Hornet because of how bad it makes the radar feel. The fact that I can't reliably STT lock a bandit I'm picking in RWS until I'm some arbitrary 83% of max range just feels terrible. Who would make such a bad desgin in an aircraft? Not that bad designs don't exist, but you would think this would be worked around and updated to not be such a bad limitation. If its realistic, so be it, but man does it make the F18 radar feel absolutely garbage to use and makes not want to fly it anymore. ED, if you can't make it realistic due to some too classified information, at least make it not so terribly anti-user friendly. 


Edited by Hawkeye91
  • Like 1
Link to comment
Share on other sites

  • ED Team
12 minutes ago, nighthawk2174 said:

@BIGNEWY or @NineLineYou know the dev teams thoughts on this, as per beamscanners post -which I fully agree with- and is accurate per every book on radar i've ever seen the current behavior is not correct and can be set fixed in 5sec by anyone with access to the code.

As mentioned before the team are happy currently, if new information comes to light we will revisit it. 

thanks

smallCATPILOT.PNG.04bbece1b27ff1b2c193b174ec410fc0.PNG

Forum rules - DCS Crashing? Try this first - Cleanup and Repair - Discord BIGNEWY#8703 - Youtube - Patch Status

Windows 11, NVIDIA MSI RTX 3090, Intel® i9-10900K 3.70GHz, 5.30GHz Turbo, Corsair Hydro Series H150i Pro, 64GB DDR @3200, ASUS ROG Strix Z490-F Gaming, HP Reverb G2

Link to comment
Share on other sites

1 minute ago, BIGNEWY said:

As mentioned before the team are happy currently, if new information comes to light we will revisit it. 

thanks

If the team will explain why the STT working so, we might become happy too... It is interesting even if not considering correctness.

  • Like 5

Верните короновирус в качестве главной проблемы, спать в маске буду, обещаю.

Скрытый текст

Hardware: AMD 5900x, 64Gb RAM@3200MHz, NVidia RTX3070 8Gb, Monitor 3440x1440(21:9), Samsung 980pro 1Tb NVMe SSD, VKB Gunfighter+MCGU, Virpil Throttle CM3, VKB T-Rudder, TrackIR.

 

Link to comment
Share on other sites

2 hours ago, nighthawk2174 said:

Have they said why?  The model is not how the radar works.

Makes me wonder if they aren't maybe understanding the sources correctly. Perhaps there's a difference between the absolute max detection range and maximum RWS range to produce a trackfile. By the time you have a trackfile brick, as others have said, maybe its within that max lock range as the radar return has been processed and filtered by the FCR, and therefore, a lockable return. Maybe the devs are misunderstanding the source thinking that max detection range and max RWS range are the same distance.

I don't know, I'm no expert, but I believe there should be some more research done as to why there's the discrepancy we are all seeing and they aren't. 

Also isn't EDs source manual a Spanish F18A with the APG-65 and not the APG-73 like our mid 2000s Hornet would have?


Edited by Hawkeye91
Link to comment
Share on other sites

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.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

I can’t decide whether this continual denial of any issue by ED is due to a complete lack of understanding of the topic at hand, or a quiet, intentional decision to keep this sim “fun” for more casual, dogfight oriented customers.

The real sad part is neither option is appropriate for a company the promotes “Our dream is to offer the most authentic and realistic simulation of military aircraft”.

If that truly is the case, than openly admitting when certain things aren’t correct or were misunderstood, should be a completely normal and productive part of the development process. Unfortunately what the customers currently see is a company sticking their head in the sand because they don’t like what they’re being told, and think they know better.

This approach just feeds the frustration of all involved, devs and customers alike.


Edited by norman99
  • Like 6
  • Thanks 1
Link to comment
Share on other sites

14 hours ago, BIGNEWY said:

As mentioned before the team are happy currently, if new information comes to light we will revisit it. 

thanks

@BIGNEWY I understand your point and, obviously, questioning the development every time is a hurdle to move forward. However, I would like to respectfully point to a couple misconceptions here:

  • New information has come to light: you have been offered a thorough explanation of why does it look like the team did an incorrect implementation, and even a potential reason for the misconception. Not only that, but even sources to verify the theory have been ppointed to.
  • The team are happy: well, it is important to us, and we value their expertise. However, when customers are repeatedly pointing a serious concern, and providing their evidence and know-how, I think happiness is not a strong enough argument to support the lack of explanation.

So, in summary, a portion of your customers think a wrong implementation has been done. They point out why they do think so, contributing with explanation of the basic theory, and pointing to reference material, employing their own spare time in an attempt to improve the quality of the product. However, you are dismissing their valid concerns without even offering a well-deserved explanation. Fortunately, no harm is done, and there's still time to step back and set a healthy debate, isn't it?

Excuse me the absurd comparison, but it sounds as if an user finds out he is able to take off with the engines off and files a bug, explaining that an F/A-18 cannot take off without power, and even referencing a physics book, but his complain is dismissed and he is asked to "point out to open-source documents where it clearly is stated that an F/A-18C Lot20 from US Navy or Marines, ca.2007 could not take off without power"... you see? Even valid arguments can be over-stretched, so I would kindly ask to reconsider this topic and offer an explanation. I think nobody asks for reverting a change with no explanation, but when the team's understanding contradicts everybody else's, and does not match with the theory backing the claim... an explanation would be really appreciated.

 

BR

raus

  • Like 10
Link to comment
Share on other sites

5 hours ago, norman99 said:

I can’t decide whether this continual denial of any issue by ED is due to a complete lack of understanding of the topic at hand, or a quiet, intentional decision to keep this sim “fun” for more casual, dogfight oriented customers.

The real sad part is neither option is appropriate for a company the promotes “Our dream is to offer the most authentic and realistic simulation of military aircraft”.

If that truly is the case, than openly admitting when certain things aren’t correct or were misunderstood, should be a completely normal and productive part of the development process. Unfortunately what the customers currently see is a company sticking their head in the sand because they don’t like what they’re being told, and think they know better.

This approach just feeds the frustration of all involved, devs and customers alike.

I think blaming developers in lack of understanding or some other weird things doesn't help getting explanations from them. They are ordinary people and become defensive when they are offended by such statements.

To avoid the confirmation bias, when we make some statement which contradicts the way it is in the game, we should search for arguments why our statement is wrong rather than searching for proofs that it is right.

P.S. I've asked the friend of mine who was the radar engineer, and he confirms that STT and RWS should have the same range capabilities. But there are caveats about deception techniques and a maneuvering target. He said that it may be difficult to track maneuvering target when it is in the marginal range. Maybe devs consciously decided not to simulate such issues for the sake of performance, but simply hardcoded the ranges where it does not the case.

On Hoggit reddit there is another explanation why STT may have lesser range than RWS, but I didn't fully understand it yet.

 

P.P.S. English is not my first language, but now I'm working on improving it. Feel free to correct me, I'd appreciate it.

Верните короновирус в качестве главной проблемы, спать в маске буду, обещаю.

Скрытый текст

Hardware: AMD 5900x, 64Gb RAM@3200MHz, NVidia RTX3070 8Gb, Monitor 3440x1440(21:9), Samsung 980pro 1Tb NVMe SSD, VKB Gunfighter+MCGU, Virpil Throttle CM3, VKB T-Rudder, TrackIR.

 

Link to comment
Share on other sites

2 hours ago, Blackfyre said:

I think blaming developers in lack of understanding or some other weird things doesn't help getting explanations from them. They are ordinary people and become defensive when they are offended by such statements.

To avoid the confirmation bias, when we make some statement which contradicts the way it is in the game, we should search for arguments why our statement is wrong rather than searching for proofs that it is right.

P.S. I've asked the friend of mine who was the radar engineer, and he confirms that STT and RWS should have the same range capabilities. But there are caveats about deception techniques and a maneuvering target. He said that it may be difficult to track maneuvering target when it is in the marginal range. Maybe devs consciously decided not to simulate such issues for the sake of performance, but simply hardcoded the ranges where it does not the case.

On Hoggit reddit there is another explanation why STT may have lesser range than RWS, but I didn't fully understand it yet.

 

P.P.S. English is not my first language, but now I'm working on improving it. Feel free to correct me, I'd appreciate it.

I can totally understand ECM and maneuvering causing issues with acquiring a solid track on a target, but if I recall correctly the targets in my track files did not maneuver or using any ECM.

If this was truly what ED are doing, a blanket reduction in radar range to account for these situations really isn't the way to go. What you are describing are different ways the radar may have issues and fail to acquire a solid track and would be awesome if this was modeled but a blanket reduction in range isn't a great temporary solution until those things can be fully realized.

Personally I feel like what others in the thread have been talking about is the more likely situation - being that ED likely sourced information on a different radar or very old radar model. Hopefully ED's team can look back into this and consider rolling back the change.

  • Like 1

 1A100.png?format=1500w  

Virtual CVW-8 - The mission of Virtual Carrier Air Wing EIGHT is to provide its members with an organization committed to presenting an authentic representation of U.S. Navy Carrier Air Wing operations in training and combat environments based on the real world experience of its real fighter pilots, air intercept controllers, airbosses, and many others.

 

Link to comment
Share on other sites

  • ED Team

As I have already mentioned, unless I can show the team better evidence it is not going to change. 

If you have evidence PM me. 

thanks

smallCATPILOT.PNG.04bbece1b27ff1b2c193b174ec410fc0.PNG

Forum rules - DCS Crashing? Try this first - Cleanup and Repair - Discord BIGNEWY#8703 - Youtube - Patch Status

Windows 11, NVIDIA MSI RTX 3090, Intel® i9-10900K 3.70GHz, 5.30GHz Turbo, Corsair Hydro Series H150i Pro, 64GB DDR @3200, ASUS ROG Strix Z490-F Gaming, HP Reverb G2

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...