maxTRX

Can I piggyback my loosely related question to all this? Is there a safety delay (1 sec ?) when pressing the pickle button in CCIP? In AUTO we obviously have to hold it pressed in, usually more then a second before the release cue creeps down, that's cool... and safe. In CCIP, the release seems to be immediate. When the cue comes up, the pickle button has to be pressed quick and timed perfectly. Well... there are other things we currently also have to deal with but those have been discussed numerous times.

It sounds to me like we are all on different builds here. I'm on the latest OB and the way this 'silly' missile works on my rig is: 1. In a low contrast desert environment - If the Mav is slaved to GMT radar, it follows the radar track from quite a distance and when close enough for its seeker to snatch the mover, it locks and stays on it till 'rifle'. Unless... there is a lamp post or a fence near the target at the time of acquisition. The Mav's seeker definitely prefers those, hehe. If the Mav is slaved to FLIR, it's still doable, just have to do bunch of cage/uncage flipping and lots of times switching TDC to FLIR then back to MAV then cage/uncage. 2. In an urban environment or around forests, roads with center dividers, lamp posts or fences... good luck. So, for me the biggest issue is the Mav seeker and criteria for acquisition of static v. movers. I doubt it is true contrast. Also, I'd be happy to see the Mav following the FLIR the same way it follows GMT when in slave mode.

Agreed indeed. Here's a short example of 'ace' level jeff... surprised the heck out me. I was actually trying to make a vid (and a track) showing the bug with TD box getting stuck on occasion, after hard maneuvering:

So far, I was unable to record a track that even remotely shows the correct sequence of events. After the merge, max performing my Hornet and AI over performing their 'tic-tocs' will always throw the track off. That's with only 2 a/c in the mission. I'll try later on again. In the past, I managed to record correctly... sporadically.

I don't have the track yet but I'm sure some folks must have seen this glitch. It happens quite frequently, regardless whether HMD or HUD only is used. On HMD, it looked like the TD box was following DL circle. In this setup, there was only 1 bandit (no other a/c) within 120nm.

It might be a good time to remind everyone of another A/G gun related bug: Gun's CCIP solution at higher elevations is off after using (or powering up) a GPS weapon. It seems like it's calculated for sea level. Hopefully it's not too far on the list of bug fixing priorities. BTW, if you also happen to have a dumb bomb in your loadout, all you have to do to fix the issue is... select the dumb bomb after JDAM, then go to guns and the CCIP points correctly at any altitude. Well, that's not a 'good' workaround tho' :/

