Flash_111

I have noted hung starts after clicking fly- usually if I click it as soon as it appears while textures are still streaming in. I suspect it has something to do with the new streaming textures methods that were added to DCS last fall. I also run custom textures in the cockpit so I probably should double check that there's no weird compression methods being used in the files I made.

I have noticed this as well. I also observed an AI aircraft flaming out and ejecting while in this state so I'm not sure if fuel is even flowing at all from the new S3 to AI aircraft.

I don't always spot the deck but when I do I like to see markings

Our group uses a high contrast custom skin for SC as well, would be great to get that functionality restored

While attempting to create an external lighting mod for the F-14 I ran across a bug I believe to be present in the LOD 1 shape files of both the A and B. It would appear that the right wingtip "halo" does not render on the LOD 1 shape (I believe the call in question is HB_F14_EXT_WING_ORB_GREEN. HB_F14_LIGHTS_WING appears to be working). To create the demo image I made a livery description.lua that initialized all the light source calls I could find from every external shape json- and pointed them to a file that doesn't exist, thus forcing each light source to show the "green barf" placeholder texture. As you can see below, LOD1 is missing the right wingtip light "orb". All light sources are present in the other LOD levels. Note- this effects the default F-14A/B and while the external lights are so subdued it is difficult to notice, the bug is present nonetheless. Another point of interest: LOD Distant appears to render the wingtip position lights in the unswept position even when wings are swept.

Would it be possible to get a little more info about how the far LOD color sampling change works? This is addressing the issue where you would zoom out and the texture changed from the 3 in 1 to a flat grey, I am assuming. I fired up the sim the other day to see how it works, and I didn't notice any difference between the far LOD's of the black playboy bunny tomcat and the white pukin dogs (I was just swapping through skins on the runway). Does the sampling event take place during game load, sim load, or swapping skins? Which texture(s) does it sample? Do skinners/painters need to do anything to take advantage of it? Thanks

It was happening at subsonic speeds below 0.9imn, and altitude was somewhere in the 20s if I recall. It also happened with the AP off.

There is an aerodynamic ace up your sleeve as well- you can increase stability at higher speeds by sweeping the wings back.

The techniques that come from learning how to fly parade formation may help as well.

Watched your track file. Your maneuvering flaps and slats rigged out ever so slightly when you unswept the wings. That is what is preventing them from sweeping back in. The fix would be to add a dead zone if your DLC is bound to an axis.

Past few weeks I have experienced intermittent uncommanded roll input in the F-14A during MP flight. It has occurred with both AP on and off. Malfunction occurred 3 times in about an hour. All were rolls to the right. First (ATT HOLD ON) was a minor disruption (~10 degrees of roll, <5 degrees pitch), second (ATT HOLD ON) was a little more severe, and third (AP OFF) we were rolled through 90 degrees. Last week I had another event so severe and abrupt that I blacked out for a few seconds and then when I came to, the oxygen system had stopped working. Rapid descent to 10 thousand kept me from blacking out. I had reports of similar events from guys in my group over the past week or two. I checked all my bindings for double bound axes and there are none. It may also be a form of desync since this is all multiplayer. Examination of DCS.log was inconclusive. If it happens again with a RIO on board I will make sure to get his DCS.log to look at also. I realize this is going to be a hard one to diagnose but I will keep working on it to see if I can isolate the bug or narrow it down to a specific system. I will update the thread with my findings.

Noticed this after yesterday's patch. Part of the shape is displaced for the LANTIRN pylon. Checked this on multiple skins on the A model. See photos below.

Nice, wasn't expecting a patch so soon. Looks like exciting changes. Is the fuel jettison effect fixed as well?

So here's a bit more info. When the key bindings for e-sweep were first added back a few months ago I mapped those functions to a 3 position switch with a press (Win Wing wing fold switch). I had raise/lower handle toggle mapped to the press and sweep/unsweep mapped to fold/unfold respectively, with the middle position of the 3 pos switch being unbound. Back then you could just raise the handle, flip the rotary to sweep and leave it there- handle would move to 68, then wait for the oversweep checks, then without any additional input continue into oversweep. That behavior changed I think in the June patch, maybe the one prior. I have successfully bound it to a spare axis which has a detent (which I can curve to the 68 position), but that sometimes causes problems with hot starts if the axis is not always in the aft position as soon as I spawn in the wings will unsweep to where the axis is, possibly hitting other planes on the deck. I can get in the habit of pushing that all the way back before loading in. But I can't quite get the keybindings to work reliably for over sweep since the last patch, only an axis works (or scrolling the mousewheel on the control itself- not ideal during taxi/parking). I'll keep looking at it because theoretically it's something that should be happening every flight prior to shutdown. I also noticed that you guys have recently looked at landing gear traction/friction for the Viggen- any chance of that coming to the Tomcat sometime? On a dry runway brakes should be able to hold the F110 at mil, and TF-30's through zone 1. In game right now brake friction gives out at around 90%RPM. Ground friction generally feels just weird in the F-14. Pubs suggest that both engines idling should be ample power for taxi (once in motion). Viper rolls around like its on ice skates whereas the F-14 taxis around like it is driving through a thick layer of mud.

