Nightwolf

Specter, thanks for looking at this. I think there may have been a misunderstanding about what the problem here is. The original post isn't saying there is a problem with an FPS difference with and without an aircraft in the scene; in fact that was more about proving it wasn't an issue involving this. Instead, we're seeing a huge difference in framerate between the camera being at low altitude and higher up. I'm interested in Rapierarch's findings, that it could be something weird causing shaders to recompile constantly at lower altitudes. If so, it might have little to do with VRAM, and not be affected by many graphics settings.

Been having this exact same thing, both in an aircraft and in F2 or F11 view. Close to the ground 15-20 fps, but as soon as the camera gets up a few hundred feet and the grass stops rendering, boom 40-60+ fps. It's basically stopped me from playing on SA since it's nearly unplayable to take off or land, and since the clutter doesn't obey any graphics settings, there's no way to get around it.

Which is why I'm reporting issues...

Another hour of exploring and: S53 03 34 W73 09 12 River runs through a non-water lake, and some other weird stuff nearby S52 45 31 W71 37 56 hard edge forest, near some other texture edges S49 54 36 W73 13 53 Infinity pool lake where the water looks to be at the wrong height, but also slopes down across the lake so the lake isn't level S49 52 7 W73 13 44 Misaligned textures and texture edges Also the entirety of the glaciers and snowy peaks render grass when the clutter/grass slider is enabled, it's just white to match the ground texture.

