MSFS -Everything you know about upcoming Flight Sim from Microsoft-

[Heretic]

i do not think so
Xplane 11 works pretty well I reckon is here to stay

Yes it does, but there is a nasty and highly annoying mindset in some users that's akin to "If Laminar does not improve [simulator element], then I will leave for MSFS". So basically once those users are gone, the amount of distractions will decrease.

 

[manschy]

The default FS2020 airports are using generic textures for aprons and taxilines like the airports that we design with ADE.

Okay, but what about other places like abandoned military airfields for example? How easy will it be to remove every actual/current scenery parts of MSF?

 

[rhumbaflappy]

The latest development roadmap from Asobo shows an SDK update in late September. So, it's unlikely the SDK will be released in a completed form before then. So, only approved 3rd party developers will have access to the SDK until at least that time. So, we will all be in the dark until sometime after September, and hopefully it will be free or reasonably priced. I have read the SDK is a little sparse as of now, but they are working on it.

The sim's release will be August 18th. I read it will be upgradable if you get the cheapest version. The more expensive versions contain more default aircraft and detailed airports, so essentially you would be buying DLC. But the cheapest version will be complete. Associated programs like Little Navmap should fundamentally work through Simconnect. And I read the Dowsons are working on an FSUIPC version.

We'll need to be a bit patient for the tools we need for development, but essentially, the same elements are there. Objects, autogen, imagery, flattens, elevation BGLs, aircraft, living world. There was mention in earlier posts about migrating FSX items into the sim. I think this just relates to gauges translated through web assembly (you'd need to look that term up). As far as I can determine, that is the only migration possible, and you would probably need the C++ source code to migrate it. I think all gauges will need XML, or a combo of Simconnect or FSUIPC to function.

I do not think we can simply use a BGL from FSX and expect it to work. So there is lots of room for development. 40,000 airports to rework, tons of the earth to detail with imagery and autogen. I have no idea if objects have conditional display available (I doubt it as the ortho-imagery just has Bing and snowy winter as seasonal display). Aircraft developers will have a new clean slate for development of nearly any aircraft. All the addons for FSX and P3D will not work, so if you are concerned about your past 'investment', it's not good news.

 

[delivery guy]

Got a new message today from one of my beta members that Bill Leaming posted info about the new SDK. I wanted to get some feedback as this was not 100% clear. Here is the message i got.

Quote:
Interesting post below by Bill Leaming in response to posts wondering why Milviz and A2A have been so quiet about developing a/c for the new MS sim:

" I am but a humble poly-bender and part of the "fit and finish" crew. I am not a spokesperson for Milviz.

That said however, the SDK is not yet complete, but the parts of it I have read and studied inform me that everything has changed! There is nearly zero resemblance to FSX, ESP, or P3D.

More concerning however is the decision to isolate access to the core of the MSFS display engine by requiring the use of WASM* (Web Assembly), thus making high-level C++ "gauges' highly questionable. It may take many months to investigate and possibly discover suitable workarounds. WebAssembly is specified to be run in a safe, sandboxed execution environment".(edited)


Bill also said this about the new sim in another post: "Dynamic Link Libraries (.dll or .gau) are not allowed at all. All WASM must be compiled into an executable (.exe) which will only run in the VM "sandbox" totally isolated from the sim engine".

 

[rhumbaflappy]

I'm sure a great deal has changed, but the basic components are still as I outlined above, and those are familiar. DLLs are verboten. Using the web assembly process could be so convoluted that rebuilding everything as XML would probably be better. The problem is XML is not flexible enough to do what the DLLs were capable of delivering. And this is a complication for building study-level aircraft.

I thought Dos Equis would be the death of XPlane and P3D. It will be the death of FSX instead. I think simmers that are enjoying P3D and XPlane will continue to enjoy them for the reasons they migrated to them in the first place. FSX lovers will migrate to MSFS. It will be a while before the new platform is improved with 3rd party addons. But we will hack it apart and give it functionality the creators did not imagine possible. It's what we do.

 

[delivery guy]

Using the web assembly process could be so convoluted that rebuilding everything as XML would probably be better. The problem is XML is not flexible enough to do what the DLLs were capable of delivering. And this is a complication for building study-level aircraft.

I code in XML so this will be good for my aircraft development to continue on for FS2020. But i still use some DLL's written by others that i paid for and these re important to have study-level aircraft as you said. So that is not good. I hope we will figure how to use existing DLL's or at least write new ones that work well.

 

[WarpD]

I have seen no evidence that XML gauges will be supported.

 

[rhumbaflappy]

Perhaps not XML? Certainly not C++.

 

[adino]

Wasn't XML variables we have seen in the soundscape discovery series, perhaps a hint?

 

[rhumbaflappy]

Here's an interesting link:
https://www.avsim.com/forums/topic/578494-milviz-didn’t-say-much-either/

 

[adino]

So reading the thread thru for what I understand XML gauges most probably will be still supported in MSFS since XML being native in the sim?

 

[WarpD]

Those are SimConnect variables... which XML uses... but they exist in SimConnect, which has been mentioned as still existing in the new sim.

 

[DragonflightDesign]

Compilers and language virtual machines:
[LIST]
[*]Compilers for languages which can target WebAssembly (C/C++, Rust, Go, C#) should be able to run in WebAssembly themselves, emit a WebAssembly module that can then be executed.
[/LIST]

So... I'm really not sure that I want to learn yet another way of programming a flightsim. Actually, I don't, full stop and I'm certainly not going to be starting another doc the style and size of the sd2gau series telling folks how to program the sim. Unless Asobo have vastly extended SimConnect, in my opinion only the current version of SimConnect even in P3Dv5 is itself incomplete. As a single simple example, you cannot turn the APU on and off through SimConnect but you can read the state that the on/off switch is in.

 

[WarpD]

You can turn the APU on and off via SimConnect. Not sure why you think you can't.

As for WASM.... use of GDI, GDI+, and/or DirectX is not possible in WASM. Unless there's been seriously drastic upgrades to it recently?

 

[theisomizer]

No drastic recent improvements. They are building a gdi+ compatibility layer on top of https://github.com/AsoboStudio/nanovg but it is still in the very early stages.

Bill's comments regarding XML are correct. It more or less works out of the box.

Simconnect is built from the FSX implementation. Don't be expecting LM's API additions to be re-implemented by Asobo in the near future.

 

[scruffyduck]

I can confirm that the bgl structures related to airports are not the same as earlier versions.

 

[manschy]

I know this may be too early to ask, but are you thinking about a possible tool for us freeware developer as for FSX or P3D?

 

[DragonflightDesign]

You can turn the APU on and off via SimConnect. Not sure why you think you can't.

Only that it's not listed as 'settable', but then I've long been suspicious of a lot of the information in that particular column in the P3D SDK because it's obviously a direct copy of the FSX document. Seriously Ed: is there a better source listing of what is settable and what is not, bar the old suck-it-and-see method?

 

[WarpD]

All events are usable via SimConnect. Why are you not using the defined event IDs? Setting a variable is not the ONLY, nor is it the BEST way to make the sim do something. Events exist for a reason... at least I believe they do.

 

[scruffyduck]

I know this may be too early to ask, but are you thinking about a possible tool for us freeware developer as for FSX or P3D?

From what I have read there is something of an inbuilt click and drag airport design tool. It may well be that there is no need for an external tool for this sim. If it transpired there was a need then I would certainly look at that.