Sideslip

My god you're hostile! But seeing the same rude attitude with your replies to draconus's other thread I'm not surprised. That or you just enjoy sarcasm a little too much. I know you don't want to hear it, but I'm actually going to type some of my thoughts and opinions into this here box. I know you weren't braking in your test. But that's what 90% of the thread is about. Otherwise I wouldn't have gone on to talk about braking... While you say you aren't talking about locking the brakes and skidding... that is far more likely to cause a tire failure than overheating. The whole point of the thread was what is causing tire failure on his landings (and then could braking too hard do it). If you cannot come close to locking the wheels (which in the 25 you absolutely can't), you probably cannot create enough heat to blow the tires anyway. When you see an airbus blow a tire with the brakes flaming, it's because it has (and was using at the time) an anti-skid system so it can apply maximum braking force without locking the wheels. That tremendous amount of energy is what overheats the tires, not gently braking (again, what the 25 does). If it didn't have an anti-skid, it would possibly lock one or multiple wheels, which would still cause tire failure, but those brakes would not be overheated. So the 25 can't lock up, that's one way it's brakes can't cause tire failure. It also can't brake very hard, so it's unlikely they can overheat the tires. That's the only two ways brakes can cause a tire failure ruled out. So brakes on the 25 can't blow a tire, therefore the only other two things are hard landing or skidding. Pulsing the brakes, brought up in this thread, is completely unnecessary. And while Ironhand did test landing at max gross, he did not do a complete braking test to determine if brake temperature is modeled. All he did is verify that the brakes are capable of stopping a fully loaded aircraft without failure, not that they cannot fail. That's why I suggested what I did, as it's the maximum amount of brake energy that you could create on the 25 within the limitations of the sim without causing failure by rolling at ridiculous speeds. Again, I doubt they modeled that anwyay. I wasn't twisting your arm to do the test, nor was I suggesting that you and you alone have the responsibility of proving it. I have no desire to do it because I never blow tires so it really doesn't matter to me. But if someone else really wants to find out if it's possible, that's how. While my comments are rarely addressed to one sole person (I don't provide 15 quotes for each and every topic I discuss), you yourself did specifically say not to brake too hard on the 25 or you will lock the brakes. You can't lock the brakes. It does not lurch to one side, there are no differential brakes on the 25 in DCS and there is no other way for that to happen with regards to braking force in a straight line (you certainly can with steering though). You cannot overheat the tires through braking (to the extent that Ironhand tested). While these are concerns that may exist in the real world, and I don't fault you for expressing them, they don't exist here.

The shaking was added just a little before 2.5 IIRC. It's just for "immersion". It's supposed to make you "feel" the runway/taxiway. If I was shaking the bad in a real aircraft while taxing on pavement I'd take it back to maintenance or never take that taxiway again. It's the same as getting the shaking when getting hit or being near an explosion, nothing changed as far as the aircraft is concerned. I personally hate the vibration because at frame-rates under 100hz it's almost nauseating. I wish programmers and game designers would realize that you can't shake a virtual camera in the way you might get shaken IRL. The frame-rate affects that movement you see in a very negative way. I've flown the 25A and 25T plenty since they implemented that and I've not broken the steering once. The 25's nose wheel has always been very fragile. You cannot make sudden movement of the steering and you cannot take turns fast. If you are breaking the steering on crosswind landings either you are exceeding the crosswind limitations or you are being too rough with rudder inputs. Also, don't use the drag chute with strong crosswinds.

If you guys really feel the need to test it, go find the longest runway on a hot day, load up to max gross, take-off, land at the proper speed (10degrees AoA) and apply the brakes as soon as you put the nose wheel down, then increase throttle to maintain that speed under braking for the entire length of the runway. If you go off the end of the runway before you blow a tire, you will never blow a tire due to braking.

SU-27 brakes are much better than the 25, but unless it's a slippery runway I don't think you'll ever lock them. I have no problem using full brakes, though I have less experience in the 27 than the 25. Another thing to consider is the 27 is almost exactly twice the weight of the 25A (max gross) and 13500kg heavier than the 25T. So even if blowing tires due to breaking were a thing on the 27, it has both higher weight and much much stronger brakes (stopping more weight much faster).

Guys... really? Come on. Take your car down a road a 500kph and see what happens. That has nothing to do with weight or braking or temperature, you are twice as fast as what they are designed for and literally blowing them apart. You should never be on the runway over 300kph. You shouldn't really even have your gear down bellow 350kph, and I'm pretty sure (it's been a while since I tested it) over 450kph you are going to damage the gear just from having them down in flight. The brakes on the SU-25 are pathetic. You could almost brake faster by sticking your arm out the window. You cannot lock the wheels unless you are basically still flying and only have like 500kg on the runway. I don't know if brake temperature and failure is modeled in the game (I doubt it is), but in the last maybe 50hr or more of flying the 25 and 25T I have not blown a tire. I do not use the drag chutes unless it's a short runway, I apply brakes as soon as I lower the nose wheel, and I do not stop braking until I am at a safe taxi speed. Basically on every landing brakes come on around 230-250kph and are on down to 30-40kph. The only way you are going to blow tires on the su-25 are from slamming it on the runway or from sliding. If you slam the rudder to one side you will slide the nose wheel (it turns instantly). If you want to make a sharp turn, you have to smoothly and slowly increase the nose wheel angle, and the same goes for stopping a turn. The maximum landing weight is there for safety, but does not mean the plane can't be landed above that weight. When a maximum landing weight is established, it is done so for average pilot skill and allowing for difficult conditions. If you put the plane down gently, you will not damage it.

The people who think 4k makes it too hard to spot other aircraft have never had the opportunity to try and spot another aircraft while in flight. It's not nearly as easy as armchair pilots think it is. Also, the advantage that lower resolution had in that regard is no longer a thing. Lower resolution makes pixels bigger (on a screen of the exact same physical dimensions), and if an aircraft far away is being displayed as 1 pixel, it will be easier to see the pixel on a lower resolution screen. That said, 3d images aren't that simple. If the aircraft takes up 1 pixel on a 4k screen, then it will take up 1/4 pixel on a 1080p screen. A 1080p screen cannot display 1/4 pixel, so either it will flicker and be visible 1/4 of the time, or it will be averaged 1/4 the aircraft pixel color and 3/4 the background color if anti-aliasing is turned on. So really, the 4k screen would be easier to spot a target with if you have really good eyesight and the screen is of a reasonable (ie LARGE) size. To get a realistic chance of spotting the aircraft, you need to make your FOV the same as that which your monitor physically occupies in the real world. At the distance I sit from my screen that is roughly 50-60 degrees. However, in the real world I can see a lot smaller than a single pixel of my monitor, but I would have to know exactly where to be looking with really good contrast too. DCS used to have a really bad problem with LODs. The lowest level was just a box, and the color of the box wasn't exactly accurate. Aircraft changed to the lowest LOD way too close too, which made them almost pop out of existence. Actually, some helicopters still do this but they usually change to a black box which can be somewhat easy to see depending on the background. I've noticed now that the lowest LOD seems to be much more detailed now with more shape and color, which means you can actually still identify what it is (big jet, small jet, helicopter etc) from far away. The higher the resolution of the monitor, the better this will be. And I've also noticed (on the nose of my wingman) that bright reflections are being applied as well, so depending on the angle you might get a glint of bright sunlight off the target (same thing helps you spot aircraft IRL). There are three main things for you to consider: 1) If you want 4k you NEED a bigger monitor. DO NOT BUY ANYTHING SMALLER THAN 30" IN 4K! Yes the image will look really "life-like", which basically means you won't see most of the small details unless you stick your nose on the monitor anyway. I have a 1440p ultrawide which is about a 27" equivalent and sitting at 70cm I do not see individual pixels. Would a little more resolution be nice? Sure, but the difference would be very very small. Really, I would want both more resolution AND a bigger screen for the reason that I could have a similar FOV in the game as I see IRL, which means better target spotting without needing to zoom-in as often. 2) 4k will require a lot more horsepower... 4 times as much as 1080p. So if you get 60fps at 1080p you will get roughly 15fps at 4k (provided your GPU is the limiting factor). Also, despite what anybody says, 4k does not remove the need for anti-aliasing. If you run the anti-aliasing test on blurbusters.com you can stand 15ft from your monitor and you will still see aliasing artifacts, even though the pixels are so tiny at that distance that you cannot possibly perceive them. So you will still get flickering or shimmering on brightly lit buildings in the distance unless you turn on AA. And AA is VERY VERY expensive in 2.5. Coupled with 4k, you need at least a 1080ti to run that at reasonable frame rates. 3) On the positive side, if you find you cannot run 4k very well you can perfectly downscale to 1080p on a 4k monitor. Because the monitor can use exactly 4 pixels to draw 1 pixel at 1080p, it means that it will look exactly the same as a 1080p monitor would. So you can easily switch resolutions based on what game or program you are running, with no blurriness caused by non-native resolution. In my opinion, the sweet-spot of resolution and performance right now is 1440p. If you can afford to buy the absolute latest GPU hardware then 4k can be good. I prefer a higher frame rate ESPECIALLY when using something like trackir and in any game that involves fast motion. You can get life-like resolution with a small 4k monitor, life-like FOV with a large monitor, life-like fluidity of motion with a 240hz 1080p monitor (CPU bottleneck is an issue), or you can get the best compromise with a 1440p ultra-wide >100hz monitor.

I keep hearing about this and it must suck, but funny enough my MCG (not pro) on my Gladiator MKII base works perfectly. I've probably spent at least 8 hours flying with it in DCS and never once had an unwanted button press. Only issue I had was with the 16-tempo limit (I'm using 24) causing weird things to happen, but with the C version firmware that's no longer an issue. I would have thought if there would be any serious problems with firmware it would have been the Gladiator, as it is older and has a ton of it's own buttons where as the Gunfighter is just a gimbal. I'm curious if you've ever tried changing USB ports/types or a powered USB hub. I had ghost presses with my X-55, and using a powered USB hub solved that problem (before that, working the USB ports like a 1940s telephone switch-board sometimes worked).

No offense, I have many times been just as sure that I have done everything right, but in such a tight space with all the movement inside the gimbal it doesn't take much to cause a problem. Sometimes it pays off to observe the operation or movements of something both before fully taking it apart, and then before closing it up. I'm glad you found the problem, and can now properly enjoy your stick :thumbup:

Springs are going to have nothing at all to do with it. The cams also likely have nothing to do with it. Just for shits and giggles I very imprecisely measured my Gladiator. From the thumb button it moves about 2 1/8 inches left and right. That is about 5 inches above the stick base. Considering you are using an extension and only measure 2 inches on one side, which is the same as my non-extended gladiator at 5 inches, and zhukov032186 reports 6 inches (guessing he means total, making it 3 inches each way)... you have a physical obstruction. Either you miss-assembled it or it is hitting something else. I don't know about the Gunfighter gimbal, but the Gladiator Pro's gimbal hits metal stops at maximum travel, it has nothing to do with the cam. All the cam does is regulate the amount of force the spring transmits, there is no "stopper" on the cam. If you somehow came past the limit of the cam, the bearing would just roll off the end, then it would be stuck. On the side where the cam is bolted, it would probably just become increasingly harder as it got closer to the bolt, there would be no sudden stop. My guess is you installed something backwards, have a screw/bolt or wiring obstructing internally, or wherever you have your stick mounted the shaft is probably hitting something.

:megalol:

That was a different problem. If you fired that missile and then tried to re-adjust the laser position, the missile would impact nowhere near the laser, normally a few km behind. As mentioned above, it seems that the real SU-25's laser is not ground stabilized when moving. Because it slews very slowly when locked, it basically moves with the nose of the aircraft.

Just a note that CCRP always works for a single drop. It is only when dropping more than 1 bomb at a time that it glitches. Unfortunately, CCRP is most useful when dropping multiple cluster munitions.

Because of your resolution, it might be due to lack of VRAM. The 1080 has 8GB which is very good, but 4K (which is the same as 4 1080p screens) can certainly use a lot of that. If you can monitor your VRAM usage that might give you a clue. If it is pegged near 8GB all the time, that could be an explanation for the stutters. Other than getting a better GPU, all you can do is try to reduce VRAM by A) Reducing textures B) Reducing or turning off MSAA C) Reducing resolution. Also, some people claim that SSDs will fix stutters, but SSD aren't that fast compared to VRAM. An SSD can reduce hitching (very noticeable pauses greater than half a second where a HDD would be loading information into memory) but I have my doubts about any effect on stutters. Just to clarify, there are 3 types of "stutters". Micro Stutters: Extremely short skips or jitters that may go unnoticed unless you are looking for them, clearest when watching very smooth motion (like looking down at the ground as you fly straight and level). This is usually a frame-time issue related to Vsync delaying a frame irregularly and is worse when between refresh rates. IE on a 60hz monitor... 31-59fps. 59fps with Vsync will cause a micro stutter once every second. Stutters: Longer than micro stutters but still very short. Like the CPU or GPU had a hickup. Can be due to system resources, CPU at 100%, VRAM or RAM having to load lots of information suddenly. Hitches: Basically big stutters. Can be a programing problem, greatly insufficient system resources, HDD trying to load lots of textures or other information suddenly (think quickly turning your view 180 degrees and FPS drops to 2 for a second). In the HDD scenario an SSD would reduce it to a small short stutter. EDIT: Also noticing you are using a dome screen, FOV can put a greater load on your system. The wider the FOV the greater the CPU has to work to prepare the scene for the GPU.

