homepage Forums Air Combat & Civil Aviation DCS World 2..5 Release Date ANNOUNCED!!

Not everyone is frustrated/angry with the current 2.5.1 release...

Wrong. The body naturally has fat cells. A very lean woman would have 14-20% body fat, the male equivalent is 6-13%. Do software programs naturally have bugs? I don't think so. But I see where you're going with that despite you deliberately misunderstanding my example. Let me put it this way --- a few small bugs may be annoying but would not be numerous enough or serious enough for the software to be considered buggy. One or two bigger bugs may not be numerous but may be big enough that the software is to be considered buggy. Where do you draw the line? I guess that depends on whether you're a fanboy or not and/or whether specific bugs manifest on your game due to software/hardware compatibility.

Now what's the explanation regarding the pages and pages and pages of bugs and issues with 2.5 on the ED forums? What's the explanation about the memory leak/allocation issue? You picking the only example that supports your argument and ignoring other evidence is just dishonest.

2.5.1 was released on the 28th of April (or maybe a few days earlier? I'm basing this on the newsletter) and if 2.5 is good and 2.5.1 is buggy, then I should not see any complaints or issues or bug reports on the ED forums prior to 28th of April, or at least the 20th of April. This is clearly not the case.

Well...one thing we all agree on is that DCS makes some of the best screenshots...many of us want a deeper, more functional/stable combat experience however.

Yeah, DCS should be called DSS instead!

DSS - Digital Screenshot Simulator

DSG - Digital Screenshot Generator

More binary thinking preventing discussion. If having a single bug means something is overwhelmingly buggy then there does exist any non-buggy software of significant complexity on the planet. The requirement that there be zero bugs is an oddly chosen bar.

DCS certainly is pass/fail based on your memory meeting requirements. I assume Weiss has 8GB and not 16.

it is not a hardware problem - as I use Photoshop for skin making I have 32GB RAM + 8GB 1080 GTX + M2 256GB SSD as scratch disk and installed DCS on a SSD RAID disk, DCS had some incompatibility.

I know you're smarter than this Frederf. I don't understand why you stick to single bug = overwhelmingly buggy even after I retracted that exaggerated example in my last post. Besides, my original statement was of bugs, plural and not singular. Is it because if you drop this strawman, you have no other argument? So how many bugs are needed before a software is considered buggy? 5? 10? 100? If it's just one bug but it causes CTDs for 90% of the users, because it's a single bug, we cannot call it overwhelmingly buggy? I'm not saying this is the case with ED, I'm just poking a big hole in your silly example. Anyway, doesn't really matter as there are pages and pages of bugs/issues/complaints on the ED forums and those are just the ones that survive the moderator's purges. So you don't even have to take my word for it that 2.5 is buggy; go and peruse the ED forums and take note of threads and posts prior to 20th/28th of April.

As for memory requirements, I suggest you familiarize yourself a bit more with the issue as it is not a pass/fail affair at all. Besides, the memory leak/allocation issue was discovered **THEN** the minimum requirement specs were changed **AFTERWARDS**, again evidence that ED does not know its own product.

Actually there is a way to enjoy DCS in that way, it just needs you to be very active about how you play the game.

You have to find and make use of the advantage the game has. screenshot isnt the only way to make it shine.

Thankfully i wasn't consuming a beverage when i read this gem.

Sobek, that has to be the 1st moment in any thread that you let slip with a comment that made me smile at the screen.

Let's not be naive here, and this is for everyone. People cannot just pretend a software to be bug-free, not because it cannot be done, but because the cost skyrocket (cost being more related to time rather than money...eg. nasa stuffs). So contrary to what ICE believe, it is expected to a software to be buggy (so don't take it personal Fredef) with the condition that the bug itself does not offer a direct impact on the 'workflow' of the software or it is not a minor bugs festival (so many little bugs that does not prevent to use the software altogether).

DCS 2.5 has two problem:
- critical bugs, eg. memory leak that impacts the workflow;
- minor bugs, some new and some simply inherited from previous versions (plural since it is a merge of 1.5 and 2.0);

I haven't personally even installed 2.5.1 but even if they have fixed the memory leak and fixed a few minor bugs, it still has a list of bugs and the DCS history taught that this list simply keeps growing which makes it a buggy software period. You might argue that some of these bugs are 3rd party addons bugs so not ED fault...i'd reply i disagree because DCS is anything but a modular software which makes impossible to 3rd party devs to be fully independent from core software. Probably you are a living example of what ED aimed to since the beginning. Keep stacking minor bugs until they are forgotten at that point people will care only about recent and major bugs.

For me when speaking of DCS it is not about bug-free vs buggy software but rather about development process quality which speaking of ED is extremely poor. Considering the lifetime of DCS i'd say that it made very little steps and considering the overall (graphics, combat, bugs list, 3rd party SDK, sounds, netcode, weather, planes, sceneries, flight model). Don't take me wrong, they did some steps but i'd expect some different approach and priorities.

