Newbie62

I'm having trouble on push 3-1 in that Pine seems to always get confused and stop its advance at a bridge. The first try they all stopped before the bridge. Second try, the first unit in Pine crossed, but the three others stopped just before the bridge. They were undamaged, and all the enemy units had been destroyed.

Thank you guys! The terminology seems backwards so it didn't even occur to me to try going the other way. That made all the difference.

With slew rate at 1 and max zoom, trying to AGM-65D to lock onto a target, the mav usually slews right past it and doesn't lock. I'm finding that I have to go back forth back forth over the target many times to get a lock, during which I'll be burning down the DLZ. I usually have to resort to force lock, but to do that I have to get the crosshairs right over the target, obviously. What I'm finding is that in narrow FOV at a range of about 10 miles, even with the slew rate at 1.0, a quick flick of the slew hat will take the seeker clear across the target. I'd like to try a slew rate of 0.3. So UFC 0, LTR (to access the .), decimal, 3 that does get the value entered in the UFC, but then when I hit "slew" on the mav page, it says CICU input error. Seems like 1.0 is the minimum slew rate. Is that true, or am I missing something?

Thanks. I won't bother with SLI then. I had my doubts anyway, which is why i asked, and you confirmed my suspicions. I will keep my eye on the RX6800. Let it age more for further price drop. $440 is MUCH better than $1400 for a 4080, but still a bit more than i would be willing to spend. I shall live with medium textures and the other reductions i had to make, for now...

I have a GTX 1080 so 8 GB VRAM. i was hitting some game stalls (from 60 FPS to 1 FPM LOL). I run at 4k and had the video settings maxed out, and task manager showed VRAM usage maxed out when it happened. So I dialed back the video settings until the stalls went away, but i would like to upgrade to 16 GB VRAM. Problem: that is horrifically expensive. If i got another 1080 and SLI them, could DCS use all 16 GB or do you really only benefit from the extra cores in that configuration?

Haha, and what might those be? I'm not seeing them... You listed a few, but I've found them to be all but useless. When you're view chasing the opponent, you lose track of it really fast. I don't know about track IR. Don't have it, but if I'm looking back over my shoulder, all I'm going to see is the corner of my office. Maybe the way it works is a 30 degree turn of the head corresponds to 150 degrees in virtual view as displayed on the monitor or something like that, but I have no idea...

Okay, so include wingman unless there is an enemy within some number of miles. 3 miles, perhaps. If you are in a close engagement, you're probably not gonna want to be looking at your wingman. Alternatively, a new command (Alt+F5?) nearest enemy AC view. The latter would require more engineering effort, obviously. I was suggesting the path of least resistance in the hope of seeing this implemented.

When you have a wingman, F5 nearest AC view will inevitably snap to your wingman, because well, he's nearest - obviously. That isn't particularly useful though. Wish list: exclude wingman from F5. Why? In a dogfight, when looking through blank canopy you don't have much in the way of visual references. Basically you don't get the spatial awareness that a real pilot in a real dogfight would have from turning his head and knowing where he's looking relative to his own body and by extension, his aircraft. A reasonable proxy to get that spatial awareness is F5 nearest AC view. Or at least it would be, except for the wingman thing. That's also what Num. "Lock view (cycle padlock)" is for, but padlock is a cockpit view, so again once you're looking up through blank glass in a turning fight, you have very little in the way of visual references or spatial awareness. If you are padlocked and switch to F2 aircraft view, you lose the padlock. Also, taking a quick look at the HUD is very cumbersome with padlock, whereas with F5 and F1, it is very natural.

Haha naturally...that's what I'm trying to do, but there's no point practicing a procedure that doesn't work. I notice in your video that before the cut transition at 0:30, you were in area track mode, and it kept popping out to INR-A. That's what I was seeing with POINT / INR-P, which seems to cause the laser to shut down. After the cut transition at 0:30, you were in INR mode, and the laser stayed on. So I tried that, but that turned out not to be the key - the mode would stay put, but if I went wings level once I was off angle, the laser would still shut off (L stops flashing). Masking by the outermost weapon pylon, which doesn't get rendered in the TGP display, maybe, leaving one wondering why the heck is it acting like it's getting masked? So taking a cue from your video, I held a little bank to keep showing the target a little belly, and behold! It worked! Then I tried it in POINT mode, and holding a little bank, that worked too! So that seems to be the key to holding lock for a laser maverick until impact, while maintaining separation from a SAM.