I noticed that the emerg and oversweep flags pop up when bringing the wings back to 68 only using the throttle switch. Even when airborne. I am also having a heck of a time trying to get the wings to go reliably into oversweep during parking. I have tried both keybind and axis methods with the handle raise logic option enabled and disabled and it seems to want to stay at 68 unless you jiggle the axis again after 10 seconds or so. Keybind method it doesn't seem to want to go into oversweep period.

So far working as advertised

I don't know why you would need a track. I very clearly listed the steps to reproduce and diagnosed a possible cause, or at least enough for the team to get off in the right direction. It may be fixed in today's update anyway, who knows.

This is most likely caused by the client having to load the texture files for each jet on the deck as the rendering changes from the low detail distant texture (only a few files, like the 3 in 1 LOD) to the high detail close textures (depending on the skin, up to several dozen files). If you have not done so already look into compression methods for the dds files for your skins so the individual files will be smaller (in terms of megabytes) and load quicker. Maybe not as helpful but you could place fewer jets on deck, or install your skins on faster storage media. There are other space saving techniques like using a common texture folder for shared textures for your squadron: things like helmets, pilot model, intake ramps, pylons, fuel tanks, roughness maps, etc. You can direct your description.lua file to load shared textures from that common folder instead of every skin having its own duplicate copy of those files. Hope that helps

This is not a control binding or flap handle configuration issue. I figured out the cause, or at least a way to reproduce the phenomenon. I was actually going to make a post about this but when I found this one figured I would post here. So yeah, it occurs when there is a higher than standard altimeter setting when sitting an airfield close to sea level such that- if the altimeter were set to 29.92 you would be reading below sea level. Same airport with 29.92 pressure in the mission maker and maneuvering flaps will work normally. Basically if you are sitting on the ground below 0 feet pressure altitude, they won't work. This also explains why the flaps work in flight. On a related note, I suspect this also has an effect on the bomb computer's ballistic calculations. We noticed all of our bombs going long and it was because of the non-standard pressure. We were able to get good drops if we used incorrect elevation data during the alignment.

I dusted off some old mini-screens to start exporting some of the F-14 displays to them. I am wondering if it is possible to have the video source that gets enabled by the EXPORT VIDEO TOGGLE command (black and white TCS or LANTIRN video feed) displayed on another screen/viewport. I am hoping that it is possible to have this feed displayed on another screen while still being able to have the cockpit viewport active. In the event that the export video toggle feed is not exportable- the VDI export is way too dark to be useful. I noticed that this is a problem going way back. Is there a fix for that yet?

SME input is great and all but how do we explain all of the video footage of wet cat shots where the engines are staging almost simultaneously and at a faster rate than what is modeled in the sim?

Would you guys be willing to take a look at the current AB behavior? This is coming from someone who only flies the A, but I remember the B having similar issues. My basis for concern is coming from having sat through hours upon hours of footage of the Tomcat A- and my 3 concerns are thus: Afterburners may be staging too slowly. I have seen many videos where the aircraft goes from zone 1 lightoff to zone 5 in under 4 seconds, whereas the DCS Tomcat I have seen take upwards of 6 seconds to stage both engines to zone 5. Afterburners are also staging asymmetrically with exaggerated delays between engines (I have even seen that one engine can stage twice before the opposing engine advances a stage). Most of the footage I have seen shows the staging occurring between engines almost simultaneously with any delay being almost imperceptible. (this is not a technique item, I have tried binding both engines to the same axis, same result) Last issue is that afterburners sometimes will present uneven plumes. I don't know if that was intentional or not. I have actually seen a video where one engine appears brighter than the other, but most of the time they are evenly balanced.

I really wish we could see KSGU and KCDC added (already inside current map boundaries)- although non-towered, these are 8 and 9 thousand foot runway equipped regional airports with instrument approaches which support daily air carrier service, regular cargo carrier ops, extensive flight training, and high intensity fire fighting operations in the spring and summer months. Additionally, the terrain in this area is absolutely beautiful. You should strongly consider updating this area of the map. If you guys need reference photos of this northeastern area of the map- airports, landmarks, cities, etc from either the air or from the ground I fly in this area regularly and can probably get you some.

While the Tomcat fulfilled the long range strike mission for a time, it was not the F-14's long suit. The A-6 can carry a wider variety of air to ground weapons, and in most cases more of them. It also has a far greater capability to conduct all weather low level navigation. The fact that the F-14 served as a pinch hitter in the strike mission speaks more to the F-14's versatility than to the obsolescence of the A-6.