falconzx

@Lord Vader sorry if i bring this up again, but i think the last track is quite interesting in response of your latest answer. Gimbal limits should apply to the radar dish angle. In the track is clear shown what i claim: the dish in A3/A6 go where in A1 cannot go. Can we have an answer on this? Thanks. Take care.

My tests went pretty good. I used a runway number just to have something very detailed to look at and on a plain surface. I used TGP to fine check and doublechecked the behaviour on HUD/HMCS. Mastermode NAV, so only diamond on hud. My results: GPS is fixing correctly the drift, the errors caused by the GPS CEP leads to a mis-aligning of the correct STPT by a CEP of maximum 20m. I've seen fluctuations between 5m and 20m, on average it's most of the time off by 10m. I don't know if this is the desired behaviour but that's what it is now. At the end i also did a different test, i tried to perform a bad manual fix, by around 0.25nm of delta off. Then putting back the autofix, just to see how it was going to behave fixing a big error. The system in around 3-4 min (probably because of the kalman filter) gently moved the point on the correct spot(~10m) again. That was very good. Another thing i didn't like so much is the graphical drifting of the diamond on HUD. Initially i thought it was a bad aligning on HMCS (even if i aligned it almost perfectly using max zoom). But no, that happens on the HUD also. The point seems to be on the same spot where the TGP is pointing ONLY at very close distances(less than 100ft). When you increase the distance (very visibile already at 4nm) the diamond shifts, like the point where is centered is not at the center of it. Because of this issue when the TGP is off by around 10m, the diamond is off by 20-50m at 3-4nm and if you go even further away it's even worse.

yep I'll do it soon too, i'll post my results.

This is not what @bladewalker just showed in his tests and supplied images. That was not the correct way to report a bug, but if what we all see there is the current GPS->INS fixing implementation, then there is presumably a bug and someone should do a proper report. From what is my understanding the GPS CEP is that noise you're referring to. As the acronym says it's a circular error probability, so it's constant, under the same conditions it's something shouldn't increase overtime. What he experienced is an error increasing overtime. (typical INS behaviour) That error was visibly greater than GPS CEP. My deduction then is that GPS is not fixing the drift there.

Just for adding more clarifications, just because i read you are pointing out in the images the fact the coordinates are not changing on TGP: If your INS is DRIFTING, it's absolutely normal that your TGP is showing the same coordinates you preplanned but the point in the real world is "drifting" to a different location. The FIX procedure commonly adopted to fix the drift, it's exaclty done to resolve this. So you are telling the INS wich is the correct position in the real world for that specific steerpoint. And indirectly you are telling the INS which is your correct position in the world space. What i ask at this point is, why the coupling with GPS is not doing anything to correct this? what would have happened if you have waited more and traveled even more? is that drift going to increase, more and more? Shouldn't be any type of warning or notice? At least in the NAV DED page where the accuracy is rated with HIGH/MED/LOW words? At a certain point our INS pos is going to differ a lot from the GPS readings, is it correct that the GPS is doing anything to fix that, and if yes why? why is needed a manual fix then? By common sense the system could have a delta threshold to establish how much drift is tolerated before applying a fix(around the GPS CEP maybe?).

Given the number of weapons in development is increasing, i suggest in parallel to work on more variety of VFX and maybe associate them to the color/type of terrain or object hit. Some tips: -Create more types of explosions with increased duration per type/size of warhead and type of weapon, in general DCS explosions and their relative smoke or dust raised have a very short duration. -Change slightly the colour of the explosion smoke based on type of terrain/texture hit. Green/brown for soil and grass, Yellow/orange for sand, Grey for urban areas, with increased debris, white for snow. -Based on slope data(if accessible) or height data, add the number of debris/rocks relative to some type of explosions for mountain rocky/sloped areas. -More smoke/dust duration, means bending the smoke produced by explosions in the wind. I would add this influence not immediatly but after the first blast. -More variety of fires for "set on fire" things, like vehicles buildings, etc. All the current types of fire have different sizes that produce proportional amount of smoke. But the fire shape or the smoke shape and color they are very similar if not identical. I suggest to increase variation in these, like making the fire more irregular in intensity and shape, like having sometimes longer flames or irregular blazes, on random basis, to reproduce the variety of materials burning in a real vehicle. Same applies to smoke, just add some random to the colour and intensity, the amount and colour of smoke can be associated to a random basis per object at the start of the effect, and it can mutate randomly across the duration of burning. You can parent the values of randomicity to a coefficient linked (or even originated by item data or class) to items data to have some controllability per size or type of vehicle or object. If this system works good it can be applied with a more fast time evolution to the burning of aerial objects. The decrease in intensity introduced in the last years it's very appreciated but i think adding some bit of variations and unpredictability it's a key point that can make appear the sim core hugely more realistic with a minimal effort in terms of work for the team. Most of these i suggested are achievable just adding more instances to the effects with some variation in each instance. In general what make the current fires and smoke "fake" it's the lack of detail/variation.

