cfsops

@Kavinda, much of what I did with Flight revolved around automating the internal build. That functionality isn't available in the release build, so none of the utilities would work. I did a debugger that would be usable, but if you need a debugger it would be better to use something like NTSD or Windbg, which are freely available from Microsoft. What sort of tools are you looking for? If there's a specific requirement, I might be able to help. Edit: to avoid misunderstanding, if there is a specific tool requirement, I might be willing to create or help create such a tool in my spare time.

It is a lot refined. One of the people you all know from here did a huge amount of awesome work on the graphics code and is responsible for a great deal of the performance improvements seen with Flight. The phrase "flight technology" refers directly to the Flight game. Anything else would rightly be referred to a "flight simulator" technology. Prepar3D is based on ESP, not FSX, and is for commercial rather than entertainment purposes. While ESP has some relationship to FSX, the two are separate products. That's interesting. Where did you hear that?

I don't think this is as "dramatic" as it appears. The 767 was landing on runway 2, which is 8333 feet long. The A340, given it's direction and angle to the camera, is using taxiway M, which crosses runway 2 nearly 4000 feet from the start of runway 2, according to the airport diagram. The 767 appears to be at least 100 or so feet off the ground. Assuming 100 feet and a 3 degree glideslope, it may have been as far as 1900 feet from the runway. Assuming 50 feet, it would be about 1000 feet from the runway. So at the time the 767 performed the go-around, it was easily nearly a mile away from the A340. The 767 is a 767-3Q8ER with a landing speed of 145 knots, or 167 mph, or 245 feet/sec, according to Boeing documentation. Had the 767 continued it's approach and landing, it would have taken at least 20 seconds for it to reach the taxiway crossing. Even longer since the plane would be braking after touchdown. Though it goes out of frame, it appears to be off the runway about 10 seconds or so after the 767 began climbing out. I'm not suggesting the go-around was uncalled for: in my opinion, a go-around is appropriate whenever the person flying the plane believes it's necessary. In my opinion, the 767 crew exercised superior judgment by choosing to go around under the circumstances. I'm only saying that the planes were not as close as they seem in the video, nor as close as the "media" wishes people to believe.

Very cool. I'm glad it's working for you now!

The directory that you've added to the project is wrong. You have specified "inc\SimConnect.lib" and the library does not exist in that directory. The correct directory is "lib\SimConnect.lib".

Here is the USA Today article. The AOPA, however, doesn't agree with Mr. Frank's story. Here's the AOPA release.

While the timing of this may have suggested the possibility of an E3 announcement, it's also possible the timing is related to the end of the Microsoft fiscal year; trying to get the revenue booked by the end of the month.

10 million isn't that much, considering. That would be just 200,000 users spending 50 on DLC over that 5 months. Those are not "the" numbers, they just nice even ones that I plucked from the air.

From the annual Entertainment Software Association (ESA) reports that are based on NPD data, it's clear that the kind of game with which people occupy themselves is changing. These numbers provide insight into how we can try to introduce new people to the world of aviation through the simulator. But I don't think that the user base is shrinking in any significant way. In fact, I'm encouraged by the demographic spread of numbers that Tom showed in the graph of survey responders. I am one of those! I started out on IBM iron and S/370 Assembly. Though they aren't used nearly as much, they are certainly still around. There is an emulator available that allows one to run any of the older systems, (MVT, MFT, MVS, VM, DOS/VSE), on a PC. Cool stuff. It would absolutely not be hard to do. The flight simulator, at least, is/was in a position to be able to provide solutions for different kinds of users by simply presenting the product in different ways. Those numbers are way too big.

I think one basic problem is the lack of connection between potential investor(s) and the people with the knowledge and ability; the people with money don't have the knowledge and the people with the knowledge don't have the money.

Exactly. And KSFO and the Colgan Air thing, too.

I respectfully disagree. It is true that no one is going to become a billionaire selling a flight simulator, which means that the potential investor pool would be pretty small, (most investors understandably want to make lots of money). But there is enough money to be made to support a relatively small team and turn a profit. I don't believe the community is all that "picky" with regard to what it wants and expects, but it can be rather adamant about what it does not want. There will always, hopefully, be arguments over features and functionality. I say "hopefully" because it's that sort of discussion that propels development progressively forward. The same thing applies to competition. Both help all products become better and that's good for everyone. I think users can and will allow for issues with a given release, as long as they trust the development team and the direction they're going. In the end, as long as you're not looking to become a billionaire, it would be a solid investment.

