oldcrusty
-
Posts
2420 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by oldcrusty
-
-
There is also another reason why using AUTO in the current version of OB gives us advantage over CCIP, TD box on the target. Some time ago, we had an option to use CCIP over ground designations... very useful feature. The guns in CCIP mode can still be used on designated targets. Some people claimed that this can't be done in RW Hornet... for whatever weird reason.
Having an option to switch to CCIP and still have a TD box visible was a tremendous help with SA. Why would I want to switch? Simple... AUTO mode was and still is causing short hits when diving. In CCIP I could press the pickle just right to compensate... As mentioned earlier, we do what we have to do to go around bugs. Now, at least in my tests, the level release is the winner (AUTO or CCIP) hence the title of this thread. Well, we're way beyond that, which is fine.
A few OB builds ago, lofting in AUTO was the most accurate for me (at around 500kts). I liked it since I was able to sneak in and throw the bombs up at the target and drop down again quickly.
ED makes these discrete changes without any notice and we have to play test pilots to find out.
-
4 hours ago, amalahama said:
I ond't understand your point? You followed the ASL, the bomb dropped at the exact moment, you scored the hit. Where is the issue?
I don't understand myself sometimes either... I just imagined some basic trig. What if the mission computer gave you a crab angle at some point after initial that would put you on a steady path (course) that would guide you toward the release point (already calculated roughly with ASL glued to it) for your a/s. Now, hell if I know how this worked in the ol' Hornet
.
One thing for sure, RW or game. In very rough weather, this type of weapon and attack direction would be iffy at best.
-
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.
-
4 hours ago, Mikaa said:
Woo, looks like they fixed the ASL bug. Can’t wait to hop back in and do some low level carpet bombing! Thanks for testing this out.
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.
-
30 minutes ago, BuzzU said:
I'm just coming back to DCS/Hornet. Explain to an old man.
If you're using CCRP why use dumb bombs? It's not like we have to pay for more expensive bombs in DCS. Why not use more capable bombs?
Although the comment that real pilots use CCRP for dumb bombs shocked me. I thought it was accepted that CCIP was the most accurate way to deliver dumb bombs? Why is that taught in DCS?
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,
-
8 hours ago, Mikaa said:
Interesting! Sounds like I may have to revisit that. Did you try it with retarded munitions or slicks? I remember the wandering ASL being significantly exacerbated with the longer TOF of snake-eyes/ballutes.
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.
-
3 hours ago, Mikaa said:
Something is also still bugged about the ASL with crosswinds. Been marked “investigating” for a looooong time now, with no updates. So if you use little/no wind scenarios, then AUTO is your best bet for accuracy.
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?
-
1 hour ago, MarkyMark said:
Oldcrusty- name checks out
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.
-
2 hours ago, MarkyMark said:
Did you try doing an HSI/UPDT/GPS accept ?
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.
-
5 hours ago, pete_auau said:
maybe this could be the issue just a thought tried it and it does improve the hits with bombs dont know about guns though
No, that's not it.
-
8 hours ago, Temetre said:
Cant really indentify the issue, but I noticed that marking points in the distance (>30 miles) with TGP had the point drift a lot in relation to the ground targeted? Mightve determined incorrect ground height. Thats in mission editor where GPS should be available.
Maybe connected, not sure yet.
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.
-
On 4/24/2023 at 10:49 AM, sea2sky said:
What concerns me is that so far there was zero feedback from ED on this issue. Why is it so hard to announce any plans on adding (or not) a support of OpenVR? I feel cheated (as many other OpenVR users) and find the whole situation with how it got dropped and sort of kept unnoticed from ED team being very disrespectful.
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.
-
On 4/28/2023 at 3:01 PM, Flappie said:
If that is indeed a memory leak issue, it will get fixed at some point, of course.
But even without any memory leak, DCS takes a lot of RAM. My PC has 32GB of RAM, still it's not enough when playing over Syria in MP, for instance. This is were the pagefile is useful, but paging has an impact on performance (RAM will always be faster), which is why I suggest to go for 64 GB.
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.
-
11 hours ago, Hippo said:
Is that right? I had understood that with R/BL the distances were both measured from the launch point or the turnpoint (if used). I reported a similar issue some days ago.
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.
-
1
-
-
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...
-
19 minutes ago, Temetre said:
I mean, as long as the symbol is indicating that its interpolating, then its not too bad necessarily? Gotta be aware what this means and what it doesnt^^
Looked at the manual, the only mention I found was specifically under the Aim 7 radar tracking:
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?
-
55 minutes ago, Temetre said:
Oh I see now, thats really strange! Gotta look into this myself.
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.
-
40 minutes ago, Temetre said:
I think that means the F-18 has locked the Datalink target, which is being tracked by other radars? The 18 can do some nifty tricks with networking, but im not too familiar with it yet.
Additinally, when the F-18 loses a target, it can extrapolate the expected target position and try to keep track and reacquire it that way.
Whatever it was, I think the jump at 1:40 was when your radar got the target back.
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.
-
1
-
-
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.
Is Auto delivery from level flight the most accurate method for dumb bombs now?
in DCS: F/A-18C
Posted
I don't know. I haven't flown the Hog in years, stubbornly sticking to Hornets. I might fire it up some day... gonna have to configure the controls again, from scratch.