Jinks

With the new damage model I figured giving this a shot would be a helpful learning tool. Seems useful except it only seems to work for a few minutes before freezing with the last value shown. Single & Multiplayer The dcs.log shows these lines: Pasted code as shown into local saved games \DCS.openbeta\Scripts\Export.lua I wouldn't know where to start to fix this but looks like it needs a tweak after one of the last patches perhaps?

Heading out at the moment but will post later. From memory just take a full plane get up to about 5000 meters @ 800+IAS might be easier to reproduce @ 900. fly level at that speed. Roll inverted and pull as if you were defending. You won't need to pull much if you get it rolling fast. The wings will snap instantly when you hit the right input. Again, it's not that hard to learn to avoid it ... that's not why I'm abdicating for more examination. It just seems like it's super easy when rolling - like a bad calculation or something. Regarding other comments... I think I've made myself as clear as I can and there's no point discussing with anyone who's not interested in understanding the issue. Or hasn't even tried it themselves. Hopefully all of our comments get looked at and taken on merit by the right people.

You can rip the wings off with very little stick input very easily. Try it yourself perhaps. If your opinion is that's how it should behave then so be it. Saying that we're going mach and throwing the stick doesn't address anything of substance. Arguing for or against anything based on lack of documented proof goes both ways, that was the point I was trying to make.