If they are really good programmers, who have a lot of experience with the code, who care about the product and who work well together, then a small team can be most effective. It's certainly true that it can take small teams longer to implement features, (it's not just about new features, it's also essential that existing code be maintained), but that's where the users and communication with the users becomes critical: users need to be able to not simply buy the product, they need to be able to buy into the direction the team is taking the product.

Very rough count, off the top of my head, is around 25, +/- a few, that were FS-only. Bill is correct above, the "Core" or "Platform" team was the fourth group. With regard to credits, that document will list anyone and everyone who had even the slightest involvement with the product during the production cycle and doesn't reflect the number of people working on the product at any given time. Of the 24 initial members of the Flight team, 22 were from ACES, (9-FS, 10-Core, 3-TS).

Ok. Glad to see things are working for you now.

I've no idea about X-Plane, but the Flight team started with 24 people and had only about 54 at most at any given time. With regard to ACES, it should be remembered that three products were being developed by that team, Flight Sim, Train Sim and ESP and internally there were actually four different sub-groups. That makes the number, perhaps, a bit more reasonable.

Could you clarify exactly what exe is running? You say "FS9-32.exe", but that's not the name of the FS9 executable. In the task manager, the process would show as "FS9.EXE *32", assuming the original name of the executable. Was "FS9-32.exe" a typo, or is that really the name of the executable?

When ACES was shut down, there were 127 people on the team. Very few of the people on the ACES or Flight teams were on the team because it was "Microsoft". Most were there for the same reasons that most people are here, a passion for aviation and the vicarious experience of aviation through simulation.

Let's say that I have some experience with it. Regardless, I will bow to your deeper understanding and return whence I came. My sincereset apologies for any disruption I may have caused.

Note that fsx is a native app, not a managed app; it does not use the .net framework. There is a managed interface to simconnect, which does require the .net framework, but that's it.

Then I would need a buy a really big shovel. lol. There was a lot of potential. Very disappointing for those who were willing to give it a chance. I'm sure that support is appreciated, though.

With respect to FSX itself, you'll have a conflict with data stored in your profile directory, i.e. %ROAMINGAPPDATA%\Microsoft\FSX. You could have a dozen different copies of the app sitting in different directories, but they'll all be wanting to use the same information, (i.e. FSX.CFG, Cameras.CFG, DLL.XML, etc.). There is also stuff stored in ProgramData\Microsoft\FSX that would be a problem. And then there's the additional issue of the information stored in the registry that may be used by add-ons.

Yeah, the font is hard coded. Technically, you could change it, BUT you would have to use a hex editor to modify LANGUAGE.DLL. Moreover, the font is used for things other than the SHIFT+Z information, so changing it would probably mess up other things.

Font change, no. The colors can, however, be changed. In the fsx.cfg file there are TextInfo.x and SlewTextInfo.x sections that define the different levels of information for slew and non-slew mode. For example, here is what the first non-slew level section looks like: [TextInfo.1] Latitude=1,1 Longitude=1,2 Altitude=1,3 Heading=1,4 AirSpeed=1,5 WindDirectionAndSpeed=1,6 The data after the "=" for each value are "line" and "order". The number on the section name, in this case TextInfo.1, is the "level". The "level" corresponds to the number of times you press SHIFT+Z. With nothing being displayed, the first time you press SHIFT+Z, you see the data above. The second time you press SHIFT+Z, you see the stuff in TextInfo.2 section. The third time you press SHIFT+Z, you see the stuff in TextInfo.3 section. By default, as you know, we get red text on an invisible background. You can add two values to the section: TextColor.1=255,255,255 BackGroundColor.1=0,0,0,128 The ".1" after TextColor and BackGroundColor is the "level" at which the colors are to apply. In this case, the first level. The TextColor data is RGB and the BackGroundColor is RGBA. The example above changes the TextInfo.1 to display white text on a 50% transparent black background.

I made a mistake above: the adf radio will look for stations no more than about 80 nm from the player position, regardless of the signal strength encoded in the ndb definition in the bgl. apologies for the mistake.