beatle

Not sure where you are getting the 3 years value from, it hasn't even been 3 years since ACES closed yet. LM has only had the code for about 16 months, and has put out 3 releases in that timeframe. The two primary features have been a license that allows use in a commercial setting, and the fact that development on the engine is continuing. To be fair, that had nothing to do with old code, new code, hybrid code, etc - nobody has wanted to own the Weather system since at least FS5 (when I first started working on the code) - it's the subsystem itself that no one wants to own, nothing to do with the state of the code (I would hazzard a guess that about 90% of the devs interviewed to work in ACES wanted to work on the DirectX pipeline code - that's what they consider to be "game programming", as opposed to me who works on almost everything else except the DirectX pipeline code - that aversion is related to the years I spent doing direct graphics hardware programming :-> ).

A more accurate statement would be that PFC supports FSX (FSX doesn't do anything specficially to support PFC) and nobody is able to say whether PFC will support Flight (or be allowed to support Flight).

Hey All, Just wondering if anyone else is planning on attending the AVSim social this Saturday, or is it just going to be me and the AVSim folks getting drunk at the Hilton :->

Well, I don't think you would use P3D to make "something like FSX" :-> The $499 would be paid by two general types of buyers: Solution Providers - these are people who provide a complete solution, including hardware, software, custom content, etc for a single price to their clients Direct End Users - these are people who are setting up one or more machines for a commercial use (training, education, visualization, etc) who then combine the software with their own hardware and any custom content they might want to purchase or create (in the case of High Schools/Colleges/etc, we should have an Educational license available soon, so they won't have to pay the full $499 per seat) Then there are the Occasional Other buyers, which is anybody else who buys a P3D license (or developer network subscription) for whatever reason :->

Generally, smaller ISV's would probably do things like create a package with custom local sceneries, specific target aircraft, training missions, etc and sell it to say a local flight training school, flying club, FBO, etc. What you would have to pay Lockheed Martin for would be the $499 per seat license fee for each machine you provided as part of your solution. What you charged your customer for the whole package would be up to you. Larger ISV's might also include custom hardware, like the Redbird Simulations folks do with their motion platform and multi-LCD wrap around view (or LM's own MFTA based systems). Or target larger/regional/national flight schools (or maybe type familiarization for an aircraft manufacturer). Another option would be to put together a "timed experience rig" (ie you know, like those motion platforms with the roller coaster sims you see at county fairs), but using Prepar3d to allow a "Fly for x minutes for y bucks" sort of rig you could take to county fairs. In all the above, the only payment to Lockheed Martin would be the $499 for a seat license for each machine in the solution that has Prepar3d installed on it. The SDK is a free download, and the developer network subscription is optional.

Just to clear up some misconceptions, the limitations on Prepar3d are all related to pricing and marketing - ie we can't sell a product at an "entertainment price level" and we can't market it as an entertainment product. But ANYBODY who wants to buy a copy (either a full seat license or a developer subscription) is free to do so (there's no limitation on how you use it, just how we sell it :-> ).

Well, MS also kills off projects all the time for reasons that have nothing to do with money (ie office politics - like how ACES got shutdown in the first place :-< ).

Couple of ways to reset the config file without knowing where it is. You can hold down the CAPS_LOCK and CONTROL keys while the app is launching, you can add a -RESETINI switch to the FSX command line, or you can add a -CFG switch with no path\filename to the FSX command line (normally, it would be -CFG:d:\SomePath\SomeFile.cfg - this form lets you use different .CFG files for different setups). Tim

Not sure for FS9. When FSX is the foreground app (ie has input focus) it will attempt to disable screen saver/screen blanking modes, but isn't always successful (particularly if you have a domain-joined machine and the domain requires Screen Locking after x minutes, that happens regardless of what the app tries to do). The main problem is that WIndows doesn't consider joystick input as input (like it does with keyboard and mouse input). If you look around, you might be able to find software that installs as a "virtual keyboard or mouse" that you can set to send some innocuous command (like press and release the shift key, or minimal mouse movement) at some rate slightly faster than the screen saver setting (ie if the screen saver is set for 15 minutes, then send a random "input" event every 12 minutes) - don't know of any software like this off the top of my head, but since the problem exists for any joystick based software, there's probably something like that out there :-> Tim

Some of those items left behind could be "common" files shared across several products (ie a common gauge package that several addon aircraft use, etc) - in this case, uninstalling the "common" files could break other installed addons. This is fairly common in regular software as well - if you install Visual Studio on a machine that didn't have any .Net runtime installed, then uninstall Visual Studio, you will find the machine still has the .Net runtime instlaled (granted, in this case, the .Net runtime does show up in the installed programs list as a seperate item) Tim

Well, in the general sense, you can use a generic rigid body physics engine for quite a few things in a flight simulator: Collision Detection General rigid body stuff for aircraft ground handling and regular cars/trucks/etc If it includes a cloth/wave simulation, you can also use it for water surface animation, flapping flags and wind socks, etc Some also provide support for moving some calculations to the GPU, although you could also go directly through DirectX APIs for that :-> Granted, once you leave the ground, most general rigid body physics engines don't provide support for that. Tim

Prepar3 to be happy (sorry, couldn't resist :-> ).Yep, the 3DS Max Tools in the Prepar3d SDK do currently output FSX-SP2/XPack SDK compatible MDL files (well, .X and .XANIM files). And yes, the Asm2Air tool, headers, and docs are included in the Prepar3d SDK. The in-sim tools (Object Placement Tool, Traffic Toolbox, VisualFX Editor, etc) will not work with any version of FSX (those files only work when the SDK version matches the sim version).Tim

The flying races thing was part of the Acceleration Addon Pack, not part of the base FSX product, so no time was spent on it until after the base sim and the first service pack were done.Tim

Core wasn't really ever an ACES product, it was just the group within ACES that worked on the parts of the sim that were common between FS, TS, and ESP (graphics engine, terrain engine, etc).Tim

Guys,This version of FS (yeah, they may call it Flight, but its still just FS to me :-> ) will be just like every other version of FS: There will be some new features/modules/subsystems Some existing subsystems will be rewritten/greatly enhanced/etc Some existing subsystems will have code tweaks (speedups, bug fixes) and minor enhancements Some existing subsystems will be almost exactly the same (think Weather system, the system nobody wants to touch because they will then own it :-> ) You guys seem to thing there's some single "FS Engine" inside the codebase (ie that would be the entire program :-> ). There are whole bunches of subsystem engines (graphics pipeline, terrain system, autogen system, weather system, Aero modeling system, etc), they don't necessarliy all need to be rewritten for every release in order for there to be performance gains, enhanced graphics, etc in each new release :->Tim

I can't speak for ADE specifically, since I haven't used it, but most 3rd party content creation tools create output files that are in turn used as input to one or more of the tools in the SDK. It's the SDK tools which create the final FSX Compatible format files.Tim

Personally, I've found this thread to be quite entertaining - certainly more so than the ones where folks are actively arguing with each other over whether Feature X, Scenery Area Y, or SDK Ability Z will be included in the final product :->Tim

I think the point avantime was making was not that 3rd party developers would be put out of bussiness, but that 3rd party publishers (the folks that run the online stores, create the piracy protection system wrappers, etc) would (assuming Flight goes with an in-app addon store only model - I have no more idea on that one than any one else here :-> ).Tim

Of course, if there were no early adopters, then there would be no initial reviews/comments/etc for you to use to do your research into whether you want to buy later or not :->Tim

Sounds pretty accurate, although I would have applied it slightly higher up the management chain myself (ie to the MGS managament and marketing folks above ACES - Yes, ACES was always part of MGS, that isn't something new for Flight).Tim

Sure, that sounds like a valid commerical use to me. You see these sorts of setups at county fairs and trade shows, etc that have a module on a motion platform simulating roller coasters and whatnot, doing something similar that simulated an airplane using P3D would be a valid commercial use.Tim

You would have to go back an awful long way to find an x86 CPU that was 32-bit only. Those of us in the programming world were very annoyed that Win7 wasn't a 64-bit only OS release (the server equiv, Windows Server 2008 R2, was released as 64-bit only, but not the consumer OS) - similar to our annoyance with Intel and the 486SX, we thought we would finally have guaranteed access to a Floating Point processor and could drop the FP emulator code we had to include for systems without an FPU, but then they released the 486sx without an FPU (and the 487sx to provide an addon FPU for those machines).Until the only OS on the market is 64-bit, most developers aren't going to create 64-bit apps because they don't want to have to deal with testing two different versions of their app (having to test 32-bit app on 32-bit OS and 32-bit app on 64-bit OS is bad enough). Another issue is 3rd party libraries that only come in a 32-bit version with no source code available to rebuild it yourself - if you rely on one or more of those, you're pretty much stuck with 32-bit land only.Tim

Why do you think the different client apps need different settings? You can have multiple clients connecting to the same port number (up to 64 with the default settings). And I would just always use 8192 as the Max Receive size (since that's the max packet size for SimConnect). Also, most clients only support connecting via the SimConnect.0 section of the SimConnect.cfg file (which defaults to the local connection if there is no .CFG file). I've never quite figured out what the Nagle thing is all about, and usually just set it to disabled.If you really need the different settings, the best way to handle that would be to place a SimConnect.cfg file in the same directory as the client apps .EXE file (ie one SimConnect.cfg for each addon) each with a SimConnect.0 section with specific settings.Tim

As an addition to what Bill said above, one thing you can do with Lockheed Martin's Prepar3d, which wasn't allowed with Microsoft's ESP, is the Solution Provider can purchase the seat licenses for its clients and include the cost in the total solution cost (very important if you are providing a complete hardware/software package to your clients).Tim

all the various FS.exe's included in the main directory are there for backwards compatibility, some installers will only install in a directory if they see the speciifc .EXE they were looking for - none of those .exes is the actual one from that version of the app (in fact, they are all just shells that turn around and execute FSX.EXE). And all the assembler is gone, except for a couple instances of inline assembler in a couple of otherwise C++ functions, so the oldest code that could still be in there is from 1996, and most of that is stuff like parts of the window manager, a few pieces of the panel/gauge system, etc.Tim