Rosly

TGP in A-A STT tracking does not obey the physics, strictly speaking rotational inertia of the camera gimbal. As a result, rapid updates for TGP 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 tracks target by contrast but still, the problem is similar in nature. As sniper pod is in a making, I really hope this can be finally sorted out for both, by simply applying smooth angle transition by some basic math for gimbal inertia simulation.

My 5 cents about how to debug and fix this issue. You do not really have to remove all your scripts and mods in order to fix this. In most cases the problem is one of the scripts which is loaded from Export.lua before SRS. Simply speaking move the following line: ``` pcall(function() local dcsSr=require('lfs');dofile(dcsSr.writedir()..[[Mods\Services\DCS-SRS\Scripts\DCS-SimpleRadioStandalone.lua]]); end,nil); ``` to be the first line in your Export.lua The reason for this is any of the scripts loaded in Export.lua has a BUG and crash, it will prevent all remaining scripts to load. So if your SRS script is at the end it will not load because of earlier error. You can always look into dcs.log to see if there are messages to point to root cause, but also here is another hint. Pay attention to fact that SRS is loaded with pcall. This will make any errors inside SRS script to be silently dropped and continue loading remain scripts from export.lua There are two outcoms from this: - you can remove pcall and load SRS with ``` local dcsSr=require('lfs');dofile(dcsSr.writedir()..[[Mods\Services\DCS-SRS\Scripts\DCS-SimpleRadioStandalone.lua]]); ``` That way if SRS script has problem, you will se error in dcs.log (I would not bet on this as this script is well written, though some UDP socket creation problems and WIndows firewall might be catch this way) - secondly, you can use this idea to load other less trustful scripts by pcall, so they will not interrupt loading of remain scripts in the order. Finally keep in mind DCS-SimpleRadioStandalone.lua is just one scripts from 3 in total. This one is for exporting data from your plane (hence export.lua) to simulate radio behaviour in SRS app. And this script is usually the one which does not load properly. There are 2 other ones loaded as hooks, but those are responsible for UI so you would not saw the "Srs is not connected" message which is the main distinctive aspect mentioned as observation for this problem, meaning UI scripts are fine and only the data export is not working.

Setting "Disperse under fire" for Infinitary units does not work anymore. Units still run away in random directions regardless of the setting when under fire. nullIssue was notice also by other folks.

1) Find another pre-order without feature set listed in the past. 2) Those are already pretty simple avionics. Beside autostart - how those will differ from FF? What is the point other than $ income?

For god sake!!! Are you serious? First rush and premature announcement of the Ch-47F without feature list. Than "strip down" (to put it mildly) of existing "full fidelity" modules as Flaming Cliffs 2024. What next? Stickers and loot boxes? Paid plane skins? If this is the "new system" than I'm out. Sorry ... this is clear sign something is really, really wrong. The point is some of us spend a lot (and I mean rally a lot) of $ for this game. Even more for gear which works only with this game. We supported ED like no other community buying almost every DLC, signing up for pre-orders and spending endless hours in DCS over years! We design missions, write mods and spend endless hours together in virtual sky's. We all accept some level of business oddness (priority on paid modules not engine, terrain, ground units and stability) as we all know the reality and exactly how this business works and how it is kept afloat. If you do not feel difference between early access, pre orders and current situation, than sorry. There is something wrong with your perspective, not those who asking questions. PS: "We must learn a new system..." ... Gosh...

From stand point of customer relations, why ED do not address the elefant in the room, which is the question everyone is asking: why ED offered the product without specifing the feature set? It is not about pumping the drama. Everyone is actually on topic asking why this happened, as this is very unusual. Like... Why you not addressing this question, why? This is main topic question...

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.