^^^ Amen

And the lack of a different approach and reorg of priorities comes from ED refusing to acknowledge and learn from past mistakes.......which is why they continue to make the same mistakes over and over again in everything they do.

2.5 doesn't have a memory leak, it has an unoptimized high memory use probably due to a new feature chunk. I'm sue it's little consolation as both can cause a game crash. If you have enough RAM (which sometimes I don't) it's not an issue. If you don't have enough RAM it might as well be a leak. It has bugs and feature mistakes from trivial to rather glaring. I can sit in the cockpit of many supposedly complete modules and points at dozens of mistakes.

But remember the origin of this discussion: Ice doesn't like the Beta-Release two branch scheme. He says what's the point of two branches if both suck. Right now I will play R-branch but won't play OB-branch. OB is unplayable to me. OB has so many bugs that RB doesn't have. I know that's a personal cutoff threshold but I can't only speak for my own experience. Sticking to the RB historically has been much much much less headache than the usual, how do I say this without violating some forum rule, zealous insistence to try to play OB as if it was RB. I maintain that the multi-branch scheme is a good one and has provided much benefit to DCS compared to the single-branch approach.

Sorry, but I think we need to take a step back. I've never said that a software should/would not have bugs, I simply made that first statement to poke a massive hole in Frederf's claim that 2.5 is not buggy, with evidence being the memory leak/allocation issue.



Again, this is in relation to Frederf's humans and fat cells comment. A human can live the healthiest life possible and will still have fat cells by nature. A software will not, by its own nature, develop bugs (unless the software can re-write itself, but that's getting more complicated; I'm sure DCS does not re-write itself on the user's PC); these are imperfections injected by the programmer. Make a "Hello World!" program and it may or may not have bugs... it's not due to the software but due to the abilities of the programmer.




You don't have to take my word for it.

Source



Again, memory leak? Memory allocation? Doesn't really matter, call it what you want, because ED sure didn't know what to call it!! Point is that ED does not know its own product, as shown by the fact that ED acknowledged it as a memory leak, then later as a memory allocation issue.



Building another strawman? Please do point out where I said what you claim I said; otherwise, I'd appreciate it if you don't put words in my mouth.



The multi-branch scheme, an approach used by other game devs, is a good one. You won't find any argument from me there. However, just because Game Studio XYZ does it and ED does the same thing does not mean ED is doing it correctly. See the difference there?

- Ice,

Not sure if you follow DCS at other sites but, they have clearly explained what Frederf said.

The application is not endlessly consuming and then not returning system resources. That is a memory leak. That's not what is happening with 2.5.

Let's just call it a royal cluster*fvck....because it should never have got past internal testing and released to the public within an open beta....never mind the additional mess that followed with ED simply adjusting the minimum system spec in an attempt to wipe it under the carpet to cover it up without an attempt at fixing it.

If they tested on robust machines they may not have seen the issue.

I had 16 Gigs in my system and had no problems.

I am fully aware of this What I am pointing out is not whether this is a memory leak or memory allocation issue. What I am pointing out is that this caught ED unawares and they initially acknowledged it to be a memory leak issue (see screenshot) then changed it to a memory allocation issue. This does not happen if you are:
1. aware of your software's limitations
2. investigate the issue before making a statement (ie, memory leak? or memory allocation??)
3. know what you're doing

Therefore, ED does not know it's own product, did not even replicate/investigate the issue thoroughly before announcing it was a memory leak issue, and then faffed about for a few days before realizing it was **NOT** a memory leak issue but a memory allocation issue and made a second announcement.

Did ED not know the spec requirements of their software before releasing it onto the paying public?
Did ED not know how to verify such a big issue as this one? Why "admit" to a memory leak issue without proper verification?
How long did ED take to sort out a fix? Is the fix even released yet?

Again, I fully understand if ED used a 128GB RAM, 1TB SSD, and quad-SLI Titan X supercomputer to showcase their latest-and-greatest, but surely everyone can agree that "testing" does not start and end there. How hard would it have been for ED to whip up a min-spec PC and an average-spec PC and test how their software runs under those hardware specs?

"Robust".....?

All they needed to do was run an online mission with 20-30 units placed on the map and noted the amount of RAM usage to see a problem. If they'd run on lower spec machines they'd have seen the problem instantly....and it's their obligation to do that. There is no defending it. Given that they previously released a patch build that removed all the buildings on the entire map, do we even think ED test ANYTHING before releasing builds?

I have 32GB in my system and had all sorts of problems with 2.5 running at the same high settings as previous builds @4K resolutions. 15-20GB of RAM in use during game startup and 22-25GB + in use during multiplayer......which then meant that the framerate drops to 5-10fps and stutters like crazy until the game eventually bombed out....that's if the server didn't crash first. And that's completely ignoring the other myriad of problems, bugs and issues.