SFJackBauer

This is a two-part bug. The first part is more straightforward. The elevation range displayed besides the cursor in the radar display in 1 bar does not match the actual coverage. It always displays the same value for min / max, as if at 1 bar the radar only covers 1000 feet or less at any distance, when in fact you can detect contacts outside of its number as the first attached track shows. Also, even at 1 bar the altitude covered by the radar increases the farther it is from the aircraft, contrary to what happens currently in the F-18 display. This bug only occurs with 1 bar; in 2, 4 and 6 bars the number displayed correlates with the actual possibility of radar detection. The second part refers to the altitude coverage itself at any bar configuration and range. The values in the sim disagrees with public information available about the AN/APG-73 radar. I did the complete explanation and calculation in the thread linked below, so I will not repeat everything here. I will only copy here the values the sim currently possess, and which values it should have at various ranges: Current values (thousands of feet): [TABLE=head]Aircraft|Bars | 20nm | 40nm | 80nm F-18 | 1 bar | 1 | 1 | 1 F-18 | 2 bar | 6 | 11 | 22 F-18 | 4 bar | 16 | 32 | 64 F-18 | 6 bar | 28 | 56 | 99 [/TABLE] Current values (thousands of feet): [TABLE=head]Aircraft|Bars | 20nm | 40nm | 80nm F-18 | 1 bar | 7 | 14 | 28 F-18 | 2 bar | 10 | 21 | 42 F-18 | 4 bar | 17 | 35 | 70 F-18 | 6 bar | 24 | 49 | 98 [/TABLE] Complete post: https://forums.eagle.ru/showthread.php?t=253177 Tested with DCS Open Beta v2.5.5.38140 F-18 1 bar 20nm.trk

+1 :thumbup:

Great, it checks out with my calculations and the CNATRA document then. I've revised the initial post to correct for rounding (rounding down to thousands of feet instead of rouding to nearest) and a typo (I said before it was 25% overlap between bars, should be 50%). After more searching of the internet I've also found an old HAF F-16 manual which contains elevation figures that match what I've got, however I am not sure if ED could use it as a source. However I will submit it now as a bug report for both the F-16 and F-18.

I think you guys are being too quick to apply boolean logic to something that is probabilistic by nature. One thing is - whether the F-16 FCR would change its waveform to STT waveform while locking a target in SAM. Other thing is - whether the RWR in the locked aircraft would change its indication to the pilot. If the RWR is being bombarded hundreds of times per second with energy of a certain freq, it may as well interprets it as being locked, as Beamscanner pointed out. Now if you are claiming it shouldn't because in RL it doesn't, then how would you know it? Have you been locked by a F-16 in SAM mode while in another F-16 or F-18 or a Flanker and didnt received the lock tone? Then you shouldn't be speaking about it here in the forum... We are left to interpret the RWR inner workings by the laws of physics and the public information available.

