captain_dalan

Sorry to necro this old thread. If a moderator thinks it's better, i can always start a new one, i just wasn't sure if it was appropriate. Me and my friends came across it a while ago, but neither had the time to actually run any tests in DCS, mostly because the holiday season wasn't friendly to our DCS schedules. We did however ran some tests the last weekend and i continued doing some of my own well into this week. A video of the average test result, a track, the mission file and a couple of Tacviews are attached bellow. In short, my mission setup for this particular test: 15 degrees standard atmosphere, F-18C at 500ft, doing 750 knots. I wanted to minimize time for acceleration - deceleration and thus provide stable airflow and a constant powerband for the engines, so i chose the max airspeed attainable this low. The F-18C is in a 2X AIM-7, 2X AIM-9, 34000pds configuration to match NATOPS data most closely. Sparrows are conformally mounted. Internal fuel is 7050lbs. This should match the configuration in the manual for the 400 engined Hornet, with the exception of top speed, as the old engines barely reach mach 1 at sea level in this configuration. My methodology: I start the mission, kick in max AB and count the time from AB lighting up (external view) to afterburner flameout (external view). Trying to stay level as much as possible and the speed inside 5 knots. My results: The total time in burner seems to be within 6 minutes 3 seconds and 6 minutes 10 seconds, the average being around 6 minutes 5-6 seconds, which are the tracks and the video i post here. This gives us average fuel consumption ASL for MAX AB power of 1155.7lbs/minute. To tie in to the OP concerns: Open source data states specific fuel flow for the two engines used in the Hornet to be: 400 engine : 1.85 lb/(lbf*h) 402 engine : 1.74 lb/(lbf*h) The new engines are more fuel efficient per pound of force produced. Now, the engine power as rated in open sources (static thrust) is quoted as: 400 engine: 16000pds; 402 engine: 17700pds; The new engines are obviously also much more powerful as they can easily get the hornet up to mach 1.14-1.15 in the above configuration and can even get to mach 1 without use of AB. These are static engine thrust values only and don't take into account effects of airflow, but i think it's safe to deduce the new engines produce significantly more thrust then the old ones, as what is essentially the same plane drag and weight wise is now much faster (almost a 100 knots faster on the deck). Finally the crux of the matter: Figure 11-143 Combat fuel flow chart states: at sea level, in the above mentioned configuration, maximum fuel flow at mach 1 or so (top speed) is 1320lbs/minute. That's 14% higher then what we have in DCS, despite our engines being considerably more powerful (about 10% more) and slightly more efficient per pound of thrust produced (about 6.3% more). So the OP may actually have a point here, it's possible that the fuel consumption is not quite where it needs to be in our Horner. What do you guys think? Have you ran any tests yourself? Are there significant flaws in my methodology? Here follow the data: Video: Mission file, track file and tacviews: F-18 fuel flow EVAL.miz F-18C fuel flow.trk Tacview-20230119-000227-DCS-F-18 fuel flow EVAL.zip.acmi Tacview-20230118-235102-DCS-F-18 fuel flow EVAL.zip.acmi

On the topic of manual lofting, just did some mini-tests tonight as well, 50NM shots, launcher at mach 0.8. 30000ft, not non defending target at mach 0.75 23000dt: 1. A level shot results in a 2 minutes flat time to impact (1:13-3:13), missile loft apex at 66994ft and mach at impact 1.29; 2. A 30 degree loft results 2 minutes 1 second time to impact (1:16-2:17), missile loft apex at 88534ft and mach at impact 1.68. Just dropping my 2 cents for what is worth. Tacviews attached bellow: Tacview-20230118-225806-DCS-1 on1 loft test mk47 -30 degree.zip.acmi Tacview-20230118-231536-DCS-1 on1 loft test mk47 -00 degree.zip.acmi

Hmm, i'll do some more test runs then. Maybe even tonight if i get that extra free time. Same server, just to try and replicate the circmustances.

Thanks mate. Sorry for the late reply, i was just away from DCS for the holidays. I found the solution, and it turned out to be the size of my virtual memory page file. I had it set under 32 gigs. And it looks like that wasn't enough! I will clear out the temp folder though, as it seems like a good practice! Thanks again and happy holidays!

This is a strange bug that is either rare, new or it's just me first time encountering it. I was on Through the Inferno Syria this evening, grabbed an F-14A slot just as the carrier started turning. After some bumping around the carrier settled in on a new course, but my plane was leaning to one side. Never the less i still tried the starting procedure. The right engine started OK, but the left never spooled up at all. I assumed it might be plane damage, so i spawned in a new slot. The Left engine again, wouldn't start. I asked in the chat and someone mentioned it's a bug and i should start from land. I don't have a track as this was in MP, but i was wondering, has anyone experienced this issue before?

Thanks mate, your input seems to have fixed the issue!

Hi @Flappie these crashes may not be related, but i didn't want to clog the forums with new threads without a good reason, so i'll write here first. These crashes are fairly new, only started in December, which coincides with both Changes in the missions that cause them (Through the Inferno Syria and to some extent TTI Caucasus), the new DCS patch, me buying a new GPU and PSU. The interesting thing is i don't get crashes on any other MP servers, nor in SP. My rig is: CPU: i5 9600KF RAM: 32GB DDR4 GPU: NVIDEA GF RTX 3060 with 12GB of VRAM SSDs both for the system drive and the game drive I wrote to the guys of TTI on their forum page/post as well. And here is my latest log file, from last night - this morning, which is the last time i had the crash. Thanks in advance and Marry Christmas! dcs.log dcs.20221225-040325.crash

What about the RWR in other manned planes?

Ever since the start of December, i just can't get a break with the Syria server, and i get random crashes to desktop. Sometimes while still starting up on the deck of the Super Carrier, and sometime after flying around for a bit, but a crash is a certainty. Sometimes the crashes happen on the Caucasus server as well, but not as often and not as regular. I run no mods, except for a few custom made skins, the A-4 and the T-45. My setup: CPU: i5 9600KF RAM: 32GB DDR4 GPU: NVIDEA GF RTX 3060 with 12GB VRAM SSD for a hard drives, both the system drive and game drive. The only thing different i noticed from before is that the ping went up from the usual 160-170, to 180-190. However, the ping on the Caucasus is usually higher, and that results in less crashes. Anyone has any ideas what the crashes may be caused by? I don't get them on any other servers, nor in SP. Thanks in advance! EDIT: here is my latest DCS log file, from last night (this morning) if it's of any help: dcs.log

Hi devs, a short question on the new flight model (yet to come) Question: Will the new FM refinements include changes in fuel consumption as well?

@IronMike?

High pitch as in manually lofting the missile?

Nice! Didn't know that.

You can change seats in MP now?

Did the same this week (got new GPU and PSU) so i'll see how things work out in time.

What about in MP?

For a time i've been suspecting this, so tonight i finally kicked two of my training missions, one against a SARH equipped Flanker and the other against the ARH equipped Eagle. External inspection confirmed, though i didn't record a video. Jester launches chaff at certain point when faced with a semi-active threat, but never against an active one, not even after the missile has gone active and the RWR is screaming. Attached Tacviews bellow: Tacview-20221211-041509-DCS-BVR F-14A duels VS F-15C.zip.acmi Tacview-20221211-041125-DCS-BVR F-14A duels FOX 1 Su-33.zip.acmi

In my case, i may need a new power supply

The final challenge, swapped the vanilla Viper for the ED version, picked the USN adversary skin, remove pylons, matched the fuel of the vanilla bandit, and tried to shoot it down before it ran out of fuel. Took 5 tries

I don't think this to be case, as i have recording of the same thing happening with selected Sparrows or Phoenixes, but i fear that if i upload any more DCS content, Youtube will ban me for spamming! It must be that then. And a few fast experiments i performed tonight, showed that if i count slowly to 10 or so before turning away, the tracking never drops. So there's a new good common practice to have in mind i guess.

Hmm, it seems that the best workaround would be to keep the nose still for about 8-12 seconds from the moment the radar transitions from RWS to TWS. That should be enough for tracks to properly build, right? As for it being a bug or a feature.... @IronMike? Might try that as well if i have the time this evening.

Yeah, i always keep 'em on as part of the challenge.

Not an impossibility, but it would happen more randomly if it was so, and there seems to be a method to this. Also, PAL and PLM are mapped to my throttle buttons. And once i punch in blower i leave it alone. My Jester shortcuts are mapped to my keyboard, and they only involve TID orders. It's my own modification of that mission to include Charlie Phoenixes, but the mission isn't an issue, i can recreate it on any mission, including vanilla instant actions. Here's some from the Persian Gulf BVR mission. In the first 2 cases, the radar reacquires and continues tracking, but in the third one it doesn't: It appears the issue is more likely to appear near the edge of the radar cone. Also, not sure, but switching TID to 50 mile scale may play a part? I also include two tracks as short as possible, for all those are worth these days: track lost and recovered.trk track lost and not recovered.trk

No mods, except for custom skins (some made by me) and A-4 and T-45. That's actually a very good idea!

Yep, 0:43-0:46. I didn't give any commands, either PAL, PLM, or shortcut for a Jester command. i was just trying to build some offset, like i usually do when i accelerate before launching. The targets were too far away for any such attempt anyways. Though, now that you mentioned it, could it be that some weird part of the Jester logic kicked in, and he changed the radar mode on his own? This is fairly easy to reproduce really, just wait for the tracks to build, and then gently turn away from them. It also appears to happen only the first time around. Later on, if you pick them up again and let Jester/AWG-9 sort them out and build track, they won't drop if you turn away.