Ahhh! I recently upgraded from A-10C to A-10C_2. Space stabilize was TMS left long in the earlier model. I have been updating my cheat sheets as I find differences. Noted. No wonder it didn't seem to do anything. I read in another forum post that ground stabilize is all but useless, since it relies on image consistency rather than spatial position. What I've seen is that at distance, the target is just a speck in the maverick TV/IR view, even with narrow FOV. So as you said, insufficient contrast. It seems like until you can begin to resolve the shape of the target (meaning, getting close), it can't lock the target.

Yes, exactly... I have it in point track and laser is on, but as I try to come off angle, even when the target is clearly visible and totally unmasked, it degrades to INR-P and the laser shuts off. It doesn't make sense, but I guess it is what it is... Also yes, exactly. So I'm wondering if there's an off-angle limit, even if that limit is well within the TGP's angular range. That certainly seems to be the case, but I couldn't find it documented anywhere. It does fine with down angles, but not in azimuth. By empirical observation, it seems to be about 25, maybe 30 degrees. Not enough to achieve what I was trying to do - hold laser lock through the maverick's TOF while maintaining some separation. I wish... Even in narrow field of view, the crosshair seems to just run over the target without locking until I'm approaching the DLZ minimum range. Even then, I have to keep moving the seeker over the target, or just past the target and let it run over the target repeatedly until it sometimes manages to lock. I've tried space stabilization (TMS left long), force lock (TMS fwd short), and force correlate (boat switch center; yes, I know that's not what it's for, I was grasping at straws) in various combinations, but when that does manage to get a lock, it seems to force a lock that isn't necessarily on the target. Just as close as I can get it given the seeker head's limited resolution even in narrow FOV, which usually seems to be a case of "close, but no cigar". Only when the maverick seeker gets its own lock does it result in a reliable kill. So I'm wondering what is the best way to go about it at range. I've read explanations and watched tutorials on youtube, but it just doesn't seem to want to work. Very frustrating...

I have been trying to take out an SA-8 in the very first A-10C campaign mission using mavericks. The SA-8 doesn't always appear; seems that some enemy units are predefined, but air defense is randomized. When the SA-8 is there, I want to take it out even though the mission is just fly the waypoints! Learning exercise, if nothing else. Using the IR and TV mavs has been a dead end. They can't lock the SAM until you get way too close and are already being shot at. So I am trying to use an AGM-65L for this. I can get a good look at the SAM site using TGP from outside its range. But then it's go time... So what is happening... The TOF for the mav is surprisingly long, so I can't just keep heading towards the SAM to keep the laser on target. So after firing the missile, I'm trying to change course say 45 degrees off, enough to maintain separation but keep the SAM site in view of the TGP so it can keep laser designating. What I'm seeing is that even maintaining clear line of sight, the TGP degrades from POINT to INR-P. It seems like when that happens, the laser shuts off, and the maverick flies into the ground. For lack of a better way to express the question...what's up with that?

Thanks. So do you recommend what I speculated, "would one be better off creating a markpoint rather than SPI, nearly always, because a markpoint can be readily set as SPI?" Whereas a SPI apparently cannot be converted to a markpoint if one has a SPI but decides to put a pin in that and get back to it later? As for the peripheral note (blank ground where a unit is), I shall attempt to document the issue adequately to raise a separate topic... It's kinda hard to prove, because the obvious counterpoint is "well duh, your TGP must not be on target". I need to try to catch the threshold, not just when the target is visible on the TGP, but the moment before when it is not. See if I can catch it in the act of appearing out of nowhere (in which case it should have been visible prior). I expect that to be difficult though, because it's a chicken-or-egg situation. Have to be looking right at something I can't see, ahead of time...

