Will DCS become fully modular?

[iFoxRomeo]

Well, the latest update(1.2.11) arose a few questions in my mind.

 

The update introduced not only a new module, but also bugfixes and unfortunately new bugs. Bugs that were reported in the open beta before.

 

Yes I know, some do consider missing engine sounds as irrelevant for flying. I and others don´t. It was not the first time this happened, nor will it be the last time. Wherever humans work, mistakes happen. That is totally normal,

and not the problem at all.

 

We do have presently 14 separate modules, plus FC3. ED, Belsimtek and VEAO are short prior releasing the BF109, the MiG-15 and the Hawk. It does not stop there. VEAO alone has additionally 11 Modules announced till the end of 2015. Well let it be 2016. Not to forget Leatherneck Sims, RAZBAM, Coretex and AvioDev.

 

I guess you see the point. It will be more and more. That is a very good thing.

 

The problem I see is that ED will be overstressed with testing and packaging modules into DCS. How will they manage it?

 

Often we read something like "it is fixed in the internal version, but won´t make it into the next update".

So why not, maybe at least in the open beta, make it that modular, that the developers themselves are able to release updates for their modules?

 

What do you think?

 

Fox

[112th_Rossi]

The modules don't need to be 'packaged' into DCS. They are independent and operate as a plugin. So the testing is mostly on part of the module developer. Obviously theres some collaboration between ED and the module dev but mostly development and fixing is on the module developer.

[Chappie]

The OP might be hinting at a larger issue related to quality or perhaps a lack thereof. In addition, the alpha and beta period is where the update is vetted for regresson as well as the present change. That is what testing is and would prevent introducing new issues with each release.

 

I don't know what software development methodologies ED employs, but I would think quality testing is an integral part of it. Missing engine sound from the Sabre is a minor issue but I don't think waiting until the end of the next development iteration is appropriate. I do share the same concern with module development from third parties, the state of Beta modules, and the future of development integration.

 

It need not be said Leatherneck is updating their module. Belsimtek is not and presently has two modules in perma-beta status which is not acceptable when major changes 8are needed.

 

I hope to see improvement and better fusion of this process especially as more modules are available for release.

Edited November 14, 2014 by Chappie

[iFoxRomeo]

The modules don't need to be 'packaged' into DCS...

Have you seen an independent update of a module outside of a DCS World update?

 

I have not. But I read from not-ED developers things like(analogous) "Bug fixed in internal version. Will (or won´t) make it into the next (or later) DCS update. But we have no date, when this update will be released by ED."

 

 

As it seems to be now:

Module producer submits update to ED(hopefully within the deadline for the next update). ED tests and implements it into the DCS update and then publishes it. All this consumes time and manpower. And with the increasing amount of modules I see problems arise. But maybe ED already thought about this(I hope so).

 

Fox

[Auger73]

As it seems to be now:

Module producer submits update to ED(hopefully within the deadline for the next update). ED tests and implements it into the DCS update and then publishes it. All this consumes time and manpower. And with the increasing amount of modules I see problems arise. But maybe ED already thought about this(I hope so).

 

This is the normal course for a software publisher. I think the general idea for ED is that as time goes on, modules should need fewer and fewer fixes. So, if you grow the number of modules slow enough, it shouldn't give too much strain on testing.

 

The real problem comes when core changes happen inside the DCS engine, which can then ripple into unexpected behavior inside individual modules. I bet ED is very careful about this. A lot of testing can become necessary, and all those extra modules give extra pain.

 

Every time you make changes/fixes, there is a potential to introduce or re-introduce bugs. At some point, a developer will have to say, "I can live with the bugs, as the product is overall better as a result of this patch".

 

There is no "perfect patch" or "perfect software". I've worked long enough in the software business to know that if you encounter a bug on released software, chances are very good (probably > 90%) that the developer knew about it before release. Which is not to say that they understand the behavior of their software perfectly, or how it runs on all hardware.

[Archer7]

This doesn't work at all how you think it works.

[QuiGon]

This doesn't work at all how you think it works.

 

So, how does it work?

[iFoxRomeo]

This doesn't work at all how you think it works.

 