South America looks great!... from 40,000 feet... and even then... All across the mountains and valleys of South America there are roads and rivers that completely mismatch the terrain textures. You can see exactly where they are on the satellite imagery used to generate the textures, and the roads and rivers follow generally the same shape, but almost never actually match them. Similarly, there are areas on the satellite imagery which are clearly water (lakes etc in the mountains) that are just dark colored grass. Furthermore, there are several locations where there are obvious shadows from the satellite imagery, which not only look silly under many lighting conditions, but also often seem to result in no trees being placed there. This all leads to a very thrown-together last-minute look the second you leave the cities and airfields behind. Below are some examples: S55 30 05 ish east-west line where trees just stop across multiple peninsulas S52 47 45 W74 40 10 strange water feature with elevated island (on google maps, this area is just shadowed not water at all) S52 48 03 W74 37 36 darkened polygon ground texture missing trees S53 38 13 W71 49 51 Shadow causing trees not to spawn, along side a whole area with clouds not removed from textures S53 37 40 W71 48 50 Lake with stream made of dark grass S53 42 06 W71 41 42 Massive texture seam S49 12 48 W73 27 05 More texture seams, along with very obvious repeating snow/ice texture tiling Whole area around S49 47 06 W74 41 56 Incredibly mismatched elevations between water and land, striping textures, as well as several baked-in lakes and streams, along with baked in shadows blocking trees, the whole shebang S52 26 10 W71 18 48 more obvious texture seams (also on the sat imagery layer this looks like a salt flat, but in game it's just a plain old lake?) S51 45 59 W71 54 18 Good example of a mismatched river, it just looks silly S61 67 43 W72 05 55 Good example of a mismatched road s51 52 41 w72 11 13 baked in water S53 10 26 W70 56 51 Weird labeling on condominiums? On the F10 map they're just in the middle of fields, and is it really necessary to label all 6 Condominios Brisas del Sur individually? There is so much map clutter when you zoom in to the cities. S50 09 18 W72 51 59 another huge texture seam S49 54 26 W72 46 00 another misaligned river, combined with a baked-in river made of dark grass S54 49 30 W64 24 20 another texture seam And that was after less than an hour of aimlessly scrolling around on the F10 map and then checking with F11 view. I can't say I'm particularly impressed. I understand it's a huge map but basically anywhere you go you can see at least one, usually 2+ issues like these...

Noticed you can also induce an uncontrollable spin by just holding forward and lateral stick input below around 300 kts. The plane doesn't seem to be able to decide what rudder input it wants which wobbles the plane out of controlled flight. Once that happens even releasing all control inputs, the FLCS just holds inputs that keep it in that spin and it doesn't recover itself.

The game is physically impossible if you redefine physics and materials science to your liking, shocker! You can't just do simple math like this to calculate the structural strength of an aircraft. You immediately assume all the weight of the plane is supported by the wing spar, which is not true even if the wings were the only things generating lift, not to mention that on many aircraft the fuselage generates a decent portion of the lift of the aircraft. Then, you'd need the force and the cross-sectional areas of the load-bearing members to calculate the stress (measured in units of pressure). That then tells you the percent deformation from unloaded that the member would flex to (where the Young's Modulus comes in). If the internal stress is outside the elastic region (beyond the yield strength of the material), then the metal permanently deforms, which is a failure. For our intents, as long as you're within the elastic region, you can load and unload the metal as many times as you want, it will return to its original position. This is why energy input is meaningless, because as long as you keep the stress below a certain point, the material won't fail (There are some factors to do with load-unload cycles that can lower the failure point of the bar but that's in the hundreds of thousands of cycles if not more, and highly material dependent). I don't know where you're getting your information but just saying "this doesn't help, it still fails" without rebutting any of the arguments doesn't work.

Young's modulus doesn't have much meaning in regards to failure points... It's essentially a measure of how much a material will stretch for a given amount of internal stress (force over the cross-sectional area). The material doesn't fail when it reaches a stress equal to the young's modulus, it fails when it reaches the end of the elastic region, the yield strength, and catastrophically fails when it reaches the ultimate strength of the material. Stress is also not cumulative, so energy input is mostly meaningless. The whole post is nonsense lol.

I should note, aside from the vertical notch one, my shots were in RWS ST SAM, which seems to be acting kind of strange recently. Not sure what happened with the one called Vertical Notch, but I was in ACM STT for both. I do have a track replay, unfortunately it's 180MB and 2 hours long since this is from a normal multiplayer session.

Removing unofficial aircraft mods from Saved Games worked for me, I don't know why they'd have this effect but it's a solution for now

Awesome thanks!

Hello, can I get any confirmation that this is an acknowledged bug? It appears that some other people have experienced similar issues that cause the same crash: https://forums.eagle.ru/forum/english/licensed-third-party-projects/heatblur-simulations/dcs-ajs37-viggen/bugs-and-problems-az/291896-ajs-37-c-error-ctd

Discovered this today on Hoggit Training: there was a player named Mjölnir who was or had flown a viggen and used the map marker system to create a bunch of marks. However, it appears that when attempting to generate DTC files based on the map markers, the file name got corrupted or used an incorrect character instead of the ö in his name for the flight plan. This in turn caused the game to crash. It also persisted until I manually deleted the .ini file from Saved Games\DCS_AJS37\ even when attempting to load into other servers or single player missions. The solution was to go through and delete his map marks from a different aircraft before slotting in to the viggen to prevent it from attempting to create a DTC file with his name in it. Attached is a zip containing the DCS crash log (which shows the crash right as attempting to load his .ini file), the full DCS_AJS37 folder containing the .ini files which it generated before crashing, a screenshot of the C++ error that popped up before the DCS crash reporter, a screenshot of the F10 map as seen from a different aircraft, and a screenshot of how the file name in question looks on my PC (As it could be a language pack thing or something specific to the windows install). If necessary, I can also provide track files and other info. Files.zip

Not sure how the definition of a released aircraft can change just like that... many of the so-called “improvements” post release are features that were promised long before early access release. I mean, we’ve been hearing about work on HARM PB mode for a while now, now suddenly it’s not an essential feature and it’s been pushed to 2021 out of early access? Multiple weapons, radar modes, even ATFLIR, the only targeting pod we were originally supposed to get, are all now not release features of the hornet? The viggen is several times more feature complete than your planned “release” state and it’s still in early access.

Well A) That's not something I want to get into the habit of doing :lol: and B) That's not very reliable (often also lose main rotor), isn't necessarily easy, and also means you can only experience the failure starting from a very small flight envelope

