Moonshine

circle is friendly, square is unknown and triangle is enemy. and to underline this for easier recognition there is the color. green for friendly, white for unknown and red for enemy. so if it is identified, red should always be a triangle. i think it was just worded wrong in OPs post

bump

dont have a track for OPs issue, for my comment, there is this: https://forum.dcs.world/topic/299714-fcr-color-after-lock/#comment-4957988

the whole FCR DL symbology is a little off. for example: how can a track that shows Red on DL (and is also detected by my radar) turn to white (unknown) from the second i bug it? do i magically lose all DL info on said contact?

interesting approach to a WCMD (wind corrected munitions dispenser) if thats the case

i think so too. while it is harder to detect on cluster bombs since their bomblet-footprint is so large and somewhat random that it is hard to tell if it did hit the correct spot or fell short (or otherwise missed). even more so if 2 bombs are dropped like @NineLine did in his test

the current inaccuracy of the TGP might not help with it. same as other GPS guided weapons (like the GBU38) dont hit within their parameters, i dont believe its the weapons fault but more the TGPs lack of accuracy. post for reference: TGP CZ issue (results in shifting Coordinates everytime CZ is pressed) -> https://forum.dcs.world/topic/315078-cz-function-issues/#comment-5132696 JDAM inaccuracy (most likely due to the inaccurate coordinates received from the TGP, making bombs miss beyond their 5m CEP) -> https://forum.dcs.world/topic/317925-jdam-still-inaccurate-beyond-the-5m-cep/#comment-5144779

any chance you could post that public document you mentioned @BIGNEWY? id love to have a look at it.

this by the way has already been part of a discussion and raised by other people, including track replays: then there is this: „The navigation system is initialized by transfer alignment from the aircraft that provides position and velocity vectors from the aircraft systems.“ source https://www.af.mil/About-Us/Fact-Sheets/Display/Article/104572/joint-direct-attack-munition-gbu-313238/ so that leaves us with this: when the INS data is transferred from the jet to the bomb, why would the currently selected master mode make a diffence in the speed at which this is done?

what makes us think is wrong? the fact that upon pressing "power on" to start aligning the JDAM should not make ANY difference at all which master mode, which other MFD pages or whatever is selected that would affect the duration of the alignment process. when starting the alignment of the JDAM while in AG mode and then swichting master mode back to nav for example completely stops (or slows down the alignment process) until the next time you get back to AG mode and check the SMS page, then it picks up where it "left off" when switching from AG to NAV. this can not be correct

id be very interested in that "other publicly available data" as the only one i found after long searches is the one mentioned in my original post. this one also includes the values for other missiles like the aim7, for which the lua data in our game files exactly matches the values in the mentioned document, not so much the 120 as the ONLY missile that has different values in the game files even the "very specific navy publication" (dont know if its still allowed to mention its true name) states that the aim 120s explosive power is larger than the one of the aim-7 even though it has a smaller explosive mass than the aim-7 edit: that navy publication says that the AIM-120 is using a 50 pound warhead that explodes into thousands of fragments. even though it is approximately 30% smaller than the warhead of the AIM-7M, the 120 is using higher density gases to propel fragments more explosively than the aim-7. edit 2: since the document is publicly available under: https://www.cnatra.navy.mil/local/docs/pat-pubs/P-825.pdf, page 158/159 according to the ED gamefiles, even the aim-9 has the higher proximity fuze setting than the 120, this defies every logic

some options only have the AI using the jammer upon getting locked by radar (i think its the default ECM option for AI). thats why i specifically set it to always jamming in the ME during my test. however, top of HSD and Top of FCR did not show chevrons at all. to note, there was no AWACS in the mission but that should not have any effect on it

Furiz is right. i did not see anything wrong in my test. set the target jamming to always be on, co-alt to avoid any of the borked lookdown effects, found him on scope as a brick at around 40nm, entered STT, then the radar scope changed to 160nm with the locked target "stuck" at the very top end due to jamming and range showing 99.9 in the HUD (as in, cant get any range due to jamming) continued hot, burned through at around 28nm, then the radar scope changed to the 40nm range and the locked target started moving down on the radar scope as the range closed in. nothing wrong there. if anything i question why the chevrons indicating a jamming contact do not show up on radar scope prior to even finding a radar contact (brick). isnt it supposed to always be there in the direction of where that jamming signal comes from? F16_STT.trk

not sure if its correct that it only shows up when enabling Search, however at the very least it shows up there

does show up for me but only after klicking the "Search" on the threat warning auxiliary panel. SA-11_RWR.trk Edit: took control of your track, just before you enter the threat ring of the SA11, clicked on "Search" on the threat warning panel and SD showed up just fine

for this one there is tracks, for the other one, maybe @101st Lonestar AUTcan provide the one from his mission (or replicate it)?

Yeah back then it was most noticeable when dropping pairs, dont know about single drop in short succession. Either way something is borked as some seem to land way short for no apparent reason besides their strange behavior causing speed loss. this plus the very little damage it does made me avoid the use of jsows since their implementation

Might be the same issue as reported here?:

I dont get your logic, all weapons are implemented the same way, having kill zone and proxy fuze radius set to the same number except the aim120, which has it cut in half…

yes

yeah sadly OAs are currently bugged (https://forum.dcs.world/topic/315005-offset-aimpoint-logic-after-latest-update-dcs-28134437/) such a handy feature if its working correctly, makes low alt ingresses much more fun

interesting stuff @BIGNEWY: dropped 3 of my 4 GBU-12, left station was empty - got re-filled completely with new bombs, one more bomb on the right wing pylon. then the order of bomb drop would have been that the last remaining on the right station will drop. funny enough, it didnt, instead the first of the newly rearmed from left station dropped. bomb releases fine until then, 2 bombs remaining, one on each pylon, one per wing. these 2 bombs never released, no matter in which delivery mode, even tried CCIP, bombs just would not drop this only seems to happen if the pylon rearms before all bombs of the other pylon are dropped, hence why it did not happen in my first try, there i pair / ripple dropped all of them in short succession unlimited_gbu-12_2.trk

VIP and VRP are no delivery modes and should not be bound to one as such. when VIP or VRP are enabled, delivery modes will display such in the HUD some examples: VIPCRP -Visual initial point/CCRP submode VIPLAD -Visual initial point/LADD submode VIP EO -Visual initial point/EO submode VRPCRP - Visual reference point/CCRP submode VRPLAD -Visual reference point/LADD submode VRP EO - Visual reference point/EO submode HRMVIP - HARM visual initial point submode HRMVRP -HARM visual reference point submode However, i could not find any mention about VIP in CCIP and am not sure if it should still display the VIP location, even if CCIP does not make specific use of it like the other delivery modes do

did work fine for me. note in the ME there is 2 rows of options. the right row lets you select the options as desired. the left row lets you enforce these settings (when hosting a server it will overwrite client specific settings by the ones you set in the mission, given you enforce those). track attached. unlimited ammo is on, i launch 4 amraams first, and you can see them getting replaced, same thing happens later on with the GBU-12 unlimited_gbu-12.trk

yeah based on the recent test i will retract all statements and question if OPs gamefiles are as pure as they should be.