Robin_Hood

Sorry to resurrect this post, but I have a question. What does the "IMU reset" procedure, described in the manual (page 282), do if it is not a kind of in-flight alignment? It does require to fly straight and level for 5 minute, which sounds like the sort of things you have to do for in-flight alignement. Also, I've tried the procedure described (INS - OFF, then INS - IMU, fly straight and level for 5 minutes), but "IM" never appeared on the TID, it kept on displaying "AH".

We have had the same experience, with the Link 4C not working after a multicrew ramp start, but working with a pilot-only rampstart. Any news on this?

Got it, thanks. I wasn't making any comparison with the APQ-120 though, I was only talking about the AWG-9 (and the above image is from the F-14 manual). Anyway, the AWG-9 is already pretty fun to fiddle around with!

Browsing again through Heatblur's manual, I came across this picture of the Pulse Search mode (page 222), where altitude returns are indicated and displayed approximately in the manner that I would expect. I am guessing then that sidelobe clutter in Pulse Search should be a thing, but is just not implemented (yet?).

Hi everyone, I hope some people can shed some light on this for me. I was wondering why there seems to be no sidelobe clutter (especially altitude returns) in PULSE SEARCH mode. I have searched but couldn't find anyone mentioning sidelobe clutter except in relation to Pulse Doppler. I understand that in Pulse Doppler, both main lobe clutter and altitude returns are filtered (MLC filter and Zero-Doppler filter respectively), and that the zero-doppler filter cannot be deactivated. However, it occurs to me that in Pulse Mode, the sidelobes should also be a problem, and shouldn't altitude returns also appear, at a distance roughly equal to the aircraft's current height? A sidelobe pointing at the ground in pulse mode would create a return, wouldn't it? Is there still some Doppler processing anyway with the zero-doppler filter even in Pulse, or some other way of filtering out aititude returns, or is it simply not implemented? Or am I missing something?

Interesting, I'll try different times and maps, but I'm pretty sure it worked alright a few weeks ago; now that I think about it, I have changed the mission start time some time ago, maybe it placed it at a different date then. I'll investigate

I would like to submit this simple mission and multiplayer track where the following behavior occurs: Initial conditions: - There is a ME-defined flight of 2 client F/A-18C and an E-2D Hawkeye - Both F/A-18C are defaulted to the same MEMBER Datalink group Behavior: - At mission start, I can initially see the other Hornet as the "B" flight member on the datalink - A few seconds later, he disappears and is replaced with a simple datalink contact from the AWACS, instead of a member or donor or even a party to the Datalink net The track file and the mission file is attached ; if I have missed something, please let me know Note: this is a very simple case that I made after seeing the problem in more complex cases (user-defined groups, custom VCS and TN, etc...) Datalink_multiplayer_test.trk test_DL.miz

I don't see this bug as "reported", so I'd like to bump this thread. Here's another track ; one F/A-18C, one train, one ground mover. The vehicule shows up on the GMT display, but the train doesn't.Trains_GMT.trk

Hope this is not forgotten, since we are getting the SA-5 also, that will have to be added to the filter.

Except that tha APU in the Hornet doesn't provide electrical power. So...

Alright, thanks, Grimes. I've been working on a modified version of MBot's ASW Script, and I wanted to have the sonobuoys work only if the hydrophones weren't lowered into the bottom. Guess for now it'll wait.

I guess testing all that on a flat terrain should eliminate any possibility of a DTED influence, wouldn't it? (Perhaps over the water, so that elevation is really constant for miles around)

Hi all, with seabed depth modelled on the maps now, I am wondering if there is any function to get the depth of a Vec2 position, like land.getHeight does for terrain elevation. getHeight gives 0 (sea level), and getDepth doesn't exist. Any thoughts?

I know 1.2 seconds (after release) is also the second option (in-flight selectable), that also works in the F/A-18C (by MFUZ = PRI, IIRC). There might be a mistake here on ED's part? Maybe this would actually warrant a bug report. There is also the backup 500 ft (IIRC) for VT fuzing (if the bomb never senses it crossed the (ground-)selected HOB, it will burst at 500 ft anyway), that I think is not modelled right now in DCS.

From the tests I did some time ago, the bombs were bursting about 1.2 seconds after reaching 1500 ft AGL for some reason, instead of immediately after reaching that height. Therefore, depending on their vertical velocity at the time, you may find them bursting between, say, 900 and 1450 ft. Which, of course, is not really helping this matter.

I think this is a reported bug that happens when the mission starts in Case 2/3 conditions and progresses through the day to Case 1 (typical of dawn/pre-dawn mission starts). The carrier only kinda changes the case and gives conflicting information. Only fix at the moment AFAIK is change the start time of the mission.

I checked quickly but didn't find a report for this (sorry if already reported). When using the new feature, USAF Aggressors is not populated at all no matter the mission date, pretty much breaking the "country" entirely.

Oh, my bad then. I used SP to do some quick tests. I tried in MP, and it works fine indeed. Thanks!

Hi, the mod looks really amazing, but I'm having some issues with obstructing objects, as per the attached screenshots. Takeoff from runway 4 on the CVN-73. Any ideas what might cause this?

For the record, we are experiencing the same problem. It seemed to work fine when I did a quick solo test on the same mission, but in multiplayer, after a 90 min flight it did as described here, on two different occasions. I hope someone is able to provide a track for it.

Check your load factor. The fact that the Hornet FCS limits you to about 7 Gs has something to do with it ;)

So the subject has already been touched a couple times, here and here, but I thought I'd bring it back once more, now that we're talking about F/A-18C roadmap and everything. First, there is a strange discrepancy in the F/A-18C, where Bullseye location of contacts in the radar and SA page is always in true bearings, but for BRAA, the radar always shows true while the SA page shows true or magnetic depending on setting in HSI DATA. And secondly, there is still the question of which they should use. So two questions that I hope can be answered : 1°) Is it normal that the SA page BRAA depends on the DATA setting, but the bullseye doesn't? 2°) Shouldn't everything use magnetic anyway ? Or is it selectable (for both, for SA page only?) I always heard the USAF and USN use magnetic reference for both BRAA and Bullseye, how can the F/A-18C not be capable of displaying that? Of course, this also raises the question of the AI AWACS, that do give true bearings, which may be the reason behind all this. I'm guessing they could be made to give magnetic bearings, but it would hinder FC3 users. Although right now it hinders everyone else, so... Just for the record, although I don't think it really necessary, here's a track that shows the problem. At 42 seconds, HSI in mag, then true. TrueMag.trk

Two things: 1. Once again, the HOF setting in the STORES page does not have any effect on actual burst height. That is set on the ground, the STORES setting is for HUD symbology and impact point computing. 2. What was your release altitude, dive angle and airspeed ? As mentionned earlier, actual burst height depends on several different factors. - If you release below 1500 ft, it will burst 1.2 seconds after release - If you release above that, it will release 1.2 seconds after release if EFUZ is on PRI, or 1.2 seconds after passing 1500 ft if EFUZ is on VT And in all cases, actual height will depend on the vertical velocity of the bomb (because 1.2 seconds), and thus on the dive angle and airspeed at release. Also (and obviously) the ground elevation must be taken into account when watching the bomb in external view). Now I have not tested in the latest Beta, so I cannot comment on if there have been changes, but all of this must be taken into account for any discussion of height of burst.

You may have missed this important part So, no, it won't be added to the EA release. That's not the same as saying it won't be added further down the line, which is what we are talking about and hoping here.

It would help if you could give ED a track of when it happens. The shorter the better, although it doesn't seem easily reproductible.