Monthly Newsletter Updates Discussion

[Napa]

Every time we have Wagdates this is what you need to expect.

 

:megalol::megalol::megalol::megalol::megalol:

 

 

No offence to anybody, I think this image captures perfectly all the hardcore simmers of this community perfectly when they see an update from Wags :lol:

[BBQ]

Viper, I would just say No it won't be in 1.2.5 :)

 

IMO, that's a bad idea. I almost got burned by purchasing FC3 based on an incorrect statement from a tester, though in the end, it was sorted out, and rather quickly to the credit of ED. Although the question from this post is in no way similar to my situation, I think this still applies.

 

If the leaders of the teams haven't already clarified the tester's role to the test team, tester being the key word here, I imagine it will be forthcoming -- pure speculation, but something along the lines of:

 

"Do not make statements regarding the release of software in any way, shape or form, including dates, or the inclusion or exclusion of features or fixes."

[BBQ]

As a software tester by trade, I would say that we're in (perhaps have been for a few years now) a new era of software design/development/testing. E.g., the software I'm currently involved with uses a kind of "continuous integration" method where there are multiple identical environments, one for testing, one for "QA" and one for "Production":

 

• Test: Individual developers and testers have access to this environment which constantly undergoes changes -- the code is essentially written/modified in this environment.
   
  
• Quality Assurance or QA: This environment is identical to Production, but serves as a place to deploy release candidates so that the QA/Testing team can bang on it and make sure it works before it goes to Production.
   
  
• Production: This environment includes the servers from which we all download the software from -- and in a way, all of the PCs of the customers, in the case of "game" title.
  

 

For a long time, software development followed a kind of Waterfall Methodology -- the stakeholders/producers would come up with a number of "Requirements" -- features that the final software must contain. A few examples:

 

• The software shall allow the user to interact with the aircraft's systems
  
• The software shall give the user the ability to view the simulated environment in six axis of motion
  
• The software shall allow the user to create single player missions
  

 

Basically, all of the features preceeded with "The software/system shall..."

 

Once the requirements were "baselined", the job of the developers was to design the software to meet all of these requirements. The problem was, it seemed the requirements constantly were changing -- so when one requirement was fullfilled, and the QA team had completed writing a test case to prove the requirement was met, all of it had to be done over as a consequence of the requirement changing. Each stage of the software creation process was like a gate -- and you were basically stuck in one part and could not proceed through the next gate until all tasks of current step were completed.

 

More recently, as opposed to the Waterfall Methodology, the Agile and Test Driven methods have been widely adopted. These methods recognize the fact that requirements were in a constant state of flux as stakeholders would add and deprecate features based on the current need of the customer. In this way work was more efficient, and changes to requirements could easily be incorporated.

 

"Test Driven Development" is the method that my team uses -- basically the developers get a list of the features and start writing tests, running them immediately, before they have even written a single line of code. Obviously, the tests all fail. For a particular requirement/feature, they start writing code and don't stop until the test passes. The single feature may be fairly broad -- and so multiple "scenarios" are written for each feature. For example:

 

Feature: As a pilot, I would like to be able to land the aircraft.

 

Then, scenarios are written that become the "tests":

 

Scenario: As a KA-50 pilot, when the engines of my aircraft are ON, then I should be able to manipulate the thrust and control surfaces of the helicopter in order to land safely.

 

Scenario: As a KA-50 pilot, when the engines of my aircraft are OFF, then I should be able to manipulate the control surfaces of the helicopter in order to land safely (autorotation).

 

These new paradigms of software development respect the fact that the various needs of the customer (and so the features of the software) change often -- especially in light of all the emerging technologies that seemingly arise on a daily basis.

 

Borderline hijacked this thread -- just wanted to put those who don't work in software development in our "shoes", if only from a very high level.

 

In summary, see Wag's signature.

[whartsell]

As a software tester by trade, I would say that we're in (perhaps have been for a few years now) a new era of software design/development/testing. E.g., the software I'm currently involved with uses a kind of "continuous integration" method where there are multiple identical environments, one for testing, one for "QA" and one for "Production":

 

