Gunrunner

Let me guess, it will be a 100mn F-35 infomercial.

Oh but you see, it's all Windows 10 now, for all eternity, meaning that things that worked and were certified for Windows 10 two years ago no longer work with Windows 10 as it is now, and things working and certified with Windows 10 now are not guaranteed to work with Windows 10 next year, unless you don't do any update at all, except for some reason you can't escape some updates... that's progress you see, and clear, pertinent information for the end user. Dropping retro-compatibility between major releases is one thing, but dropping it within the same major branch and not clearly documenting it or letting the average user opting out of it ? That's pure, unbridled genius Microsoft...

You're right, it doesn't make sense for it to be the CG, guess this is a confusion with the other red line in the source I found (or, just as probable, I got confused).

As far I know you are correct, the red one is the center of gravity of the tail assembly, the black lines are where the tail is supposed to meet the dolly used to roll the tail away (supposedly because they are the sections able to withstand the tail assembly weight), see this : .On some planes there used to be another red line behind the canopy denoting the aircraft's center of gravity, probably to help when having to crane them for shipment or something.

Nope, not updating to 10, not even because of that.

What could possibly go wrong ?

Maybe just the same pod with differing designation depending on the service or... Manufacturer produces rocket pod A with etching with that model number on part 1. Manufacturer has contract to produce similar but slightly different rocket pod B, of a design similar enough that part 1 is the same. Does manufacturer change production line, uses two references for the same part, has two reference for spare parts, maintains two stocks or just uses the same part for both pods ? I'm not saying this is the case here, but that's been known to happen in other industries.

