Rosly

Fair enough. But on the same time I think this forum is the good place to share opinions so ED can knowhow we feel with new kind of offering. This is healthy relation to expres satisfaction and dissatisfaction from product or even fear is some of us feel something is odd with our beloved sim. On the same time I'm disappointed that instead of addressing concerns about announcement and product offering new practices, we are given warnings that "off topic" posts will be removed. I cannot imagine what is more "on topic" than questions about this "new offering".

"Full set of features will be announced prior to early access" Well, I'm deeply concerned about this change of attitude to pre-order offering. Honestly, this does not look good. Actually very bad in scope of timing with events with Razbam. Deeply concerned.

I initially opened a feature request but due to lack of reaction fro ED, and reaction from other folks on this forum, I think this should be considered a BUG. The problem is that TGP in A-A STT tracking does not follow the limitations of physics, strictly speaking rotational inertia of the camera gimbal. As result the updates for angle from radar STT cause TGP picture to be jittery. It's really difficult to visually ID A-A targets with the TGP because it's repositioning the viewport with instant "jumps". It is less noticeable when TGP track target by contrast but still problem is similar.

@NineLineany chance?

Hey, Hi, electronic engineer here and some rant I put a lot of admiration to effort given to details of any engineering modelling of aircraft systems. I generally enjoy such details as those are basically aligned with my field of interest and profession. Though, the recent announcement about INS/GPS feature improvements made me start thinking "is this even make a sense". 1) Who wait for this? I do not recall wide discussion about urgent need for this feature. We already have basic implementation of dead reckoning. Why to spend more time if more wanted features are in queue? 2) How we can use it? I do not recall any API which allows to influence on GPS precision. We do not even have damage models for this, nor we can trigger GPS precision degradation from mission scripts to simulate some nice scenarios (like in recent battle fields). The only way to degrade GPS is to switch the date before 1991 (or something like that I do jot recall exact date coded into DCS). 3) How many of us will ise it? No one will use those INS features as in most servers we have GPS. As long as you have GPS the total error is below a couple of meters. This is a measurement error. It does not matter for plane navigation as this error does not accumulate! While GPS is functional. 4) Should ED spend time on more wanted features? You tell me? - heat seeking missiles see through clouds and mist (same AI units without radar like WWII or Cold War) - TGP is jumping like a rabbit when.l tracking AA targets (no inertia simulation for camera head) to the point you cannot distinguish the siluete. - no pilot body - damage model is a joke Yeah I get it the idea about simulation details and I will probably enjoy this details os few cold war missions. Though comparing the development velocity for ED and some third party vendors, and also level of perfection and details to core features, makes me very bad emotions. I'm waiting for major bug fixes mentioned above but instead I get more detailed feature almost noone will notice on daily basis. The only way to make sense of having those improvements wouldn't be model of electronic warfare or at least dumb API to define zone with degraded GPS precision.

Works for me just now

@BIGNEWY @Wags > The new scenery compute system achieved our ambitious goals of: > increased GPU performance > improved VRAM management > increased CPU performance > improved streaming from storage disk to VRAM with optimised CPU usage Whoever is responsible for this job, he deserved a pay rise! This is the biggest performance upgrade since introduction of MP. Woooow! At last! I have stable 90fps in VR on any map, including low level flight on Normandy 2.0! No reprojection. Zero! Thank you so much!!!!

I didn't found any change in Open Beta "change log" so I'm opening this as a BUG because I suspect this is a regression. Problem statement: All F-16 ECM pods are not making any difference (both in Deception and Noise Jamming modes) to legacy/old SAM radars and it's tracking, after one of recent DCS updates. I remember it worked pretty well. For SA-2 it was quite easy to break a lock, means was effective for Fan Song up to 12nm. In recent version of OpenBeta I not only cannot break a lock even at 20nm but also seems there is no difference in locking range under jamming conditions. To backup the story it worked some time ago, measurements for "DCS skynet IADS mod" of effectiveness of ECMs which simply does apply anymore. @NineLine@Raptor9 You seem to admit ECM is effective for AG. So was it changed recently without notification in change log or this is a regression ?

Not sure what you asking? Just punch in the freq and switch to FM modulation.

The temporal solution which should work to some extend till fix will be provided is to use the ARC-210 with given freq and FM modulation instead of dedicated FM radio.

SteamVR API is disabled in my Aero base config. Yes I'm sure

Seriously, any reason why not yet match ED store?

When?

Have the same problem but on Aero Varjo. Though I was thinking it is DCS single thread bin problem as multithread bin works with quad view. I will have to uninstall Leapmotion and check if single thread still have issues with quad view.

Understand, though suggesting to use different design decision for new Campaigns. Line of sight and range limitations are essential for UHF/VHF. DCS and SRS are designed to reflect reality in this regard. Using different units than the narration based ones, to emit on those radios will influence on ADF as well.

Bump. A year passed...

As electronic engineer I'm trying to point out that there is physics behind all technical solutions. You do not get infinite precision which you impose of having when making hopes for "instant measurement". Please refer to https://en.wikipedia.org/wiki/Accuracy_and_precision and https://en.wikipedia.org/wiki/Measurement_uncertainty In scope of phase measurements what you have is angles in one or two planes. The error of this measurement is huge (couple of degrees at least). You are not able to make instant projection of 3D vector over the surface from that and get precise location. RWR gives you very rough estimate of signal source azimuth. HTS is far more sophisticated and use triangulation and statistical methods to narrow down the position. There is nothing wrong in using single plane for measuring the direction for RWR. The design goals of this system if far different than those in HTS. The frequency range are different. The measurement time is different. The expected precision is different. And lastly I bet F-35 have far more superior sensors than original APR-47 Not mentioning F-35 work in network, because this network extend methods already used in HTS pod in block 52 of F-16, namely the TDOA. So comparing APR-47 to modern software define network sensors is just not sane Despite what some pilots say (like "Starbaby") the modern networked software defined radio system are far superior to any skilful pilot. But I get the point any story need at least 10 percent true If that wasn't the case, we would not get inch precision SAR images and still rely on vacuum display tubes and 2-plane phase differences. https://www.youtube.com/watch?v=RoZ_-6tvxu4

@BIGNEWY any chance to make this improvement as part of planed code development for Sniper XR Targeting Pod ?

This is not how those sensors work. HTS is not RWR and their principle of operation is different. TLDR it is already done, but measurement error is huge and you cannot get exact location by just single measurement. The basic principle on how HTS work is phase detection and position triangulation. Inside HTS you have a lot of antennas (the phase array matrix to be exact) and based on phase difference for received wave between those antenna reception points, you calculate the bearing and elevation to emiter. The bearing and elevation calculation always have some error because of the electronics limitations, noise, reflected signals, Doppler effects and other signals in the air on the same band which you cannot completely filter out (to put it simply they add the phase noise to your measurement). So you have both, the exact one you asking for, but elevation error is much higher as its relative error to range is much higher. There are also much more reflection in elevation than there are in azimuth. Never the less, single measurement is not enough and it is like giving you generic area where the emiter is. This is how RWR work and where it's functionality ends. It simply display you the bearing and for elevation it can tell higher or lower than your plane as this is max of it's precision. If you want to learn more how old EWR works here is a nice video The RWR is simply phase detector where front and rear antennas are one axis, and left wing and right wing antena are another axis. Than (in case of early RWR) those phases were plotted on a scope and give you the visualization of a bearing. There is no way you get elevation other than leaning on a wing (antennas are directional) so you will se if signal will decay. Going back to HTS. At this point you need to think you have single 3D vector to emiter as HTS has this matrix phase array (which has hundreds of antennas in it). The error for it's measurements (where you project a cone from vector and error) give you 5nm flat space at 30-40 nm of distance (more or less). So now you should figure out why we have PGM levels! The longer you fly, and the greater the angular distance from all the measured 3D vectors you acquire, the more precise the location will be. This is basic method for decreasing error came from measurement theory. The error of the measurement can be decreased if you have a lot of them. And even more, in scope of triangulation, the bigger the difference in aspect to the measured location, the smaller the error of the projection cone will be. And this is how HTS is working.