• Test: Individual developers and testers have access to this environment which constantly undergoes changes -- the code is essentially written/modified in this environment.
   
  
• Quality Assurance or QA: This environment is identical to Production, but serves as a place to deploy release candidates so that the QA/Testing team can bang on it and make sure it works before it goes to Production.
   
  
• Production: This environment includes the servers from which we all download the software from -- and in a way, all of the PCs of the customers, in the case of "game" title.
  

 

For a long time, software development followed a kind of Waterfall Methodology -- the stakeholders/producers would come up with a number of "Requirements" -- features that the final software must contain. A few examples:

 

• The software shall allow the user to interact with the aircraft's systems
  
• The software shall give the user the ability to view the simulated environment in six axis of motion
  
• The software shall allow the user to create single player missions
  

 

Basically, all of the features preceeded with "The software/system shall..."

 

Once the requirements were "baselined", the job of the developers was to design the software to meet all of these requirements. The problem was, it seemed the requirements constantly were changing -- so when one requirement was fullfilled, and the QA team had completed writing a test case to prove the requirement was met, all of it had to be done over as a consequence of the requirement changing. Each stage of the software creation process was like a gate -- and you were basically stuck in one part and could not proceed through the next gate until all tasks of current step were completed.

 

More recently, as opposed to the Waterfall Methodology, the Agile and Test Driven methods have been widely adopted. These methods recognize the fact that requirements were in a constant state of flux as stakeholders would add and deprecate features based on the current need of the customer. In this way work was more efficient, and changes to requirements could easily be incorporated.

 

"Test Driven Development" is the method that my team uses -- basically the developers get a list of the features and start writing tests, running them immediately, before they have even written a single line of code. Obviously, the tests all fail. For a particular requirement/feature, they start writing code and don't stop until the test passes. The single feature may be fairly broad -- and so multiple "scenarios" are written for each feature. For example:

 

Feature: As a pilot, I would like to be able to land the aircraft.

 

Then, scenarios are written that become the "tests":

 

Scenario: As a KA-50 pilot, when the engines of my aircraft are ON, then I should be able to manipulate the thrust and control surfaces of the helicopter in order to land safely.

 

Scenario: As a KA-50 pilot, when the engines of my aircraft are OFF, then I should be able to manipulate the control surfaces of the helicopter in order to land safely (autorotation).

 

These new paradigms of software development respect the fact that the various needs of the customer (and so the features of the software) change often -- especially in light of all the emerging technologies that seemingly arise on a daily basis.

 

Borderline hijacked this thread -- just wanted to put those who don't work in software development in our "shoes", if only from a very high level.

 

In summary, see Wag's signature.

 

ARGGG!! I come to these forums to get away from my work and now Its just like reading my requirements :smilewink:

Im a software performance engineer.

[GGTharos]

It's just new spin on old methods. The tools for achieving CI/CD are becoming more prolific.

 

However, evangelizing methodologies is not useful - maybe a particular project doesn't need 'Agile' and waterfalls work just fine for it. Better yet, the two are commonly and easily combined, so you get waterfall (pre-defined requirements) along with CI, which allows you to rapidly respond to requirements.

 

This decreases response time and increases quality, but it still requires a lot of discipline regardless of which methodology you choose, and how you apply it.

 

Maybe you don't have time to attach unit tests to everything, or do functional/integration tests. There's such a thing as 'by the book' CI/CD, but not all projects are suited for 'by the book', nor are they all suited for TDD. I highly doubt ED uses TDD, and I would not expect them to. I don't even expect all the projects I manage to implement TDD - TDD isn't needed for one-off demos for example.

 

More recently, as opposed to the Waterfall Methodology, the Agile and Test Driven methods have been widely adopted. These methods recognize the fact that requirements were in a constant state of flux as stakeholders would add and deprecate features based on the current need of the customer. In this way work was more efficient, and changes to requirements could easily be incorporated.

 

