01-30-2018 OB2.5

04-04-2018 Release 2.5

approx 9 weeks or so. Question Answered.......

And what better person to come out with this official release for a 'fix' than FiveLine himself.....that way anyone who shows proof of any 'memory leak' or questions 'going against the grain' see their posts removed, topic locked posting rights removed.

A prime example of this is found within the same thread SevenLine created as mentioned above

Locked

Original Source of 'Memory Leak'

Edit::::: Apologies Ice, I did not see you had quoted the source already

Ice quoted for the record

You're classing a name change as an official release?

I'll be classing 2.5 as a release when it works, is mildly optimised and when it reflects something worthy of a release. Now is not that time regardless of what those incompetent developers like to label it as.

Well of course Ninelies will lock threads / suspend people on such hot topic threads

Ah, I love it. Mind if I use name that from now on?

feel free buddy

I hope he's not holding his breath on that one.


So wow! Much snowflake! Enlarge safespace!


Fair enough. ED can't even polish their own game and meet their own goals, why waste time comparing itself to others?

After all, no other sim gives you big maps and simulates different types of sensors. Nope. Nothing at all. No other sim features modern combat aircraft with a slew of different sensors that allows pilots to see targets from miles out.

The initial release of 2.5 for OB and the release of 2.5 for Release branch were different code with different version numbers so no, that is not what I'm saying at all.

The latest Open Beta version is exactly the same as the 2.5 Release version......same code. There were no fixes, no updates and no optimisation when the ‘milestone’ was reached.

ED clearly don’t know what integration, test, quality control/assurance and release is. They continue to make it up as they go along.

I have no idea why anyone feels the need to defend these incompetent clowns. If they are not embarrassed then they clearly don’t care.

The initial release of Open Beta 2.5 is a different version but the latest release of Open Beta 2.5 has the same version number as the Release 2.5 so in essence, they just called one thing two different names.

Which is perfectly fine. You don't test a version, then fix something and immediately put it on the stable branch. Every stable version needs to spend time as beta test version beforehand. If you change even one single thing, you have to test it again.

You're absolutely right, as long as the 'stable' version has fixes in place and is actually tested......however, ED decided not to fix something and put it on the stable branch when it clearly isn't stable nor optimised. Clearly, ED's version of the 'stable' and 'release' branch is different to every other developer in every corner of planet Earth and integration/test teams around the world.

They may well have just put 2.5 into their definition of a 'release' candidate on the 30th January. Their 'release' versions are still open betas and I can't see how anyone can argue against that.

thankfully I read this - before I downloaded it all again and ended up with the same problem, only this time with the stable version.

I'll wait for 2.6 now.

So? That's how it has always worked since forever. That's the right way to do it.

Of course. My apologies. I've forgotten that ED treats us as both the beta tester and the customer.



Except there was no stable branch, there was only open beta.



Where was this logic when you were trying to make excuses as to how the memory leak issue slipped in?

Okay, someone explain this to me:

Source

So ED really did not know the state of their product when they released it? They didn't know about the memory leak... which is now not a memory leak... but they're now working on improving memory management! What systems were used in testing the build before releasing it to the wild? 256GB RAM and quad-SLI 1080Tis?

Another sign that ED does not know it's own product is that their first act was to change the system requirements to cover up their mistake, then Sith comes out with a statement about removing un-needed units (read: make the environment more sterile!) and asking people to upgrade their "old" setups with 8GB RAM, and now ED is talking about Preload Radius setting. It's like ED's discovering their own product at the same time as the customers are!!

Also, I guess ED is admitting to their product being an un-optimized mess if they have to work on improving memory management



So external testing is different from Open Beta. Who is doing external testing then? If it's ED's testers, won't it be called INTERNAL testing?

Someone please explain this flow to me as well:
> 2.5.1 is released for testing
> 3rd party updates their aircraft to 2.5.1
> 2.5.1 is released to Open Beta

Why are they asking 3rd party to do work for every step of DCS version? Why even ask 3rd party devs to adjust their module for a build that isn't even final yet? Why not go for a stable version, then ask 3rd party devs to update their product? Seems like asking other people to do more work that they'll have to re-do again later.