+1 QuiGon

 

Okay Archer7, then how does it work @ED?

 

Fox

[stray cat]

The way it works is this:

 

ED sells more copies, can hire more people so its not 5 guys in a basement coding and being slowed down by overseeing 3rd party modules. So more 3rd party stuff does not slow down the development, it accelerates it, because more modules, more sales, can hire more staff

[BitMaster]

......... Which is not to say that they understand the behavior of their software perfectly, or how it runs on all hardware.

 

 

There is a distinct difference between complicated and complex.

 

Software is complex and any change in the gears may or may not produce effects no one could have imagined before. Too many possibilities that scale with each addition of code and function.

 

 

A Lange & Söhne Pocket Watch, Grand Master of Time or how it is called, the most complicated watch in the world ever made ( in the 1920 without any CAD guys ). It is complicated, but you can PRECISELY predict what happens if you change that gear or that spring, it is a lot to learn but has an ending and a countable number of possibilities, a software code doesn't.

 

 

I love complicated things as you can dive in, down to the ground and master it.

 

With things that are complex, it is an endless learning of side effects and events of surprise

and you will have a very hard time figuring out why things went left and not right, or up instead of down etc... You think you got it, change it and have a totally new outcome, unseen before...haha

 

as I said ENDLESS

 

It's a mind game and one has to settle with knowing that he will never know it all and has to face surprises with complexity.

 

Bit

[Archer7]

So, how does it work?

 

+1 QuiGon

 

Okay Archer7, then how does it work @ED?

 

Fox

 

Well, the basic concept of modularity works by ED or any other software developer creating a central software with open ends so to speak that allow for easy module integration and then another developer (or in some cases ED) creates a module which interacts with the central software through the open ends but basically without deeply interacting with the core of the central software.

When done perfectly it means any modules plugged into the engine may only have internal bugs and that the engine may have internal bugs but that modules may not cause engine bugs.

 

Think of DCS World as:

And modules as:

 

A malfunction in the Xbox AC adapter "can't" possibly break the socket bar, but when it happens it will stop working with the socket bar.

 

And what I mean by that is ED don't have to worry about deeply integrating all modules into their software. DCS World is developed to be modular. Drag and drop content, ideally!

Edited November 18, 2014 by Archer7

[iFoxRomeo]

The way it works is this:

 

ED sells more copies, can hire more people so its not 5 guys in a basement coding and being slowed down by overseeing 3rd party modules. So more 3rd party stuff does not slow down the development, it accelerates it, because more modules, more sales, can hire more staff

 

I don´t think that by increasing the team the bugfixing is accelerated by the same factor. It could lead to problems if the team gets too big.

You know the thing with "Having 9 women pregnant brings you a child once a month". But maybe I´m wrong.

 

Well, the basic concept of modularity works by ED or any other software developer creating a central software with open ends so to speak that allow for easy module integration and then another developer (or in some cases ED) creates a module which interacts with the central software through the open ends but basically without deeply interacting with the core of the central software.

When done perfectly it means any modules plugged into the engine may only have internal bugs and that the engine may have internal bugs but that modules may not cause engine bugs.

 

Think of DCS World as:

And modules as:

 

A malfunction in the Xbox AC adapter "can't" possibly break the socket bar, but when it happens it will stop working with the socket bar.

 

And what I mean by that is ED don't have to worry about deeply integrating all modules into their software. DCS World is developed to be modular. Drag and drop content, ideally!

 

Well I didn´t say anything that differs from your example. But I went further than you did.

 

When did you see a "individual" update of a module without increasing the DCS World version. Is it right now possible for any 3rd party developer to release an update for a official module without sending this build to ED?

 

That is what I´m talking about. Updates have to be approved by ED first and will be only released in packages most of the time together with updates of other modules. You do get updates only via ED´s updater (or Steam but still via ED), not via the 3rd party developer´s website.

 

Does Microsoft release the updates for modules that other developers produce for FSX?

 

Letting the 3rd party developers release updates by themselves would reduce workload for ED and reduce time between possible updates.

 

ED can still overwatch the updates. E.g.:

Every quarter there is a deadline of 2 weeks before the quarter´s end, so developers could send ED a stable build of their module(s). Then ED releases a "official update" for all modules together. And between a official release and a deadline the 3rd party devs could simply release intermediate fixes by themself on their webpage.

 

 

 

Fox

[stray cat]

I don´t think that by increasing the team the bugfixing is accelerated by the same factor. It could lead to problems if the team gets too big.

You know the thing with "Having 9 women pregnant brings you a child once a month". But maybe I´m wrong.

 

Yes you are wrong. the pregnant example is completely useless here. The more people and money are thrown at a task, the faster it will get done. Works for everything, skyscrapers, Call of Duty, DCS.

 

Same if you connect more hamsters to more hamsterwheels you get more power

[cichlidfan]

The more people and money are thrown at a task, the faster it will get done. Works for everything, skyscrapers, Call of Duty, DCS.

 

:megalol::megalol::megalol:

Edited November 18, 2014 by cichlidfan

[QuiGon]

I don´t think that by increasing the team the bugfixing is accelerated by the same factor. It could lead to problems if the team gets too big.

You know the thing with "Having 9 women pregnant brings you a child once a month". But maybe I´m wrong.

 

 

 

Well I didn´t say anything that differs from your example. But I went further than you did.

 

When did you see a "individual" update of a module without increasing the DCS World version. Is it right now possible for any 3rd party developer to release an update for a official module without sending this build to ED?

 

That is what I´m talking about. Updates have to be approved by ED first and will be only released in packages most of the time together with updates of other modules. You do get updates only via ED´s updater (or Steam but still via ED), not via the 3rd party developer´s website.

 

Does Microsoft release the updates for modules that other developers produce for FSX?

 

Letting the 3rd party developers release updates by themselves would reduce workload for ED and reduce time between possible updates.

 

ED can still overwatch the updates. E.g.:

Every quarter there is a deadline of 2 weeks before the quarter´s end, so developers could send ED a stable build of their module(s). Then ED releases a "official update" for all modules together. And between a official release and a deadline the 3rd party devs could simply release intermediate fixes by themself on their webpage.

 

Fox

 

 

+1, that's what I'm curious about as well.

[EtherealN]

Yes you are wrong. the pregnant example is completely useless here. The more people and money are thrown at a task, the faster it will get done. Works for everything, skyscrapers, Call of Duty, DCS.

 

Am I correct to assume that you have not worked in large software development projects? ;)

 

Yes, having more people will usually make things go faster, but this is with diminishing returns - having 10 guys instead of 1 will almost always make things go faster, but it might go 5 times faster; not 10. You might also end up with new problems because of it, since the team becomes more difficult to manage and coordinate (potentially causing an increased rate of new bugs). The management of large software projects is a whole science unto itself.

 

(On the testing side, an example I have seen (not related to an ED project, before anyone asks) is where bug regression slips up since one tester misunderstands a bug that is up to be regressed, and marks it as fixed, and the other testers then do not regress that bug at all since that was already done... and then the bug remains unfixed while everyone - including project managers and engineers - believe it's no longer an issue. Until someone accidentally "discovers" the bug again and is confused because "wasn't this fixed already?" :P )

[sobek]

The more people and money are thrown at a task, the faster it will get done. Works for everything, skyscrapers, Call of Duty, DCS.

 

No, this is simply not true. Ask anyone that has worked in the software business.

[Flagrum]

Yes you are wrong. the pregnant example is completely useless here. The more people and money are thrown at a task, the faster it will get done. Works for everything, skyscrapers, Call of Duty, DCS.

 

Same if you connect more hamsters to more hamsterwheels you get more power

That only works if there are enough work packages that can be worked on in parallel.

 

For really large project this is often the case. But even there some tasks just can't be parallelized(sp?:huh:). Only one person can work on a specific source code file at given point in time. To complete his task, he might need to work on several other source code files as well, often leaving them in an incomplete, non-working state in the mean time. If others would make their changes in these files as well, it would just not work and would only result in a huge mess.

 

For DCS, my personal guesstimation would be, that maybe up to a "hand full" of people can work on the cockpit and aircraft systems at once. Then maybe one or two on the flight model. Another one on the 3d cockpit model and the last one on the external model. Then there are perhaps 1 or 2 working on textures. But much more than 10 persons per aircraft ... I doubt that it would be viable.

 

edit:

hamster wheels? How do you connect X hamster wheels to your generator? All on the same axis perhaps, ok. But if you have 5 or 50 hamsters spinning the generator with their hamster wheels ... the RPM would not go up further at some point, no matter how many hamster wheels you add - depending on the Vmax of your hamsters. :o)