If you aren't already, when CPU bound like that a 10% CPU overclock will give you almost exactly 10% more FPS. I think you were at 4Ghz, so if you can get 4.8Ghz that would be 20% (takes 50fps to 60). I've had my 3820 (3.6/3.8 stock) over 4.5Ghz since the day I got it 5 years ago, currently running 4.75Ghz.

Something along these lines could help solve your problem while continuing to use that laptop provided it is not ancient: https://www.makeuseof.com/tag/everything-need-know-external-gpu/ https://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Order=BESTMATCH&Description=egpu&ignorear=0&N=-1&isNodeId=1

If that's the case, I have this USB stick that when plugged into a USB 3.0 port will give you 10% more FPS and sharper anti-aliasing than 8XMSAA. It's yours for only $100. :shifty: I could see how moving past 8GB would decrease some stutters. I have 16GB and normally I see a usage between 8 and 12GB, so that little bit extra might make a difference.

From my other somewhat incomplete thread:https://forums.eagle.ru/showthread.php?p=3388898#post3388898

Those are what we call "flat shadows". The low sun is casting long shadows on the trees. Those shadows do not conform to the shape of the terrain and are sticking out on the horizontal plane. If you view them from above it looks fine, from bellow... well you can see that. If you set terrain shadows to default and have shadow quality set to low, med or high, the closest trees will have proper shadows that don't stick out like that. However, even on highest setting the trees that are just a tiny bit further away will still do that. I don't know if ED can make it so that flat shadows are orientated according to the angle of the terrain the object is placed on. Even if they can, that won't 100% eliminate it as it's possible for the trees to be at the top of a hill and then have the shadow stick up off the peak. I don't know how much of a performance impact that would have either. Or it could be that their shadow engine doesn't know how to deal with being viewed from bellow. In the meantime, avoid flying bellow trees during dawn/dusk if it bothers you too much.