Yep, I see the bug now. It can be reproduced on any waypoint already in your NAV database. Select waypoint (doesn't matter if WPT and/or 'SEQ' are 'boxed') Go to HSI-DATA and change waypoint's ELEV from meters to feet. Back to HSI page. Press WPDSG. Everything looks good there. Confirm your target desig. on FLIR. Now, go to DATA again. The designated waypoint numerical value is in meters now but... FT is displayed next to it now. FLIR still shows correct target. If you undesignate and designate again, that's when the trouble starts... Every re-designation, converts the elevation again, so... for now might as well stay in meters.

No. I've just tested a similar setup. All LDDI buttons worked fine, including HARM. As far as WPT ELEV change, there was no error. Well, I didn't do it exactly as you did in your mission. My WPT was set at the target elevation at the start of my mission. I designated it (WPDSG) then undesignated and unboxed the waypoint sequence in order to test the WPT elevation change. Once the change was done, I re-designated the WPT and the new elevation showed correctly on both, WPT DATA page (in feet) and the JSOW mission page (in meters). All done in SP custom mission.

Amraams within NEZ. Just a shooting gallery type of test. Could have been 100% kill ratio if I didn't fire 2 missiles at one target and another one at a target .4nm in front of me (high crossing angle) and... that Amraam came off the cheek station

I was wondering if 'expanding box' or any other way to define the acquisition area would help in this situation: On uncluttered roads, it doesn't really matter. PTRK locks on vehicles w/o any problems:

The lack of 'expanding box' is still a big problem but... the heat imaging in the latest OB is a big step forward. There might be some issues with textures on some vehicles (according to bug reports)... just look at the difference on A/A objects:

sounds scary

Practicing different methods... using our Hornet's crappy FLIR

Short clip from night time photo op.

I don't pay too much attention to DCS LSOs, as far as grading goes, ambiance perhaps. I try to stick to established ways as much as possible and usually I can spot my mistakes and correct or... chew my own butt

Well, there are number of issues with this version of Hornet's A/G radar but there is definitely one fix that could mitigate most of them and make the expanded modes useful. Zoom/resolution of EXP3 and possibly EXP2 (a little). With zoom level doubled in EXP3, I wouldn't care about rotation (as long as it rotates around the designated point) or other error inducing quirks. (when banking, etc.) Designating and refining would be fairly easy. ...just a thought.

You'll notice the difference. I keep the wake turb. off for now. Updraft over the ramp is not too bad but... it took me a few tries before I learned to deal with it. Another thing... I don't know if it's my imagination or what, but after the last 2 updates the power response seems a bit sluggish for some reason. Drag?

Frederf might have some evidence and knowledge related to ground radar, I don't... just basic anecdotal stuff. That's why this is all hazy in my head. I always thought that once the expanded mode was 'locked' around the designation point and was scanning and re-scanning, refining the image as the jet was getting closer. The quality of course depending on distance and offset angle. As far as slewing is concerned yea, I wouldn't try to refine the designation from too far, whatever that distance may be. I also thought that the 'freeze' function was simply a snapshot of the area, rotating to show proper orientation with respect to ownship. Any violent maneuvering shouldn't 'throw it off' as it does currently. And of course, radar is not working 'solo' during this entire process. Perhaps someone can shed some more light on this sooner or later...

What's the optimal distance/angle to minimize errors for our version of APG73? It seems like the cross is always off. I know the target elevation should not be an issue with radar ranging but it almost seemed like my JDAMs were pointing at the proper coordinates shifted down to sea level (?) As far as radar resolution goes, I could only distinguish target shapes (TU160) from around 4nm, that's only at proper offset and bank angle toward the target (?). Also, 'FRZ' function is still effected by radar updates in the background. I hope this is not the final version of this ground radar. In this clip the first target is co-located with WPDSG designation, still the cross on EXP3 page is a little off. The second target was designated using slew function on EXP3. The first hit was dead on, the second short, target partially damaged.

Boring and mundane but still... it won't go well without regular practice.

OK... 3rd time is a charm. I guess what I really wanted to know is whether having a specific program boxed meant automatic download of 'that' set of programs for all stations unless manually changed. Say I have 8 JDAMs again, all stations have TOO1 and TOO2 set. I have TOO2 currently selected. I release QTY of 4. Now, wouldn't this be easier and faster to simply select TOO1 and with the QTY already set... it's just a matter of another pickle instead of stepping through all stations and re-selecting TOO1 on each. If, all of a sudden there was a need to change to the other TOO, I could always do it then by selecting it manually. Anyways, I raised this question since I always try to find a way to do things quick (cutting out few secs. can make a difference). If it was up to me , I'd make this process flow as simple as possible with the flexibility to change programs, if 'really' needed. But... if there is a reason for current mech other then slowing me down, I can live with it. I should be able to get some feedback sometime next week unless someone here beats me to it.

I knew I should have placed captions for every button push I was making... I understood what was going on when I was testing and setting up for QTY releases. My question was about the TOO logic in real jet... I guess I'm gonna have to pry other sources for info. Anyways, I was curious why stepping through all stations with TOO1 program boxed, downloaded immediately but when switched to TOO2 and stepped through stations again didn't follow the same logic. Each station had to be 'confirmed' by boxing TOO2 after each step, that's all.

Regardless whether dropping 8 JDAMs in one pass happens a lot in RW... in DCS, especially in single player ground pounding, it's a nice feature to have. Question: With both, TOO1 and TOO2 programmed for all 8 bombs, when stepping through weapon stations in TOO2 for instance, the target coordinates show all 4 weapon stations on TOO2 (remains boxed through stepping process)... cool. Now, I decided to launch my TOO1 bombs first, so I box TOO1 and step through all stations but TOO1 is not being downloaded automatically. Each time I have to box TOO1 after every station step. Well... it's workable but does it really work like this in real jet? I understand this makes it possible to mix programs in QTY releases but if I have 8 targets that 'just' popped up and I scooped them up with my FLIR pod, I seriously doubt I'd have time to be mixing and matching TOOs for my QTY releases . Here's a short vid showing my fumbling with stations and TOOs but it did work. Does anyone have idea how this worked in RW... circa early 2000s or so?

Oh FFS (no, ff doesn't stand for force feedback... ) It's either your stick setup or what WOPR said: before touching the trim switch, make sure to disengage any autopilot sub mode you might've engaged before the break. Smack the paddle switch just to make sure. Well... first, make sure your paddle switch assignment is correct. When rolling out after the break, you should be slow enough to avoid any horrendous ballooning, just counter with the stick. The FCS model is still being worked on (I hope) and NO... it's not similar to Cessna. With the way things work currently, I prefer to gradually start adding power and trim simultaneously as soon as I see the velocity vector beginning to creep down. You should be in a descent anyway, from 800 to 600 ft. (Of course, talking carrier ops here) Takes a little practice to do it smooth. Other then that... check, double check, triple check your stick setup.

I see this once in a while in the latest OB. On top of that, AZEL might show AWACS feed in the mission but not in the track replay (?)