Not sure if my understanding is correct or if there is an actual bug, so I am posting it to cross check with others before reporting it. I measured in the simulation the radar elevation coverage for various ranges and bars in the F-16 and F-18, checking the number on top and bottom which represents the maximum and mininum altitudes covered at 20nm, 40nm and 80nm. [TABLE=head]Aircraft|Bars | 20nm | 40nm | 80nm F-16 | 1 bar | 1 | 1 | 1 F-16 | 2 bar | 9 | 18 | 36 F-16 | 4 bar | 28 | 56 | 99 F-18 | 1 bar | 1 | 1 | 1 F-18 | 2 bar | 6 | 11 | 22 F-18 | 4 bar | 16 | 32 | 64 F-18 | 6 bar | 28 | 56 | 99 [/TABLE] First thing that struck me is that, in 1 bar scan for both the 16 and 18, the elevation caret displays a single number and does not change in value regardless of distance. Shouldn't it be increasing in coverage the farther from the aircraft? The only public reference I found on the APG-68 beamwidth is a PDF from the University of Tenessee which states 3.25 deg for azimuth and 4.55 deg for elevation. I assume the beam is oval-shaped as it follows inversely the shape of the antenna. Therefore at 20nm the beamwidth would be aprox. 9655 feet, which is close to the value that the simulation actually exhibits for the 2 bar at 20nm. Therefore I would expect to see the coverage for the 1 bar scan be the same as the 2 bar scan is presently. Given that F-18 APG-73 antenna is circular, I would assume its beam in elevation is 3.2deg as literature describes, and therefore at 20nm its coverage would be aprox. 6700 feet. Again, in the simulation this is the value displayed for a 2 bar scan, so I believe these values are correct but should be in 1 bar instead. Now for the 2 bar scan things are more complicated because there should be some overlap between the bars, so it wouldn't be just the double of 1 bar scan. I couldn't find information for the F-16. For the F-18 there is a CNATRA PDF which shows 10k feet of coverage at 20nm for 2 bar scan, which implies an overlap of 50% between the bars, assuming that 1 bar would be 6700 feet. If this is true, then at 20nm 4 bar should be 17k feet and 6 bar should be 24k feet. Applying the same overlap between bars to the F-16, it should have 14k feet at 2 bars/20nm and so on. I calculated what the values *should* be in the table below: [TABLE=head]Aircraft|Bars | 20nm | 40nm | 80nm F-16 | 1 bar | 9 | 19 | 38 F-16 | 2 bar | 14 | 28 | 57 F-16 | 4 bar | 24 | 48 | 96 F-18 | 1 bar | 7 | 14 | 28 F-18 | 2 bar | 10 | 21 | 42 F-18 | 4 bar | 17 | 35 | 70 F-18 | 6 bar | 24 | 49 | 98 [/TABLE] And here are the differences between my calculations and the simulation. Note the huge increase in coverage in 1 bar, moderate increase in 2 bar for F-16 and 2/4 bar for the Hornet, and slight decrease in 4 bar for the F-16 and 6 bar for the Hornet. [TABLE=head]Aircraft|Bars | 20nm | 40nm | 80nm F-16 | 1 bar | +8 | +18 | +37 F-16 | 2 bar | +5 | +10 | +21 F-16 | 4 bar | -4 | -8 | -3 F-18 | 1 bar | +6 | +13 | +27 F-18 | 2 bar | +4 | +10 | +20 F-18 | 4 bar | +1 | +3 | +6 F-18 | 6 bar | -4 | -7 | -1 [/TABLE] Now some other factors to consider: I did not test the radar actual detection coverage, I just checked the numbers in the radar scope itself. It could be that the numbers are wrong but the coverage is working, but I never noticed picking up contacts outside those numbers so I doubt it is the case. But it should be tested. There could be a fundamental error in my understanding, for which I ask the community for help in pointing out. I double checked the numbers and the theory and they seem to match. There could be other factors that change the radar coverage - for example, the overlap between the bars could be different between 2 bar vs 4 bar vs 6 bar. I haven't found any info that indicates this, but lack of info does not mean lack of existence. If this checks out, then other aircraft which implements air to air like the F-14 and Mirage could suffer also from this problem. I would verify them once / if these calculations turn out to be correct. So what do you guys think?

The radar is not interleaving the HI and MED PRF modes properly when scanning in more than 1 bar. For one scan in 2 bars, lets suppose the first bar is HI, then the second one will be MED. For the next scan then this should be inverted (first bar should be MED and second be HI) in order to maximize the chance of detection given a scanned volume. Instead, in DCS if the first bar happens to be MED, then it will always be MED throughout the scans. Same applies to 4bar and 6bar. This is how it works in the F-15 (RL and in FC3) and it makes sense for this logic to be present also in the APG-73.

I think you hit the nail in the head here, although I would go further. At this point this complaining about TWS is not rational anymore. We have people complaining about a three-letter acronym that they would seldom use over other features once it is released. However what these same people do not acknowledge is that they have no other option. ED's is the only one in the business, and that is because the market for it is extremely small. Therefore, instead of getting into the blame game that is so popular nowadays, we must support each other to keep this passion alive. There are companies out there that have to charge montly to survive, or constantly release "expansions", "DLCs", "loot boxes", "cosmetics" or whatever to keep the boat afloat. Somehow I don't see ED's margins being huge and the devs and CEO vacationing on a beach for 3 months a year... But also I know that even if ED charged for more lets say to hire more people, pouring more hands into a software of this complexity wouldn't make it go faster... Its not like making "Fortnite skins" or content like that which can be hugely parallelized. So I see people saying "I won't buy from ED anymore", fine. Go ahead. But you are only making our hobby harder to survive.

Meant to say implemented by ED, omitted since the first and second posts referenced ED explicitly, and not Heatblur or Razbam.

Its the first time TWS will be implemented in a high-fidelity module. F-15C TWS doesn't count as it is a Flaming Cliffs aircraft.

Check on Axis, ANT ELEV Knob, make sure its bound to the correct joystick axis.

Honestly I would vote for just implementing the more sophisticated IFF system and then everyone in MP just switches to mode 6, so you just save time and resources by not implementing any of the "reading into the mission description string" and stuff like that.

Careful... you guys may end up getting another customer (me) if you keep being reasonable like this :)

From my understanding it comes from the vertical line that is projected into the Radar scope or HUD that represents the missile range, which together with the max range / no escape zone brackets looks like a telephone pole.

You are failing to put the radar antenna elevation into the range it will detect the datalinked contact. You can always get a datalinked contact altitude from the SA Page (either moving the SA cursor over the desired contact and hitting STEP, or hitting STEP and cycling through all contacts). Once you see its altitude, move the radar elevation until it encloses it. I've submitted a bug report similar to this in https://forums.eagle.ru/showthread.php?t=235930.

