-Everything you know about upcoming Flight Sim from Microsoft-

Deano1973

Resource contributor
If Microsoft wants to prevent failure, they need to get HERE, and right quick. :banghead:
This post just about sums up perfectly both what we're all hoping for, and what we all fear. But it's not just about whether Microsoft allows the freedom for third party developers to produce commercial add-ons. As rhumbaflappy says, it's about the amateurs we all started as. We learned all these processes due to a passion for this hobby. If Microsoft allows third-party developers produce only commercial software, and allow it only to be sold via their own website: if they attempt to maintain a stranglehold on the industry and not allow freeware developers to produce add ons, then the new sim will still die, because they'll be taking away people's hobby.

It's how we all got started, right? I'd be really disappointed if I couldn't produce freeware any more, because I just like modelling things for flight sim even when they're not commercially viable. My P-61 Black Widow is a case in point - two years it took me to make that damned thing. I desperately wanted to see one in the sim, but no good ones were available. The finished product wasn't up to payware standard, but it made great freeware. How many people coming into flight sim would stick it out for two years to learn something, knowing that their work could never actually be used? How many wonderful sceneries and airplanes and tools would we not have, had FSX been solely a closed-door project?

I fear that rhumbaflappy is right, and that nobody on the dev' teams for the new sim actually know much about the community. Somebody should come here, or to SoH, and see what really goes on, what's really kept the hobby and the industry alive all the time after Microsoft abandoned it. I hope that I'm right in reading in Microsoft's announcement the term "community content creation" as meaning what it sounds like it means - freeware.
 

Heretic

Resource contributor
I'm absolutely against the idea of FS20 picking up anything related to legacy code, tools and development procedures or even ask the community for opinions. It's supposed to be a fresh start and clean cut after all and any contact would just produce half-hearted compromises. Let the dev team do their thing first, evaluate the result and only then help them to make it better.
 
As far as "SDK" goes I hope it works more like a modern game engine such as Unity. No closed formats like BGL or MDL, just drop a standard FBX, GLTF or Alembic file into the game. Then it works with the built-in exporters of all modern 3D modeling tools, no silly "gamepacks" or secretive ".X" export plugins. Have an in-game editor to attach colliders and scripts for animation or other behaviors like flight dynamics. Have a built-in script debugger and logger, perhaps integrated with VSCode or Visual Studio. Drop in .TIF for elevation maps or ground textures and support plugins for Substance Painter/Designer. Make it easy and open to define/edit airport facilities, navaids, airways etc.
 
I'm absolutely against the idea of FS20 picking up anything related to legacy code, tools and development procedures or even ask the community for opinions. It's supposed to be a fresh start and clean cut after all and any contact would just produce half-hearted compromises. Let the dev team do their thing first, evaluate the result and only then help them to make it better.
I totally agree with that
 
I totally agree with that
I do not necessarily agree for all type of content.
Take the flight model part for instance. Many people claim it does not work as it should, it is not realistic etc... Some even say xplane does a better job.

My findings is the model implemented is quite good. From a mathematical standpoint, we are very close to the models used in full flight simulators. It would require just some more flexibility in the tables offered, plus a better compressibility model for higher altitude/mach numbers. And engine model as well.
But the accuracy, if you have the good derivatives, is closer to the real deal than the marketing flow model from xplane.
This means they don't need to go from scratch here. And it would be very easy to keep current FDM files as compatible while enabling better models to be developed.

If you take aircraft (and other objects) 3D models, I can't help but think of those as vertices with textures. I can imagine with some caveats on advanced effects (PBR, shaders or whatever) you'd lose some eyecandy but reusing these binaries vertices should be possible somehow while still enabling a complete new file format and development tools.


I might be naive here, but new content does not have to mean old one is obsolete, but it could mean you can get better while keeping what you have.
 
And my BIGGEST hope is that they simplify 3D lights (for runways, light posts, etc) and CTL-J jetways....as I was never a fan of having to use 3rd party for animations to function properly.
Unfortunately, per the preliminary display, jetways still look like &$it. LOL
 

Heretic

Resource contributor
As far as "SDK" goes I hope it works more like a modern game engine such as Unity. No closed formats like BGL or MDL, just drop a standard FBX, GLTF or Alembic file into the game. Then it works with the built-in exporters of all modern 3D modeling tools, no silly "gamepacks" or secretive ".X" export plugins. Have an in-game editor to attach colliders and scripts for animation or other behaviors like flight dynamics. Have a built-in script debugger and logger, perhaps integrated with VSCode or Visual Studio. Drop in .TIF for elevation maps or ground textures and support plugins for Substance Painter/Designer. Make it easy and open to define/edit airport facilities, navaids, airways etc.
I hated Unity when I tried making parts for Kerbal Space Program. Having to have an entire game engine development package installed just to produce a game-compatible bunch of vertices and textures exported from a modeling tool plus a collision model just struck me as too much effort for too little return.
Besides, the .X file format is not really secretive at all and perfectly human-readable and ready for manual manipulation.



I do not necessarily agree for all type of content.
Take the flight model part for instance. Many people claim it does not work as it should, it is not realistic etc... Some even say xplane does a better job.

