oldcrusty

Now I see what the issue was when it was reported long time ago... the ASL doesn't show the lateral offset required 'at release point' and it gradually and constantly creeps toward the target as it gets closer. Currently, we have to anticipate and lead the ASL just before release. It creeps rapidly at very close range. So... it's pretty much 'Kentucky windage', ;). This become very obvious when dropping high drag bombs. When aligned with the wind, no problem. At 90 deg., stay ahead of the game. Yea, I still used 40 kt wind, I guess I was too lazy to change it. So for now, it's probably better to figure out an ingress route and attack direction more aligned with wind. Another thing... I released at only around 450 kts., since I wasn't sure if DCS factors in the limits for any kind of HD bombs or not.

It certainly acts different, well in my opinion. I haven't tested high drag setup yet, perhaps today. This scenario should definitely require different approach.

I think you'd be better off getting an explanation from a youngster... I'm probably not that far behind you but who's counting . Short explanation: Hornet weapon systems, JHMCS, release calculations and 'few' other things are still partially borked up... Sure, there are always ways to adjust to the bugs and develop your own ways to 'WIN'. From that angle, hackers are the most powerful weapon... Well, we are both too old to start on that path, lol... or are we? (jk)

OK, I had enough time for one test run, before my Reverb G2's cable started showing signs of wear and tear... well, it's the original one. Rockeyes x 4, 40kt wind. In the first attack, almost perfect tailwind, second run at 90 deg. Perfect hits both times. I left the burst ht at 300 (whether it matters or not). Well, the thread is drifting off a bit but ED doesn't pay too much attention anyway,

No, not yet... I wouldn't expect the same results though. With the same wind condition, the attack direction would 'probably' be a major factor, along with release altitude. Hopefully I'll have some time to run a test today.

You know what... after you brought it up, I went and tested it. Hmm, it looked a lot better now, as compared to an identical test I'd done over 2 years ago (damn, time flies!). The winds of course have to be set within certain limits... We can't use dumb bombs in 80 kt. crosswind component, well even smart bombs might have an issue... I tried it anyways, lol - no dice! OK, in my 'normal' test I had a 40 kt wind from my left 90. (same wind @1600ft, 6000ft and above) Target elevation was 4400ft. I released from a level flight at 9000ft, just below 500kts. I didn't worry about heading caret vs. tgt diamond on heading tape... seemed OK to me (I remember some folks reporting issues with that part in the past). Simply lined up VV on the ASL without making any major corrections as I approached release point. Spot on! As long as I released from level flight, nailed it every time. Some people might say that was a bit too optimistic? Not me, lol. I was happy. Now, releasing from a 30 deg. dive was always short.

In the latest OB, level release still rules, anything else is way off.

Regardless of designation method (FLIR, HUD/HMD), the TD box goes bonkers after couple of violent maneuvers. WPDSG (w/o correcting by slewing and re-designating with TDC) seems to be more stable. This target was designated by TDC on ATFLIR pod. Anyone else on ST DCS latest OB?

Hehe, it sure does. We all get there... well, the lucky ones do. Mission Computer should keep all sensors on the 'same page'. That elusive sensor fusion is not quite there yet.

We're past that point already... I'm running the game with SatNav box checked now. Why? I explained in one of the posts above. This thread started blooming into another issue, again... described earlier, just before I was offered to watch "How to improve my aim 10 x' Looks like it's time to lay off for a while and clean out my install.

No, that's not it.

I don't know... I have the SatNav checked in the game settings now and the INS switch is always on IFA when starting hot or in the air. Now, things got even stranger on my last hop. No more discrepancy between HUD/JHMCS and the FLIR when the target is designated... at least not my last mission. I flew over the same map as before (Syria), in different area though. However I noticed something else: When I had my sensor priority on HUD or HMD, then designated the waypoint as target (WPTDSG) on HSI, The target diamond popped up in the air in the random spot. Repeated the process and the designation jumped to another random spot in the air. The WPT elevation was set correctly. I switched priority to FLIR and redesignated. The target diamond was in correct position. So... I put SOI back to HUD and redesignated the same waypoint again. This time no error. Switching to a different waypoint and running through this drill recreated the bug. I think the code is alive and all these bots that I decimated are hitting back at me, lol.

