BillC

There might be more compliance if the rule were ENFORCED more often?

I would suggest going to your stats on vatsim.net and review the flight in question since the stats server records every change to the flight plan and who or what made that change. This will help identify what is affecting your logged flight plan. On paper it would be impossible for FSInn to do anything with any file produced by ASN or the 777 and certainly not automatically.

Scott, this happened to me a few times. If after typing the message and submitting it goes straight to the "new ticket" page then it seems your message hasn't registered and therefore no ticket number. I gave up in the end after several tries. A couple of other people have reported this and it seems that sometimes it works and sometimes it doesn't but I've yet to see an official response as to what's causing it.

I had this problem at LEMG a couple of months ago, no procedures available for any runway. A couple of days later a v2 of that airac was produced and the problem went away. Navigraph btw.

How did you fix it? This happened to me when the 777 was released and I never found a way round it.

A fair few peoople in here havn't really read what the OP actually said and are assuming what the problem is. My emphasis below: So it's not your FSInn setup since it works ok with other planes. You also say below that FSInn recognises you're transmitting so you shouldn't need to go tinkering with FSInn, PTT's etc. First question is, can you hear the controllers? With mine you can't hear the controllers until the correct mic switch is on so if you CAN hear them then you've probably got the correct mic on and set to COM1 on VHF L. Can I suggest you pop up a screenshot of your radios panel?

I honestly suspect that your problems with this lie elsewhere on your systems. I've been using FSInn with FSUIPC autosaves every 5 minutes with PMDG products (737 v1, 747, JS41, NGX, 777) for years and it's never ever kicked me off Vatsim nor indeed killed the flight in other ways. I wouldn't know where to start looking on your systems I'm afraid but I can promise you that there's nothing in this combination that automatically kills your flights or connections. I've not used SB for about 10 years though so can't speak for that.

Will it have a 2D cockpit?

If you use the cockpit in full screen try switching to windowed, load FSInn then go back to full screen. It works for some but it's a workaround for a problem somewhere else though. NB: Re the advice to load another a/c first, PMDG do not recommend loading other aircraft before one of theirs.

You said it. I would rather the development resource was used elsewhere.

I was getting this on every other flight but since doing a reinstall and rebuild of my custom panel state I've not seen it once. My original custom panel state was built from C&D but the new one was done from the default start-up state. I'm not saying I've cured it but it's certainly not (yet) happened across a number of flights so it's happening a lot less if at all.

You havn't still got your FSInn "multiplayer range" set at the default 150 miles have you? That'd be asking for trouble because your system will be drawing & tracking all those aircraft in it's head even though you can't actually see them, the load would be humungeous during CTP. I rarely have my range above 30 miles and you'll never have 60 a/c in that box unless ATC have bigger problems than you!

Since these issues always seem to relate running FS in full screen (which I never do) I just tried it. 777 at a sceneried airport in full screen loaded from 'fly now' and I got a very unexpected result when loading the Control Panel. It loaded QUICKER than in windowed mode! As I said, I suspect these problems are the result of something other than 'just FSInn' because it doesn't cause such issues by itself IF it's installed and running correctly. My suspicion in this case is actually a graphics issue since in full screen it does initially blank the screen then refresh it on load. What's the betting that with all the rabid fiddling that goes on with graphics settings for FSX that "a tweak" somewhere is causing this?

So am I. That is not normal behaviour for FSInn at all. When running correctly it does not struggle with complex aircraft (or scenery), it just doesn't. I've just done a test. I loaded the default 172 at a non-sceneried airport and the CP took 4 seconds to load. I then rebooted and from 'fly now' loaded the 777 at a heavily sceneried airport, the CP took 4 seconds to load. Identical. So, the solution lies somewhere other than that. FYI, I've run FSInn since v1.0 on 6 different computers (some 'under-specced' for FS), 2 FS versions over 3 operating systems in 9 years and never seen this loading problem so there is something fundamental going wrong with either how it or FS is installed or what it is being given to work with. I'll give a basic rundown of how mine is set up.... Everything runs on the local machine and the same HDD, namely c:. Everything - FS, the various FSInn programs etc are ALL set to run "As Administrator". Everything was installed using "As Adminstrator" - FS, FScopilot, FSInn, all addons, all installers, the lot. All the required modules are cleared through the firewall and all FS folders are listed as exceptions from AV monitoring. FSInn settings: Basic - General - Graphical borders off, Internet online mode off Various - all unchecked Aircraft - Synchronise a/c repository on startup is on, everything else off FSFDT Control Panel - FSCopilot is set to 'specific' and Localhost " FWInn - Options 1 & 2 - all set off " Options - Autostart FSFDT with FS (NOT with Windows) On startup my FSInn is loading 1,794 aircraft which consist of the usual payware add-ons plus the VIP AI set that came as an option with FSInn. NB: it is not unheard of for there to be problems with a rogue aircraft being loaded but that doesn't usually interrupt the startup, it's more likely to cause an issue when one is encountered as one flies. Everything with the one exception of my UK photo scenery is installed to its default directory. I know that goes against lots of people's ideas but I've always believed that defaults exist for a reason and if a default folder causes a problem then fix the folder, not the installation. I never run UAC and I "own" my default FS folder. My suspicion with these CP loading problems is that it's something very basic at fault. Something not set "as administrator", something 'non standard' about the installation or something not cleared through a firewall. FYI the modules that must be cleared through the firewall are: FSFDTCP.exe FSInnUI.exe FWINN.exe FSInnUIVVL Hopefully something in that lot is of use. If not then there is something else on these systems which is causing the problem and we're then into needles and haystacks.

