Module updates from beta pushed onto stable

[RuskyV]

With the the current state of the beta being almost unplayable is there any chance the next stable update could include all the module updates from the beta?

 

Seeing as this new lighting update is not panning out for the beta and the stable version is now coming up to 5 months without an update, might be good to show some love for the stable release. :thumbup:

[BuzzU]

Your post makes no sense. You claim the OB version is unplayable but you want it uploaded to the stable version?

[Anklebiter]

Can we take all the good parts of beta and update stable with them? If it's OK, just go ahead and leave all the bugs in beta. Thanks.

[Savvy]

Good idea, all they have to do is uncheck the 'include bugs' box before they push the [release to stable] button.

[GrislyAccord]

I think y'all missing the point of the OP.

 

Modules are being repaired, updated, improved, and released from EA (like the Anton)...but only for the OB. As in, many of the newest features and improvements are not available in Stable. Or even entire aircraft, like the JF-17.

 

Yet when the OB breaks (it's unplayable for me right now, so I have been playing Il-2) we're told, "Well, it's the Beta, if you don't want bugs, play Stable." Which is great, except the plane I paid money for isn't available in Stable. Or it's broken in stable. Or it's lacking features in stable.

 

Ideally, each individual module should be updated independently of DCS World.

 

The funniest thing, to me, tho, is that STABLE isn't stable! I had three CTDs yesterday alone. (It's the AV8B. I can't remember the exact sequence, but pressing the DATA button in the MFCD when in HSI (but not moving map) crashes me every time.)

 

So OB is broken, the features that I like or rely on and the planes that I have aren't available in stable and stable itself keeps crashing...

 

...I'll just go fly Il-2. Which I've been doing exclusively for a day and a half now and will continue to do until DCS is fixed.

 

Also, Il-2 has the Jug already. But then, even if DCS had released the Jug...it wouldn't be playable right now anyway. hahaha.

[RentedAndDented]

My opinion is that this is something ED need to figure out, being able to have modules independent to some extent of the base installation.

So, allowing the publishers of a module the ability to publish themselves.

 

This is perhaps not possible, and even if it is it is not trivial. As one example, they'd have to do things like version off the API so things don't break on updates to the API. I am sure there would be hundreds of others.

[RuskyV]

The stable release has not had an update in 5 months, with the module updates and improvements (assuming) to be separate from the new lighting effects in the open beta why can’t we at least get something that does work pushed to stable.

 

-For those that don’t understand what I was originally saying I’m not sure how much clearer I can make it.

[hornblower793]

I think the issue is that the new lighting effects are not the root cause of the issues being seen in OB and ED are still troubleshooting the underlying reasons. Many bits of code will have been touched and i suspect that a lot of fixes then depend on one or more of these bits of code.

 

Sent from my SM-T835 using Tapatalk

[Canada_Moose]

The stable release has not had an update in 5 months, with the module updates and improvements (assuming) to be separate from the new lighting effects in the open beta why can’t we at least get something that does work pushed to stable.

 

-For those that don’t understand what I was originally saying I’m not sure how much clearer I can make it.

 

 

I think you were pretty clear. Some people not getting it for some reason.

 

 

I agree, features like the improved Hornet gunsight or the fixed dispersion of the A10 gun and the 100's of other module specific fixes can surely be implemented to the stable version without the mess of the "improved'' 2.5.6 core graphics engine.

[pimp]

The stable release has not had an update in 5 months, with the module updates and improvements (assuming) to be separate from the new lighting effects in the open beta why can’t we at least get something that does work pushed to stable.

 

-For those that don’t understand what I was originally saying I’m not sure how much clearer I can make it.

 

I think you were pretty clear. Some people not getting it for some reason.

 

 

I agree, features like the improved Hornet gunsight or the fixed dispersion of the A10 gun and the 100's of other module specific fixes can surely be implemented to the stable version without the mess of the "improved'' 2.5.6 core graphics engine.

I don't think y'all get how software development works. Why do people think 2.5.6 is nothing but graphic engine improvements. We have no idea what code has been implemented in this version. The module specific fixes you're wanting are coupled to the 2.5.6 code base. So are you requesting that those fixes get decoupled from the latest code and put into a stable version? Please correct me if I'm wrong.

[RuskyV]

I don't think y'all get how software development works. Why do people think 2.5.6 is nothing but graphic engine improvements. We have no idea what code has been implemented in this version. The module specific fixes you're wanting are coupled to the 2.5.6 code base. So are you requesting that those fixes get decoupled from the latest code and put into a stable version? Please correct me if I'm wrong.

 

I don’t know how software development works and I’m going to even claim I’m an expert either. If I did know I would probably not have needed to make this post.

 

If someone on the ED’s software development team does know maybe they can tell us if its possible to roll out separate module updates?:thumbup:

[jasonbirder]

I don't think y'all get how software development works. Why do people think 2.5.6 is nothing but graphic engine improvements. We have no idea what code has been implemented in this version. The module specific fixes you're wanting are coupled to the 2.5.6 code base

Are you SURE that things like new manuals, new training missions, campaign fixes, 3rd party plane updates (graphics, new weapons, HUD fixes etc etc) are REALLY tied to the core engine code that's causing lighting and FPS problems with 2.5.6 ???

 

 

I'm pretty sure most of them aren't...and if so WHY SHOULDN'T stable users get them? Especially 3rd party changes...the user PURCHASED the module from a THIRD PARTY, the THIRD PARTY releases updates/new functionality/bug-fixes to ED in the expectation that will be distributed to their CUSTOMERS.

 

 

Not that it'll be distributed to a tiny fraction of their customer based and locked behind a wall for the majority simply because ED values the minority on Open Beta MORE than it does the majority on its release version.

 

 

Yes, ED has had many, many problems with OB...but there is no reason AT ALL for ED not bundling up the third party changes and adding them to stable...for ages ED hid behind the claim that a stable release could ONLY be the previous Open Beta release (as that's the "way it works") well lo and behold! When it suited ED for marketing/promotional purposes...what do we get? A stable release that ISN'T the previous OB release - but something completely different (DCS 2.5.5.41371.1) so there's simply NO REASON for ED not to do the same with all the third party content that has been developed and walled away from stable users...

[BIGNEWY]

Been over this many times already.

 

When doing updates we work with version numbers of builds, not individual modules.

 

The man hours involved and the complexity of making a module work in an older build that may need merged code from the core of DCS to work is not possible. It has to be done as updates to whole builds.

 

Situation is not ideal at the moment with our public test open beta and a stable update is not going to happen until we are happy with the 2.5.6 build. Our plan was to update stable as soon as possible, that did not happen, delaying the stable update is the correct thing to do, until we have resolved all of the issues.

 

 

Thanks

Edited April 23, 2020 by BIGNEWY

[Northstar98]

jasonbirder said:

Are you SURE that things like new manuals, new training missions, campaign fixes, 3rd party plane updates (graphics, new weapons, HUD fixes etc etc) are REALLY tied to the core engine code that's causing lighting and FPS problems with 2.5.6 ???

New manuals? No, everything else. Yes, it's designed for 2.5.6 so it's fixed for 2.5.6 they are tied together, as has been said many times.

jasonbirder said:

I'm pretty sure most of them aren't...and if so WHY SHOULDN'T stable users get them?

You're mistaken, it doesn't work like that.

In order for stable to get the same fix they have to perform the fix on the stable version, effectively doubling their workload - does that sound like a good idea?

jasonbirder said:

Especially 3rd party changes...the user PURCHASED the module from a THIRD PARTY, the THIRD PARTY releases updates/new functionality/bug-fixes to ED in the expectation that will be distributed to their CUSTOMERS.

Again, the fixes are designed for 2.5.6, NOT 2.5.5 they are different builds. We've seen time and time again fixes in one, being broken in another - you can't just update for one build and expect it to work exactly as planned in another.

jasonbirder said:

Not that it'll be distributed to a tiny fraction of their customer based and locked behind a wall for the majority simply because ED values the minority on Open Beta MORE than it does the majority on its release version.

Locked?

The OB is free to download if you absolutely cannot wait for new features and new fixes, if you aren't willing to download the OB for whatever reason, you are simply going to have to wait.

jasonbirder said:

Yes, ED has had many, many problems with OB...but there is no reason AT ALL for ED not bundling up the third party changes and adding them to stable

Yes there is, it has been explained to you countless times. Your personal incredulity doesn't trump reality, I'm sorry.

jasonbirder said:

ED hid behind the claim that a stable release could ONLY be the previous Open Beta release (as that's the "way it works")

What planet are you on? No stable isn't the last version of OB, nor has it ever been the case that it could only be the last version of the OB. You can go ahead and find a source for that, otherwise it's just made up nonsense.

What it actually is, is the latest version of the OB that worked properly. Since 2.5.6 there hasn't been an OB branch that worked as intended (largely talking about performance here), which is why there haven't been any updates to the stable branch.

Hell lets give you some evidence here:

Before 2.5.6 there were 86 updates to 2.5.5 OB branch, meanwhile there are 23 updates to the 2.5.5 stable branch. Meaning that on average, the OB got updated ~3x as often as the stable branch - does it sound like stable has EVER been only the previous version of OB?

(Of course stable updates are often the combination of multiple successive updates to the OB - still doesn't mean that "stable can ONLY ever be one version behind OB" was EVER the rule).

I mean really Jason, really... I don't know if you were with DCS a few years back when 1.5 and 2.0 were separate versions, where you couldn't even play on the same maps (if you wanted Caucasus, you had to play 1.5; if you wanted to play NTTR you had to play 2.0) the versions were incompatible with each other and we had to wait YEARS before we got a unified version (2.5), a few months is little in comparison.

jasonbirder said:

what do we get? A stable release that ISN'T the previous OB release - but something completely different (DCS 2.5.5.41371.1)

As has been the case with EVERY SINGLE MAJOR UPDATE to the OB

This isn't new!

jasonbirder said:

so there's simply NO REASON for ED not to do the same with all the third party content that has been developed and walled away from stable users...

YES. THERE. IS.

The problem with you is you assume that because one fix works in one specific version, it must work in another.

A.) No - the fix was designed to work in that specific version, not generally across different major versions. In order for it to work properly in stable it's likely that it'll need to be coded to work specifically in 2.5.5 - well great, we've just round about doubled the workload for developers... Yay! Just what everybody wanted!

B.) Any fixes to any version require testing, so instead of getting a stable release we now just have 2 public testing versions, one testing the fix designed for 2.5.6 and the other 2.5.5 - well, what have we done now? Ah yes, completely undermined the point of stable... Yay!

 

Look, I exclusively play stable too, I get that it is frustrating to see so few updates for stable and going without updates for months is a pain. But I'd rather have a release that's workable for me, above the latest new thing.

2.5.6 was a release that seriously did not go well and ED are still hard at work trying to get it sorted. And until it is sorted it's going to hog developers basically exclusively, if they want to update stable in parallel then in practice all it means is that more work is created for developers and 2.5.6 takes even longer to sort out and means that it takes even longer for 2.5.6 to come to stable.

For me, I don't want anyone to touch stable until what they're going to do with it has been verified to work properly without the major performance hit that 2.5.6 has largely been.

Stable has always been a build of the OB that worked properly, since 2.5.6 we haven't had a properly working OB build (at least as far as performance is concerned) and that's why stable hasn't seen an update.

 

In closing, if you can't handle waiting for the latest features and fixes then get off stable, it isn't for you. There really is only 2 options here and this is how it actually works.

Option A.) You play OB (the public testing branch), and you get access to all newly developed content, features and fixes but at the risk of said content, features and fixes not being fully fleshed out. If you find issues you go about the proper procedure of reporting them, so that they may be fixed in the future.

Option B.) You play stable, you can play with all the features that work properly and largely without any major issues. This with the drawback of having to deal with fewer update frequency and waiting longer for new content.

