Datalink movement

[Beamscanner]

Has anyone else noticed that the datalinked tracks on the SA page and radar dont move smoothly when you turn?

 

The datalink tracks seem to skip around trying to keep up with the turn while other items such as the map, compass, way-point, radar bricks, etc; move smoothly with the turn.

 

Datalinked tracks have positional data (like a lat/lon coordinate). It would make sense that, if you maneuver, the tracks would smoothly slide in azimuth following that coordinate in space.

 

Other DCS modules, like the F-14/SU-27/A-10C, dont appear to have this problem. To me, the current state makes the datalink picture look like stickers applied to the screen rather than an integrated system.

 

 

Does this stand out to anyone else?

[Santi871]

yep, same issue here

[theinmigrant]

Yes, since day 1. WIP I guess.

 

Still much left to put in the oven ;)

[Harker]

Good observation, again. Seems logical to me, considering the Hornet's systems. This fits with the thread about the RWR, DT2 on the HUD, HARM TD box etc. https://forums.eagle.ru/showthread.php?t=238656&highlight=rate

Maybe you should add this there as well.

[Rainmaker]

Just keep in mind datalinked tracks not picked up by your own sensors aren't constantly updated at the DL is not a constant transmission. It's going to have a slower refresh rate. It's probably a bit more realistic than the previous versions that we have on other aircraft IMO.

Edited August 6, 2019 by Rainmaker

[noisy_lightning]

Just keep in mind datalinked tracks not picked up by your own sensors aren't constantly updated at the DL is not a constant transmission. It's going to have a slower refresh rate. It's probably a bit more realistic than the previous versions that we have on other aircraft IMO.

The OP is not talking about the refresh rate of the other tracks he is talking about the rate at which the entire screen is rendered. Take for example that there no other tracks on the SA page except for the route, WP, couple of s2a range rings, when you turn the aircraft the entire display stutters at a low "refresh rate" similar to the HUD on the F14, whereas it should likely move fluidly and smooth with no stutter like the F18 HUD.

 

Sent from my ONEPLUS A3003 using Tapatalk

[Harker]

Just keep in mind datalinked tracks not picked up by your own sensors aren't constantly updated at the DL is not a constant transmission. It's going to have a slower refresh rate. It's probably a bit more realistic than the previous versions that we have on other aircraft IMO.

Exactly what noisy_lightning says. Compare the movement of SAM threat rings to that of the compass rose and you'll see what the OP means. Especially for SAM rings, they're not even updated, just marked as coordinate points, so there's absolutely no reason for them to lag.

[Rainmaker]

The OP is not talking about the refresh rate of the other tracks he is talking about the rate at which the entire screen is rendered. Take for example that there no other tracks on the SA page except for the route, WP, couple of s2a range rings, when you turn the aircraft the entire display stutters at a low "refresh rate" similar to the HUD on the F14, whereas it should likely move fluidly and smooth with no stutter like the F18 HUD.

 

Sent from my ONEPLUS A3003 using Tapatalk

 

I disagree with your assessment based on what he wrote in his second paragraph. Doesn't sound like he’s talking about the entire page to me.

[noisy_lightning]

I disagree with your assessment based on what he wrote in his second paragraph. Doesn't sound like he’s talking about the entire page to me.

Agreed he talks about the tracks however if a rotary aircraft was in a hover and not moving the track should still move smoothly even when the donor updates it when our f18 is turning. Yes the tracks will "jump" on refresh but for those seconds they are not being updated they should rotate smoothly like the compass rose.

 

Sent from my ONEPLUS A3003 using Tapatalk

[Rainmaker]

Agreed he talks about the tracks however if a rotary aircraft was in a hover and not moving the track should still move smoothly even when the donor updates it when our f18 is turning. Yes the tracks will "jump" on refresh but for those seconds they are not being updated they should rotate smoothly like the compass rose.

 

Sent from my ONEPLUS A3003 using Tapatalk

 

Is that currently the case or are we speaking hypothetically?

[Harker]

Is that currently the case or are we speaking hypothetically?

Right now, the different elements lag more than the compass rose, even though they're supposed to be space-stabilized. If you're asking whether it is like that or not IRL, I personally cannot comment on that, but I'm basing my opinion on my understanding of how the relevant systems work.

[Beamscanner]

What I’m talking about has nothing to do with trackfile update rate. It could update once every 5 minutes for all I care.

 

