norman99

Ah, we were..... It won't even initialise if CASE I recovery ops were still being conducted, so that's definitely not the cause. Everything else works fine up to 6nm, some of us are just unable to obtain an ACLS lock-on, (change to MODE 1) and remain in T/C.

@Atazar SPN You are able to active CPL P/R because you have achieved a successful ACLS Mode 1 Lock, indicated by mODE 1 on the DDI. My problem is I just don’t get an ACLS lock on at ~6nm. Stays in T/C and the tadpole never appears, hence when CPL is selected, it engages in HDG mode.

Atazar’s video might not be the best reference. He’s not exactly following the correct CASE III profile. Instead of maintaining 1,200ft till 3nm, he’s already at 800ft at 8nm and 600ft at 6nm, so he’s much lower than ideal? Whether this effects the ACLS capture or indications I’m not sure.

Can anyone explain to me the correct usage of the uplinked T/C command heading guidance. NATOPs describes using T/C heading guidance coupled to the autopilot to provide automatic flight to the marshal stack. Is this just a general guidance to get you somewhere in the right ballpark, or is it specific to your cleared marshal point, ie 23nm, and should direct you to this specific point? Each time I’ve tried to use it, I end up ~35nm, no matter what the marshal instructions were. Is this as correct? (The NATOPs ACLS diagram show a marshal at 35nm & 20,000ft, but this is just an example.) I guess I’d like to know how to use it with DCS’s current implementation, as well as how it’s used in the real world.

Seems overly excessive to me. With a CASEIII using ACLS Mode1, it almost always drops me on the ramp, before the 1 wire, causing a bolter. There's a few tweaks coming soon.

Track file below. ACLS remains in T/C and never switches to MODE 1. https://www.dropbox.com/s/083qu9he5kz9es1/ACLS.trk?dl=0 Original Supercarrier CASE III mission with Link4 and ACLS added in the ME. This mission includes 2 Hornets recovering prior to my aircraft.

Exactly the same problem for me. Added Link4 and ACLS actions to the default CASE III mission. When established at 1200', 6nm, on speed, engage ATC, I never get the tadpole, and the ACLS mode indications remain ACL RDY & T/C. It never indicates MODE 1.

Really pleased that ED has included this in the latest patch, it greatly helps scripters and mission builders. Thank you. Triggers. Added a trigger and scripting function to display a message to a selected unit. Triggers. Added a trigger and scripting function to sound to a selected unit. Now, to add to this new functionality, we just need a function "F10 menu to unit." This way the code can identify which unit within a group is making a request. Again, using MOOSE AirBoss as an example, currently only the group can request marshal etc, and whilst it's now possible to reply on an individual unit level, it's not yet possible to know which player payed the request for the marshal. Should I make a new whish list item, or will it get noticed here?

@BIGNEWY No mention of this in the latest patch notes. Has this been fixed? It's become unplayable in some servers, tossing aircraft overboard and/or breaking them to the point of requiring a respawn. (Affects all aircraft, not just the F-14) In our server, this is quite literally the biggest, show stopping bug we are currently facing.

Honestly, with what the Skynet IADS script can currently do (SAM radars remain off till they shoot, switch off when HARMs inbound, integration with EWR network, control nodes & power sources) we have most of what we need already. I add it to all my missions and it completely transforms them.

Seriously? Beamscanner has provided an incredibly detailed yet digestible explanation on radar theory, which clearly shows with modern pulse doppler radars, STT should actually provide better detection capably than broader scan patterns (provided you are pointing directly at the target to see it in the first place). With all due respect, how can the ED team be satisfied with this current implementation, when it is unrealistic and opposite to basic radar theory?

Exactly my thoughts, but it seems ED and determined to reduce radar effectiveness when jamming, even though they clearly state the mode modelled is changing to radar priority.

Recently I've struggled getting a RecoveryTanker to use AirBoss as the controlling authority when returning to the carrier. It always just seems to use the DCS SuperCarrier ATC instead. I've read elsewhere that if using the Dev branch of MOOSE, AirBoss no longer controls all AI groups, but only elements defined as a FlightGroup. Is this my problem? If it is, how do I use the RecoveryTanker Class, and define it as FlightGroup so it's controllable via AirBoss?

