BBQ

Thanks for the great link!

learn to competently fly the aircraft until it becomes an extension of your body.

thanks!

From takeoff to landing, flying BACKWARDS!

I thought it was a problem with my sidewinder 2 -- but no matter where you trim the pitch -- say 5 degrees up, it will sometimes pitch down drastically. Watch controller input at 25 seconds into video, and again at 1:05. I am simply taking my hand off of the joystick -- after having trimmed it. In both cases it maxes out the pitch (forward). In other times in the video, when you hear me trimming -- I am letting go of stick, and it works fine.

You might consider paying the producers for their efforts (it was a huge effort, involving an entire team). Unless you won it in a contest or something?

Guess I wasn't too clear -- it is not my software, nor do I have any rights to it -- I simply edited the missions to make them compatible with the current DCS World (quite a bit of work, actually -- but I learned a lot). I won't be providing the updated campaign to anyone, except the producer, who can do with it what he wants (hopefully he'll make it available to current and future owners of the campaign).

I'm in the final stage of testing after making this campaign 100% compatible withe DCS World v1.2.5. However, I'm not sure how this will be made available to previous owners. I'm in no way affiliated with Vergeev Group, but am in contact with the producer. Stay tuned.

It only required an email address from me.

lol

likewise I can confirm

Glad to hear I'm not the only one who could use this!

I made this quiz for those of you who could use a refresher identifying various IADS components. Click here to view the flashcards/quiz.

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.

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."

Makes sense. Thanks for everone's input!

Is it possible ony the one channel is dependent on the INU?

Wow, just reread my post. Someone must have snuck a few drops of "instant grouch" in my cereal this morning!

You nailed it seikdel -- I had indeed, forgot to switch on the INU at startup!

K -- let me put this question another way: I was about to land, and verified the three green lights indicating my gear was down and locked. I now know that those lights have no relationship to your gear actually being operable, as when I landed, I didn't have any nose gear. But hey, the green nose gear light said I was good to go, so I went. BTW -- I was not asking the dev team to put it at the top of the list so that it was the first thing done when the office opened up in the morning. I was attempting to make the simulation better (if indeed it is a bug), but either way, when and if the bug gets fixed, and the order in which it is fixed in relation to other bugs is so off-topic that the mention of it borders on thread high-jacking. I could really give a **it which bugs someone else would prefer to have addressed first, nor do I care whether or not someone thinks my point was "moot" or not, though I do appreciate the opportunity to use the word "moot" in a sentence.

The entire strut.

So why not then, just have one light? Red up, green down and locked? I figured since there are three lights, that they can individually show status -- and if nose gear is inoperable, then if not red, then unlit, but certainly not green -- just my two cents.

I pledged yesterday, I hope there's one heck-of-a push for the last two days! I wonder if that's common for kick starter projects -- kinda makes sense I guess. With the announcement of Maddox games joining up (if that indeed is true -- I didn't read the whole thread), it seems the disparate parts of the flight simulation industry are in lead pursuit, and forming up behind the lead, our very own Eagle Dynamics/The Fighter Collection team!

Bug description: During my take-off it appears my nose gear was blown off/destroyed -- but I continued with the mission, eventually arriving back at Sochi to land. However, I noticed that I still had three green lights indicating all of my landing gear checked out OK. Should not the light representing the nose gear (of the three landing gear status lights) turn red because of the damage? I took off around 17:10 -- just start track and fast forward until I'm rolling down the runway -- Note: I am using a cockpit mod -- Ricardo's HD Russian variety. I didn't have time to test it with default cockpit -- but will do so this evening (EST). Steps to reproduce: Start mission and be sure to taxi to runway, and then do a rolling take-off. PC Configuration: * See attached XML file (Speccy) Attachments: noseGearLight.zip comprised of the following files: Track Logs PC Specs

Thanks! Back to Sochi ...