Captains-

 

A quick update so that you have an idea what is cooking behind the scenes....

 

We are hard at work on SP1b, which is a essentially a stability update for the PMDG 777-200LR/F and PMDG 777-300ER **software**, and also a stability update for the airplanes themselves...

 

I have mentioned previously that we are not currently engaged in a "lets add 3,000 new fixes" development cycle- instead we are focused on making this a quick-hit to stomp out some items that did not appear during testing but have appeared in release.

 

I had thought we would push this update to you last weekend but a confluence of events conspired to prevent that from happening- and we are currently looking at this weekend, but it will depend entirely on what feedback we get from our beta team on Thursday and Friday.   (We occasionally find that things break when we fix stuff... and those breaks are normally worse than the condition we were fixing...  Last week's build update was a textbook case of this behavior... it is a very good thing we didn't give it to you!)

 

Right now the SP1b is planned to improve the stability of the product be eliminating the "Cockpit Display and VC and flight control freeze" condition that we were able to identify with user feedback.

 

The SP1b also improves the stability of all three 777 types in the pitch channel, with some minor enhancements to the flight model of the 300ER.  We have eliminated a couple of CTD conditions, and performed various other minor improvements- almost all of which improve either the airplane's flying qualities or the software performance and stability.

 

This build has been wrapped up and is in the hands of our testing team who will tell us if it is safe to issue it to you- and then we will shift gears to another update that will be called SP1c.

 

SP1c is going to be collective update to kill off one or all of the following:

 

PAUSING BEHAVIOR OF FSX:

We continue to collect data on this topic.  We are not yet prepared to make any conclusions and we cannot make any firm recommendations for mitigation yet- but we are getting closer due in large part to the number of users who are reporting information here or working directly with our tech support team as we investigate.

 

What we HAVE been able to determine through the use of normal debugging techniques combined with some very advanced diagnostic tools and some in-house developed methods is that these pauses happen outside the 777, or- to put it in layman's terms- "the pause is happening when the computer is doing something else outside of the 777 code/dlls." 

 

The reasonable person might point out that they do not see them when using airplanes OTHER than the 777- and this is precisely why we are continuing to investigate.  While we are very comfortable reporting that the pause is not something latent to the 777- we very much want to know why some users see this when running the 777 even though the vast majority of users do not.

 

Some users see these pauses with many different addons, some see them only in the 777, and some never see them at all.

 

We WILL figure out what/where these pauses are happening, and we are relatively confident that once we put our finger on the particular factor we will be able to make recommendations to you that will mitigate the problem.

 

Stay tuned on this one...  We are just as eager to solve it as those who are impacted by it.

 

HEADING SLEWING DURING ACCELERATED FLIGHT:

This one is another area that we are chasing down with the user of some specialized tools that we have installed on various users machines to collect data that will help us to localize and kill this annoying little feature.

 

What we are seeing in many of the "wing wagging" users is that the heading data becomes corrupted and the airplane is unable to accurately calculate it's trajectory over the ground.  Once it loses this ability- it begins to wander all over the sky during accelerated flight.

 

We started out with a theory that "something is causing simconnect data corruption" but we have partially ruled out that theory after seeing some data off machines of affected users.

 

We are on about our fourth iteration of test methods installed on user machines to collect still more data- because we really would like to know why the original v1.00 777 wasn't impacted by this problem but the SP1 version experiences this problem, but only on some user's machines...

 

The number of users reporting this problem is exceedingly small in terms of percentage of users- but there are enough users seeing this problem that we are confident a wide data collection effort will highlight the pattern that eventually solves the problem.

 

I know that some users are frustrated that we don't crank out new updates at the snap of a finger- but this stuff is very complex and solving these issues in many cases means developing test tools to collect data from user machines, analyzing the data, refining the collection tools, etc.

 

In some regards we rather enjoy this process because it does put us into direct contact with end users and it gives us a chance to show someone first-hand just how hard we work to make these products as fine as they can be for end users.  It is a long process- but this is our product and we feel it is very important to do whatever is necessary to make certain that it works for you- even if that means solving problems that aren't necessarily ours... 

 