Sorry but I disagree. That sounds like a symptom of something else at play since I and a lot of others have always loaded the desired aircraft direct from 'fly now' and then opened the CP, never had a problem. Btw, I have FSFDTCP set to load as soon as FS starts so that's already in my task tray before the aircraft itself loads.

Are you running FSinn on the same machine as FSX or networked? If networked then your start delay could be to do with how you've configured the networking part. I run it on the FSX machine to minimise any potential issues and there's no notable performance penalty (on my system). FYI I always run FSX windowed because I use two screens and have loads of windows open on the second screen (incl the chat & atc windows from FSinn). You can minimise frame loss by a) Using the Mini CP and b) Turning off the FSInn graphical borders.

I'm not seeing this issue at all, FSInn starts up just fine from the menu bar having loaded the 777 from 'fly now'. Have you checked your dll.xml to make sure FSCopilot is the last entry?

I've had AP disconnects in the cruise 3 times now. The beta guys suggested a controller spike which is something I have never suffered from in any other PMDG a/c. Anyway, I added spike elimination into FSUIPC and it's now happened twice since. Each time the horns go off; LNAV, VNAV, AP remain lit and the aircraft starts to climb dramatically and above MCP altitude. Meanwhile "autopilot disconnect' is illuminated. On all three occasions I hadn't touched the aircraft for quite some time, it was just sitting in the cruise. No idea what's causing it but next month's CTP is going to be a nervy affair with minimal trips to the fridge (which is bad news). p.s. FMA reporting correctly in all cases.

I tried to raise a ticket on Friday morning (UK time) re a particular 777 issue, I checked this morning and apparently there a no tickets against my support login. I managed to reproduce the problem yesterday and since apparently I have "no tickets" when asking to send current tickets to my e-mail I tried to raise another one with more information and a screenshot. I just checked and again it says "no tickets". I don't have a ticket number for either attempt so all I can do is click the box for "send tickets to me e-mail address" which just says "no tickets". I know the system did work because I had a ticket on the NGX previously but at the moment I just don't know if my issue is in the system or not! Help? TIA!

This sounds very similar to a problem that I have raised a ticket for when my ND, PFD and EICAS all froze in mid flight but everything else continued normally with the CDU updating correctly and the a/c continuing to fly the route properly. I was cruising on LNAV/VNAV at the time and a momentary switch to HDG SEL and back to LNAV 'unfroze' the displays. I've managed to reproduce it too. It's obviously not the "long pause/freeze" that's been reported by others since that seems to relate to a total freeze of the simulation which this clearly isn't. Same as you I don't suffer from OOM's or any other FSX crashes. Btw, I say I've raised a ticket but I'm not sure it registered since according to the support system I don't have any tickets currently.

I have now left Z as the disengage, put "Resettable Siren" to YES and clicking the Master Caution button does then silence it. I don't use C & D.

Sorry to contradict David but I am getting a good 15-20% better with the 777 with similar Performance options set to my NGX. Obviously such things are always system specific but I have been delighted with the performance. I do realise it's not the same for everyone but it does illustrate that PMDG weren't necessarily making false claims.

In that case, Dan, we need to nail what conditions will cause this - you've had it twice, I've now had it, as have others, and my weather is also smoothed so that FSX own so-called Weather doesn't cause issues (with anything else). I've been at this lark long enough to know that the disco I had isn't "normal" on a system set up to avoid such grief. The Woodpigeon development process has dragged on too long. FSLab's version will be out before PMDGs :unsure:

Hmm, "Never" for A/T override as I am set should mean that manual throttle "never" overrides the A/T and I just tested it, in the cruise I waved the throttle up and down with wild abandon and nothing happened. As far as I am concerned that rules out that setting. Ref weather, that was the reason for original post, would a slow reversal of winds (smoothed by FSUIPC) trigger an AP disconnect? If it does then the 777 is more sensitive to such things than any other PMDG I've spent hundreds of hours in. Incidentally, at the time of the incident in question I was totally hands off everything, mouse, k/b, joystick, PTT's everything. I never use time compression. I do agree it might well be a weather effect but with smoothing on it shouldn't be unless, as I said, the 777 is far more sensitive to it?

No trim axis assigned, default keyboard setting for that. "A/T Manual Override" is of course set to "Never" which is the totally intuitive setting for it (as in "never override the A/T"). That's how my NGX is set and that has never had a spike problem, in fact I've never had a spike problem in anything! Are you saying that "Never" means it CAN override if it gets a spike? Ummmm, why?