maxTRX

Everyone should try it. Works nice... for now ;)

No, I don't. I'm just running my mouth and repeating bits and pieces from other posts... here and there.

A little vid for those who get cross eyed when looking at graphs and formulas. Call me nuts but I think this stuff makes sense...

Pushing the envelope of ED's version of HARMs

There is bunch of stuff missing in ED's HARM implementation, from what I understand. One of the features I'd find very useful when... or if we ever get it would be ability to see the designations from other sensors or NAV on HARM's TOO page (dashed box). No need for the threat radar to be on. This also provides range. PB mode sort of fills the gap but... Also, ED needs to fix the SP mode priority threat auto select (CLC). Currently, once the priority threat activates SP or PLBK and there are multiple emitters active, hostile or friendly, you can bet your primary threat will not be 'boxed'. Instead, some friendly radar behind you will be selected by CLC... So, what we have to do now is press 'RSET' to make CLC select the correct emitter. Seconds lost, might make a difference. Another thing, when PBLK activates and is not overridden, we should also get EW page pulled up on opposite DDI. (from what I gather). etc, etc.

After reading the entire thread I'm obsessed now to see what happens after the missile motor shuts down, the batteries are dead and control surfaces are stuck... For non-engineer types like me, the videos with whatever telemetry displayed in a replay with abilities to change viewpoints works best. Runs to test dead missiles... (yes I know, some basic flaws with the entire aerodynamic model might show up and I won't be able to tell anyway, lol)

Definitely something I need to work on...

A little motivator vid. This guy just started posting bunch of vids showing routine carrier ops, flying Growlers... well, it's all in the 'bugs' family. I timestamped the vid, starting at commencing from 'port overhead', formation switch to right echelon then accelerating before initial, break, landing config (no ballooning ;) ) and... waveoff for fouled deck. https://youtu.be/eU_e-bbGaVU?t=457

Without roll/yaw auto trim, which is the case here, we basically need the tables for launch only to keep the wings level (more or less) at flyoff airspeed. As we accelerate, corrections are needed until settled at cruise a/s. Any a/s change would require trim change. Same in PA mode. Trim until wings stop rolling at 'on speed'... for the most part. Then again, approaching and coming down the groove, it's constant wiggling left or right... I probably wouldn't even notice a minor pull one way or the other

Only 2?!... It should be 4. Plus, another set of 2 following ghost VV and... I would gladly trade all of this 'info' for a simple shlem circle with couple of numbers tagging along when I move my head.

I'd love to see someone from ED publish their model of APG73. Parameters and limits, mech and some sort of a operating procedures for most common tactical situations, regardless of how they changed or estimated them. We could at least see whether something is fudged up after each update or they are following their model, no matter how silly it may seem to be. Then, the folks with the 'docs' can duke it out with the team. If the radar model remains along the current lines... Is there any way to 'remove' the radar (leave the gun w/ funnel alone!) by adjusting the weight and CG so I can show off in front of my AI crowd?

The spin could have been faster if I entered differently... The second test was Aim9X. It passed

Well... she's been messing around too, especially with her radar First, I haven't done a cold start in a long time so perhaps there's something along the whole process that causes the jet to behave differently... but I doubt it. Currently, when coming in for landing or a trap I don't even notice the ballooning. 350kts or so, gear and flaps coming down when still in the break. By the time I roll out on downwind, the airspeed is around 190ish, so depending on weight there might be a tiny bump. Yea, on a straight in, you still have to counter with the stick forward a lot more, unless the flaps come down below 200kts. btw, I noticed something different with the pitch trim behavior after the last OB update (perhaps even before): Now, when I start trimming up as soon as my flap switch is down, still in the middle of the break, by the the time I roll out and stabilize the power to 'on speed', the VV is roughly in the middle of an AOA bracket, depending of course on how long the trim switch was pressed. Before, it was a struggle and I pretty much had to wait till I was close to approach speed before the trimming function was effective. Weather this was something on my end or in the code... I'm happy now (well, just with that part, hehe)

Even more strange... Say you have JDAM powered up, select Mk82 and box gun. Go back to JDAM and the gun can fire happily w/o any reticle or even a gun cross. Also, if I () designed this inventory/weapon selection/power up scheme, I'd let the JDAM remain boxed when selecting a dumb bomb. With both of them boxed and the dumb bomb options displayed on DDI, boxing a gun would put gun's CCIP/MAN reticle on HUD. Deselecting a gun would bring back the dumb bomb options on DDI and HUD. The '8*LD' would be boxed again with gun deselected (JDAM remains boxed throughout this entire process). Now, if we decide to go back to JDAM... unbox '8*LD' and it's all good. Oh well.

I don't know how this works in DCS, I don't use g ovrd. at all. Pulling the stick violently with the paddle depressed while on A/P would certainly disconnect A/P first before engaging g ovrd. so, yea... probably no real issues there.

Well... alignment is one thing, then there's ED's version of blanking options and symbology overlap and 'jumping' (from HACQ to HUD bore, for instance). Could very disorienting in the heat of battle. Too much crap and 'duplicate' symbology. A/G is not that bad. In A/A, sometimes it's better to disable blanking, turn the HUD brightness down making sure you can still see the pitch ladder, missile countdowns, etc. It's a lot smoother and more intuitive... at least for me it is. BTW, I use VR and I'm curious if TIR has the same implementation as VR. I would think so.

I'm not a Hornet guru and haven't tested this myself but if indeed the paddle switch performs 2 functions simultaneously and allows g override with any mode of A/P on... that would surprise me. Though, I don't ever remember disconnecting A/P while pulling on a stick more then 1/2 inch but... yanking hard on a stick while A/P is on would disconnect without using the paddle. :D.

I've just had a brief look at it, using ext view slewing... Couple of things: 'Mini' is too glossy... put some sandpaper on him. These 'Supercarrier' manuals sitting in a book rack are too thick. Are they for future versions of SC? ;). Also, how do they open that little fridge, below microwave? Unless, these are something else...

A little update: Looks like TD box getting stuck is not related to 'age' setting. Even with setting of 32 the lock breaks a second or 2 past the gimbals and HACQ acquisition works fine. Back to square 1. Out of 5 gunfights, I saw TD box stuck only once. It would not get unstuck until the castle switch was pushed up (HACQ reset) or pinky button was pressed. Still no track... Jeez, with so many people that love gunfighting, there should be crapload of bug reports. Track or no track. Perhaps one of the devs or internal testers could do some turning and burning once in a while.

I don't think so. When I have time I'll try to make a few more structured tests with different settings and hopefully record a freaken track that resembles the actual flight. Also, I'd like to put Aim9x to some challenging scenarios since so far I couldn't find a single reason to complain about it... in SP.

OK, I'm guessing but the track age is probably related to this. When I set the age to 2 secs, the track is maintained roughly 2 secs after the radar hits the gimbals. The SME's would have to chime in to confirm but I think the Hornet's radar should drop the track as soon as it goes past the gimbals, regardless of 'age' setting. As you can see in this very short clip: Right at the start, after the bandit passes me head on, the track is maintained briefly (looks like TD drifts off) then the lock breaks and the HACQ re-acquires when I point the aiming circle on the bandit again. On a different note: I got a kick watching the sparks from the gun...

I use 9x unslaved... a lot more flexible and I haven't noticed any issues with it. It you slave it to radar then yea... same problems. BTW, I tried 1v1 guns today after the latest OB update and almost immediately after the merge I saw the TD box go nuts then I tried something that shouldn't really make any difference. I changed the track age to 2 secs and so far I haven't seen the TD box drift YET I only flew one hop so I'm not jumping to any conclusions yet. I'll do some more testing later on, see what else comes up.

Not only in MP. I see it all the time in SP, couple of other folks have also seen it. I reported this bug in bugs forum but I only included a video, no track. In the mission used in that vid there were only 2 jets, me and the bandit. I had AWACS support. My track age was set to 4sec. (shouldn't really matter). The easiest way to reproduce this bug was by making a high alpha rudder turn or pirouette type of maneuvers. The TD box would drift somewhere and it actually looked like it was following the DL circle movements on HMD and we all know how blindingly fast our Link16 update is, so... In another vid I posted in the main DCS forum, there were only 2 jets w/ no AWACS. The TD box was still getting stuck after violent maneuvering. Hitting the radar gimbals would not drop the lock. I had to press Undesig. button and HACQ to re-acquire. Even if I managed to replay the track correctly on my rig (which I did once or twice), it would probably be a different story on someone else's rig. Anyone can reproduce this bug easily.

I gave it a shot and it was close enough for the government (whichever government that may be... :/) I dropped 8 Mk83's on a column of trucks and tanks from a loft delivery and had to break away around 3nm from TGT. At that point I had 20 secs to go, for 15:12Z TOT. I watched the targets on FLIR and at the time the bombs hit the AUTO midpoint, I had 2 secs to go. https://youtu.be/OgSoKmdLN68?t=116

Well, most of the time the 'thing' drops where the other 'thing' is, Anyways, a delay of .5 or 1 sec would be easy to implement if this was really a 'thing' in the real jet. The reticle/cross would already be calculated with release delay. So... it's still a pickle AND HOLD (you might be dropping more then one bomb) when 'thing is over a thing' but the release program would do its own 'thing'. Same as calculating the impact point in the center of the bomb salvo.