Same bugs in realease as in OB

[Whisper]

In an ideal world, the Stable version should be updated to the last bugfree Beta version, 1 week later to give time for "bugfree" state confirmation, without a single change done to it, not a single addition, changes and addition which could be incorporated to OB the same day the Stable is updated to previous OB.

Ie, OB vers 1.5.59994 is seen as being bugfree enough for Stable, 1 week after its release. Stable can be upgraded then to 1.5.59994, the same day new things are introduced into OB 1.5.59996. All these changes will be incorporated into Stable X weeks later when introduced bugs are squashed.

 

My issue really comes when things are introduced into Stable when they have not been beta tested, while we have a Beta version just for that! (and I'm a pure Beta user, I never launch stable). Releasing a patch to Stable is kind of a "no return" operation, when it's done right now, some people (non Nevada owners) are forced to this version without alternative, so it really must be a Stable version.

 

And since we have OB for development, I don't really see how this would slow down development.

[9.JG27 DavidRed]

thats a good point...we have a open beta version to look out for bugs. and a release version which in theory should be stable without any major issues at least...the thing is, sometimes it seems that after an oben beta release, bugs are fixed(or not!), new features added, and then directly released to official version. which can be the cause for serious problems.

 

i tried the open beta, and never experienced the mouse courser problem there for example.

one more thing which definitely didnt turn out ideal:

 

the lack of force feedback in the 109 was introduced in a open beta version...it was reported.

then the patch became official version, and we were forced to fly without ffb in the 109 for 4months.

 

i think the only way to minimize such problems is to really fix bugs in open beta until it appears to be a stable version, and then release exactly this version without changing a single thing as official patch.

 

having said that, the current release version has many good improvements too.

[OttoPus]

The multiplayer tanker radio bug for flights with multiple aircrafts is indeed a game breaker. Somehow it made i through the stable version, maybe we poorly managed to report the bug.

[FlightControl]

Please take your time to consider the underlying written.

 

"I wonder whether the community can be more proactively and interactively involved in the testing of new releases of DCS World by ED."

 

The simulator is an enormously complex program, and I can imagine that in order to test for a new release, the ED development team, ED testers are facing enormous challenges to ensure that the product stays bug-free and that defects are properly reported and followed-up.

 

What we're noticing within the community is that there are people who have become very acquainted with the simulator in its mission design aspects and mission editing aspects:

- Designing missions using the DCS world scripting API.

- Making highly complex scripts.

- Having a large set of "mods" made within the product.

 

The amount of users and scripts and missions have grown exponentially, and thus, the challenge for ED to release a bug-free product has grown, and the complexity to keep backward compatibility has also grown also.

It has become very hard for ED to test everything keeping this large community happy.

 

The challenges for ED are in the following areas:

 

- Ensure that the promised functionality gets delivered within the expected deadlines.

 

- New modules are integrated in relation with the partners.

 

- Partner modules can have bugs, and fixes are required.

 

- Changes in the DCS world core engine may sometimes mean a large rework, with a high risk for bugs. eg. the planned merged product (version 2.5), is a huge challenge for ED today.

 

- the DCS world lua scripting engine is used within many missions, bugs appear frequently. Backward compatibility is key, and the functions need to work consistently.

 

- the mission editor needs to keep up with the changes... and keep backward compability with previous designed missions.

 

- cope with unexpected crashes during run-time, due to memory errors or other internal bugs in the C++ code...

 

What we've noticed in previous releases is that bugs appear, and are staying within the system for a couple of months, if not years. Some bugs however, get quickly fixed, while others are awaiting to get fixed for a (very) long time...

 

And unfortunately, some of these bugs were only detected after "beta testing", in the already release product... And i see a couple of reasons of that:

 

1. Beta releases are appearing very shortly after each other. The community has a hard time to follow-up...

 

2. Core changes are done in the product, but are not communicated to some community people who maintain complex scripts...

 

3. I really wonder how closely the broader community is involved today in bug fix prioritization and bug fixing. (So Beta testers are also community, but i mean here the broader community ...)

 

Therefore, i have a couple of suggestions to help ED to make this better:

 

1. Would it make sense to involve some people of the community in "pre-release" testing? Especially major releases should be tested properly. Or another solution could be, the BETA stays longer alive, until all urgent defects have been reported and resolved ...

 

2. Would it make sense to establish a communication channel for testing and test results? A proper logging of bug fixes and follow-up? I don't think the ED forum is a good platform to do that. I think something else is needed.

 

Hope these points make sense ...

[Dee-Jay]

+1 with Azrayen.

Edited November 30, 2016 by Dee-Jay

[bkthunder]

+1 to OP, Azrayen, etc.

DCS has been plagued by some show-stopping bugs that make/made life hard for virtual squadrons and MP pilots, and this is not something recent but it goes back to DCS A-10C.

I applauded the release of the OB version, but it's not being used as intended IMO.

[bushido]

I support this conclusion, take your time guys, please double check and released more polished stable version.

 

It's a lottery now for every new update will my module still work ? Will my campaign still work ?

[Schmidtfire]

Once 2.5 hits, I think that ED should have serious a look at their update policy. Maybe have separate module and DCS engine updates or something. With so many modules and parameters in play there is just to much stuff being updated at once. Working modules are breaking and bugs are sometimes discovered 10min into release.

 

Maybe have a separate update for modules in early access stage 2-times a week, since there is a lot more features to be added (and bugs to be discovered).

 

DCS is growing fast. The system we have now kind of works, but for how long?

[BIGNEWY]

you are right DCS is growing fast, to me it feels like the final push to 2.5 is a challenge for the team and they are doing as much as they can to make it as smooth as possible, but as we know it is not a simple task.

 

I do as much as I can to help, but sometimes it is not enough, but onwards and upwards we are pushing towards 2.5 I hope things will become easier for all of us then.

[StandingCow]

you are right DCS is growing fast, to me it feels like the final push to 2.5 is a challenge for the team and they are doing as much as they can to make it as smooth as possible, but as we know it is not a simple task.

 

I do as much as I can to help, but sometimes it is not enough, but onwards and upwards we are pushing towards 2.5 I hope things will become easier for all of us then.

 

I'd love to see hotfix patches for broken DLC campaigns.

 

I am sure things will stabilize once the merge is completed though... ED has their hands full atm.

[BIGNEWY]

ED team are aware, mission designers have contacted me also and all the necessary reports are in for the dev team.

 

I don't know how long it will take sorry