*Sigh* This is not correct, it is an assumption you are making possibly on past experience. I can definitively say DCS 2.5 will use more than 1 core. How much more? That depends on your fps and situation, but I see steady 20-25% CPU usage with spikes up to 75% out of 8 logical cores. Every 12.5% = 1 core. That's not thread-hopping or whatever you want to call it. I don't care how loud you want to scream "DCS is single threaded", it's not true. Is the entirety of the engine completely multi-core? No it's not. Can you get constant 300fps (looking at the sky on an empty map doesn't count) on lowest settings with 2 X 1080ti in SLI and a 10-core CPU? No you can't. But to say DCS does not use more than 1 core is just plain wrong. If you disable all but 1 core of your CPU, you will definitely lose fps and probably will experience severe stuttering/hitching. Edit: There, open your eyes and look. 17% with only 1 core (4.5% is probably background tasks) and 28% with all cores assigned. 10% more CPU usage or just under a second full core. 86fps with 1 core, 99fps (GPU maxed out) with all cores. You can go ahead and do your own benchmark with min settings and uncapped fps. I'm not wasting my time on it.

It's funny, when CPU usage is low people complain it is using too much GPU power. When CPU usage is high they complain that the CPU is working too hard and it's destroying their computer... obviously having no idea how a computer works. The CPU is what prepares frames for the GPU. The higher the fps, the more the CPU has to work and the more work the GPU(up to 99/100%) is doing. If you want more fps, you can usually lower setting so the GPU can work less per frame (still 99/100%) and the CPU will work harder. If you want 200fps you want the CPU working as fast as possible up to 100%, but most games (it is improving) can't use that much so then you end up with 25%CPU and 80% GPU and 150fps which is whats called a bottleneck. If your fps is locked at 60 and your GPU is only using 80%; Game is working PERFECTLY. If your fps is fluctuating but your GPU is at 99/100%; Game is working PERFECTLY. If your fps is fluctuating and GPU is 80%; You have a bottleneck likely the CPU and is doesn't matter one tiny bit that it is only using 20%. /ENDall"cpuonly50%gameisbroken"foralltime

Unfortunately, I think this is a problem with the way most 3d game worlds are rendered. It's most obvious when you can see long distance to the edge of what is rendered, especially when things like fog are in play. Basically, the world being drawn on your screen is a box (cube technically). Everything outside of that box is not drawn. Being a cube, the corners are further away from you than the flat side directly ahead. So when you turn your view, you can see farther at the sides. I have seen this in TONS of games, so I don't know if there is a way around it or not. There may be some technical or performance related reason for not using a sphere or cylinder.

No, what you had was EXACTLY microstutter. I watched your video and you did not have stuttering, and THAT is "pauses caused by spikes in the cpu while its loading something or doing some other work". You had micro-stutter probably because your framerate and refresh rate were completely out of sync. 60 fps with a 63hz refresh will mean that 3 times per second your monitor repeats a frame, which means that 3 times per second an object that your eye was trying to track is not where it was expected to be. That is a micro-stutter. You have "fixed" it by returning to 60hz, but the problem will forever exist unless you have Gsync or Freesync... or have a 500hz monitor (doesn't exist unfortunately). If you lock your framerate with a frame limiter to say 58fps, you will see exactly the same thing. Go ahead and try it.

I don't think you fully understand whats going on. Problems with your observations: 1: Just because you don't see the other trees, doesn't mean their shadows aren't being computed. Yes you can only "see" a couple trees, but there are almost certainly 10-20 more hidden at the top of your picture. 2: If you have grass enabled it is a big load on the GPU. Grass it not drawn beyond a very very short distance. When you bring the camera in tight like that, your GPU is working to draw that grass that it wasn't drawing when there were hundreds of trees on the screen. So tree/shadow workload decreased and grass workload increased. Result is no change. 3: All tree shadows are flat after a certain distance, and that is a very short distance. Sure you removed 90% of trees from view, but the 10% that are left are the only ones that had high quality shadows in the first place. 4: Zooming in increases the distance at which things are drawn. Zooming in on distant trees increases their quality and the shadow quality. 5: Shadow resolution dynamically gets higher the closer they are. Zooming in has the same effect. Shadows in any game have always been demanding, DCS is no different. Set the terrain shadows to flat and it is no longer a problem. And why do you insist on using high shadows and then complain about the performance? There is are settings for a reason. If you aren't happy with the performance, lower the settings. This is far from a bug. As per my pre-existing thread, if you are hell-bent on using default terrain shadows, using high quality requires a lot of horse power. Off | Flat | Low | Medium | High: P.S. Showing CPU and GPU usage without framerate is a little ambiguous. GPU load can remain the same as framerates increase signifying a reduction in overall load per frame.

Indeed, but that is a fact of life without using MSAA or SSAA (DSR also works but is even more costly). You won't see shimmering like that in Call of Duty 47 because there aren't as many thin lines. In DCS, you have such a long view distance that there are lots and lots of small lines being drawn with huge contrast (sunny apartment roof 5 miles away, low angle, against green background). Then the motion is very slow (because it's far away) which causes that shimmering as the color slowly alternates. There is nothing anyone, including ED, can do about that. The only way to address it is with higher resolution through MSAA (including MFAA), SSAA or DSR/Downscaling. FXAA can't fix it. The only other alternative is set view distance to low, but that's a terrible choice. You wont notice the shimmering 90% of the time when you aren't looking for it. If you are trying to shake a SAM, the last thing you will be thinking is that it'd be nice to have MSAA turned on.