craig_read

Wikipedia.. is.. brilliant... so there... lol

https://en.wikipedia.org/wiki/Precision_Manuals_Development_Group Out of interest how accurate is the above?.... Well I say 'how accurate' obviously since it's a Wiki it's 100% accurate without question, I blindy and without question believe Wiki pages as it doesn't have things wrong it has 'potential inaccuracies' which are completely different. Have you guys got dates for the beta entry for your previous products or would someone (with more patience than me) have to go through the forum looking for the old topics?

Not wanting to contradict, and I may be mistaken, but I believe I heard in the interview that Tech Testing was going well. A lot of things had been uncovered and now Tech Testing was nearing completion. RSR also said it is perhaps the most thorough Tech Testing run they've ever had and consequently was optimistic for a shorter beta (I stress, this was just optimism, not stating it would be). I think I heard 10 days or so for moving from full blown Tech Testing to Beta Testing, but again believe this is an aspiration at this point. Based on this it's not unlikely that we'll get an RSR update end of the month, but nothing is in stone.

Thanks for that Kyle, I will try to put this into practice, do you think it's something that gets filled out during flight or more something that's done if the situation arises?

I'm trying to understand the data that's entered into this page, see below: http://www.theairlinepilots.com/forum/viewtopic.php?t=756&sid=7c16c0bc5b8c6e6e08df8215f39ae4b5 As with the 777 FMC here there is a page 2 for each alternate in the list. The interested areas are WIND and ALT/OAT, but which level is it refering to? Is it an expected level for the flying portion of the diversion, so for a field significant distance this could be say 20,000 feet or more, or is it conditions at say 3000 feet above the field. I'm trying to understand and I've done an extensive search. I assume it's used for fuel calculations for routing to the field. Is it an average wind and temperature component for a given altitude? If someone could give me a view and perhaps some examples of how it would be completed that would be great! Cheers Craig Read

This might be because of your download rate? I install all the liveries and it doesn't really take that long. I think in my last re-install (was a while ago I must admit) I just downloaded all liveries for all 737 and 777 variants for P3D in a matter of about 20 minutes or so. To be honest most of the time was spent clicking on every single one to install individually. Which leads me on to..... If I might make a request that's along the lines of the OP and I would hope very simply to implement, could we have a button for "download all" in the OC for liveries for an aircraft? I never bother differentiating between liveries on install and have plenty of capacity so I quite like the choice I get at the end. Cheers Craig Read

HI, Currently I'm running a i7 with 8GB RAM. I run two separate SSDs one for P3D / FSX and one for the OS (Windows 10), I will probably by another one for X-Plane and run it on it's own drive. I have a storage drive on the machine too of 1TB, but storage isn't really a problem as I have a NAS with a lot of capacity. It's the memory I'm considering most, my current PC has this installed: CMY8GX3M2B2133C9R - 8GB (2x4GB) Corsair DDR3 Vengeance Pro Series Red, PC3-17066 (2133), Non-ECC Unbuffered, CAS 9-11-11-31, XMP, 1.65V I was considering jumping this up to 16GB, not for P3D or FSX but because I'm considering adding X-Plane to my machine as an option. Looking at memory prices another set of this RAM for my 2 other slots works out marginally cheaper than this: CMY16GX3M2A2400C11R - 16GB (2x8GB) Corsair DDR3 Vengeance Pro Series Red, PC3-19200 (2400), Non-ECC Unbuffered, CAS 11-13-13-31, XMP, 1.65V My questions for you all are: 1) Am I wasting my money going up from 8GB to 16GB as far as X-Plane is concerned? 2) Is it better to just buy more of the same or simply replace with 16GB of the new stuff here instead as the cost differential is quite low. Thanks for your help! Regards Craig Read

