Moonshine

yeah had the same happen multiple times now. sadly all in large missions so the trackfile is massive. there is multiple things wrong. why does TDOA command EVERY HTS pod on the team and not just the one from my 3 other flight members? that means it even commands someones pod who might be on the very other end of the map for no reason. plus if the radar "turns off" during TDOA commanding, it bricks the HTS, you get stuck symbols or cant even use the whole pod anymore.

odd. mine are there: null

Yes

from a cold start you need to boresight just like we are used to. from airstart and hot start it magically is perfect. wags video was most likely an airstart, hence its perfectly on target

good to know. thanks

fair point. tried that too now. third track, only "engage air weapons" vs a HARM. doesnt do anything. no missile fired SA-15 no point defense_3.trk fourth track against a maverick. here it shoots and destroys it as expected. SA-15 no point defense_4.trk and because one might say "you were too close and it didnt have time to react", track 5, max range POS-PB shot: SA-15 no point defense_5.trk

no matter what i try, TOR do not engage any HARMs currently. two tracks, on the first i placed the TOR with no specific action to evade ARM or engage air weapons. - it just dies.SA-15 no point defense.trk on the second track, i added "engage air weapons" and "evade ARM" yet it still.. just eats the HARM. bit sad as due to that there is not really any working point defense system currently SA-15 no point defense_2.trk

seeing the same. no steering line on any GPS guided weapons. therefore no release cue (other than the little thing in the DLZ on the HUD showing in range) GPS_wpns_no_steering_line.trk

Must be linked to this. According to the last comment, the whole symbology stuff is still WIP. Would love to see some improvements there. There is some more:

HARMs are broken in multiple ways: 1. currently CTD when employing HARMs in a POS mode https://forum.dcs.world/topic/375872-agm-88c-pos-still-crashing-the-game/#comment-5665934 2. POS modes themselves do not work correctly: https://forum.dcs.world/topic/375872-agm-88c-pos-still-crashing-the-game/#comment-5665934 however; did the SAM in your mission have the "HARM evasion" action activated (mission editor setting) or are you running an IADS script (MANTIS, SKYNET)? that would shut the SAM down when it detects a HARM as a means of self defense, which would explain why your HARM goes stupid in the last phase of flight

@BIGNEWY any chance you could move this to a bugreport? at least mine and furiz post as while yes he did not align the helmet properly, it still is a bug

That is true, yet even with a perfectly aligned helmet the TD box is off from where it should be. The TD box as seen in the HUD does not match the actual position the TGP is looking at as seen in the TGP page. So even without the HMCS the marker vs the tgp view is off. most likely connected to the issue with excessive drift etc made a short track to showcase. - Airspawn -> so HMCS is "perfectly" aligned -> GPS is on, so i should not get much INS drift - on the first pass the deviation is minimal as i have been flying for barely 5minutes. - on the second pass the deviation is already easily visible, and im only flying for 15minutes - on the third pass i use the HUD only (so i could not have thrown the symbology location off by doing a bad HMCS alignment) - still, TD box VS point tracked location on TGP is off quite significantly. and thats after 15 ish minutes. the longer you fly the worse it gets. no alignment will ever fix that. this is also referenced here: and here: so, while you definitely MUST align the HMCS during a cold start to "not have that problem", it currently does not eliminate the problem, rather than just make it "a little less off" TD_box_misaligned_vs_TGP_view.trk

confirmed, seeing the same. yet it only defaults NAV mode to Azimuth 1, not A-A. Azimuth_1.trk

make sure the .png is written in lowercase (.png and not .PNG)

why a wishlist? was literally a report in 2021:

with GPS, Bluefor Viper at around 40m and redfor (without unrestricted SATNAV active) 100m or more according to this post: If even with gps you are getting 100+ m of deviation, then something is off as it does not match the „no more than 40m“ claim in the linked post. there is also bugreports about SPI location drifting etc.. so might be a combination of things that lead to excessive perceived drift. Pretty sure TGP sight picture would not match Hud diamond (or TD box) placement in your track either

look, i did not claim my post was "the solution as it would be in the real jet". it is just the way DCS does it at this very moment in time. reference this:

Dont turn on Mids before your alignment is complete and your time page shows „GPS“. In some cases, you even have to roll out of the hangar.

or you take the AG radar, slew the cursor over until the bullseye location of the cursor matches the bullseye location you are supposed to find and create a FCR Markpoint off of it..

as per the title, the waypoint as set in the ME seems to be off compared to what the jet will show. attached the track and a screenshot. you can see where i put the waypoint in the ME (at 0ft AGL) and you can see without moving the TGP that it starts drifting off as if the waypoint was hanging a couple meters in the air. this happens even in a point track and even with markpoints that have been created using Laser ranging first. on top of that, if you zoom in on the TD box (or the waypoint diamond), it starts jittering heavily the higher the zoom level is. TD_box_jitter.trk

Its been over a year since that bug was reported here, its pretty big of a problem if there is multiple emitters of the same type in the mission and it would be nice getting that fixed. since the old report was locked, id like to simply bump it again.

Not working for me, clean game, except SRS and Tacview. crash log attached. @Lord Vader dcs.log-20250123-163132.zip maybe its the sheer amount of contacts causing this. not getting crashes with "low" number of contacts.

we had this issue before, described here: with the lastest patch, it was re-introduced. was fine before the update on the 21st of January.

Thanks for the test, good insight. i do know that some servers/scripts dont just „shut down“ things, instead it effectively „despawns“ the units as the player moves a certain distance away. Would explain the disappearance you are describing and probably the next thing to test.

isnt that "on" or "off" thing meant to be for force sensing sticks (when set to "on") and for spring ones when set to "off"? thought either newy or nineline posted about that a while back, cant find the post just now Found it: