AvroLanc

It depends on the Aircraft / community, but especially with the F-15E this was a common technique. The bombs on each side of the jet would be set up for different codes. Dropping one from each side with own ship lasing one code and wingman lasing the other code. Would allow near simultaneous impacts of two weapons on two separate targets, without the dust and impact smoke obscuring the laser (difficult to coordinate two drops from two aircraft and still get simultaneous impact).

The truth is, I doubt it’s much closer than it was 4 years ago…. Reference the nice static DTE page in the Viper. It does take time, but you wonder if an odd hoc method of special waypoint functions might have been added in the interim, similar to Heatblur or Razbam.

Thank you Raptor, good to know. You’re doing a great job as part of the ED team.

There's an entry in the 24/8 OB patch of: Fixed: TADS: Limit Indication Error This maybe refers to the LOS Cross flash in the Weapons Symbology when the TADS is at an azimuth or elevation limit. Problem is...it's still bugged. The LOS Cross reticle should flash when it's at a 'limit' and the LIMITS message should show in the 'Sight Status' field on the HAD. Before the patch the LOS Cross reticle did indeed flash in the HDU TADS, but not on the TEDAC TADS. This has now changed to NO flashing in either. I believe this is incorrect. There should be a flash of the reticle (and the missing message). Real TADS footage online will confirm this. Thanks. TADS LIMITS.trk

Ideally it should be done on the armament screen, along with choosing fuses etc. Similar to what you’ve done with the WW2 stuff….Which is very welcome. The ability to set bomb laser codes on a pylon per pylon basis is important. I’m thinking future F-15E application here in particular. The kneeboard thing is still a bit gamey, if you ask me.

If you’re on the latest 24th August patch, it’s working again now.

I’ll add here that the actual ‘type’ of CM are not even correct in most cases. The AE Enemy Armor CM seems to be the default for every enemy ground unit…infantry…..APC….trucks…. All get the same icon. And why does a generic T point get a 3km threat ring? Please ED, let this be user configureable, or just revert to old the behaviour. I don’t think anyone asked for this in its current form.

Hmmm… moved to wish list… I would have thought this was initially more of a discussion item than wish list. Especially considering how dead this Apache forum seems to be at the moment.

So it seems TSD Control Measures now auto populate all friendlies and enemy units. Wasn’t in the change log. This is a mixed bag, while it saves time in writing down and entering MGRS etc to enter yourself, the TSD can now be extremely cluttered, with lots of superfluous unit icons. Most of which will need deleting. Can this become an option or something? Or better yet, can we enter only desired CMs through the Mission Editor? This brute force method doesn’t suit all occasions. Thanks.

No.

Err…..those missing things are actually in the patch notes…. Plus, give it a while, patch has only just dropped.

No, he doesn’t actually store them ….yet. Hopefully one day he will, but it could get complicated for George if there are many targets in the same area, you wouldn’t store each and every one. ED will need to work around this. EDIT, beaten to it. The suggestion in the above post is rather good.

Yeah, the VIP/VRP functions are working much better than the OAPs. I was pleasantly surprised, but the precision problem remains. OAs have never worked correctly in the Viper, and at the moment they use completely the wrong logic. Slewing actually changes the preset offset range and bearing data rather than the TGT location, which is insane. ED doesn’t seem to want use the already existing ME functions for any of this. Offsets, Pre -planned threats, JDAM targets, HARM targets could all be set in the way that Heatblur and Razbam use. Instead we wait for a DTC function that is pretty much never going to happen anytime soon.

Offsets generally aren’t used for CAS in the way you mean, but in real life they would have proper planning software to very precisely plot the offset for radar offset bombing. The offset range function should have a ‘feet’ option, but ED haven’t modelled it. Offsets are completely broken in the current OB anyway.

The exact same information is available in the Hornet code as you TUC a contact: Abbreviated Callsign, Aircraft Type and Speed. For hostiles, Aircraft type and Speed. Is there any reason why these can't be added to the F-16 as well? Without this 'Expanded Link 16 data' It makes the HSD display pretty useless, as you can never tell who anyone is..... It's a MASSIVE glaring omission to your Link 16 depiction. Hopefully this is more than just a wishlist item.

ED have just used LANTIRN pod symbology and control logic and overlaid it on top of their LITENING pod optics implementation. This is the reason why no PTR option currently exits. LANTIRN had no PTR mode. I imagine they couldn’t find a good allowable reference for LITENING symbology and logic.

Yes it is, and I was pointing out you’re totally correct. Maybe not totally necessary, but isn’t that that allowed?

There’s no way to do exactly what you want. The closest you get is kinda the opposite as Floyd1212 describes above….make GHS your acquisition source and select TADS as the sight. Now when slaved the TADS will follow your line of sight. Deslave when you’re looking at the desired spot. Otherwise you make do with the FOV box position in the Field of Regard box at the bottom of the TADS display. It shows the rough TADS LOS relative to the aircraft. You also can see the TADS LOS on the TSD MAP and terrain associate off that. Generally I’ve found you don’t really need what you describe, you should have enough awareness of what you’re looking at with all the other aids, what you see in the TADS and just by looking out the window. This is all by design, it works ok.

Thanks Guys, I’m aware of the background of Link 4 in DCS, and why Heatblur have a unique in-house solution. I’m still curious if anyone is having issues with the two different implementations conflicting with each other. When I had EDs system activated in the ME , the F-14 wasn’t doing an ACLS properly. When I took away those ‘link 4’ and ‘ACLS’ special waypoint properties from the SC, the F-14 worked ok. Does this mean you can’t have both F-14s and F-18s in the same mission and expect ACLS to work for both? Anyone else noticed this? (There are some weird bugs with EDs system….any other carrier capable AI flight group that takes off or lands on the carrier will render the ACLS inop for the player……maybe this is playing its hand here too).

So I deleted the ED Link 4 and ACLS from the Carriers properties in the Mission Editor. It appears Tomcat ACLS is working OK after this. Is there a known conflict between ED's LINK 4 stuff and Heatblurs ACLS?

Only RAD ALT hold still works, BARO ALT HOLD is completely non-functional until the next patch....

So I notice there's a few historical bug reports of ACLS. To be honest, it's been an ON-again, OFF-again feature ever since release, but can anyone confirm the current working status for ACLS in the Tomcat? I've been trying all afternoon to get ACLS working with the supercarrier, the best I've got is the 'VOICE' and 'LANDING CK' light, but certainly no A/P couple. How bugged is it at the moment? I get no other ACLS status lights, and no A/P REF light at any time..... Do I need SC or Forrestal? It certainly used to work with SC. Does ED's Link 4 system being activated totally bork Heatblur's implementation? Should I deactivate it? Even the CASE 3 Instant Action mission doesn't work. Will HB ever migrate over to ED's Link 4 system. It seems odd that there can effectively be two different LINK 4 frequencies/system active in a mission. Thanks.

This is a bug in the latest build. The CZ label disappears when the the system delta is zero….in other words….when there’s no CURSOR SLEW to ZERO. It shouldn’t do that, CZ label should always be there. But…..for the moment when ‘CZ’ disappears you’re good.

The recently 'fixed' Offset aimpoint logic is still not working correctly I'm afraid. The OA logic was recently fixed to now always provide CCRP steering (and TD box SPI) to the target Steerpoint rather than the Offset location. Which is correct...thankyou... ....however any slews you make to the OA1 point now don't behave right. The expected behaviour is that any radar slews you make in OA1 will have a matching and corresponding slew movement to the Steerpoint (i.e TD box/target) location. This is the very essence of offset bombing and the very reason for the OA1/2 feature. What happens instead is that the selected Steerpoint remains fixed in location and the slew you make now defines NEW offset location data in the DEST page. This is obviously completely opposite of what should be happening - the OFFSET data should be fixed and the slew should move/define the new target location. In my test the offset is at the tip of the island, the target is SP1. From measuring in the ME, the offset is at a distance of 20142ft and 222M from the planned target. You can see that when I slew over the desired island tip, those OA figures are updated when they shouldn't be - but the Steerpoint refuses to move.... (I've purposely set the Steerpoint away from the true target in the ME, to simulate INS drift and the actual need for radar correction). (Also, I believe the OA data should be in degrees TRUE, but the system is working in MAGNETIC, but that doesn't affect the above behaviour is just an observation.) Thanks. F16 OA Bug.trk

There seems to be errors with the ALTITUDE HOLD functions with the latest OB patch. 1. The box around the RADAR ALTITUDE digital readout (IHADSS and FLT page) now doesn't appear with ALT HOLD engaged. 2. BARO HOLD doesn't work at all. No engagement, no EUFD advisory, no box around altitude readout. 3. RAD ALT HOLD is now rubbish, doesn't really work well.