Moonshine

it did work prior to the ominous christmas last minute update in 2022.. since then they are broken again

dont know why this is tagged as "missing trackfile" this issue is now sufficiently reported..

he did state that he switched the fuzing of the bomb to "nose" hence the fins (for the snakeye) or parachute (for 82Air) will not deploy and slow the bomb down... he isnt talking about tossing them in hi-drag settings

this. and also there is still this issue:

does work for me MGRS.trk

This is still the case. And nothing in the patchnotes. Its about time the viper gets some serious bugfixes. Long overdue.

been reported here, apparently "WIP".. hope to see some changes soon. current implementation makes 0 sense and does not reflect any manual either

another example. as you can see, i clearly step to the wingman (and no, missile is not pitbull off the rail), yet still both missiles track the same target. Aim-120_TGT_selection.trk

Need to enable ground jettison plus master arm sim or armed on ground

DTOS still gives you an ASL upon designating. also youd use CCRP until you can visually see the target, then switch to CCIP. Switching modes mostly happens on the final wire to the target (after the pull down and roll out) thats why OAs are so important. By stepping through the sighting option you get steering information to the offset aimpoints (thats how you fly a proper pop-up profile as per the manual). CCRP is for level flight, but not limited to it. toss profiles are far from level flight and CCRP is much more accurate than LADD

while i do think upside down bombing is rather questionable if not unreasonably dangerous, the ASL (azimuth steering line) should still not point in the opposite direction of where your steerpoint actually is, no matter the attitude of the aircraft. and as mentioned by VarZat, a pop up profile that requires some offset, some roll over and pull down to get on final attack heading will include this. if during that maneuver, the ASL misguides you, this can end very badly

just tested again, this time waiting for the initial toss cue to disappear so i dont drop at the edge of the envelope. while the effect is significantly less, its still present. CCRP_Rel_cue_jumping3.trk

@skywalker22 you can not use HTS and Harm HAS mode together. If you use HTS, you need the harm to be in a PB mode (any of them). Because: in HAS, the HARM seeker is your sensor. With the HTS and HARM in PB, your HTS is the sensor, not the HARM. dont mix those two up. If you use HAS, your HTS is useless to fire the weapon, no handoff will be made. while you surely can display the HTS (HAD) while having the Harm in HAS, it does not share information with the missile, so the HAD just a fancy display of emitters that you cant do anything with. edit: resolved

so, flew some bomb toss attacks, noticed that upon starting the pullup, the release cue on the ASL starts "jumping" up and down. is this supposed to happen or is this bugged? CCRP_Rel_cue_jumping2.trkCCRP_Rel_cue_jumping1.trk

appreciate this, thank you!

been reported, still an issue

Would have to see a track of how you employ it. Generally, pay attention to the keyhole during your maverick employment. Too far „off-bore“ and the missile wont be able to turn in time. Its not super maneuverable.

watched and reproduced. nice find. Test_2.trk

Most likely your SOI in this case is the hud. And in AG mode CCRP or DTOS, you can slew the TD box on the hud, therefore tgp moves along with it. see track attached Test_1.trk

Interestingly, that one manual that has RWR information in it of a previous RWR version built in block 50 C/D did have so called „range rings“ (25nm and 50+nm). this alone indicates that measuring range was possible even with an older version of the RWR. however and rightfully so, someone came up with the reason that range alone isnt the only factor on how „dangerous“ something is. Hence the newer version does work with target priorities as explained by raptor. is it too bold of an assumption that the range measuring „feature“ is added on top of that „priority“ feature to not only display „level of danger“ but also position the indicator accordingly on the RWR (2 identical emitter, both tracking my jet, yet one much closer to the inner ring than the other due to distance)? pre update the RWR felt like this was the case. The current one not so much while i understand the exact function of the system itself to be confidential, simply "connecting the dots" based on the little information available of the arl 56m and the info on previous RWR, it does seem less like a "lucky guess" in modelling that, more an educated one. and ED did go down that road with other systems too which surely is the right approach

i observed similar using your track to test. nails -> outer most circle - spike -> middle circle - active missile launched -> center of RWR. the logic seems clear, however it might need some finetuning as in some examples, the symbology was "jumping" from the very center to the very outside in relative quick intervals tested it with a buddy, note especially the rwr during the time i am low level defending a missile. the "16" is very jumpy mobettametas_Dogfight_Arena_v1.73.2-20230418-194938.trk

I used the scenario you described and made the 5s test. Then i remembered ED saying that seasons and temperature do have an effect as well, hence i added more tests with different season and time settings (to see if night/day alone changes something) in order to provide comparisons. This can be taken even further by conducting even more tests with a similar approach (altering the units this is tested with and more weather settings like sun vs rain or just clouds and even different maps. and from Taz' post above even the surface the units are placed on seem to have an effect, hence why i placed one on grass, one on tarmac.) but the two most extreme examples (summer/winter) show the most significant differences. Everything in between will show the same tendency with smaller amount of impact on the outcome

@NineLinesince you dont seem to want to provide the evidence you have (which you claim is public) it makes it really hard to argue any point. Not saying you might not be right, however it would also not be the first time some manual was misinterpreted, even more so since it bears the risk of getting mixed up in translation between languages. Now with the current approach you guys seem to take about requesting undeniable proof from public documents before you even move a finger (yes its an overstatement but the tendency is pretty obvious) it is getting out of hand. i understand you get tons of bug reports. Some more questionable than others but the current approach will not keep any customers in the long run.

If the January 2023 video is accurate, then the current implementation is not accurate as it does not reflect what is being shown and said in that video. would be appreciated if the infos ED provides about a system would be the same everywhere. Now we have a very new video saying one thing and Newy saying something different. Makes one question which one is now correct and causes unnecessary confusion amogst the playerbase. Simple as that.