One thing I bet will make people scratch their heads at first is that LNAV actually activates and becomes the green/active mode on the FMA if you push it on the ground before takeoff (most of the AP modes will actually), there's no white armed mode + engage at 400 feet stuff, no idea where we originally got that from lol.Anyone flying in a warm part of the country (like Phoenix in July!) is going to see some warnings that they may think are bugs - we've modeled the effects of the outside air temperature on the plane's systems... actual SWA pilots deal with this all the time in PHX and LAS.

Ryan, will the manuals explain how to prevent the alarms and at what OAT will they start going off? I imagine external air hook up is the key?

Tabs or Robert,On a serious note though. If I may suggest, PMDG may have to create a MOCC (Maintenance Operational Control Center) to deal with some of the "what may appear as abnormalities" for pilots who are going to experience what they may think is a potential problem. it is a pity that it could not be a live system as we do it in the real world, where a problem is trouble shot via ACARS or SATCOM rather than having the crew return to the field un-necessarily. Some of this may have already been thought of in-house, but an interactive MOCC module could be modeled where pilots are able to get some assistance trouble shooting issues while in flight.Another REALISM kicker!!!!!Simeon

There will be a section of the manual with a number of these things that we think are going to be the most commonly cited issues or whatever.

:(

:(

:(

Ahhhahahahaha, classic! :(

Anyone flying in a warm part of the country (like Phoenix in July!) is going to see some warnings that they may think are bugs - we've modeled the effects of the outside air temperature on the plane's systems... actual SWA pilots deal with this all the time in PHX and LAS.

Looks like I will have to [happily] deal with them in summertime then (Adelaide, Australia). :(

Especially with this product where quite a few things that have been simulated incorrectly forever are now right and will probably get called bugs at first until people get used to it.

Ryan, you are still the king of teasers !! :( Take care,Wijnand Lindelauf (EHBK)

Gents-There are MANY reasons why we would not want the public to have access to our bug reporting system. here are just a few of them:1) Our Tech team provides us with candid, sometimes brutally honest feedback because they know the conversation is private. Allowing the outside world to see what they tell us would alter their comfort being brutally honest- and would negatively impact our relationship with them. (We trust these guys to tell us what they think- and you'd be amazed how candid they can be...)2) Sometimes we have discussions inside the bug reports that include data that is proprietary to one of our sources (Such as a little company named Boeing... ever heard of 'em? They are almost as big as that coffee company up in seattle...) We need to be able to share this data and information privately between members of the development and tech teams in order to suss out and resolve some problems.3) We don't care to share the methodologies and techniques we use to simulate complex pieces of the airplane. For example, we had a WEEKS long discussion going on inside one of the bug reports discussing one specific instance where the autopilot might give up the ghost and turn control of the airplane back over to the pilots. In this discussion, we reviewed a number of the conditions that could cause this and how they were handled internally within the simulator. It is this type of simulation capability that makes our products look act and "feel" like a real airplane- so we aren't going to share that with anyone not in our closest trust.4) Sometimes we make dumb mistakes- and correcting a bug takes three, four or ten tries. We frankly don't want you to see our screwups. :( There were some others- but I've forgotten what they were...Anyway- an example of things that you will notice on this airplane that haven't been modeled in previous FS addons:When you put the engine run switch to CUTOFF, there are a number of things that happen as that engine shuts down. It is easy to model all of them as they are listed in the FCOM... HOWEVER: Rather than just saying "X and Y and Z stop working when you shut down the engine" we actually simulate the PROCESS by which those things stop working, so the hydraulic pump will cease working because the processes that it requires in order to run cease to support the pump... This takes a certain set of parameters, all of which are modeled, so that pump drops offline when it does on the actual airplane. The same is true for the IDG: the FCOM tells you it will drop offline, but it doesn't tell you WHY or WHEN... We have taken the time to research this information and it is accurately modeled.The data that is displayed to show you engine parameters starts changing as an engine is started or shut down. The parameters that determine what is shown and when it ceases being shown are all accurately modeled... That just one example... We have a document with pages and pages and pages of similar examples with actual details. (I've avoided giving you the specifics here intentionally.)It is important to note here that going to this depth in the simulator does NOT make the airplane harder to operate. What it DOES do is to immerse you on the flight deck with a more realistic simulation that not only LOOKS right, but it FEELS right... You will see what we mean the first time you load this airplane and just start moving switches and knobs around. It is hard to explain, but you will know it when you see it!

If you guys could just go ahead and post a link to download the NGX source code, that would great. Thanks.

If you guys could just go ahead and post a link to download the NGX source code, that would great. Thanks.

Yeah, like full svn access? (ok, ok, without commit) :( Robert, how does that level of complexity affects your debuging process, and the stability of the entire system (By system, i mean the aircraft)? Must be a pain to debug such a complex piece of code. Im wondering, how many classes you guys have there :(

Yeah, like full svn access? (ok, ok, without commit) :( Robert, how does that level of complexity affects your debuging process, and the stability of the entire system (By system, i mean the aircraft)? Must be a pain to debug such a complex piece of code. Im wondering, how many classes you guys have there :(

Enough to make for a class act I hope :(

Yeah, like full svn access? (ok, ok, without commit) :( Robert, how does that level of complexity affects your debuging process, and the stability of the entire system (By system, i mean the aircraft)? Must be a pain to debug such a complex piece of code. Im wondering, how many classes you guys have there :(

Juan-Don't let our nice clothes and table manners fool you: We operate completely without class here. :( As far as debugging goes- there are really two different types of debugging that take place:1) Structural: Problems with pointers, memory allocation, syntax, etc. The stuff that has to be debugged in every program no matter what the complexity. We use some pretty sophisticated tools to assist with this process so it is no more/less difficult than with any other program.2) Logical: Problems with the way something on the airplane operates. In some respects the significant attention placed on complete and accuate simulation makes the product easier to ebug because we are using the same tools that you'd use to troubleshoot a problem on the airplane. So for example we recently had a report from one of the Tech Advisers about a problem with the engine driven hydraulic pumps. I sat down with the trouble shooting documents and went through the system step by step, reaching the conclusion that we had the pump output pressure sensor located in the wrong position relative to the check-valve.... Since the whole system is simulated, that took almost no effort to find and resolve.

I sat down with the trouble shooting documents and went through the system step by step, reaching the conclusion that we had the pump output pressure sensor located in the wrong position relative to the check-valve....

Translation: Yes we are that good and the view from the top ain't bad.

Since the whole system is simulated, that took almost no effort to find and resolve.

I actually find it intersting that the "location" of a sensor in simulation can actually matter, given that, as you say, it isn't really located anywhere except in lines of code. Neat stuff.

That's impressive. I can't wait to be lost on this thing and relearn my way around the NG cockpit!

Hi Team!Maybe this is a bit geek but i was thinking... Can you give us access to your bug tracking system? (Maybe bugzilla?) If we have access, we can track the beta bug squashing process, and see the progress. After the product is released, we can use such system to post our bug reports and see bug reports from other users too.I find it very interesting. Maybe because as a developer and avid linux user, im used to such systems.

That's either an incredibly naive or arrogant question--Oh, by the way, PMDG, could I go over your source code??Jack Hancock