"Test Driven Development" is the method that my team uses -- basically the developers get a list of the features and start writing tests, running them immediately, before they have even written a single line of code. Obviously, the tests all fail. For a particular requirement/feature, they start writing code and don't stop until the test passes. The single feature may be fairly broad -- and so multiple "scenarios" are written for each feature. For example:

[Cedaway]

It's Wagsday,...

 

:)

Opened, now F5-F5-F5-..........

 

A guess of the news?

[ApoNOOB]

These threads really suck.

[Silver_Dragon]

That funny :)

[Cedaway]

These threads really suck.

 

But let you comment the Friday news... ;)

[159th_Falcon]

..............................:doh:

 

Really, can't we just wait for the update for once?

[Aginor]

Somehow these threads are funny and annoying at the same time...

[Flying Penguin]

:)

A guess of the news?

 

 

 

The GAU-8 will be retrofitted to shoot fairy dust and unicorn kisses.

 

Combined Arms will be re-titled "Kumbyarms" and will focus on the struggle of the Georgian peace movement, including highly accurate simulations sitting in front of a tank singing songs and chaining your fellow protesters to the undercarriage of military aircraft whilst being manhandled by the brutal fascist military police.

 

The KA-50 will have the gun removed and loud speakers added. They will only supply the music for "Blowing in the Wind".

 

The loading screen will now look like this:

 

 

Well it's as good as any other guess and so far there is nothing to contradict it.... ;)

[ApoNOOB]

But let you comment the Friday news... ;)

 

 

You don't need to make a thread hours in advance. Furthermore there won't be any discussion in here, only useless spam. Any real discussion will be buried under pages of "lol can't wait F5 F5 F5!11".

 

In case you haven't noticed, many people don't like to pick through pages of talk only to get to the important bits. This forum is already horribly cluttered on all ends, please do not purposefully add to that - every week! :)

[eurofor]

(...)

 

In case you haven't noticed, many people don't like to pick through pages of talk only to get to the important bits.

 

(...)

 

What important bits? There will only be crying when the update is actually out.

[GeorgeLKMT]

It's part of local folklore, threads created way ahead of update with people both loving and hating it at the same time.

 

As for the update, I would be happy to hear something about fixing A-10A issues. Also "We decided to add PAC into FC3 A-10A, so the most prominent feature of this airplane, the gun, could be usable once again" :)

[159th_Falcon]

Does the real A-10A have PAC? Always thought it was an A-10C feature.

[Rotorhead]

Well, guys if you really can't wait that much so you have to create a thread ways before the actual update, then at least do us a favor:

 

Mods, or even better, the OP, should edit the first post with something like "relevant discussion begins with post #36" or so after the update comes out. Saves our time reading through "I can't wait OMG so excited" stuff.

[howie87]

Does the A-10A have PAC IRL? I noticed the cockpit has SAS switches... Kinda hate SAS when trying to shoot down aircraft in the A-10C though. Have to remember to flip the gun arm switch the other way!

[GeorgeLKMT]

AFAIK, A-10A really does have PAC. It became a part of the LASTE upgrade and I also made some citations here. Also, there's a obvious PAC switch in the cockpit (sniped ^^^^^^). ;)

[159th_Falcon]

AFAIK, A-10A really does have PAC. It became a part of the LASTE upgrade and I also made some citations here. Also, there's a obvious PAC switch in the cockpit (sniped ^^^^^^). ;)

Roger, never fly the bird so i obviously never saw the switch.

[howie87]

DCS: F/A-18C? Seems reasonable.

 

Doubt it but it sure would be nice to hear something. I think Wags knows better than to get us all excited though...

 

We're already a weird bunch!

[Fishbreath]

The KA-50 will have the gun removed and loud speakers added. They will only supply the music for "Blowing in the Wind".

 

At least the Ka-50 would get some love for once. :P

[Raven68]

May be better to create one after the official "Wagdate" posting with today's date.(I'm sure Skates will do it :music_whistling: ) This thread is bound to get lost after today.

[skouras]

Does the real A-10A have PAC? Always thought it was an A-10C feature.

yes

[Hamblue]

Maybe he'll announce the first "open beta" mentioned recently.