Yep, I had to drink a lot of soy milk to mellow out after this 'drop' event. I was ready to make some comments that would definitely get me kicked out from here . At least the internal testers must have had some cues to what was going on. QA?... Oh, that's right. We are the QA.

I'd better start looking at my logs and see what the heck is going on occasions. I only use ST DCS.exe, single play, loaded with 64g DDR5 (fixed page file set to 9216, never even bothered above that). I haven't had any crashes in years, even before my recent rig upgrades, until this MT thing showed up. I gave up on it for now. Memory was probably not the only thing leaking there, hehe. Currently ST is holding up OK for me, even in fairly long missions but... once in a while my Reverb G2 goes 'grey'. Nothing will fix it until the OS reboot. The game is still running on the pancake screen and the head tracking still works. There is some other strange behavior after quitting the game or rebooting my rig but I have to investigate more, could be just VR related.

I think the search start point in R/BL is measured from launch point. In BOL from the turn point if used. I flew the similar mission to the one OP posted with the turn point on the grid he provided. The target ship was another 20 nm from the turn point (90 deg turn) I launched Harpoons over Khasab with the search set to 53. Worked fine.

Slight correction: It was 'RAID' button I was pressing not Uncage. Somehow I had my older controls config file loaded instead of the new one, my bad. The issue in question still stands...

Sure thing, within radar's gimbal limits not just outside of HUD. In my vid you can see the solid box when I peeked over my shoulder. I think it's just another bug but if someone has some feed back from the devs or SME's... anyone?

I ran another quick test, this time w/o AWACS and Link16/Tacan powered down. It does look like some sort of extrapolation and it lasts a few seconds. This also happens in other A/A radar modes. From what I understand, the track should be dropped past radar gimbal limits but what do I know . Extrapolation in a turning fight can actually be counterproductive. If you get transfixed on the TD box instead of gluing your eyes to the bandit, especially when the bandit is blending with terrain, after few seconds the TD box WILL be way off then... good luck getting a tally again.

Nah... I don't think so. The jump around 1:40 was caused by me pressing 'cage/uncage' again. Actually, 'cage' button has a different function when the radar is in GACQ mode. Something to do with the funnel or sim mode... I think.

I stumbled on this by accident when testing the gun director mode. The first few seconds of the vid show the final part of that test.

It seemed strange to me. When I pressed cage/uncage button, the locked target snapped to the center of DDI and it stayed there during my turn with the bar scan moving toward and past the gimbals. The lock was never broken and I was able to make a 360 turn, coming back on target... COOL, lol. The JHCMS showed the arrow throughout the turn. I'll do some more testing later just to make sure it wasn't a one time glitch. The track was incorrect but I made a vid, might post it later. Anyone seen this? ST DCS.exe Edit: It was RAID/FLIR FOV button not Uncage (my old controls config file was active not the most recent :()

Well, I've just wrapped up a quick test and I have to say that the gun reticle is usable now. When I was outside of the gun range or the locked bandit flew past the radar's gimbals, I might have a question or 2 for SME's or other folks 'in the know' related to reticle position, etc. With the target in sight and approaching the gun's range, the reticle behavior did not cause any issues. It looked good from that point till the kill. I didn't notice any excessive jumping around. It seemed like it followed the same path the funnel would draw, + range. This test was done in ST DCS.exe and I have no Idea how the gun director behaves in MT currently. Now, I did notice something strange though related to pressing cage/uncage button with the target locked in HACQ mode and possibly other ACM modes. (excluding WACQ). I have to make a separate thread in Hornet's general forum. Perhaps someone might have an explanation for me.

Well, no changes there, more scissors. Cool. Someone needs to bring out some gung-ho, air combat trained GPT bots and let'm loose.

It's weird the way it works here. You can power up the Mav by boxing it on SMS and it slaves to the pod with no problem but if you want to cage/uncage again using HOTAS... no, you have to have master arm on...

You mean 1 bottle? lol 8 would probably be enough, if you gobbled up lots of water gradually throughout the the night but who does that. Coffee dehydrates as hell too. Now back to the sim... I only fly Hornet and never have issues with high G, before I know it the energy is gone and I'm just wallowing, spiraling down and... still kill the bots.