The issue for many of us has nothing to do with being able to learn the new behavior. It's whether or not it's completely accurate. As you've pointed out there are others with more complete data who may be paying attention and trying to interpret how to implement that data the best way possible. Discussion doesn't hurt. In my post I did shoot down a couple of comments - because they are easy to prove incorrect in the sim itself - and serve no constructive purpose. Many points/questions/opinions are also being shot down based on some seemingly esoteric understanding of "real world" behavior of very complicated and intricate issues. I have a non-technical question to ask you. Have you flown the flanker with the new update and tried to reproduce the non override wing failure? Not the mach 1 post merge cobra which most people would agree needed to go away. The point for many of us was the wings ripping off unexpectedly while cranking/defending at medium ranges. Straight up it just feels very wrong. Not very scientific and maybe totally lost on you which is fine. If it's to be left that way so be it. Enthusiasts will learn. However it's probably a good idea to make sure that is absolutely the intended behavior and is modeled correctly. Without resorting to a flanker / eagle flame war we can still call a spade a spade. Under the current conditions you have a situation where one can fly it's wings off by going defensive and the other does not. Nothing to do with cobra button. What real world proof do we have that this is realistic? A bunch of textbook numbers being thrown around. An example of an eagle surviving sustained over g (it's better than it's textbook numbers) and zero example of a flanker flying it's wings off (so it obviously can't)... Using textbook numbers for one plane and not the other is just simply never going to make sense to many of us. Regardless of what order the flight models are upgraded in - trying to make the sim balance them to be "fair" is the wrong approach. However a case can be made for balancing the logic used to come up with those upgrades. The end result most of us want is an accurate and fun simulation experience for everyone.

That's a cool video. I'd be curious to know if they had a microphone anywhere near the wing itself while loading it. Even if an audio cue doesn't makes sense, it's quite obvious that the the stress was visible. The flanker wings aren't nearly as long but it's hard to imagine there wouldn't be at least some flexing before they just snapped off. And again - the point for many of us is not whether or not this should be modeled. It's how it's modeled now. The point isn't being made to use the over-ride and pull a 20G maneuver. That's quite obviously not realistic. Is it really accurate that the computer (still engaged) cannot handle rolling and leading to the situation where the wings snap off very suddenly. If not rolling the issue isn't there. Yes that can be learned but is it accurate?

Obfuscation: intransitive verb : to be evasive, unclear, or confusing There are two concurrent threads regarding the new damage model for flanker filling up now 13 pages and filled with a lot of discussion that's going all over the place. Reasonable questions are being lost by extraneous points in all directions. Effectively devolving the conversation to a F15 vs Su27 fanboy war. Using "real world" examples of why an F15 would never have it's wings come off then failing to provide examples of a Su-27 flying apart with a fully functional computer makes no sense. Complaining that the F15 is easy mode / "arcarde" is equally as pointless. That discussion has no bearing on whether or not this was implemented in the best way for the Su27. There should be an official thread for that somewhere else to be used as a cathartic. There is some bad information being argued and I'd like to point out a couple. No. You do not need to over-ride the ACS or AoA to have the wings rip off. This has been explained and is easily reproducable. Go over 800km/h roll inverted while pulling. It's already been established that you do not need to exceed 12g's to have the wings rip off. While a lot of the complaints about this update have been rather whiney - the true irony here is the many posts trying to have a constructive conversation on whether or not this has been implemented correctly or in the best way - not whether it should be there at all. --- Many of us (flanker pilots) totally understand and agree that you shouldn't be able to manually over-ride the computer without penalty. Wings ripping of without warning and without over-riding the computer is a valid concern. There have been many posts implying that this is hard to do. It is not difficult at all as pointed out and easily reproducible. The question has been posed whether or not this was intended and if it is actually correct. To some degree it was answered. If the first shot at the new model is an accurate representation of real limitations of the computer then so be it. There's nothing wrong with wanting to get that right. The other valid point made by a few people is that there is zero warning. It just happens instantly - which is likely not the best behavior. Telling someone real pilots don't pitch while rolling doesn't address that. If the simulation is monitoring flight data for a certain condition to be met... Perhaps there is a way to let the dumb pilots - sitting in his chair at 1g - know he's about to rip the wings off when approaching that condition. Or perhaps it makes sense to allow for an instant of being over that condition, some type of audio cue (creaking), or anything that helps reduce the confusion. Questioning how it works or making suggestions does not mean one disagrees with the existence of the new damage model.

Ok, you're saying the tolerance is lower while rolling? Still curious if having the wings fly off without over-riding automatic control system or angle of attack limiter..... was an intended behavior of the patch? Kev2Go... Loading the wings until they fail wouldn't necessarily have to be strictly a result g load would it? You could break the airflow and put incredible strain on the wings without having to change direction all that much. Example: Imagine a brick with a pair of wings flying through the air at high velocity. Pitch the brick up 90degrees suddenly... the wings rip off without the brick changing direction hardly at all. Realism is good but does the flankers ACS really fail at preventing that while rolling? If that's how it is so be it fine, no doubt flanker pilots (myself included) will learn it. But if it's not really accurate it should probably be addressed. "Wings fly off while defending" is kind of not a small thing added to workload of learning pilots.

Yup, fly 800+ roll inverted and pull as rolling. No ASC or AOA over-ride required to have wings fly off. Million dollar question... Was this the intended behavior?

Tried that. Also repairing doesn't fix it. Uploaded two UNLISTED videos to youtube that show what happens, relevant log files already attached. First [ame] [/ame] Second (after repair and starting in administrator mode) [ame] [/ame]

Meant to include, seems to happen during some type of button pressing. Have noticed a couple times that it's happened when switching to BVR after take-off.

Consistent CTD in multiplayer. Not a matter of if but when - sometimes it won't happen for an hour which is the longest I've seen it work without issue. 00417.813 INFO EDCORE: # -------------- 20160319-010911 -------------- 00417.813 INFO EDCORE: 00417.813 INFO EDCORE: # C0000005 ACCESS_VIOLATION at 3FCC8415 00:00000000 00417.815 INFO EDCORE: 00000000 00000000 0000:00000000 00417.815 INFO EDCORE: 3FCC8415 0024ECD0 0000:00000000 00417.816 INFO EDCORE: 3FE459CC 0024EFE0 0000:00000000 00417.816 INFO EDCORE: 3FDE21BE 0024F030 0000:00000000 00417.816 INFO EDCORE: 3FEC3520 0024F060 0000:00000000 00417.816 INFO EDCORE: F7896CEF 0024F0E0 0000:00000000 00417.816 INFO EDCORE: F7897235 0024F130 0000:00000000 00417.816 INFO EDCORE: 40008068 0024F1A0 0000:00000000 00417.817 INFO EDCORE: 4000CA35 0024F200 0000:00000000 00417.817 INFO EDCORE: 400226A4 0024F230 0000:00000000 00417.817 INFO EDCORE: 400225F4 0024F260 0000:00000000 00417.817 INFO EDCORE: 400C756C 0024F910 0000:00000000 00417.818 INFO EDCORE: 400CABC5 0024F950 0000:00000000 00417.820 INFO EDCORE: 779059ED 0024F980 0000:00000000 BaseThreadInitThunk()+D 00417.820 INFO EDCORE: 77B3B371 0024F9D0 0000:00000000 RtlUserThreadStart()+21 CTD Message: Problem signature: Problem Event Name: APPCRASH Application Name: DCS.exe Application Version: 1.5.3.51218 Application Timestamp: 56e4490c Fault Module Name: DCS.exe Fault Module Version: 1.5.3.51218 Fault Module Timestamp: 56e4490c Exception Code: c0000005 Exception Offset: 0000000000028415 OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 1033 Additional Information 1: f3ac Additional Information 2: f3ac2eba13701109f6bdac83aba074c3 Additional Information 3: 43f9 Additional Information 4: 43f9c822ec54b4f61c54645af8eb153b Windows 7 64bit, i5-4670k, 16gb ram, gtx760. crashdump.zip

forums.eagle.ru says "you cannot give reputation to this post". Ok, I'll say thank you Frostie then. Solved a headache.

Pilot Callsign: иɪɢнтмдяᴇ - Preferred aircraft: Su-27 / F-15C - Nationality: Canadian - Location: Western Canada - Confirmation of availability on Saturday 16th of January 2016 from 1800z to 2200z - Confirmation of availability on Sunday 17th of January 2016 from 1800z to 2200z - Confirmation that you have read the rules posted on:http://www.sa-sim.com/wp-content/for...hp?f=39&t=2816 Check, Check, Check.

When it's working there seems to be 4 pages or modes for navigation. 1. Blank (no destination but navigation information displayed) 2. ENR 3. RTN 4. LNDG As described, after re-spawning ENR mode disappears. **Spawning in a different player slot put ENR mode back (at least on 104th).

Woke up this morning to this. Sat down with my coffee and I've seen the download speed jump to 10KB/s in breif spurts yet the "1013.2" has not budged in the last 10 minutes. If I hit cancel does it re-download the entire file?

Uploading at speeds up to 200kb/s and downloading from 0.5 to 30 kb/s. Been running for hours now.

In my case yes. By doing this the frame rate here does not drop at all when firing missile zoomed in fully with cockpit resolution @ "1024 every frame". It seemed like impact had something to do with it for me as well but it was the accumulation of smoke and it's dispersal pattern that was killing the frame rate.

Using JSGME this mod still works in DCS 1.5+ however the add radio item in mission editor becomes broken. Disabling the mod returns the ability to add radio item to coalition / group. Been poking around trying to figure it out but no luck yet.

Problem still exists in 1.5.0.45208.37 Figured out how to remove smoke (well sorta) from only the vikhr. Posting the information for anyone else struggling with this. Purchased the BS2 module a few weeks ago and would rather continue to use the beta until this problem is addressed. Seems better than having the shkval look like a coleco vision display. Make a backup of... blahblah\DCS World OpenBeta\Config\Weapons\schemes\missiles\vikhr.sch Open the file with Notepad++ and alter the values to those shown here. @ Line 105: ["nozzle_position"] = { ["value"] = { [1] = { [1] = -1000, [2] = 1000, [3] = 1000, @ Line 117 ["smoke_transparency"] = { ["value"] = 0, @ Line 129 ["tail_width"] = { ["value"] = 0, @ Line 151 these subsections appear again - I changed those as well. This effectively pushes the smoke very far away from the missile - and makes it completely transparent so it's not seen. You'll see zero smoke - which is weird, but this doesn't change smoke from any of the other missiles which is good. SAM launches, air to air etc is unaffected. If a video of the frames dropping from 130 solid (with shkval zoomed in fully) to less than 20 would help anything I'll post one to youtube. Perhaps the drop is not as severe on all computers but there's obviously some issue with the shkval displaying smoke. Zooming into the smoke trail fully from the pilots perspective with the shkval turned off does not change the frame rate... It's the combination of the two that's killing the frame rate. This high tech representation shows how the shkval stares right down the line of fire of the missile - rendering all the smoke at zoomed in levels. New Bitmap Image (3).bmp

+1

Spent a bunch of time poking around the files hoping to find a temporary fix. Haven't really had much luck. I'm not aware of a way to edit the smoke effects for vikhr only. The issue is the shkval but figured it would be a quick fix until the issue is addressed. There is a way to reduce the smoke until it had almost no impact on FPS however it also reduced smoke on missile trails from SAM's which is undesirable. Altering this line seems like a happy medium between seeing the smoke and not dropping to 20fps if fully zoomed in. defaults to 5. Zero does work but removes all smoke trails. [DCS World folder]\Config\Effects\ParticleSystem2\smokeTrail.lua detailFactorMax = 2.5 During the testing I've noticed a few things. It's when the shkval is zoomed in fully that it's an issue. If you use wider view the FPS hit is negligible. As such I've started to get into the habit of immediately zooming out after the missile hits to recover a stable frame rater faster. There is a combination of particle effects that dip the frames. The smoke trail from the vikhr is the biggest fps killer. There is also a smoke plume after the strike that lingers for a few seconds that hits fps but nowhere near as bad. Perhaps there's a way to not render all those particles inside the schval view screen without losing much.

Chat Window: "Join requests" Since the latest hotfix (1.5.1.46722) this join request box is attached to the chat box. Haven't been able to get rid of it, clicking the allow or deny doesn't do anything. It's a bit obnoxious and in the way. Probably not the only one who leaves the window "open" while flying. Hopefully this isn't a permanent addition to the chat box? No idea who Chizh is.... It's filled with the same name each time.

Same thing with a dual setup. 2 x 1920x1080 monitors.

Lighting from illumination flares and search light aren't shown on the Shkval in a way that's expected. Screen shot 1: The area the Shkval camera is pointed at is lit by the search light. Screen shot 2: When turning your pilots view angle the area is no longer lit in the view screen, even though the camera and the search light have not moved. This also happens with illumination rockets. The problem is much more pronounced when in flight. Searched forum for "shkval lighting" and came up with nothing. Apologies if this is already reported or something that's existed from pre 1.5.

Did some testing on instant action (Ka-50 shooting range). 130 fps stable drops to as low as 25 when missile approaches target then slowly recovers. To confirm what Feuerfalke said, turning off shkval mid-flight instantly restored frame rate as mentioned. Also.. Doesn't matter if you look somewhere else (turning completely away and looking at the back of the cockpit for example). Even when using F6 to follow missile the frame rate is effected in exactly the same way. Changing "Resolution of Cockpit Displays" helps. From 1024 --> 512 improved the drop from -100ish to -50ish. When set to 256 it was more like -20.