In case you think this is fun:

There are days in this process where it is hard to contain our frustration.  For example, we began to get reports of a particular problem that was being experienced by a subset of users.  We found through data collection that these users all had a single add-on application in common, so we assigned one of our most highly skilled developers to the task of unwinding the problem between the 777and this addon app.

 

After a few hours of research we began to wonder if the developer of this particular app had made some assumptions based on the NGX SDK and decided to "hack" memory addresses in order to accomplish the task of controlling a function within the 777.  We reached out to said developer and were assured that this was not the case, but after nearly a week of developer time (about 80hrs, for those who are counting...) we found a couple of forum posts in which said developer boasted that he had used the NGX SDK to hack memory addresses in the 777 in order to....

 

Yes...  Precisely what we had asked in the first place... 

 

It is unfortunate that we were not answered honestly because instead of using **our** developer to back up the guys working on the pause/wandering problems, he was wasting his time chasing his tail.

 

You can't make this stuff up, as they say....

 

Okay- enough blithering from me....

 

Stay tuned- the moment we are confident in this updated package, we will let you know how to get it, how to install it, etc...

 

Thanks again for your patience- and for all of you who have been working with our support team to collect and share data with the development team- your participation is very valuable and very much appreciated!

Good news

Thanks Robert (no problems with my 777, anyway). A prayer: in the meantime could you also fix the issue(s) affecting the SDK, so that Bryan can finish and release FS2Crew? The 777 is a 2 pilots airplane, a copilot is desperately needed!

Thank you!

Looking forward to fixing the time acceleration problem for those of us affected soon.

 

Francis

It must be frustrating, Robert: fixing something (yay!) then realising you broke something else (oh, crap!) and then fixing that (yay!) only to realise you broke something else... again (oh, double crap!) and so on and so forth.

Seriously you guys do a great job. I can imagine how complex this stuff is and how difficult it must be to fix this  bugs  eeh features. PMDG one of the company i will never lose my trust. 

 

And remember.

 

Excellent news, Robert. Looking forward to the update.

 

Regards.

Look out for my upcoming thread "How NOT to become a beta tester".

 

And, even more important, "How NOT to become a coder"!!!  

Nice. Cheers for the update.

Thank you very much for your frank statement.

 

I am one of those affected by FSX pausing, but it does not really prevent me from finishing a flight.

So I am patiently waiting for all the fixes, especially the obvious one, being all the time impressed by your professionalism.

 

Being a fan of 747 and A340 (I'm a quad-jet lover) I never thought I would really enjoy flying 777.

But your product is so good that it is changing it and I am having more and more fun with two engines. :smile:

I started flying long hauls again and due to the lack of enough spare time the 4x time compression comes in handy.

 

Thanks again and take your time.

Thanks Robert and to whole PMDG team. 

 

Happily supporting a great company like PMDG by buying its products. 

Hope we can sort out this 777 stuff soon to focus on 747 v2.  

Thanks for the update !

Thank you very much for your frank statement.

 

I am one of those affected by FSX pausing, but it does not really prevent me from finishing a flight.

So I am patiently waiting for all the fixes, especially the obvious one, being all the time impressed by your professionalism.

 

Being a fan of 747 and A340 (I'm a quad-jet lover) I never thought I would really enjoy flying 777.

But your product is so good that it is changing it and I am having more and more fun with two engines. :smile:

I started flying long hauls again and due to the lack of enough spare time the 4x time compression comes in handy.

 

Thanks again and take your time.

 

I second that. I am somehow relieved that the freezes are being investigated. I've tried everything: tweaking, GPU and processor fan control, the pauses are just 10 minutes long and just heart shattering, 

 

Other than that, the PMDG 777 is something the programmers who worked on should be very, very, very proud of.

Thanks for update, Robert! 

Thanks for the update, Robert. Yet another one looking forward to a flight without the pauses. ( my first few were OK, then.......... )