Well not necessarily, right? Especially at higher speeds and altitude it's possible to use the weathervane or airframe keel effect to keep the helicopter oriented, right? (I'm definitely no helicopter expert) I'd think that especially for combat helos, as long as the main driveshaft to the main rotor is intact and you have power to maintain altitude you'd rather not instantly autorotate the second you lose your tailrotor since you're probably over enemy territory. Even at lower altitudes and speeds, I would think you would be able to climb and get altitude, then reduce collective to reduce torque and bank/pitch the helicopter to get airspeed which would then weathervane the nose to the right direction. Then on landing you come in fast, stop fast, and put down before the rotations get too fast? But then again, this is why I think we need failures like this, and stuck pedal is a good one too. I don't know exactly how the helo will react because I can't make it happen so I can't practice it. The damage model for it is already there, the only thing we don't have is the option to fail it ourselves.

I decided I wanted to practice some tail rotor loss scenarios in the Huey and to my surprise, there is no failure option for it! The only failure related to tail rotor is a gearbox chip, and as far as I can tell it has no effect on actual operation. I feel like it's important to be able to practice tail rotor loss and recovery especially for a combat aircraft where it is much more likely to occur. Is it possible to add a triggerable failure such as a tailrotor gearbox failure similar to the main gearbox failure to the Huey? That way people can practice recovery and landing without having to work very hard to hit the tailrotor on a tree or building or the ground without damaging the rest of the helo just to have a nonfunctioning tail rotor.

Yep same thing here, I ended up cruising far behind and above them and eventually went to 2-4x speed because they were also flying so slow. Really disappointed to find that this bug has been "reported" for more than a year and a half, especially one that makes the mission so much more tiring and lengthy. It also made it pretty difficult to get to "close formation" so the reporter can take pictures etc.

I'm starting to wonder if ED ever even looks in here anymore, or cares about FC3...

Bump

Well we're on to more than three months since the report, I still haven't seen ED anywhere acknowledge that this is a requested feature or anything. Can we get some confirmation whether GGTharos's new logic is being worked on, or if we're ever going to see an enable/disable loft option in the eagle? Regardless of whether or not you think it's better what we have right now is unrealistic and many people don't like it, often having to use AIM-7Fs on servers where there are no AIM-120s so that they don't have lofting missiles... A simple keybind with MFD indication would be all that's needed for a minimum effort fix, not asking for any new HUD symbology or completely new loft logic, just a toggle button.

Multiplayer really needs the ability to dynamically create and remove "client" aircraft, or just not show aircraft of one side when located at an airbase of the other side. Having over 1000 slots on servers where airbases can change sides so that everyone can use every airfield when it's on their side and then using a script to kick people out of slots they can't use is less than efficient.

The excitement builds! Just a couple small typos in the first few pages: Page 21: Autopilot Pitch and Roll switches: "The roll switch includes the HDG SEL setting to have the aircraft turn to a and maintain the heading select bug on the HSI" Page 22: FCS and DBU Warning lights, "Angel of attack" Page 22: ADI, "needle width equates to 1 to 1.2 a degree per second" should be "1 to 1.2 degrees per second" Page 26: Speed brake indicator "and when it has not power" -> "no power" Page 33: Audio 2 Control panel "Just below the audio 1 control panel in the control panel for audio 2, and this includes..." I think you mean "is the control panel for audio 2" Page 35: Anti-Ice switch, "will automatically turn one if ice is detected" -> "turn on"

Thanks BIGNEWY, No insult or witch hunt is intended in the document. Other than the intro and conclusion, the document is only plain facts, about which everyone is entitled to come to their own conclusion. We only went to these lengths to create this document because we want to see the gazelle reach the same level of realism and accuracy that DCS is capable of. We actually specifically said it’s not within our purview to make any conclusions about the developers’ conduct or development strategies other than that it seems development has stalled. The only thing we ask is that you actually read the document, analyze the evidence, and see for yourself why we thought this document was necessary.

Just FYI that Mistral.lua was only relatively recently added, I believe by ED themselves. It’s not the same file that is used for the Mistral that the gazelle uses. You can tell because it doesn’t have a magical second stage that burns for 6.8 seconds but doesn’t produce any thrust. EDs Mistral might look correct but the real FM is hidden compiled in another lua somewhere else.