Oh by the way, another way to solve the AA quality with 10x0 nVidia cards, unless you already run at high resolutions, you could use Dynamic Super Resolution, in effect it renders the frame at a much higher resolution then downsample them to the screen resolution, offering better AA, better details. In my experience with a 1060 and 1070, it does so while offering better performance than fixed resolution and "classic" AA up to twice the native resolution. The reason the 10x0 have a problem with AA and some shaders on older games is simply that they are DX12 optimised, with some DX11 heritage but are starting to drop DX9/10 support, going as far as not supporting some DX9/10 functions in hardware anymore and emulating them in software in the drivers instead (which is not specific to nVidia or this generation of GPU, it's been the case for everyone for quite some time).

If it is a question of sharpness, it's more probably a question of settings than hardware performance, maybe try to contact these people to know which graphic settings they are using and whether or not they are using custom shaders and environment/flightengine.inis Optimising your hardware choice to get the best ouf of SF2 is becoming hard, but a lot is still a matter of configuration.

It won't benefit from it, at heart the SF2 series is a monolithic game, the latest patches do offload some minor tasks to other cores but at least 90% of the work is still done on only one. You would benefit more from having the best single-core performance you can afford. Keep in mind that many modern CPU get increased performances through optimised path and instructions that would not benefit to SF2 because it never was compiled for it and relies on API versions that do not benefit from them either. Considering the same principle applies to GPU, you might end up in a situation where older, "slower" hardware might get you better results than newer, faster one (or require high-end parts to see significant improvements over what was middle of the road hardware). If you look at benchmarks, compare DirectX9 (eg. 3DMark 06) or DirectX10 (eg. 3DMark Vantage) ones, anything above that is not an indicator of how useful it will be to SF2.

Translation : "We have so much riding on that thing that we are fine with lying a bit to ensure the program goes on as expected." Seriously, it's so over-the-top it could be a Trump speech, that's how you know it's bullshit.

Welcome aboard and sorry that I'll have to be a smart ass for your first post but... You do realize that the real thing probably never reached that speed at sea level, right ? Most aircrafts top speed, unless otherwise stated, are given "at altitude", never at sea level by default. I would suggest getting back to the stock ini and trying, let's say, around 15000/20000ft which is probably the altitude for the documented top speed. Lower is unlikely and would mean a far higher top speed speed at altitude. Higher is also unlikely as, starting at 30000ft it would make it supersonic, which the Yak-25 was definitely not in level flight. As a rule of thumb for planes of that era, at low altitude you reach lower speeds than at medium altitude due to atmospheric density (meaning higher drag, in part due to far from perfect aerodynamics), at high altitude you reach lower speeds than at medium altitude due to underperforming engines in a less dense atmosphere. Also keep in mind that the higher the altitude, the lower in km/h the Mach number. At sea level in a standard atmosphere, Mach 1 is about 1225km/h. At 20,000ft, it's about 1138km/h. At 30,000ft, it's about 1090km/h. From 40,000ft and, for all practical purposes, above, it's about 1060km/h. So, did 850km/h at sea level for a Yak-25 sound right ? Yeah, definitely... Does 1000+km/h at sea level seem entirely unrealistic ? Definitely.

Whoever wins the election, the only thing sure is that the US "democracy" and US citizens will lose, as will the rest of the world.

Title says it all, I was trying to identify a freeze crash my father was having when free flying, turns out he was running into The Wall and, instead of the usual song and dance, the game freezes with audio stutter. I've reproduced it with a few modded installs on 3 different computers so far (except the audio stutter on one), but not stock installs, anyone else can confirm ? P.S. : Apparently it's tied to custom FLIGHTENGINE.INIs.

Hi back then, sorry I snapped at you earlier, but in the last few years we've had our share of indelicate modders and scam artists, so some of us are more suspicious than others, but I was wrong and I'm glad.

Proving me right once more, I quote, starting from 4:44 : "Games such as Wing Commander or Test Drive III however run way too fast. To turn the machine into a 386 we access the BIOS and disable both the processor cache as well as the motherboard cache; Now Wing Commander and Test Drive III will run just fine.[...]To turn the machine into a 486 we disable only the processor cache but leave the motherboard cache enabled; This is a great settings for games that run too slow on a 386 but too fast on a Pentium; Theme Park is such a game." At no point is it suggested it's a problem with cache, but with execution speed. It's not a cache architecture incompatibility, it's an instructions-per-second problem. I'll admit it makes it not truly a clock speed problem either though, but since some games are actually clock-speed sensitive, it's a better bet to use underclocking than cache starvation to tailor performance for old games, it's also a much more fine-grained solution, provided your hardware supports it of course.

For early DOS games (from the 8088 to the early 486 era), the issue is very much clock speed as many just assume a clock speed and don't compensate, making them stupidly fast on modern hardware (they were already too fast at the time). When it comes to cache architecture I'm not aware of any game having problems with that but I'd be interested if you have the time to give me a few examples.

Nope, no problem at all with old games (most emulators allow you to adjust clock speed and CPU identifiers to suit your needs), emulation and virtual machines have come a long way lately. It's really only a handful of titles from between 1999 and 2006 which are problematic because they expect direct access to GPU functions no longer present in modern hardware, but even that is becoming less of a problem, some have already been updated for Steam or GOG re-releases, others have wrappers in the work. I'm no stranger to replacing components but it's just not worth the time and effort, especially considering capacitors might be only the most obvious problems. If anything else fails, you are up for hours to days of figuring out the problem, sourcing the replacement, nah, it's not worth the hassle anymore unless that part is what you find enjoyable, which is perfectly fine but no longer my cup of tea, and I have enough hardware around already.

Yes, "conductive" dust is mostly bullshit but in my experience that happens under two conditions : - Industrial / workshop environments, but even then I've seen it only twice in over twenty years. - In homes where people both smoke and have pets, but not because the dust is conductive per se, but because the combination of cigarette smoke and pet hairs make it clump and stick and acquire enough static electricity charge under some circumstances, if that happens in the right place, it can do damage. My sister used to kill a motherboard a year that way (that one was fun to figure out and led to my practice of favouring multiple low-power fans over single high power fans). By the way, the later is the only case of damage by static electricity I've had; In my experience, unless you go out of your way to demonstrate it or are very careless, it doesn't happen in the real world and grounding yourself is mostly a ritual inherited from when you dealt with individual electronic components rather than complex hardware. I favour low-power vacuum cleaning with a plastic end and brush not building up static electricity myself (just in case, because there is potential for real damage... get it, potential), it removes the dust just as well and doesn't send it flying to make everything else dusty and it takes barely longer for a much cleaner overall job.

Suspects a problem with conductive dusts shorting something; Proceeds to blow the dust around. Utterly brilliant. Oh, I forgot, suspects the problem is with the PSU, but doesn't remove and clean it... The way it's mounted, it's sucking air from below, with pets it's a recipe for disaster, at the very least the filter needs to be cleaned, at worst it's not filtered and the PSU needs to be cleaned.

Especially considering that most legacy had - by modern standards - crappy components (capacitors notably), making it difficult to find legacy components being cheap, stable and reliable at least for a few years. Nowadays, with the exception of a few titles from the late Windows 98 to early Windows Vista, everything works acceptably through emulators and virtual machines.

Don't worry, I didn't feel attacked or offended, I perfectly understood where that came from and entirely respect it (even though I'm suspecting I missed a post before the thread was closed, but hey, I'm no stranger to being abrasive). In fact my initial response came from the exact same place, because what the community doesn't need is more drama and modders with shady ethics; Fortunately it wasn't the case here as far as I've been able to determine, everything seems clean and legit, and I've said so after checking. The main problem is that the code was not particularly optimised and modern at the time of release but there were enough hardware bottlenecks that it wasn't showing much but we reached the point where the code has become the bottleneck.

Fubar512, and ? nothing in your copy-pasta actually proves your point... Before the advent of hardware 2D acceleration were all 2D games "faking" it ? Were they truly 1D games, despite using 2D coordinates and 2D sprites ? Are you also suggesting that 3D Studio, released in 1990, was not "really" 3D ? What makes a game "true" 3D is a positive answer to both these questions : - Does the game manage the position of the player and objects in the game world in three dimensions ? - Are the objects in the game world dynamically created from a mathematical/algorithmic three dimensional representation ? Let's consider the implications : - A game where the world is built in pre-rendered 3D, and actual 3D objects move and are scaled around it (e.g. Grim Fandango, Little Big Adventure, Total Annihilation) ? "Fake" 3D - A game where the world is built in true 3D, but where objects are 2D sprites, either classical or pre-rendered 3D (e.g. Wing Commander I, II and Privateer) ? "Fake" 3D - A game where the world is built in true 3D and where objects are dynamically rendered 3D objects (e.g. any of the games I cite, including Elite and its primitive wireframe system, but also the original Battlezone) ? "True" 3D Whether the game also include sprites for effects, or a 2D foreground for instruments, cockpit (unless you really want to argue that early DCS games were not true 3D games due to their 2D cockpits), weapons etc, is irrelevant. What is even more irrelevant is whether or not the objects are textured or shaded; a simple transparent wireframe (1980's Battlezone) is enough to qualify as 3D. Even more irrelevant is whether the calculations are the result of software executed on the CPU, low-level calls to the GPU, API calls offloading it to a GPU, or a combination of the two. It could be run by an army of monkeys and inputed back through punch cards, that wouldn't change the nature of the algorithms. Does 3D acceleration hardware allow for better and better looking 3D games ? Certainly. Are they a requirement ? Hell no.