Hi, recently I've experienced multiple crashes when operating around the supercarrier on a multiplayer server. Happens on different servers, usually after an extended period of time, such as returning after a ~1 hour long mission, or after 10+ CV patterns. Always in the vicinity of the carrier. All servers running MOOSE Airboss. Log and file attached. The track file is useless, as it replays a completely different sequence to what actually happened. dcs.log

Wings level crab works best for me. Remember, when in the grove, it’s all visual flying. Whilst the HUD is useful, don’t let it distract you from doing whatever you have to do to stay on centreline. In that regard, it’s like flying any other aircraft with a crosswind, look out the window and stay on centreline. Also, try not to carry a deviation all the way to the ramp in an attempt to be ‘smooth’. A training pilot once told me, “F*** being smooth, just be accurate”. What he meant was, as soon as you see a deviation, make an early and deliberate correction, rather than allowing the deviation to grow whilst you slowly and smoothly attempt to fix it.

Personally, I just want to be able to return back to base, with a couple AI wingmen, and land in an orderly and realistic fashion. Not the unpredictable mess we get now (that’s if the wingmen get home in the first place…)

I’ll admit, this has me a little confused. In the Mini update, it states the following: Changed the Electronic Countermeasures, ECM, such that when in XMIT it will use radar in priority rather than jammer in priority. This will allow the radar to operate with ECM transmitting, but at a lower radar detection capability. Maybe it’s just me, but this sounds more like Jammer Priority rather than Radar Priority. I would have thought in Radar Priority, the radar works correctly, and any interference from the jammer is minimised by reducing the jamming capabilities. What is described is the opposite, when the jammer is activated, radar capabilities are reduced to allow the jammer to function correctly, ie the jammer is the priority. Seems backwards to me. Have I just got this wrong? If anyone could explain both options it would greatly appreciated.

I’m not sure the relevance? Above 5,000ft, Baro altitude is still displayed, and hence the altimeter setting still needs to be set according to local/theatre procedures.

Is this intentionally high descent when referencing the TACAN documented anywhere? NATOPs implies there is no difference between a waypoint and a tacan station when calculating descent guidance. If it is implemented for one of the reasons you said, instrument approach, flame out (though less of a problem for the Hornet v Viper), I’d expect this to be explained somewhere.

Personally, I've always thought that a one off price, somewhere in the $50-$80 range, for a MAJOR version upgrade of the DCS core (V3.0, V4.0 etc, etc) every 3ish years, would provide the best compromise. Genuine improvements to the core sim would have to be developed to justify the cost, but finally resources allocated to the core would contribute significant revenue, as apposed to the business model currently in use.

Apologies for the NATOPS quote. Not sure why the images aren't working for you. They appear on all my devices, but can take time to load. I'll try to get a track attached as soon as I have the time.

Don’t hold your breath for this one. Apparently it’s a .Net issue and would basically require a rebuild of the entire multiplayer code base, or something along these lines anyway.

Standard practice in the civilian world is pitot heat always on, and engine anti-ice on when in visable moisture and the ambient temperature is 10⁰ or less. If you want to be pro active, you could follow this. NATOPS however seems to indicate they should be off untill the warning illuminates, then switch them both on. As previously mentioned, extended pitot heat usage on the ground may cause some damage, as without airflow they can overheat. Engine anti-ice should produce a small but noticable effect. As it uses bleed air from the 4th stage compressor, it should result in a slightly hotter engine temp and slightly higher RPM% for a given thrust setting. Whether this is modeled in DCS I don't know.

So we can’t fly low level and lookup due reduced range. We can’t fly high level and look down either for the same reason. We can’t STT at max range to avoid dropping the L&S temporarily… Anyone more cynical them me might even start to consider there’s some quiet ‘game balancing’ going on in the background. There certainly are a lot of vocal viper drives that seem to have a beef with anything the Hornet can do better. /s