Currently while tracking targets by radar in STT the TGP in A-A mode is driven without any dampening of the seeker head movement . It seems its elevation and heading is instantly updated with refresh rate of STT tracking. As result the TGP image shakes and creates artifact's like tearing and ghosting (especially in VR) In reality TGP seeker head has natural physical acceleration and speed limits which naturally smooth out the movements of the head (azimuth and heading corrections to look at target when supplemented by STT and not tracking by contrast) This seems to be a simple fix in code to add acceleration and speed limits to change of azimuth and elevation for small angular adjustments of TGP when it is not tracking targets by contrast, but instead is driven (updated) according to STT updates from radar. This would remove jitter and ghosting as well as make TGP movement more realistic (mean close to real by flowing physic limits).

Bump - This feature would be customisation multiplier on all mission making fronts.

Why not use the wingman unit for mission 2. He is actually the one who makes the narration.

I see a general lack of possibility to integrate mission elements with avionics. The example form the topic is to be able to give players the sense of a bit more human wingman to share datalink targets. It would be great if instead of sending cords over voice narration (which player has to manually type into flight computer), mission makers would be able to just trigger mark-point data sent (from lua or event scripting) to player occupied flights. This way missions would be far more immersive as we would be able to simulate real coordination in the flight during the attack. Now it is a bit funny that during the heat of battle you need to type anything, or you need to bend the narration in a way that target location is known before the attack phase (sadly).

On Mission 6 I got right engine failure. There was flame ans stuff and I could not ignite engine back. I needed to abort the mission. Latter on I noticed I have "random failures" set to ON in my options and it seems I was unlucky enough that it fired during the campaign mission. Also it seems missions from this campaign does not force it to be off (I checked mission 6 in editor and it seems to be so). @baltic_dragon was this overlook in mission setting which does not force random failures to be off? Improvement proposal: If users have this setting to be on, there should be an option to abort the mission if a failure occur and does not allow to finish the mission. Or the mission should overwrite the user setting and force it to be off if the mission does not implement such mechanism.

Ok I reproduced the problem and recorded it on video. Seems the root course is the ED update for sensitivity levels of A-10 radios. To put it simply, this defines now much range each radio has with given TX power on the transmiter side. It seems the unit which is transmitting is not our wingman and once we flew out of range (or we mask the transmiter by terrain) we are no longer able to hear it. I was able to overcome the problem by switching to more sensitive ARC-210 radio, by setting FM freq on it. I was even able to confirm the FM radio is still able to receive the transmission, though with high level of static. You can switch the squelch and be able to hear something, but it is not pleasant nor well understandable. Once I got closer to Nelis the problem vanished. Question to @baltic_dragon what is actually a transmission source for Mission 2. If you used "RADIO TRANSMISION" action, than it needs to use ZONE bound to unit in order to drag the zone with the unit. Otherwise the static zone might be masked by terrain or the power will not be high enough, after recent updates to radio loss and power transmission calculations. Also the zone size does not make any difference, as for this action the zone is used to mark the position, not the range of the reception (this is defined by transmission power). The zone is only used for its center position which defines the position for transmiter. Or you can use Lua script and make unit to transmit on radio, which is far more handy but requires to code conditions in Lua and not in mission TRIGGERS. Video is long (and sorry for some Polish curses) so here are some time marks: @18:00 - there is sudden abrupt in FM coms. I'm switching squelch on FM and able to hear some parts of transmission over heavy static. This confirms again the transmission is on correct frequency and the problem is the reception level in this specific location. Question is who is transmitting (which unit). My wingman is right next to me, so it cannot be him. @18:38 - funny enough the transmission go back to normal @22:43 - again FM transmission problems, same story. By switch squelch I'm able to hear something over heavy static @28:43 - I decided to switch to ARC-210 radio for FM freq and overcome the problem of able to hear the narration. I'm playing around with squelch, freq or remain part of the video to proof I'm able to hear on both radios, though the FM one seems to have lower RX sensitivity and this seems to be a source of the problem.