Robin_Hood

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.

I really appreciate the new direction ED has taken with those two messages from Kate. Thanks for your honesty and for giving us a glimpse into what is to come. Don't be too distraught about all the fuss people make. If the Supercarrier had been released with critical bugs, there would have been complaints anyway (especially since a lot of people use the Beta as a stable version). @watermanpc: Kate talked about that in her reddit post. Clouds have proven difficult, and they had to start over several times because it just didn't work (or was too much of a fps hit, maybe). It is clearly something they really want to improve but are struggling with. I wish them to succeed, as I have always been very eager in clouds and weather improvements.

The updated manual draft posted by Wags confirms that "All radio functions for the carrier (i.e. Marshal, Approach, Tower and LSO) will use this single frequency". I still hope they consider allowing (even as an option) more realistic frequency changes at a later point. Currently, the Marshal telling us "approach button is [CHANNEL]" (or argualy "go tower") doesn't make sense.

My bad, I meant CNATRA P-1211. A quick google search of both "CNATRA P-1211" and "LSO MANUAL" should give you what you're looking for.

Great job on the Supercarrier manual! I am looking forward to seeing the rest of it when available. Now I know it is still early WIP, but I'd like to point out that the manual uses the phrases "Left for lineup" and "Come right" from the LSO. It was my understanding (from sources named below) that these two phrases are not used, and that it is always "Come left" and "Right for lineup". Is it an oversight or do you have sources that say otherwise? Sources: CNATRA P-111 (Carrier Qualification) and LSO NATOPS

What is your source for the INS being automatically updated by GPS when not in AINS ? Because that's not what the NATOPS seems to say (eg. in the phrase "In GPS capable aircraft the INS is coupled to the GPS (in AINS mode) to provide a more accurate aided source of position and velocity"). Also, remember that GPS can be disabled in DCS (by date or by coalition), so that makes it relevant.