The only thing I will say that Eldur brought up in another thread, is get stable up to 2.5.5.41962 OB from 2.5.5.41371 - but the solution to that is download OB and revert it to 2.5.5.41371.

Edited January 12, 2022 by Northstar98
formatting, spelling

[RuskyV]

Been over this many times already.

 

When doing updates we work with version numbers of builds, not individual modules.

 

The man hours involved and the complexity of making a module work in an older build that my need merged code from the core of DCS to work is not possible. It has to be done as updates to whole builds.

 

Situation is not ideal at the moment with our public test open beta and a stable update is not going to happen until we are happy with the 2.5.6 build. Our plan was to update stable as soon as possible, that did not happen, delaying the stable update is the correct thing to do, until we have resolved all of the issues.

 

 

Thanks

 

 

Thanks for the reply BIGNEWY, I Just wanted to understand how it all worked. Cheers!:thumbup:

[ThorBrasil]

Good idea, all they have to do is uncheck the 'include bugs' box before they push the [release to stable] button.

:megalol:

[CBStu]

I guess I am weird. I play stable only. I want to fly what ever is available and working. I have no interest in working as a tester. I keep seeing threads where someone is miffed that XYZ hasn't been updated. So? Is there somewhere that it is stated that ED owes us an update every X days? Seems to me that if X doesn't work in Y module, there are a LOT of other modules to fly. If plane Z can only be flown in OB, and OB isn't working well right now, I am sure ED is working their collective a$$e$ off to get it fixed. 2 years ago I got back into flight sims after being away for a long while. I started w/ X-Plane. Flew a 737 and their FA-18. Found DCS, flew both for several months, and then got the DCS FA-18. I haven't been on XPlane since.