John, Thanks for the replies will definitely look into the ALTN ALT selection etc. BTW and just for your interest I got to the bottom of the ABEAM issue. Apparently the problem was that the ABEAM point on the route was an arc i.e. a turning point at a waypoint. When I put in a sudo point before it to make that part of the plan straight the ABEAM went in no problem. This point was more than 700nm from current position so I think the restriction you mention isn't in place here. Does anyone know if the real 777 does this? I would have thought it could still do an ABEAM even if it was on a 'bend'... Cheers

Hi, I'm trying to put in some situational awareness into my flights so using the FIX and ALTN pages a little more than I did. My plan was to enter my alternates etc. I'll start the with the ALTN page question: When entering an alternate and then selecting the details of that alternate the following data can be added: WIND ALT/OAT This is basically the selected wind and OAT at a specific altitude, is there any logic used to select this altitude? Should it be the altitude expected at that point in the plan or a closer to ground level altitude to give a view on surface winds? ALT in the top right seems auto calculated, can someone tell me what this is? I've looked in the FCOM and it says that it's an entry of any valid altitude or flight level into this line and it causes a recompilation of ETA and arrival fuel. So for example if it was an ETOPS fuel and I was half way over the pond would my current cruise altitude be a good choice? Onto the fix page, selecting ABEAM on a fix seems to be 'playing up'. One I figured out what was happening and I was trying to select abeam on a point that was actually in my plan (my bad) so I totally understand why it was an INVALID ENTRY. However there is another field I am using some 60nm from my track and when I attempt to select ABEAM it says "INVALID ENTRY" and I have no idea why. Could it be because the perpendicular line probably intersects at a point where the aircraft is turning? I would have thought it would cope with this.. is this how the real 777 behaves then? Cheers Craig Read

Hi, I've been watching quite a few videos lately of the Boeing 777 and I've noticed that there are a whole raft of options built into the electronic checklist system such as 'PA Announcement' for Air Canada. Also they seem to move things around to suit the carriers style of operation. I think this has been mentioned before but does anyone know if a future expansion of the 777 to include the other variants would potentially include a electronic checklist modification to allow incorporation of carrier specific checklists? I mean it's not a show stopper by any means but I am curious as to the PMDG view on this one. Out of interest, the current setup for the checklists, can anyone tell me what carrier this is based on? Or is it a 'standard' that Boeing impliment in the case where carriers have no specific checklist requirements? Thank you Craig EDIT: ah ha! It seems it was, but this was some time ago, does anyone know of any updates to the position here? http://www.avsim.com/topic/419083-pmdg-777-electronic-checklist/

Obviously there are 3 main options here, 1 limited to use on IVAO only of course. I'm simply trying to determine which of these options is the best one. I've had a look at the IVAO MTL tool, which seems a bit buggy to me (windows 10) as it sometimes shows the AI Model list and other times doesn't when you start it. It seems to install fine and using IVAO I can see the traffic models, I wasn't overwhelmed with them though I must admit which has lead me to looking at uninstalling and using another option that will also give me the flexibility of online platform. What are the general thoughs? If you had a blank canvas and the money to buy an appropriate Traffic model set e.g. UT2 or MT6 what would you go for and why? Any help / opinions would be appreciated. Regards Craig

I hope I don't offend anyone but I thought I'd just put in my 2 pence here (notice pence, British you see). I think sometimes on forums it's difficult to tell 'tone' of a response and things can be read in very different ways; sometimes offense can be taken when none was meant and this is one consequence of this form of communication. In my humble opinion, the original post was quite open, relaxed, non-critical and seemed to me to emphasise that it should be taken in a light hearted fashion with a 'laughing' emoticon at the end making this as clear as it could. I feel that light hearted posts should be met with fairly light hearted jokey responses, and if you read Kyles post cold you would be forgiven in thinking it doesn't come across that way (no offense Kyle ). Taking this post aside, and being sympathetic to Kyle (there are always two sides), he is very good with responses and tries to the best of his abilities to answer questions posed here, however there are times when comments by posters are inflammatory, often deliberately so. I can only speak for myself but I know for me this would really grind my gears (family guy reference) and perhaps my frustration would come out in short curt responses when a more relaxed approach would have been better, but meh, I'm human. For what it's worth, I don't think it's a 'bug' either, but the OP makes a useful and valid observation, I think for testing purposes having it remain operational in flight is also useful too. Regards

