in synthesis developing something for this sim will be very very harsh for what I red here..

13 hours ago, domkle said:

What kind of new architecture are you thinking of ? 

None in particular. Just that consoles in particular have changed processor architectures in the past - and WebAssembly would make a possible future transition seamless for addons.

However, better stability is probably the overriding reason for using WebAssembly.

13 hours ago, domkle said:

What kind of new architecture are you thinking of ? 

Maybe not a big factor yet for desktop PCs, but Microsoft has been playing with ARM based Surface tablets. Windows itself has been ported to multiple processors over the years and ARM processors are becoming quite competitive with x86 processors. May not be a reason for their choice of WebAssembly though.

Edited March 14, 20206 yr by goates

On 3/13/2020 at 8:56 AM, Lorby_SI said:

Sorry, can't really comment on this.

I can, since I didnt sign any NDA.

When I stop laughing.

I didnt actually think they were serious about the js thing. Good grief.

Due for initial release Nov this year

not expected to be usable for creating production applications before Nov 2021.

The phrase beating a dead horse springs to mind.

 

20 hours ago, mp15 said:

in synthesis developing something for this sim will be very very harsh for what I red here..

If by "something" you mean programmatic assets, then probably not harsh for completely new products. But straight ports of existing addons seem to be out of the question, I'm with you there.

For in-process addons like gauges and systems simulation it looks like we get WASM - which Asobo has to implement first, before 3PDs can follow and adapt. 
For "outside" addons there will be SimConnect. But that API must be rewritten by Asobo too, married to the the new internals of the sim.

From my perspective, all bets are off as to how existing addons with programmatic assets will work at all or if they will be on the same level of functionality that we are used to. And how long it will take to implement them in the first place. The timeline that Mathijs Kok recently presented may not be that far off the mark. 

Quote

The phrase beating a dead horse springs to mind.

I'd have to disagree with that. In this case a horse is being beaten that has not been born yet. That is a new one for me.

Best regards

Edited March 15, 20206 yr by Lorby_SI

1 hour ago, Rob_Ainscough said:

hopefully Asobo/MS do a serious "re-think"

Hello Rob,

I don't know, what's to rethink? GDI+ is dead, Scaleform is dead (or so I hear, besides, that was P3D tech). Asobo have to do something to provide complex in-sim functionality outside of the box, that also works cross-platform. If WASM complements their tech, then why not.

Nobody can really have expected that everything we know from the old world would sail over smoothly "just like that". New core sim means new API, means new SDK. No two ways around that.

Even if for example SimConnect (as the remaining legacy API) is built up to full FSX functionality, you can't just rely on it either. I have to assume that it is being implemented from scratch too, and there is just no guarantee that it will behave the same way as in the old sims. Just think of the hundreds of lines of code that we had to write to work around certain behavior issues with the API - all that is gone, has to be reinvented, new issues have to be fixed. A professional developer won't mind - if we could only do things that we did before, we would be poor engineers indeed. But it will take time, and, as a consequence, require patience on part of the customers. And even more patience, when some functionality that we had in the past just can't be provided - not only "later" - I mean - "at all".

As far as I know, people wanted to start from scratch, compatibility be d**ned. Looks like that wish will come true.

Best regards

Edited March 15, 20206 yr by Lorby_SI

7 hours ago, Lorby_SI said:

I'd have to disagree with that. In this case a horse is being beaten that has not been born yet. That is a new one for me.

dot "last seen in production in 2013" net.

Being beaten over the head with javascript, in a last ditch hope someone other than microsoft will use it as a build target.

In order that they can lock developers out of key hardware functionality (such as custom cockpits and force feedback controllers)  via UWP.

The funniest thing was all the "running on multiple cores" talk. Instead they target single core with twice the ram requirement to run at half the speed.

Not even chromes V8 can manage multithreading reliably yet.

As good as confirms every worst fear I had at the start.

Same old distrust the user trust the software default mindset that made everyone dump them in the first place.

Edited March 15, 20206 yr by mSparks

@Lorby_SI there will be a plugin for 3ds max and c++ editing or not?

10 hours ago, mSparks said:

Being beaten over the head with javascript, in a last ditch hope someone other than microsoft will use it as a build target.

WebAssembly has nothing at all to do with .NET, and is only relevant to Javascript if it's implemented within a Javascript engine, which almost certainly isn't the case here.

MS have literally said, in plain English, that it's been implemented as a way to run legacy native code inside a sandbox. UWP or Javascript hasn't been mentioned at all.

I'm not in the Alpha, but I would be surprised if C# isn't a target language, or indeed the recommended language for SDK development.

17 hours ago, Rob_Ainscough said:

WASM is not something I want to work with now or ever, hopefully Asobo/MS do a serious "re-think".

They said it was intended to run legacy / existing native code. It would be surprising to make sandboxed native code the default SDK development path over something like C#. I therefore doubt that it's something any of us will have to work with, unless you have aircraft to port over and don't want to rewrite.

 

3 hours ago, mp15 said:

@Lorby_SI there will be a plugin for 3ds max and c++ editing or not?

The default model format is glTF so it should be pretty 3D app agnostic. There may be an app to convert glTF assets from any source into MSFS assets.

1 hour ago, nickhod said:

WebAssembly has nothing at all to do with .NET, and is only relevant to Javascript if it's implemented within a Javascript engine, which almost certainly isn't the case here.

MS have literally said, in plain English, that it's been implemented as a way to run legacy native code inside a sandbox. UWP or Javascript hasn't been mentioned at all.

I'm not in the Alpha, but I would be surprised if C# isn't a target language, or indeed the recommended language for SDK development.

https://devblogs.microsoft.com/dotnet/introducing-net-5/

C# is compiled to webassembly and run on .net 5.0, on a single thread, consuming twice the ram, and running at half the speed, completely isolated from the system and any other code complied to webassembly.

For extra comedy read the comments.

Edited March 16, 20206 yr by mSparks

5 hours ago, mSparks said:

C# is compiled to webassembly and run on .net 5.0, on a single thread, consuming twice the ram, and running at half the speed, completely isolated from the system and any other code complied to webassembly.

WebAssembly is a virtual machine spec. You can embed that virtual machine in a Javascript engine or in native code itself (as Asobo will be doing).

You can write C# that will target that virtual machine spec, you can also write native code. MS said specifically said "existing native code".

I guess you're assuming that WebAssembly is not just for legacy code? I can't see any foundation for doing so.
It would not make much sense as you can just host the .NET Core runtime to support C# in a native app.

@nickhod is it possible to create a gITF with animated parts controlled by scrollers in Windows 3D viewer?

On 3/17/2020 at 2:52 AM, Rob_Ainscough said:

WASM and .NET 5 is just more of the same MS self serving technologies.  Nothing to do with providing anything developers really want

Yeah whatever... Guess I don't want full stack in C#.