[jasonbirder]

A.) No - the fix was designed to work in that specific version, not generally across different major versions

 

 

I'm DEEPLY confused by this...IF the previous third party updates were built to work with a specific open beta version and couldn't POSSIBLY work with anything else...

 

 

How is it that for example,

 

DCS Campaigns

 

Enemy Within 3.0 campaign by Baltic Dragon:

 

• M07: helipad and insurgent camp is no longer covered by the trees.
  
• M09: minor changes to AI wingman target reporting.
  

 

Released to Open Beta on the 14/1 can ONLY be compatible with the current Open Beta Update (released 16/4) - Did the Third Party developers get sent som code back in a Time Machine for them to work on? Or are they not quite so narrowly "version compatible" as you seem to insist?

[BuzzU]

The stable release has not had an update in 5 months, with the module updates and improvements (assuming) to be separate from the new lighting effects in the open beta why can’t we at least get something that does work pushed to stable.

 

-For those that don’t understand what I was originally saying I’m not sure how much clearer I can make it.

 

I did understand what you were asking. I was a beta tester in auto racing sims for years. It's not as easy as you think and DCS is much more complicated than auto racing sims.

 

ED isn't holding back updating the stable version on purpose. They want to keep it updated. They will when it's possible.

[BIGNEWY]

Thanks for the reply BIGNEWY, I Just wanted to understand how it all worked. Cheers!:thumbup:

 

