With all due respect to Jean-Luc,
There is a absolutely large amount of information, but much of it makes a number of assumptions that don’t necessarily track.
The reality here is that named events already exist, they’re H events. Could they be more discoverable? Yes, that is known. Could a control system on top of all this be more abstracted? Yes, that is also known and is being worked on as we speak. We are also talking daily about how to evolve the API away from only being heavily var based. So, we have a pretty good awareness of those kinds of limitations, although it should be known that most of the third parties that exist in the simulator sphere at the moment are more heavily weighed towards wanting things to be as they are. For example, the reason the GDI+ API was brought forward was because third parties demanded it intently.
I share Jean-Luc’s personal opinion that some of these things should be effectively deprecated but that isn’t the majority third party view and they need to be supported. So we have to balance everyone’s interests. My goal is to democratize development, especially on the JS side, but it’s going to happen over the course of the year, and not instantly.
The general thrust of many of the comments is about building DLLs and getting direct GPU access. Those things are not on the roadmap. The sim API is not designed to use the sim as basically a glorified graphics engine or hook in arbitrary native code. Those things are just not in scope, due to sandboxing and security, and the team’s position on that is unlikely to change.
If folks have specific graphics API requests and examples of things that are impossible to draw at the moment, then those would be good to bring forward. But presently, and I know it’s disappointing to some, direct hardware access in the form of arbitrary native code loading and/or GPU access is not coming.
-Matt | Working Title