Milviz twitch live stream

[omarsmak30 4,068]

1 hour ago, cwburnett said:

The third bucket comes down to momentum vs change - for example we've been told by some well known and liked 3PDs that WASM wouldn't support autothrottle/FADEC - basically that the WASM/simconnect interface wouldn't allow us to intercept throttle events. This proved to be misinformation, as we've been able to do it without trouble. So, there is some general misinformation floating around that people tend to take as fact and it gets perpetuated. This isn't helped by the lack of documentation. I suspect some won't believe it can be done until we actually release publicly our WASM-powered FADEC for the CJ4 that fully intercepts hardware and software throttle events, and I bet even after we release it, a few will still insist that it can't be done, evidence-be-darned.

Not only this, but even the new fly by wire system for the FBW mod is compiled using WASM. And the new misinformation surfing around here in Avsim that WASM is slow which is not true, if you'd take the new fly by wire system as en example. 

 

1 hour ago, cwburnett said:

How many industries have we watched fight open source only to eventually embrace it? How many companies in the last decade (or two) have claimed they’d be forced out of business if they embraced open source, only to end up thriving. One of those companies is Microsoft. Don’t misunderstand me, there’s plenty of opportunity to charge for products and make money, but maybe there are now aspects of the sim that are best developed in the open – and maybe common flight decks fall into that category.

Exactly! This is how the new software industry now works, group of companies will all work together in the same open source meanwhile every company has its downstream enterprise offering for this open source project. Examples:

• Apache Kafka: a well known open source project that is backed by Confluent and other companies like Google, Microsoft .. etc. All these companies work together in the same target meanwhile each company has its enterprise offering of the project, for example Confluent has an enterprise version of Kafka with additional features like security layer .. etc.
• Kubernetes.
• Apache Camel: I am a main contributor to that project and the company where I work at offers an enterprise offering of this project (they just hired me to contribute to the open source project).
• Apache Spark, Spring .. etc 

The open source concept has proven to be very powerful, you contribute to the community and other companies as well do, you'd save a lot of money by just working with the community, for example instead of hiring 20 engineers to just work on the project, you'd just hire 5 to work with the community on the project .. etc. It is a win-win situation for all.