No problem, and we know it is frustrating currently, but we are doing everything we can to get open beta ready for a stable version.

 

thanks

[sobek]

IDid the Third Party developers get sent som code back in a Time Machine for them to work on? Or are they not quite so narrowly "version compatible" as you seem to insist?

 

 

All the code matures together. You don't lock yourself in a room and work for three years and develop a module for what DCS will look like by then. You take what DCS looks like now, you develop a bit, then test it against current DCS. When it works, you develop the next bit, then test everything against what is by then the current version of DCS, fixing any bugs that popped up. This means that your code uses all the bells and whistles of current DCS and is not out of the box compatible with anything else. When DCS gets updated, you once again need to test your own code against new DCS and if something got broken, you fix it against that version.

[jasonbirder]

All the code matures together. You don't lock yourself in a room and work for three years and develop a module for what DCS will look like by then. You take what DCS looks like now, you develop a bit, then test it against current DCS. When it works, you develop the next bit, then test everything against what is by then the current version of DCS, fixing any bugs that popped up. This means that your code uses all the bells and whistles of current DCS and is not out of the box compatible with anything else. When DCS gets updated, you once again need to test your own code against new DCS and if something got broken, you fix it against that version.

 

 

 

 

I was refering to it specifically in the context of Third-Party "fixes" bundled with a particular open beta build...not more broadly the development of modules wholistically.

[sobek]

I was refering to it specifically in the context of Third-Party "fixes" bundled with a particular open beta build...not more broadly the development of modules wholistically.

 

 

And i'm telling you that it doesn't make a difference. You DO NOT take software from one branch to another and expect it to work. You expect it to break something. Which means you need extensive testing. Will it work? Sometimes it will. It will fail spectacularly some other times.

[jasonbirder]

No problem, and we know it is frustrating currently, but we are doing everything we can to get open beta ready for a stable version.

 

 

Hypothetically speaking...IF the current iteration of Open beta takes a significant length of time to resolve lighting/VR/FPS issues...taking us later and later into 2020

 

Will ED at SOME POINT consider an update to stable including use of purchased 3rd party modules (IE JF17) updates from 3rd Party developers (module updates and DLC fixes) etc

 

Or is EDs final word that Stable is frozen in time for AS LONG AS IT TAKES (be it 6 months, 9 months, a year, more) to work on the current Beta Version.

 

 

Also if rolling Open Beta 2.5.6.xxx into a stable release is ED'd priority...why does every Open Beta new version contain additional functionality and code, new features, new additions etc etc...why isn't ED making 2.5.6.xxx work sufficiently well to release to stable first BEFORE layering additional complexity and changes on top?

[jasonbirder]

And i'm telling you that it doesn't make a difference. You DO NOT take software from one branch to another and expect it to work. You expect it to break something. Which means you need extensive testing. Will it work? Sometimes it will. It will fail spectacularly some other times.

 

 

 

 

Which was EXACTLY my point...software updates/fixes created for a January release into Open Beta can't possibly be "ONLY COMPATIBLE" with the current Open Beta release in April can they?

 

If they're compatable with January 2020 code AND April 2020 Code (written AFTER they were released - so impossible to have been tested against) why is so difficult to imagine they might be compatible with December 2019 code as well?