What I’m saying, as others have clarified, is the the datalink tracks are not space stabilized like the other objects on the displays. Being that they exist at a known position in space, they’re placement on the display itself should refresh smoothly and synchronized with all other objects on the display.

 

 

Instead what we see is tracks that jump at discrete intervals (rather than a smooth continuous movement) on the display. It doesn’t look natural or ‘solid’ to me. It’s much more apparent when exporting the DDI to another monitor.

[Beamscanner]

Good observation, again. Seems logical to me, considering the Hornet's systems. This fits with the thread about the RWR, DT2 on the HUD, HARM TD box etc. https://forums.eagle.ru/showthread.php?t=238656&highlight=rate

Maybe you should add this there as well.

 

I agree that fundamentally these are the same issues, just with different data on different displays. I would guess that it could be similar code being used for both displays. Hopefully they can fix this soon. It really lowers the quality of what should be a premium product.

[oldcrusty]

Right now, the different elements lag more than the compass rose, even though they're supposed to be space-stabilized. If you're asking whether it is like that or not IRL, I personally cannot comment on that, but I'm basing my opinion on my understanding of how the relevant systems work.

 

 

I was just messing with it few minutes ago. The DL objects do "stutter" a little in angular movement but at much better rate then ECM contacts... doesn't even compare in my opinion.

 

The ECM display is a slide show when maneuvering in a DCS Hornet

[Harker]

I was just messing with it few minutes ago. The DL objects do "stutter" a little in angular movement but at much better rate then ECM contacts... doesn't even compare in my opinion.

 

The ECM display is a slide show when maneuvering in a DCS Hornet

Yeah, it's much better than the RWR. That one's a nightmare and useless during maneuvers. Check the DT2 TD box and HARM TD box in TOO mode (both on the DDI and the HUD) as well. This issue exists in several things, in varying degrees. I think it's just a result of the sensors not being really tied to the INS in DCS and just coded separately on their own

[theinmigrant]

I just don't understand why this wasn't thought before. I mean, come on, ED has a lot of experience in this industry to have this slipped through.

[Harker]

I just don't understand why this wasn't thought before. I mean, come on, ED has a lot of experience in this industry to have this slipped through.

If you look at the bug post I linked at the beginning of the thread, one of the items mentioned is the LTWS L&S TD box on the HUD. After it gained attention, this was fixed (although I think LTWS should extrapolate the contact's position between refreshes and thus the TD box, but that's a different issue). I'm guessing it has to do with the fact that the Hornet is still WIP or sometimes, simple stuff escape even the most competent people. Or it might have to do with the coding process or the yet incomplete INS implementation. Also, that's what we're here for and as long as ED is willing to listen and investigate, I'm happy.

[Joker328]

Assuming this is not how it functions IRL, my guess is that it's a performance issue. Every time it needs to update the display, it's going to take some CPU cycles to do the calculation of how each object should move based on the movement of the player aircraft (even if it's not updating the contacts). Multiply that across numerous contacts and multiple systems (SA, Radar, RWR, HUD) and it becomes more demanding. I assume the slow update rate is a way to mitigate this. Perhaps they will be able to optimize things in the future, but it may never be as smooth as we would like.

[Harker]

Assuming this is not how it functions IRL, my guess is that it's a performance issue. Every time it needs to update the display, it's going to take some CPU cycles to do the calculation of how each object should move based on the movement of the player aircraft (even if it's not updating the contacts). Multiply that across numerous contacts and multiple systems (SA, Radar, RWR, HUD) and it becomes more demanding. I assume the slow update rate is a way to mitigate this. Perhaps they will be able to optimize things in the future, but it may never be as smooth as we would like.

I'm guessing that this could be circumvented by setting the datalink contacts as fixed points in 2D space (x,y or r,theta), with the position of the point updating every time there's a sensor update. Then, the points moving with the display wouldn't cost more resources than a waypoint moving. Also, what about the SAM threat rings? These are pre-defined, non-dynamic fixed points. They should cost exactly as much as waypoints to move around.

 

There's another point to be made on whether the SA page contacts should be stationary between updates or if there is some extrapolation based on their velocity vector.

 

Since the SA page is causing performance issues for a lot of people in MP, I would accept the current state, if CPU resources are a consideration. Same for the HARM TOO TD box. I would definitely like to see the DT2 target and RWR work properly though, as their functionality is severely hampered by this, right now.