As a long time customer of ED I am with you guys. The document speaks for itself and the Gazelle and Mistral weird behavior is well known online where it can sometimes outperform dedicated fighters in the scoreboard. The Gazelle is the only chopper I do not own because of my "spider senses tingling" and I can see now that I was right. The RWR part is pretty disgusting to go through given the standards other 3rd party devs and ED itself apply when dealing with customers. Hopefully the discussioin will steer towards substance instead of deflection or ad hominem attacks.

You are conflating the cost of the seat and HOTAS into VR, when those things are good in itself. Therefore VR costs drops down as others have demonstrated here. However you should really try the headset you are intending to purchase first (or at least a similar headset) so you can check if you can cope with the sensorial overload and are immune from any nauseating effects (please try a decent VR app, like the oficial demos from Oculus or Valve). Also if you can cope with the reduction in resolution that you would have, especially if you go with not the latest VR headsets. Remember that VR is not a full-fledged consumer tech yet, so it has its rough edges, whether its resolution, refresh rate, the need of cables, comfort so you have to be willing to endure its downsides in order to really enjoy the upsides.

I fly online during weekdays mostly in the 9:00 PM ET timeslot onwards, and during weekends any time of day. DM me on Discord of pretty much any DCS server, or here in the forum and we can arrange some cooperative sessions.

Ciribob, I appreciate immensely your work and as a regular SRS user I don't find the instructions hard at all. However I am fairly technical savvy, so if you may I would suggest some changes to the release page on Github. - Focus the first two-three paragraphs on instructions for end-users, not stuff about TCP ports and banned IPs which only affects server owners. - Instead of putting the installer inside a zip file with a bunch of other files in it, just attach the installer exe itself directly onto the github release page, alongside the zip file for whoever wants to install manually. - Ask for server owners who use SRS to announce the website you guys made - dcssimpleradio.com - in the server briefing so people who never visit the forums would be able to know where to get it. The website is well designed btw, and it is the first result if someone googles "DCS SRS". - Whenever describing SRS on the website or Github page, try to not compare it to Discord or Teamspeak, because people who never used these softwares wouldn't then know what exactly it does. Perhaps saying "SRS introduces a realistic voice communication system into DCS that integrates with the aircraft radios inside the simulation etc etc." I am only making these suggestions because it is frustrating to use this extremely well-made and useful tool and knowing some people just didn't went through the initial hurdles of getting it set up. For any new thing to be adopted we have to dumb it down the installation process as most as possible. As I know that only making suggestions is easy but implementing them is hard, I offer you my free time to make these changes if you agree with them.

Not as a placeholder, they are literally the same pods the A-10C uses.

I heard these are scenes from the next TopGun movie

I agree that sometimes banter is annoying. You only want to fly, follow brevity and try to play out some tactics or fullfill a certain server objective. I mostly stay off Discord, only using SRS which by its nature prevents unneccessary chatter. There are always similar minded people out there - you just found one (me). Just think about what you may be missing by not playing online.

You are overthinking it. I play DCS 99% online for about 10 years. My ping to US East servers is about 160ms. The netcode has been improved a lot; in the past we had issues with warping and rubber-banding, now its gone even with highly populated servers. This is not a quick reaction Counter-Strike type of game which would require single digits latency to be competitive. If everybody enforced sub-50ms Europeans, South Americans, North Americans, Koreans etc. would never be able to play together. The multi-culturality of DCS online play and the variety of people you would enconter online is one of the factors that makes it enjoyable for me.

By this I assume you mean the red diamond symbol of a donor track which appears both on SA and Radar. What do you mean byt "estimating from the radar range"? By your wording it seems you are confused about how MSI works. Every time the radar detects something, the radar "knows" its position in 3D space. Given that the donor aircraft detected the donated contact with its own radar, it also knows where in 3D space that contact is. Once these positions are shared amongst the aircraft, its easy for the Hornet computers to overlay these contacts over your own radar scope - no "estimating" is required. STEP on SA page until desired donated track is highlighted, check altitude. Adjust radar antenna elevation to cover this altitude.

Hornet gets the first shot off? Both planes field the same air to air weapons. AIM-120C/D, AIM-9X Both planes have helmet mounted sights integrated with 9X. Why would the Hornet get the first shot off in equal situations?

Not sank in the immediate sense as we see in DCS. It was rendered inoperative and sank 6 days later. "Even two months after the attack, the board of inquiry was uncertain whether the Exocet’s warhead had detonated. Although crew members were convinced it had detonated, the board’s five members eventually concluded that it had not, and reported that the fire had been caused by the missile’s propellant, only 40% of which had been used during its flight. A fresh MoD reassessment made public in 2015 concluded that the warhead had exploded."