Edited November 19, 2014 by Flagrum

[sobek]

Only one person can work on a specific source code file at given point in time.

 

Not necessarily true. There are tools written specifically with this task in mind, like git, which was devised for working on the linux kernel, where many people would work on the same files at once, afterwards merging their work into the master branch.

 

edit:

hamster wheels? How do you connect X hamster wheels to your generator? All on the same axis perhaps, ok. But if you have 5 or 50 hamsters spinning the generator with their hamster wheels ... the RPM would not go up further at some point, no matter how many hamster wheels you add - depending on the Vmax of your hamsters. :o)

 

Being partially an electrical engineer, i just can't let this go unanswered:):

 

This is too simplistic. There's always a flux and a potential involved. When you add hamsters, the flux stays the same (velocity), but additional torque is added(potential, all in the mechanical domain). You could increase the excitation in the generator and get a higher current output.

 

With that being said, there are limits to what can be done in software development by throwing more money at a project, especially when there isn't a lot of money to begin with.

Edited November 19, 2014 by sobek

[piXel496]

..the team becomes more difficult to manage and coordinate (potentially causing an increased rate of new bugs)..

 

True, the best thing you can do as a manager is wear transparent wings and make a buzzing sound when you walk around.

 

 

 

 

 

 

 

 

 

 

.

Edited November 19, 2014 by piXel496
I'll promise to be serious from now on

[Flagrum]

Not necessarily true. There are tools written specifically with this task in mind, like git, which was devised for working on the linux kernel, where many people would work on the same files at once, afterwards merging their work into the master branch.

 

 

 

Being partially an electrical engineer, i just can't let this go unanswered:):

 

This is too simplistic. There's always a flux and a potential involved. When you add hamsters, the flux stays the same (velocity), but additional torque is added(potential, all in the mechanical domain). You could increase the excitation in the generator and get a higher current output.

 

With that being said, there are limits to what can be done in software development by throwing more money at a project, especially when there isn't a lot of money to begin with.

Git and the like ... okay. Tbh, I never actually worked with these tools, but yes, I know how they work. Or suppose to work. Then the granularity might be finer, but the core problem remains: several independend changes on the same "functionality" are vulnerable to create a mess. If that "functionality" is now encapsulated in a source code file or in a function, LUA table, whatever. As soon as interdependend changes of the logic of the same functionality are to be made, even automated tools get to their limits.

 

About the hamsters: you are basically saying (for me as non-e-engineer), adding hamsters would help if I also add i.e. more generators / replace the generator with a more powerful one? Yes, sure. But then we are leaving the given system and basically build a completely new one: sure, you can scrap DCS 2.0 and go right over to DCS 3 and re-make it from scratch ... in this case, assuming proper planning, 10 times the number of devs might then certainly help. :o)

[Shaman]

Steam Workshop, please.:worthy:

[QuiGon]

The question remains how ED will handle third party patches. Will the third party devs be able to release their own patches in the future independent of DCS World patches?

[sobek]

About the hamsters: you are basically saying (for me as non-e-engineer), adding hamsters would help if I also add i.e. more generators / replace the generator with a more powerful one?

 

There are generators where you can govern how much torque it takes to turn them at a certain speed (by modulating the phase between the rotor and stator fields). If we move over from our analogy, that would mean that you would make tasks more parallelizable, which is only possible for certain kinds of tasks (as it is only possible with certain kinds of generators :)).

Edited November 19, 2014 by sobek

[sobek]

The question remains how ED will handle third party patches. Will the third party devs be able to release their own patches in the future independent of DCS World patches?

 

Right now they are rolled out with EDs patches, which i suppose is how they plan to also handle it in the future.