Let's try again with a more clear track, now i've used active pause. Data to reproduce the incoerency: Aircraft state: Pitch: +30 Roll: + or - 90° Radar and Antenna settings: Azimuth: A1 and A3 Mode: CRM. RWS or TWS (not relevant) RDR CURSOR position: just put it close to the MFD lateral edges, without touching them (it will cause an azimuth change) Use Active PAUSE to mantain this aircraft attitude while doing the tests. Observations: In A1 the scan volume determined by the azimuth blue caret (bottom of the screen) is not following the RDR CURSOR on the entirety of its gimbals. More precisely as you can determine by the graduated scale on the bottom, the scan volume is limited by 20° degree on one side, so the gimbal is like 60° on the side not affected by the issue and 40° on the other side. Putting A3/A6 the azimuth caret will go and scan where the A1 just couldn't go. More precisely the antenna is going back to it's original +/-60. This happens on the left if you have left wing down. This happens on the right if you have right wing down. If you repeat the test with -30 pitch: This happens on the right if you have left wing down. This happens on the left if you have right wing down. If you repeat the test with 0 pitch: No issue is observed. Little offtopic(sorry), but i've no time to follow now to a different bug report: in the second part of the track i played with elevation to see how in SAM mode the elevation caret is not showing anymore the angle relative to the horizon (gyro stabilized) only, but seems it's alternating a nose relative angle while tracking the target. Considering that SAM it's alternating between tracking and scanning, that's theorically ok, what it's not ok it's the "delay" between the two visualizations. Seems like the antenna has to travel in elevation between the two phases, while it's only a change about relativity of the angle visualized by symbology. That's not correct, if i've not moved my ANT ELEV axis on my control, the antenna should be very close to the bugged contact, so there should be no delay or transition stealing time to scan phase. Considering the VERY limited time to scan in SAM mode it's important to "unlink" what's the symbology "speed" from what's the antenna actual position and moving speed. F-16_azimuth_scan_volume_incoerency.trk

I actually appreciated the efforts ED is doing to re-make systems that were working good enough for the sim standards, like the choice to implement a INS+GPS more deeply. Instead, this radar false returns, seems a step back to an ancient, well known, philosophy: all hat and no cattle. Seeing how much is WIP, it's a feature force pushed into the update in a state that can be titled only with: "fake returns", further explanations are quite fancy given that the user can't be convinced in any way this is not a fake graphical effect on the radar screen. You move the radar, nothing changes, you turn off the radar, nothing changes. I just give my two cents: we don't need candies and fancies, just pay more attention to the DEEP details that can make this sim good. Start checking the gimbals of the antenna on the scan pattern when azimuth is set to A1 and the aircraft is maneuvering with medium pitch angles, scan volume positioned on the gimbal limit and you roll the aircraft. If someone in the team only have the patience to do proper tests they will notice something wrong. A problem that only the F-16C has, but a lot of people just don't care because most of pilots don't use A1 and use the radar while leveled. This... months are passing and still we don't have a proper functioning AUTO MLC Filter. At the current patch its forced on, so it filter all even in lookup(no clutter) scenarios. I think going on with decorations while these and more core radar issues are still there its a waste of time.

I can confirm. I usually fly in quiet and i saw them.

In my squadron many pilots reported this crash related to the laser arm, they experienced it with ATFLIR only, expecially if starting cold from an airfield and mounting atflir via rearming. But they still not have exact steps to reproduce, it's like happening 50% of times.

UPDATE: Using template the STN can be specified to a correct number, this resolve the DCS crash issue. However all planes will have the same STN of the template. On F-16C you can edit it in cockpit and solve the issue. On F-18C you can't so the TNDL between dynamic spawned Hornets will not work! (Someone should report this in F-18C section)

Yesterday evening we tested dynamic slots in my squadron. I just enabled some airfields in ME. Then after startup, as usually we go to TNDL Page3 to configure our STNs/own numbers. Default for F-16 is only a strange number containing an "X" on 1st line, dobber down to select it and DCS freezes (you need to kill process to exit). It happened to all my squadron pilots. Maybe i can try to put F-16s under a template with a manual STN. Today i will test if it's a viable workaround.

After a short test, the issue in current patch remains, but now i think it's affecting F-18C also. In the previous patch i could add a F-18 to my team asking him to tell me his STN. Now it doesn't work anymore. Maybe because the F-18 also have to confirm his "position" in his team. Unfortunately i'm not aware about a way to do it.