My FMC Nav app shows I have 1602 V1 installed, I'll probably wait till the next version and go from there.. at the moment I am having to fly the transition on fixes.. not a problem but it would be nice to be able to programme it properly.. Thanks for the suggestion though I will try this on the ground shortly! Cheers

It's being caused by selecting specific transitions I think. If I leave the transition out from the approach it works fine, with it the routing (magenta line) jumps around and never settles. Obviously the majority of transitions it is fine with.

In my humble opinion the PMDG 777 is probably the best simulated aircraft out there. It's in a class of its own really, so should you buy it? Yes. The expansion is well worth it too, I fly a mix of the ER and LR. Other than this the NGX is fantastic and if you fancy something different the Majestic Q400. Again top class and very different. As for where to get it, personally I would just pay the little extra and buy it from the PMDG site, it'll probably save you hassle in the long run with updates and the like, and frankly (and this might not be popular) it's cheap at twice the price. I used to prefer boxed versions of software but now prefer instant downloads with a safe backup elsewhere. Get it, you won't be disappointed. Enjoy

http://www.avsim.com/topic/432377-vnav-preditced-altitude-not-show-on-fmc/ This post seems to be similar: IRS Aligned, flight plan entered weights set, perf page set with cruise altitude set. GR WT 260.5 FUEL 56.4KG CALC ZFW 204.1 RES 10.4 CRZ ALT 340 COST INDEX 95 CRZ CG 7.5% STEP SIZE RVSM Seems ok to me, this is how I've always set it up and I've had no problems. When I look at the Legs page I see the speeds and altitudes for a split second then they disappear. On VNAV Page 2 my step at flickers between 0241z/1739NM and NONE, and it won't settle, FL360 sits within limits for the cruise. Setting the step to 0 calms the page, when I go back to the legs again I see the speeds and altitudes, they flicker then disappear. I can turn on VNAV and it illuminates, only to disarm moments later. Manually setting the STEP to 2000 makes no difference either. PROG page flickers, that is ETA and FUEL (values and top labels), DTG and TO do not.. TO T/C indicated at 2321z/ 113NM this too is flickering. Manually entering the step climbs into the LEGS page again puts the altitudes back temporarily and then they disappear again. Can someone enlighten me as to why it's doing this? I've also just tried to save the panel state and it won't let me, I put TEST into the scratch pad, select the filename field and nothing... sometimes it temporarily illuminates EXEC but then it extinguishes and I can't save it.. hmmm... Yep definitely broken it won't let me load panel states either.. restarting P3D again Cheers

Hi, I've had this a few times now and it seems to be somewhat random in when it occurs. But I'm programming the FMC for a flight, everything is going fine, however I can't engage VNAV at the gate. When I look at the FMC the FMC generated altitudes appear in the legs page, they flicker once, then disappear. No matter what I do I can't get them to stay there! I've tried re-aligning the ADIRU but nothing seems to make a difference. Basically once it's done this once it just continues to do it all the time. The only way I can get out of it is to restart the flight completely, loading P3D again and then it's fine again. Is anyone else seeing this? Cheers

I can only assume then that the makers of PFPX are making reference to the fin number in the aircraft database, and should consider renaming that field to save confusion. It would seem superfluous to have a "Registration" field and "Tail Number" field per aircraft. I've also got the lists of 'fin numbers' for other airlines now

