1 hour ago, n4gix said:

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

Hi Bill,

I thought there were tools for compiling C++ code to WASM, and if so, why would making C++ gauges be an issue?  And along those same lines, will XML gauges have to be 'compiled' into WASM, and if so are there any tools for that?

Thx,

Al

1 minute ago, ark said:

Hi Bill,

I thought there were tools for compiling C++ code to WASM, and if so, why would making C++ gauges be an issue?  And along those same lines, will XML gauges have to be 'compiled' into WASM, and if so are there any tools for that?

XML is native in the sim (as is JSON and Lua IIRC). so there's no problems there. However, XML has no read/write support which of course seriously limits what they may accomplish.

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.

Beyond those basics, the portion of the SDK that's currently provided to developers simply does not provide enough information. Lots of questions and not enough information available to even guess what the answers might be.

But then again, I know my limitations and am not a "gauge guru". I know only enough for the simple things.

1 minute ago, n4gix said:

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.

This may be just a preference nowadays. I know the Aerofly folks have a similar aversion to dll's etc, and the stated reasoning has a lot to do with seeing what several years of random developers doing their own thing did to the speed and stability of FSX/P3D......

2 minutes ago, HiFlyer said:

has a lot to do with seeing what several years of random developers doing their own thing did to the speed and stability of FSX/P3D......

Precisely the reason indeed! I can only hope that they haven't "locked the barn" too tightly though!

5 minutes ago, n4gix said:

Precisely the reason indeed! I can only hope that they haven't "locked the barn" too much though!

I've had the suspicion that this is also why so many features that were formerly the pervue of third parties are now native to the sim. Keeping possible bad/slow/sloppy code out of the base.

28 minutes ago, n4gix said:

However, XML has no read/write support which of course seriously limits what they may accomplish.

Bill, Just to make sure I understand, is this any different than currently with P3D?

Al

1 minute ago, ark said:

Bill, Just to make sure I understand, is this any different than currently with P3D?

There is no discernible difference at all. 

3 hours ago, HiFlyer said:

I've had the suspicion that this is also why so many features that were formerly the pervue of third parties are now native to the sim. Keeping possible bad/slow/sloppy code out of the base.

Yep I applaud that approach, there is to much of that code floating around 😉

no comment

6 hours ago, n4gix said:

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.

I don't have a clue as to what this means except I am real glad I did not start removing all those old trash Sims Like P3D with DX-12. LOL!!

6 hours ago, Chapstick said:

They posted a beta for the V5 version in their user forum, FYI. The port to V5 will be free.

Thanks very much. With summer finally here and enjoying every day of it I've been spending more time outside mainly on the motorcycle. I will go look for it. That was the final aircraft i was waiting for before removing 4.5.....disk space is getting a little tight.

Dave

2 hours ago, Rob_Ainscough said:

Indeed!  ... ye old “bad code” ... too funny.

Guilty as charged if the crime is not being interested in the nomenclature for bugs, inefficiencies or whatever.

When working with Orbx as a tester, the Cityscene products were released, and immediately ran into a problem of huge loading times that to many manifested as an apparent freeze at 6% loading.

There were tons of posts about it and no ready solution.

I was curious, and ran process monitor to step through what P3D was doing while the apparent freeze was occurring. To my surprise, it was opening and closing zillions of files completely unrelated to the scenery in question, and it was taking forever.

In fact it seemed to be opening the exact same files again and again, scanning them repeatedly.

I fiddled with this for awhile, watching the process a few different ways for a few days, and then informed orbx what I was seeing. They asked what I was using to see this, and I gave them a link for process monitor and instructions for what I was doing. They also wanted the logs I had made, but they were too huge, several gigabytes of P3D mindlessly open and closing files.

Orbx techs and developers took a while to confirm all that, and track down and exactly what was going on, and then report the problem to LM, who began working on a fix.

A thread was made describing the findings, but it seems to be gone now, and this is all that I could find: https://orbxsystems.com/forum/topic/166920-cityscene-orlando-performance-tweaking-faq/?tab=comments#comment-1467513

Was it a bug? Was it simply inefficiency? Was it bad code? Mentally, I went with the latter and put it out of my mind, being a lot more interested in getting it fixed, than I was in precisely what it was called.

Over the years, I've bumped into several programs interfering with each other in ways that seemed to cause issues within the sim. What were the precise problems? Don't know, didn't really care either. Removing the addons in question solved the issue.

Again, what the issue was called precisely was and is not a biggie to me.

Nowadays my Xplane installation is extremely lean. (P3D is deleted)

Too many bad experiences spending valuable time tracking down issues with addons.

If MSFS blocking off its core can ameliorate that sort of thing happening, then I'll jump ship in a heartbeat and not look back. I suspect I'm not alone.

5 hours ago, HiFlyer said:

 

If MSFS blocking off its core can ameliorate that sort of thing happening, then I'll jump ship in a heartbeat and not look back. I suspect I'm not alone.

I understand your point but there is a balance to find between totally sanitizing an environment and let creativity running wild. Life is messy.

Edited July 20, 20205 yr by Dominique_K

7 hours ago, HiFlyer said:

Guilty as charged if the crime is not being interested in the nomenclature for bugs, inefficiencies or whatever.

There's nothing wrong with calling it "bad code."  I remember hearing the phrase in the Pentagon in 1976 from a guy who had been a programmer for many, many years, predating COBOL.  "Hm, sounds like we've got some bad code in there."

Hook

59 minutes ago, LHookins said:

  I remember hearing the phrase in the Pentagon in 1976 from a guy who had been a programmer for many, many years, predating COBOL.  "Hm, sounds like we've got some bad code in there."

Hook

Was he looking in the CRM 114 Discriminator  ?