I Confirm. And still not the AG modes like GM or GMT also.

Ok... I understand FC3 is no longer on shop, but it's not correct to force people to buy FC2024. At least i expect ED to transform all the old FC3 Licenses in single plane licences to grant who bought FC3 the usage of the planes they have paid for.

I just updated, i have Flaming cliffs 3 installed, when i launch dcs it say FC3 modules are not authorized. I click OK, i go on module manager inside DCS, pop-up appear saying i have to install FC3. I click OK, DCS quits, try to reinstall FC3 but fails. Launcher re-opens, and if i launch DCS the loop repeats endlessly. Any idea?

Pilot died on this lowpass. I don't remember the area exactly, but it was somewhere SE from Shayrat airbase. probably heading 130° and between 5/15nm. Suggesting to check hitboxes of the pipeline. TY

i can confirm this, another report was made about different master modes but this now happen also with NAV. For example i was used to leave GM (Ground Mapping) in NAV especially in night operations, then i configure my A/A mastermode preselecting TWS and setting the Azimuth. It was used to retain all of this in background. At the current patch it's all useless because of this wiping back to RWS on every master mode change.

The workaround is confirm the "own" position in the STN DLNK page. If each team member change it or just confirm the ME position, the team visualization come back to live. Other strange behaviours are about the GPS time, before using a non GPS sync, so just syncing client clocks TNDL worked fine (i think IRL there should be a NTR to master the time) now you can't see other F16 but you see the F18 members, strange no? Other messed thing, staying on topic is the sharing on FCR. Before the numbers on top of a shared contact indicated correctly the number of the team member who bugged it. Now it's not anymore consistent. Best regards

I've noticed that the symbology around the contact is changing when bugging a contact, is it a choice or is just a bug/wip thing? I mean: - sorting number disappearing - altitude changing format At this current state it's not very practical to deconflict errors in sorting; if my wingman bug/commit on the same contact i bugged i can't know because the number on top of it it's not showing. It's showing only if i un-bug that contact. Video and track for better explaining and visualizing. Best regards and thankyou. F-16_sorting_symbology change.trk

Loadout 4xGBU12, Litening. Steps to reproduce: -Set DTOS mode -Designate a point with TMS up (i did it via HMCS) -DMS down for TGP SOI. -TMS right (area track) to ground stabilize -ICP 7(Mark) -TMS UP x2 to create mark. -press 0(M-SEL) to select that mark as active STPT -dobber RTN to exit Mark mode. -NWS to switch to CCRP -TMS down to CZ Here the TGP will CZ to the previous waypoint and not to the active one. Workaround: Make SOI a different sensor (FCR, HSD) change waypoint then CZ should behave correctly again.

Hello, thanks for reviewing but maybe i'm misunderstanding how the antenna gimbals works. F-16s as i know, and tested in DCS is a +-60° in all directions(try STT for example). If this is true the limits should be equal, regardless the roll state of the airplane. If roll influences the gimbals the causes could be two: gimbals are irregular(so there's something wrong in STT), or, there are problems to the gyro stabilization of the antenna. In the track you can see this irregular behaviour, same pitch, same radar settings, different roll states = different results. If it can help i've made a video to better explain what i mean, and what's the behaviour expected versus the sent track behaviour on rolls. In this case i modeled the plane have a +30° pitch and the scan is horizon centered (simulating an ANT elev left to zero) and i've lost 4/5° degree circa over a 60° degree gimbal. In DCS: F-16C values are way more big. So i suggest to check the math behind this, and also check why results are not even during rolls. Thanks. gimbal_and_roll.mp4

Very short and simple track. As you'll see from my inputs in the track, i'm not touching any radar controls while performing rolls at +-30/+-40 degree of pitch. Bank towards the scan only cause the problem when pitch is positive. Bank opposite of the scan only cause the problem when pitch is negative. F-16_A1_SCAN_MOVING_BY_ITSELF_ON_ROLLS.trk

2.9, years passed, the bug is still present. Bank angles towards the turn in a climb move the A1 scan volume from the inside of the turn, towards the center. If you roll/bank outside the turn it stops happening. If you dive the behaviour is inverted: bank angles opposite of the scan volume push the scan azimuth towards the center. Any news?

You can fix it syncronizing the GPS clock manually with your mates, if you do the same procedure you need to do in the 80's with no GPS, you will fix this as well. DED -> DLNK -> Put GPS TIME OFF then sync the time, in the 80's you need to decide who is the NTR, in modern you can put GPS time ON again. We also synced the clock in TIME page accordingly, but i don't think this specific does take any effects. Tested in my squadron and working. With GPS and without it.