Correct me if I am wrong, one of the reasons I go slightly off topic is because I'm trying to learn about this, but tail numbers and registrations aren't the same thing are they? A lot of airlines don't bother with tail numbers at all (American Airlines and United included, the tails are blank), but all aircraft have registrations; this is the reason why PFPX has a separate reg and tail number field for each aircraft. I can't think of many airlines that actually use tail numbers, but my understanding was that it is a quick and easy way to identify aircraft using 2 or 3 characters rather than the full reg. British Airways definitely use tail numbers for their fleet, so if you look at G-STBB (a PMDG paint for this is available in the Operations Centre) you'll notice the reg on the back (G-STBB) and also at the top of the tail, it's tail number 'BB'. I think Air Canada and Delta do it too; in the case of Delta and BA they often resemble the reg or are an abbreviation of it. But I have seen some that simply don't resemble the reg at all (although I can't think of a specific example, typical huh) but consist of what appear to be random numbers to the observer such as '706' or something when a reg is all alphabet characters. I imagine for the airline they have some significance but bear no resemblance to the registration. If my understanding is wrong I'd appreciate being corrected, I mention this because I am pain stakingly entering all the PMDG liveries with accurate data where possible, including tail numbering where it's available. Next trying to find accurate ETOPS numbers per aircraft and equipment lists, ETOPS seems almost impossible to find actually, often just the 'general' max available is published and never specific ETOPS ratings for specific registrations (as I know they vary even for the same type for the same airline depending on the required maintenance programmes). Anyway I digress. PLEASE, correct me if I'm barking up the wrong tree and have made a silly error. Being wrong and shown the right path is just as important, I have no ego to bruise.

Rick, Ah ok, you see counter to that I often like to multi-task for efficiency (sometimes to my detriment I would concede) and I was in the process of installing both the 737 and 777. I got both aircraft working and activated within the P3D simulation, installing the most up to date versions and then wanted to batch install all my liveries for both aircraft while I did something else. Hence wanting to queue the whole lot rather than break it up on aircraft type and have to come back and queue up a whole bunch of liveries again for the second type. I guess what I am saying is, and with all due respect, I think that is also a perfectly logical approach because I am not prevented from doing so by the menu system. Like I said this is trivial and by no means am I criticising. I like the Operations Centre and this is likely an edge case not seen by many. I imagine this hasn't been spotted before by others or it is known but low priority for a fix (which is completely reasonable). But in my humble opinion, and operations centre aside because this isn't about that specifically, software shouldn't 'crash' when a user does something valid or un-prevented using the menu system within that application. If you have a known error state that will occur when using menus or want to force a specific way of doing something to prevent one, the software should force specific conditions e.g. using this case purely as an example a popup message perhaps with "Do you want to cancel the queued downloads?", and if the user clicks yes the software simply stops downloads and then allows the user to move to the next aircraft type in the menu prevents the crash, or alternatively the software allows the user to change their menu without deleting the queue with no message, either would prevent the crash condition. Consequently I believe this to be a bug, but as we all know bugs have different priorities and I will stress again that I don't consider this important, it's simply an observation I have made and I think it's good to provide that information to the developers, as I like to get from my users with my work projects. It's often a case of "oh, you know what, we missed that.. do you mind if we sort it later on because it's no biggie?" often the answer from said customer is "oh we don't really care but just thought we'd say, fix whenever".... this sort of bug is certainly not critical! It is something that can be lived with easily, or if fixed, is done so when a developer is home alone, bored, there is nothing on TV, they don't want a short nap, have 2 hours to kill and the beer fridge is empty. Regards Craig Read PS: I don't want to get off on the wrong foot; I think we just have a different point of view that's all and I won't labour the point any further.

Did you switch from the 737 to the 777 while 737 liveries were still Queued?

Just to clarify, I didn't say activation through the Operations Centre was a bug (so I agree with you); that along with the "install all liveries" button were both marked as 'suggestions' in my post, not bugs, I made what I thought was a very clear distinction for the team. What I think is a bug, is during install of liveries within say the 737 i.e. I have a number of liveries 'Queued', if I am to select the 777 (because at the time I wanted to start installing those liveries too and thought I could simply add those to the 'Queue' as well) I have found that the application crashed. As originally stated, this is minor, but perhaps hasn't been spotted before. Regards