My findings is the model implemented is quite good. From a mathematical standpoint, we are very close to the models used in full flight simulators. It would require just some more flexibility in the tables offered, plus a better compressibility model for higher altitude/mach numbers. And engine model as well.
But the accuracy, if you have the good derivatives, is closer to the real deal than the marketing flow model from xplane.
This means they don't need to go from scratch here. And it would be very easy to keep current FDM files as compatible while enabling better models to be developed.
For both MSFS and XP, the amount and quality of source data is king. XP's vortex-lattice approach has the adavantage of being more approachable by its use of a geometric model, while MSFS' method is more efficient in terms of computing resources. Both are able to produce credible results within its limitations (usually imposed by the engine modeling, although XP by now has a huge advantage in turboprops).

If you expand the scope to systems modeling, XP is light years ahead. I needed dozens of lines of XML code to simulate a second battery and better charging/discharging characteristics, while XP has this out of the box. Not to mention better pressurization and fuel systems. FS20 really needs to play a serious game of catchup in that field.
 
I hated Unity when I tried making parts for Kerbal Space Program. Having to have an entire game engine development package installed just to produce a game-compatible bunch of vertices and textures exported from a modeling tool plus a collision model just struck me as too much effort for too little return.
Interesting, my experience was the opposite. Animation keyframing/tagging/exporting seemed a lot more laborious than just edit/test in-game. Same with colliders. But the more important thing to me is to avoid the lock-in to a specific 3D software that MS chooses.

Besides, the .X file format is not really secretive at all and perfectly human-readable and ready for manual manipulation.
True, it's more my perspective which is that the Gmax plugin doesn't allow access to the .X file (unless you use the FS9 SDK and install a MakeMDL trojan horse).
 

hairyspin

Resource contributor
it's more my perspective which is that the Gmax plugin doesn't allow access to the .X file
The reasons for that are historical and can be forgotten now, since there’s not the least chance of Gmax being used again. So long as they don’t use Granny 3D or suchlike which makes even 3ds Max look cheap and was talked about for MS Fl***t
 
Last edited:
The reasons for that are historical and can be forgotten now, since there’s not the least chance of Gmax being used again. So long as they don’t use Granny 3D or suchlike which makes even 3ds Max look cheap and was talked about for MS Fl***t
That's right, Flight used .gr2 format. I'm sure it was because reasons but it's not a widely supported format AFAIK.

There are a number of good 3D tools with reasonable Indie and Hobbyist licensing so I hope with MFS there's no lock-in to ultra-expensive software such as 3dsMax.

Some of us are still Gmax grannies...
Right on, you can pry Gmax out of my cold dead hands. Who needs an Edit Poly modifier anyway? Well, I do but I learned to live without. :D
 

hairyspin

Resource contributor
I’d think a little cold commercial reality might intrude here - imagine (say) Milviz spending appreciable sums building a systems-heavy 787 Dreamliner only to find anyone can open the final model in XYZ Modelling suite and read the model source code and mesh. I believe we’ll still be dealing with a compiler, whichever tool a model is built with.

Just my tuppence ha’penny.
 
I’d think a little cold commercial reality might intrude here - imagine (say) Milviz spending appreciable sums building a systems-heavy 787 Dreamliner only to find anyone can open the final model in XYZ Modelling suite and read the model source code and mesh. I believe we’ll still be dealing with a compiler, whichever tool a model is built with.
That's a good point but if the compiler takes standardized formats as input then it's not an obstacle for modelers to use their software of choice.
The game engine might support compiled or uncompiled models, a bit like how MSFS can work with cabbed or uncabbed gauge code.
 

hairyspin

Resource contributor
That, old boy, would be the Golden Fleece, the Rosetta Stone, the cat’s pyjamas, the developers’ ultimate. Build a model in Blender, Max, Rhino, whatever and export in a well-supported format like, say, FBX to a proprietary compiler for the new sim. We can but hope they’ve gone that route.
 
Last edited:

Heretic

Resource contributor
Interesting, my experience was the opposite. Animation keyframing/tagging/exporting seemed a lot more laborious than just edit/test in-game. Same with colliders. But the more important thing to me is to avoid the lock-in to a specific 3D software that MS chooses.
I hope a Blender plugin (official or unofficial) will sort this out as that tool provides the current standard for freeware 3D modeling.

True, it's more my perspective which is that the Gmax plugin doesn't allow access to the .X file (unless you use the FS9 SDK and install a MakeMDL trojan horse).
Ah yes, one of the worst quirk of the GMax gamepack, next to locking the modeldef.xml for changes whenever the program is running.
 

Heretic

Resource contributor
I’d think a little cold commercial reality might intrude here - imagine (say) Milviz spending appreciable sums building a systems-heavy 787 Dreamliner only to find anyone can open the final model in XYZ Modelling suite and read the model source code and mesh. I believe we’ll still be dealing with a compiler, whichever tool a model is built with.
X-Plane's OBJ files can be read and manipulated with a text editor and there's some damn complex and expensive payware aircraft out there...
 

nickw

Administrator
Staff member
I don't think there's much of a problem for the developer community. Many of us (freeware and commercial) are gently drifting away from FSX and across to P3D anyway, so the lack of an SDK in this game is not going to be that much of a problem. Then comes the day that you start it up and the Azure cloud is down. Yes, it does happen and far more often than Microsoft would have you believe. I went onto Azure as a developer and came off it almost as quickly because its stability was unreliable. I'll give this game a miss, despite the beautiful visuals.
The Azure cloud won't be down.

I would suggest that the Azure implementation is exactly how the studio got budget approval. No Azure. no sim.
 
Top