Because if they release 2.5.1 and anyone's favourite module doesn't work at first try, not only you will jump at their throat ?

Could anyone enlighten me and explain what memory leak is and how can I verify it on my computer.

"I've forgotten that ED treats us as both the beta tester and the customer."
ED does not do enough to separate voluntary testing practices with released product. They actively market the testing phase as "it's out (tm)." which they absolutely should not do. I was very disappointed to see their 2.5 DOWNLOAD NOW! plastered across their home page during 2.5's testing phase. I think voluntary testing branches are a great idea but they need to be clearly expressed that way.

"Except there was no stable branch, there was only open beta." What we call the branch that isn't OA or OB is stable branch or release branch or main or whatever is the official name always exists. The code that was showcased by OB was then deemed worthy of being the Release product which is why OB and Release matched versions.

I think the development cycle is internal, then a closed beta from hand-picked folks, then public beta on the dedicated branch, and then release branch.

What I think should happen with module devs is to see the new code coming in OB and get ready for it. Devs keep multiple copies of their product around. You'd probably stop developing relative to Release code since you know referencing OB code is going to come home to roost soon enough. That may be hard if OB is a moving target or the new code is a radical departure like it is now with deferred shading but those should be rare.

Traditionally a memory leak is an opened ended process that takes more memory without limit. DCS has some issue which takes a large chunk of memory but it doesn't increase without limit. It's not so much a leak (ongoing process) but the opposite of an optimization. That's how I understand it anyway. It doesn't matter practically if you have less than the required memory for a finite resource requirement or an ever-increasing resource requirement, too little is too little. I play DCS just fine with 16GB and someone I know struggles with 8. A recent log showed peaks around 12GB in one play session but today I hit all I had and had to restart. The tip to halve the preload radius makes a sharp difference in memory needed.

The main problem with the release management from ED is three-fold;

1) The test team are poor at their jobs (or ED do not listen/acknowledge the problems raised)
There is no way on earth that the problems we see/find should get through to the public......missing buildings and memory issues are prime examples of this.

2) ED do not have any release strategy
It’s all fine and well stating that bugs/fixes are put in place and tested before moving to a stable version, but ED aren’t doing this......they are moving version numbers and trying to call a baseline is in place without actually trying to fix glaring problems. 2.5 should be a major milestone build.....only superseded by v2.6 or v3. The fact they have just skimmed over the cracks and seem to think they are now working on 2.5.1 without putting the fixes and optimisations in place tells it’s own story and is the reason this entire product will never ever leave beta status. Apart from the obvious problems in 2.5, those using VR have an almost completely broken product now, many of the major changes within 2.5 are not functioning correctly at all when using Rift/Vive.

3) ED do not have a clue what an alpha/beta/release candidate actually is......or they do, but choose to implement a completely different definition to these categories than any other software developer.
Little needs to be said here, it appears that because of having no strategy as defined above, ED just make it up as they go along. It’s also obviously apparent that they have no road-map or if they do it’s ignored hence the lack of control and management of the products. The last minute changes and moving of goal-posts (the latest being to ask the community what WWII platform they should look at at next, probably because they’re having big problems with current scope and will be beat to the punch by IL2 BoX - highlighted by Johnny_Redd in another thread). That clearly doesn’t feature in their development timeline.

The problem here is that the new products are driving the changes to the software versions. By that I mean ED just down tools on the major baselines because concurrent work takes priority. The 2.5 seems to be a good example of this......what are the odds that ED just moved the version numbers and catapulted 2.5 into the category of the ‘stable’ build because the new terrain is close to completion and that’s where it needs to be positioned, along with the preparation for the Hornet with its partial functionality and major sensors and interfaces missing......so ED think they can just move version numbers around and fix the problems of a major software version in incremental builds. What should be happening is that the fixes should be applied to a baseline build BEFORE the milestone version is reached and subsequently released. What we are seeing at the moment shouldn’t even have the 2.5 moniker.

Incompetence continues.