Now in MSFS, has unleashed new paradigm of software development (well this paradigm has already started in X-Plane, aka Zibo), but now the difference by introducing technologies that are appealing to the younger generations of developers, tools like Javascript, HTML and CSS as core in the sim which are mainstream in the younger generations. I wouldn't even be surprised that Asobo and Microsoft will make the simconnect APIs in Javascript and hence we wouldn't have the need for WASM and everything can be done in JavaScript (by the way don't underestimate Javascript now, it has proven itself to be a powerful technology, thanks to the V8 engine from Google that interpreters Javascript code super fast!).

Now with the mix of appealing new tools and the open source projects, I wouldn't be surprised that there will new set of 3PD developers that will work directly with the community in the open source meanwhile offers an advance version of the add-one as payware, just similar to the concept that I mentioned earlier in the software industry. For example as you mentioned, working with Working Title on G1000 meanwhile offer its own payware with its own model and flight model. The same goes for FBW mod, I would work with them on the base Airbus system and offer an advanced let's say A330 payware based on the FBW open source system but tweaked for A330 flight model .. etc. If FBW mod or Working Title has done an amazing job on implementing the systems, why do I have to do this job twice and give myself headache with it? And why I even find it really appealing is that, let's say the price of an advance A330 for example may cost 50euro in MSFS meanwhile for the an add-one with the similar complexity in P3D may cost 150euro.

 

Edited December 15, 2020 by omarsmak30

[cwburnett 1,809]

7 hours ago, raymar said:

Matt,

What is this updated CJ4 going to be named in the forums here? I don't want to miss it.

Regards,

Ray

Here it is: https://www.avsim.com/forums/topic/591671-working-title-cj4-v080-open-beta-lnav-vnav-fadec/

 

[Opiam 5]

5 hours ago, cwburnett said:

Anyhow, just my musings on the subject...as someone that pines for some of my P3D faves to make their MSFS debut...back to tweaking VNAV for the Working Title CJ4... 😉

Thanks for sharing. Your "musings" make perfect sense and we as a community are blessed having contributors like you among us.

[abrams_tank 7,453]

14 hours ago, cwburnett said:

Purely my opinion, but there are three buckets I think.

First, just like with prior ESP/FSX/P3D sims, SDK documentation is weak. There's a lot in there, but in none of the SDKs is there good guidance on how to code in the relevant languages. For example, if you read the P3D SDK, there's no step-by-step guide on how to code a FMS - and neither is there one for MSFS. The challenge is that the new sim relies on newer development languages, so while the old sims didn't have great documentation, the devs had figured it out and had a large base of knowledge to work from. Now it is all new and without strong documentation, one has to figure it out by looking at existing aircraft and code. Basically that's how we did most everything we've done - by reverse engineering the default aircraft. It helps to know the languages and we were fortunate to build a team of people that really understand JS/CSS/HTML - and that's a new framework for flight sims.

Second, as you and others have mentioned, protection of IP is a concern. In the ESP/FSX/P3D world, code was compiled into DLLs and the like; reverse engineering that by decompiling is more difficult (sometimes nearly impossible), providing developers with security against IP infringement. MSFS offers 3PDs a DRM capability, but there does seem to be some resistance to that. Some 3PDs have availed themselves of that already - for example I believe the Carenado products rely on this. But, as with all things new, there are probably a lot of unanswered questions about it and I admit that I haven't looked extensively at that so can't speak to potential pitfalls.

The third bucket comes down to momentum vs change - for example we've been told by some well known and liked 3PDs that WASM wouldn't support autothrottle/FADEC - basically that the WASM/simconnect interface wouldn't allow us to intercept throttle events. This proved to be misinformation, as we've been able to do it without trouble. So, there is some general misinformation floating around that people tend to take as fact and it gets perpetuated. This isn't helped by the lack of documentation. I suspect some won't believe it can be done until we actually release publicly our WASM-powered FADEC for the CJ4 that fully intercepts hardware and software throttle events, and I bet even after we release it, a few will still insist that it can't be done, evidence-be-darned.

I think there's an opportunity for a new way of working together as a community, but change is hard. I have tremendous respect for many of our 3PDs and I own dozens and dozens of their products for P3D. However, like it or not, the flight sim world is changing – or maybe already has. The door was swung wide open by building the default panels on the HTML/JS stack – it is modern and easy to work with and, yes, a by-product of that is that it is also more open. How many industries have we watched fight open source only to eventually embrace it? How many companies in the last decade (or two) have claimed they’d be forced out of business if they embraced open source, only to end up thriving. One of those companies is Microsoft. Don’t misunderstand me, there’s plenty of opportunity to charge for products and make money, but maybe there are now aspects of the sim that are best developed in the open – and maybe common flight decks fall into that category.

I guess my question is, what’s the risk? What’s the downside? In FSX/P3D there were plenty of payware planes that relied on default sim systems that were basically locked. We couldn’t very well improve the default FSX/P3D GNS530 – we just had to live with it. Now MSFT/Asobo have said, no…you CAN improve the default gauges and panels. You can improve performance, reliability and features. So in the old model, every plane developer had to write custom panels. But today, 3PDs have the opportunity to say, hey, we’re going to release a new plane and it’s going to work with the default G1000 (or the Working Title G1000, or another community supported product) – and we’re going to partner with the community to improve that panel - and as the panel improves, so does our plane. And for our next 10 planes, we’ll use that same panel. And, yes, my competition can also use that panel, but my flight model, my physical model, my systems are what set my product apart. Suddenly they can dramatically reduce their development time, make use of an open-source panel that is of very high quality and drive revenue by bringing more planes to market faster. Is it a major change in how we look at the market? Yes, but…might it be worth it to give it a try? If you can suddenly bring 2 or 3 planes to market in the next few months, I’d think that risk would be well rewarded in the marketplace.

Anyhow, just my musings on the subject...as someone that pines for some of my P3D faves to make their MSFS debut...back to tweaking VNAV for the Working Title CJ4... 😉

This is a great post and gives us more insight to the SDK.

PDMG and other 3rd party companies like PDMG don't want to write new code because I assume it will cost their developers more man hours and that translates into $$$ for companies like PDMG.  They prefer that Asobo's SDK convert their legacy code to be compatible with MSFS so they don't have to lift a finger (or at least, they can minimize the hours spent porting their planes over to MSFS).

People in the community totally don't understand the capabilities of the SDK and that the SDK is complete and fully functional, if you are willing to use a new coding methodology (ie. Javascript) and if you are willing to write new code that conforms to the new API of MSFS.  Unfortunately, there is misinformation in the MSFS community that the SDK is incomplete because of the vague statements from PDMG and other 3rd party developers who have legacy code. The SDK is complete, provided you are willing to use the new coding methodology, and conform to the new API for MSFS.

[kevinfirth 1,417]

1 hour ago, abrams_tank said:

This is a great post and gives us more insight to the SDK.

PDMG and other 3rd party companies like PDMG don't want to write new code because I assume it will cost their developers more man hours and that translates into $$$ for companies like PDMG.  They prefer that Asobo's SDK convert their legacy code to be compatible with MSFS so they don't have to lift a finger (or at least, they can minimize the hours spent porting their planes over to MSFS).

People in the community totally don't understand the capabilities of the SDK and that the SDK is complete and fully functional, if you are willing to use a new coding methodology (ie. Javascript) and if you are willing to write new code that conforms to the new API of MSFS.  Unfortunately, there is misinformation in the MSFS community that the SDK is incomplete because of the vague statements from PDMG and other 3rd party developers who have legacy code. The SDK is complete, provided you are willing to use the new coding methodology, and conform to the new API for MSFS.

But it isn't documented at all in many areas... Before anyone chimes in, I know, the P3D SDK isn't exactly covering itself in glory in that respect either 🙂

[ca_metal 2,033]

1 hour ago, abrams_tank said:

This is a great post and gives us more insight to the SDK.

PDMG and other 3rd party companies like PDMG don't want to write new code because I assume it will cost their developers more man hours and that translates into $$$ for companies like PDMG.  They prefer that Asobo's SDK convert their legacy code to be compatible with MSFS so they don't have to lift a finger (or at least, they can minimize the hours spent porting their planes over to MSFS).

People in the community totally don't understand the capabilities of the SDK and that the SDK is complete and fully functional, if you are willing to use a new coding methodology (ie. Javascript) and if you are willing to write new code that conforms to the new API of MSFS.  Unfortunately, there is misinformation in the MSFS community that the SDK is incomplete because of the vague statements from PDMG and other 3rd party developers who have legacy code. The SDK is complete, provided you are willing to use the new coding methodology, and conform to the new API for MSFS.

There’s a thread on the aerosoft forums about the Aerosoft’s CRJ and Robert Randazzo posted there. He said they intended to send half their people to Bordeaux to work closely with Asobo for 2 months, but the pandemic happened.

I think it’s not just about what 3rd parties want, but what they can accomplish right now.

Also, on that same thread, someone from Majestic posted something too. They were granted the same level of access as Aerosoft has, and things may move faster.

[JB3DG 225]

20 hours ago, omarsmak30 said:

Just the same like Asobo 787, is protected by the DRM, hence nobody can do anything. 

This is not quite correct. We have found instances of users cracking the Asobo DRM rather easily. Its no where near the protection systems we have available in C++ where we can make it really difficult, if not impossible to debug when disassembling.
 

22 hours ago, MattNischan said:

This is not really true. WASM bytecode can be turned back into readable Javascript, which has about the same readability as minified/uglified/obfuscated Javascript. So, the IP can be protected roughly the same amount in either case, which is to say not infinitely, but relatively well either way.

Additionally, the JS code can be protected by the Asobo provided DRM system as well if you want to prevent access.

-Matt

its not Javascript WASM that we are after. Its C++ that we want.

[MattNischan 3,822]

1 minute ago, JB3DG said:

its not Javascript WASM that we are after. Its C++ that we want.

Oh yeah, I definitely understand that. But WASM bytecode, no matter the source language, can still be decompiled, since it isn't assembly, it's a higher level language. Think more like .Net IL. There are multiple tools to change WASM to a readable language, and since WASM has roots in JS, you can use something like Binaryen to turn WASM into JS, or you can use WABT to turn it into actual C or a even a C-like pseudocode.

My point here was that if the concern with going to JS is keeping your source code and IP safe, minified/uglified JS and C++/WASM offer the same level of source code obfuscation. So there isn't really a reason to stick to C++ for the sole reason of keeping the IP a secret. I'd actually argue that minified/uglified JS is actually way harder to read than converted WASM. And, you can't debug the JS directly by connecting a regular debugger, since it's being run by a JS VM, and not compiled at load time to a native assembly like a WASM module is.

So, if I was a commercial third party, going to JS to get all the advantages of the platform would not be a concern for me at all. With the DRM and minified JS you're as protected or moreso as you would be in the WASM scenario.

-Matt

[omarsmak30 4,068]

40 minutes ago, JB3DG said:

This is not quite correct. We have found instances of users cracking the Asobo DRM rather easily.

Sorry but this has been always the issue with the software industry hacking, even now I wouldn't be surprised if MSFS has been cracked and available in torrents. And why do you even worried about this? I mean this DRM layer is not your responsibility, it is the responsibility of Microsoft and Asobo, in event of cracking or whatsoever, they have to take the full responsibility to rectify the issue since this was their preferred way of encrypting the files for 3PD add-ones not yours.

Edited December 16, 2020 by omarsmak30

[leprechaunlive 1,859]

4 minutes ago, omarsmak30 said:

Sorry but this has been always the issue with the software industry hacking, even now I wouldn't be surprised if MSFS has been cracked and available in torrents. And why do you even worried about this? I mean this DRM layer is not your responsibility, it is the responsibility of Microsoft and Asobo, in event of cracking or whatsoever, they have to take the full responsibility to rectify the issue since this was their preferred way of encrypting the files for 3PD add-ones not yours.

A quick searh shlws that MSFS is accessible via torrent, last patch included. And if you push it further you'll see that all the planes released so far are also cracked already. So whatever drm they use, it might protect the code, but it doesnt protect the monetarian value of the product. 

[Republic3D 1,232]

I would love a 737-200 without FMS. 

I had the Milviz 737-200 for FSX, and I love the addon. The FMS option was just a nuisance. 
However I did love the radio navigation option, so much more fun.

I would definately buy a Milviz 737-200 with just radio navigation. An INS option would be cool too. 

[MattNischan 3,822]

17 minutes ago, leprechaunlive said:

A quick searh shlws that MSFS is accessible via torrent, last patch included. And if you push it further you'll see that all the planes released so far are also cracked already. So whatever drm they use, it might protect the code, but it doesnt protect the monetarian value of the product.

That may be true, but that's also been true in the past of basically every commercial aircraft release, no matter the copy protection. And in this case, it's still possible to read the WASM code to figure it out. All copy protection is just a deterrent, not a total failsafe protection.

I think it's pretty easy to get into a spot where we can be arguing whether copy protection really protects software or IP (my opinion, having been in this position before, is that it does not), but I think the real takeaway here should be that in MSFS either JS or C++/WASM offer equal levels of protection on the MSFS platform. So that should not really be a driving factor in the choice of technology.

I don't want it to sound like I'm a particular language evangelist. Folks that know me know I pretty much love most languages (in my gig I use C#, JS, TS, Scala, Python, they're all great, and in previous gigs I've used C, C++, Perl, all kinds of stuff), so this isn't borne out of pushing for a tech just because of an attachment to it. But just trying to show some practical arguments to using the absolutely fantastic and modern tools that a full presentation stack like HTML/JS/TS bring to the table. The iteration times alone come down by a whole order of magnitude, and the performance is not a concern at all when using the right techniques.

The reality here is that there will eventually be a new wave of flight sim devs (not unlike ourselves and the good folks at FBW) that will take this technology and run with it to drive development costs and time down. I can have a working attitude indicator complete with speed tape and altitude tape laid out and in working prototype condition now in a day. One month ago our VNAV was just an idea. Two days ago we didn't have a TOD map marker or any of the TOD PFD indications, flashing, and messages. I completely changed the map drawing system in 45 minutes. The new course needle animation was 25 minutes. Smoothly translate an element from one position to the next? OK, one line of CSS.

And so, the current giants of this hobby (a deserved title, I may add, they truly have made this hobby great) may find themselves at a competitive disadvantage that they weren't prepared for, and I'd hate to see that. The older business model of competing on what state secrets a company can keep about how they twist the sim into a sufficient enough pretzel is not going to last forever, unfortunately. Both sides of the SDK are going to slowly become extremely well documented, and so the current battlefield of a lack of information is really going to give way to a time where everyone knows all the techniques, and the only thing to compete on will be time to market, accuracy, and quality.

-Matt

Edited December 16, 2020 by MattNischan

[marsman2020 1,310]

Well if there are no products out for MSFS because of <insert constant stream of goal post moving complaints here> then I just won't buy your stuff.

Pretty simple.

Enjoy the cushy military contracts.

 

[TravelRunner404 596]

Why in the world did the guy say at 21:32 that MSFS is 'single threaded' and '32-bit'.  Neither of those two statements seem true.  Then he ranted that it 'flies like it's on rails'.  What?

[MattNischan 3,822]

16 minutes ago, MattNischan said:

and the only thing to compete on will be time to market, accuracy, and quality.

I know I'm replying to myself here, but I really, really want to punch this point home.

The market for each individual plane, at the high levels where the Milviz, PMDG, FSLabs, A2A compete at, is relatively fixed. It's much larger than before, given the reach of MSFS, but it's still fixed. Whomever brings a high quality <insert popular plane here> to market first is going to by far have the greatest sales advantage by a long shot. So, if I'm in a commercial FS developer's position development time, ease of maintenance, ability to iterate, ability to bring desired features to market first, that is far and away a much bigger concern than a couple folks who crack the DRM or the small handful of enterprising individuals who happen to figure out how to spy on the code. There are now millions of simmers, and I guarantee than less than fractions of single-digit percentages of them are going to bother to try and steal IP.

It's going to be a much different calculus going forward, one that I think will only bring positives to the community and to the hobby. I know I keep saying this, but the future on this platform is indeed crazy bright.

-Matt