Hi, Before I start this is quite minor but I thought you might be able to look into it as a developer if you happened to be home alone and the TV was broken. Potential Bug?: Whilst having to do a complete re-install (because windows decided to turn itself inside out) I was re-installing my PMDG aircraft into P3D v3.1 and using the operations centre (which I really like actually). I was adding my liveries in the 737 liveries section, selecting download, and queing them up for install. The process was working fine, while that was going on I thought I'll do the 777 liveries too so went to that page and the Operations centre crashed and I had to restart. Thought I'd mention it, it wasn't a big deal as everything worked fine once I restarted. Suggestion 1: I like some people like to have all the liveries loaded, disk space isn't a premium on my machine and I install the lot so I can have a bit of variety. If you feel inclined, and obviously as long as it's a feature many of us would like, perhaps a button that simply activates all the downloads for all liveries could be added? Suggestion 2: Not sure how this works but another good option would be to be able to activate products via the operations centre directly rather than having to load the simulation aircraft individually in the sim and activate there. This would make activation a lot easier in the case of re-install, also a view to show which products are successfully activated would be good (for numpties like me that activate things using the wrong keys and then wonder why it's not working but need to restart the sim to find out if it worked in the first place). Hope this helps, during the next update I'd be interested to hear how the Operations Centre will be expanded, I think it has great potential as a tool. Cheers Craig

Hi, I believe I'm suffering from the crash many others are when they use their PMDG 777 aircraft within P3Dv3 after 3 hours or so. I'm not posting here to diagnose that crash more a question on how to get information out of my event viewer. I know how to open event viewer and view the log information for applications, security etc and what to look for, what confuses me is that I can't find any record at all of the P3D CTD I am experiencing so it makes it hard for me to understand what's going on. I've downloaded AppCrashViewer and I still can't find any record of the CTD I get. Can someone perhaps give me some clues as to what I am doing wrong here? I can find other crashes such as PFPX falling over or other apps, but absolutely nothing for Prepar3D. I'm looking in event viewer around the right time the crash occured, I've done searches, I've installed the crash viewer and still get no further. Any pointers would be appreciated, I am hoping this can help me diagnose the issue. Regards Craig Read

I'm not normally one to contribute to such posts as frankly I don't really see company pricing as any of my business. I thought I would add an opinion that might change some minds or prompt thoughts. I don't really have an issue with the fact that PMDG charge for their P3D and FSX products separately, speculation suggests that they are very similar and this may well be the case, but pricing of products isn't just about the development and manufacture, they are also as much about risk and exposure too. I recall a company that made cabling (not going to mention names or specifics but this probably has some relevance) for various applications. As a consumer you could buy a cable product (a simple highly re-enforced cable of about 2m with mil-spec connectors) for a very small cost if you wanted, say £30, but that exact same cable (absolutely no changes) was used on a system where it became a safety critical component. The price of that item in that circumstance didn't double, triple, even quadruple, that price was literally 100's of times more expensive. The reason was simple, risk and liability and the steps that needed to be taken to ensure it was 'fit for purpose', a statement that could be proven in the event of failure. If we were to adopt some of the the logic expressed in this forum on this topic here, the manufacturers of systems that utilised that cable component would complain visciously and feel they were being taken advantage of, but they didn't. They didn't because they knew the manufacturer had essentially accepted a specification laid down onto them and the risk, liability and exposure that went with it, this in itself had tangible monetary value. I'm not suggesting that PMDG software is in some way 'safety critical' or making a direct comparison. I am merely demonstrating that just a change of use without any product modification at all can legitimately have dramatic affects on the price. If the purpose of P3D is different to that of an entertainment platform (FSX) then there are different exposures, liabilities and risks that also need to be considered in the pricing. P3D is intended for training use, and consequently (although not necessarily massively different in it's 'mechanics) is a different 'environment' altogether for developers. I hope this view doesn't make me unpopular amongst some posters here, it is simply my opinion, nothing more. Regards Craig Read