Good one Gepard, the first plane I made for it was a Mirage 2000. It was 1993 and it was very much 3D. @ Blaze95, true but some voxel games were weird, which one I can't remember but they weren't using a true 3D world representation but 3D objects, I remember an action RPG but not its name.

@Fubar, oh, thanks, I forgot Falcon 3.0 in that list, and by the way, you couldn't be more wrong. Let me see, according to your conception of a "true" 3D game, if you played Mechwarrior 2 in its software-rendered version the game was 2D, but play it in its Mystique or 3Dfx version, only adding effects and not using a rewritten engine, and suddenly it is a true 3D game ? I know, you'll pretend that since they were different versions they weren't the same game thus making your point, regardless of the actual nature of the code. Let's take Unreal then... Are you suggesting that in software mode it is a 2D game, but activate Glide and it suddenly is a 3D game. You are trolling me, right ? You have stupid ideas at time, but I've not known you to be that out of touch with reality. 3D game doesn't mean it is using hardware accelerated 3D, just the way it manages spatial positions of objects and the generation of polygonal objects (excluding some "sprite in a 3D world" games - early Wing Commanders and LucasArts sims - as well as some voxel based games which weren't really 3D). Come on, even Julhelm pointed out your mistake. Oh, and let me add yet another example : Elite, 1984