Is there a way to create a markpoint from a SPI? If I set a SPI and am working on refining it in preparation to attack, but a greater threat appears and I break off, it would be nice to be able to save the current SPI to come back to it after the greater threat has been neutralized. Seems like the way to do that is a markpoint. But I've combed the manual and don't see a way. Is there a way to do it? Or would one be better off creating a mark point rather than SPI, nearly always, because a markpoint can be readily set as SPI? On a peripherally related note, I have found that MAV seekers are pretty horrible at locking onto targets. I'm finding that refining SPI with TGP then slaving MAV to the SPI is the way to go, but even that is hit-or-miss. I'm new to this game, so I don't know for sure, I've just observed that so far. But along the way, I've noticed that when I slew the TGP right to where I see the target visually (or more often "cheating" by slewing TGP just up and left of the label) and set a SPI, and come back around several times like "where the heck are you", in the TGP, no matter what the zoom level, the target just plain doesn't appear. I can zoom in, zoom out, crawl all over the place around that point and most of the time all I see is blank ground. Especially going after ZSU-23s. Every once in a while, there it is, plain as can be. It fills quite a bit of the TGP display at max zoom, I can even see the guys sitting in the gunner's chair, so it seems like at lesser zoom levels while searching, the gun should have been visible in profile or farther out, as a speck. It's almost like the terrain is being rendered over the ZSU, even though the ZSU is on top of the ground. While looking at forum topics on this, I saw a reference to "Barthek's mod" and the accompanying text made sounds like this (ground being rendered over a target sitting on top of the ground) may be a persistent known issue which has been addressed by the community because ED didn't. But it was from like 2016 and the link was dead. Does anyone have any insight into this?

Okay, I see it now, thanks! And I now see that the reticle tends to be off by a bit in the HUD relative to the seeker view in the MFCD, so I can also see the utility of it.

In the A-10C flight manual where it describes the various HOTAS hats and switches, under DMS short (all directions) with MAV as SOI, it says Reticle up/down/left/right. That sounds redundant with slew control. So I've been playing around trying to figure out what DMS short commands actually do with maverick as SOI. They don't seem to do anything. Is there actually some functionality there that I just can't figure out, or is this an error in the flight manual?

@Yurgon Follow-up: I found a JDAM tactical manual from a public source, but apparently public source doesn't satisfy the policy "When posting aircraft, sensor or weapon information more recent than 1980, you must also include the source of the document showing that it is 100% public and verified as not from a classified or non-ITAR controlled source." and I got a strike. So I will follow up but tread more carefully this time. ED must be simulating INS alignment quality. My lazy turn as I built separation from the target wasn't enough to achieve alignment. The 20 second more aggressive turn for line up in the track I posted was enough to get alignment and the bombs went green just as I straightened out, but it wasn't a quality alignment, which consequently only lasted 45 seconds before the JDAMs went white again in DSMS. Referring to the observed behavior in DCS, longer lasting non-lazy turns result in a better quality and more lasting alignment. Bottom line: I stand corrected, and when you said "It's often times quite surprising how operating procedures are used to work around shortcomings of technology" you hit the nail on the head. Realism .

I went to look at that F-15C "one more try" track just now, and this time I could switch to map and external view. But the plane flew into the ground during lineup for approach, which isn't what happened. So I guess the track was corrupted. Between the arbitrary and persistent blockage of external views that I saw yesterday, and this today with replay not matching what I actually flew and saved yesterday, I suspect a memory corruption bug, that can just whack random bits of state and lead to indeterminate behavior. As a software engineer, I've been there. That's why I am a huge fan of valgrind. I've worked that into continuous integration / regression testing for every project on which I was ever the lead engineer, and even when I wasn't, whenever I could "sell" the concept and get sign-off from the lead to do so... https://valgrind.org/

"Sounds like allow external views got set to “no” in Options somehow." Maybe, but I started seeing that on all my tracks yesterday. On the "one more try" at F-15C ISL that I did with reduced wind, and other training missions I ran yesterday in which I ...ahh... didn't do so well and wanted to see just how bad I did. Now today it has corrected itself, and I didn't do anything to change it one way or the other. Weird...

"Just to be clear, when you make sure that your GBU-38 show green weapon stations in DSMS, do they now release correctly for you? Or do they still fail to release?" I didn't do a statistically significant check, but in one rerun just now in which I replayed the track until run-in, took control just as I was coming into max range, and yes successful release before the bombs went to ALN RDY. So you definitely hit the nail on the head as to what the issue is. Question is, should it even be an issue? "I'm sure even B-52 can fly turns of 60 degrees heading change without breaking their wings off... " Of course. Can. But do they do that at a matter of course just prior to target ingress, just to keep the JDAMs from fucking up? I doubt it. Were that the case, JDAM would have been sent back to the drawing board... "What I can tell you is that it has been like this for a very long time, and most virtual pilots have adopted and made it their personal standard operating procedure to plan a heading change of at least 40 or 50 degrees prior to engaging targets with JDAMs" Well my heading change was 270 degrees. Still didn't help, because I straightened out a bit early to line up my run, and in that brief time the bombs went to NOPE mode. Hard turns and short run-ins sounds like a workaround for something that should have been fixed in the game a long time ago...

Anecdotal, but... B-52s drop JDAMs IRL. I doubt they're pulling hard g's 30 seconds before they line up their drops just to get the bomb gyros to align.

At the risk of expanding the topic... I tested that theory by using the mission editor to create a copy of the F-15C cannon training mission with reduced wind (but not reduced to 0), so that crosswind effects will be present but the velocity vector and LSC won't get pushed beyond the edges of the HUD. Following the LSC brought me in pretty much over the runway. I still crashed because with zero visibility I couldn't tell when to flare after I crossed the runway threshold and lost ILS, and I came in on the right shoulder - to which I may have drifted once I lost ILS, or ILSN may have guided me there. Topic expansion: while reviewing the track (no need to share it), I tried to change views, F10 to see if ILSN took me off to the right (or was that all me once I lost ILS guidance) and F2 to actually see the plane and runway since from the cockpit it's almost zero visibility due to the weather. My operating assumption is that I fucked up, but I wanted to see what really happened. That didn't work. Which is weird because just the other day when @Ironhand and I were dissecting this, I was doing that all the time: changing the view during replay without taking control. Now all of a sudden, the view is locked to whatever is recorded in the track. There hasn't been a game update. So there is obviously some confounding variable as to whether the view can be changed in replay. @Flappie, any comment?

@Flappie since I was introduced to you in the F-15C ILS topic...

Seems like a bug. They were aligned fine going into the run, and I had just come out of a turn which from what I read in another thread triggers realignment (or as you mentioned stick hard forward). In this case, I see what you're talking about. Had I dropped a moment sooner that would have been the 20% case of what I observed: "It's not that JDAMs never work. I have seen them release before and hit the target, but it seems like 80% of the time, they don't release." These two images were five seconds apart. I read in that other thread that IRL that doesn't happen, they will stay aligned in straight and level flight almost indefinitely. So bombs losing alignment isn't something that ED should have even simulated... Or, at least do it realistically...

While running the PGM training for A-10C (original, not II), I encountered failure to release by JDAM. Actually, I've seen it many times, it seems like JDAMs work only rarely, but this time I decided to save a track and raise a forum topic. Timestamps refer to the clock, just right of the IFFCC switch. 7:23:07 to 7:23:14: side note: the TGP failed to box the target. I had to move the target cross around a few times before it finally boxed. That matters because I've noticed that laser guided bomb delivery seems to be degraded unless the TGP actually boxes the target. I'm not sure whether this is normal, on either point (having to move the crosshair a few times to get good TGP target lock, and degraded accuracy with loose lock). Anyway that isn't the subject of this post. Just a side note. 7:26:24: Hit the first target with a laser guided bomb. Dead on because I had done the previous trick of shifting the TGP crosshairs until it actually boxed the target. Also off topic, just a side note. 7:31:04 to 7:31:36 : I had the reticle right on ASL / PBIL most of the time. The range bar was between min and max. I pressed and held the weapon release button, and not when the ASL / PBIL strayed from the reticle. No release. 7:33:36: start of attempt #2, range bar starts to unwind 7:33:49 to 7:34:00: I have the reticle right on ASL / PBIL. I pressed and held the weapon release button. No release. 7:36:47 to 7:37:05: attempt #3, same result. I tried press and hold until release (which never comes), press and hold then release the button after a presumably adequate time, and quick press. None of them worked... It's not that JDAMs never work. I have seen them release before and hit the target, but it seems like 80% of the time, they don't release. A-10C-Training-PGM - failure to release.trk