Dear MSFS Team - Third party install outside sim root directory

[virtuali 4,419]

5 hours ago, maggussje said:

Just answer me this question: why am I not able to grab the files for one of you airports and use the add-on.xml method without the Addon Manager? It's because you cripple the installation by hiding or removing key scenery files with it, isn't it?

If you actually read what I wrote, you would already knew the answer. I'm giving you the benefit of the doubt and saying you just haven't read it...

Fact the Addon Manager DOES NOT handle DRM anymore, it's not something open to discussion. I'll try to make the explanation as simple as possible, since you apparently are bored by more than a few lines of text ( "Trumpian", really ??? )

Let's take our latest scenery, of O'Hare. It's our first and only scenery that it was *made* for P3D4, and it's not hampered by the baggage of having to run on FSX too.

It's made almost *entirely* as plain standard .BGL files!

 

Almost, because in order to control piracy, we should at least make "something" disappear. And that's just TWO single objects: Terminal B and C, that's it. Those are the ONLY files that disappear at the end of the Trial, and are the only files that are controlled by Couatl ( NOT THE ADDON MANAGER!! ).

Some things the Addon Manager + Couatl are doing in O'Hare V2 ( which explain why you require a software module to run them )

- Dynamic Lights are controlled with a custom collision system (which runs in Couatl, so it's calculation won't affect fps since it's a different process, running on a different core), so we can precisely control their amount, to have full DL at a huge airport without the associated cost in performance. O'Hare is lighted almost exclusively by DL, they are not just an afterthought.

- The same collision system and scripting language in Couatl, handles the creation of the detailed interior of Terminal C, which doesn't even EXISTS in memory, until you decide to go in Avatar mode *and* cross a boundary which use the custom collision system that precisely maps the building perimeter so, when you are just outside the door, it's NOT loaded (not taking away ANY fps or memory ), and it loads only if you open the door and go inside, together with its complement of DL.

- Walking animated passengers are generated across multiple paths in the interior. This feature was more like a testbed for our future additions to GSX, which will cover passengers walking out of the stair and going to terminals on foot and, of course, it's handled by your friendly "Couatl the DRM"...

- Render To Texture, which makes interactive panels that shows useful information and looks like in real life and DO NOT affect fps at all, are made by the Addon Manager, since they are a PDK feature, which can only work as a .DLL. This allows us to use ultra-fast native C++ DX11 code, nothing can run faster than that.

- Has anybody ever seen *working* AI panels inside an airport terminal, that shows the actual AI ? There are 3rd party add-ons that do just that, for us it's just one of the many features at O'hare. Those you can only do with some *SOFTWARE*, to reply to your question "why I cannot just take your .BGL and use them without the software ?"

- Custom ground traffic at O'Hare is handled by the Addon Manager, that has a special system to create vehicles using paths we can define even outside the constrains of the AFCAD standard, and that we can control entirely in appearance, density, speed across all part of the course, etc. That's done by your friend the Addon Manager "DRM", the one that doesn't do DRM anymore since something like 2015...

That's why a scenery like O'Hare couldn't possibly work without the software. Or, it could work, but it would have to be downgraded. So the reality is exactly the opposite of what you said: if we wanted to make O'Hare running with not support software, we would have to seriously "cripple" it.

And before you start with "there's another O'Hare that doesn't require any software", then stop here, because DD O'Hare *requires* SODE, and some of its key SODE files are "crippled" ( to use your term ), because they are not even in clear XML, but use the SDX encrypted format. SODE it's made by TWO modules, one it's a .DLL, and another it's an .EXE.  Guess what, just like Addon Manager + Couatl. 

And there are many other sceneries out there that use SODE as well so, I'm sorry, but your theory that a scenery should not use any software modules, is simply out of touch with the current reality of the modern scenery development, because users want higher and higher realism, they want performances, they want interaction, and these simply cannot be done "just" with plain .BGL without some kind of software support. . BGL it's just a dumb container of 3D data, how do you expect to have a scenery "doing" things, if not without some kind of software.

And a clear proof that we didn't use the lack of interactivity possible by the FSX/old P3D SDKs, just an excuse to push our DRM, as you were trying to say, it's again in how KORD V2 is made. All the things which weren't possible to do without our software in previous sceneries, like changing of textures depending on season, weather, lighting, etc. has been moved to the STANDARD LUA method, which we could finally afford, not having to run in FSX too. What we are doing now with the software, is something that can't be made in any other way, and some of it ( Render-To-Texture, mainly ) can be made ONLY with a .DLL, which I have already explained, is "potentially" dangerous, just like any other .DLL in the sim, since only .DLLs can really crash it. But again, this .DLL, since several years, does NOT handle DRM anymore. That doesn't mean it would never, ever, crash but, what program doesn't, ever ? 

Edited November 23, 2019 by virtuali

[SnakeP 39]

Amen. I'm not limiting my critisism to the Addon Manager, if you read my comment thoroughly. Of course Couatl is responsible for scenery elements, it's abundantly clear when you restart it and see all buildings etc. disappear for a second or two.

Again, I'm not getting into this discussion (to avoid the next lengthy try to justify yourself); your extensions (whether it's the Addon Manager, Couatl or whatever) are interfering way too much with the core sim, period. Imagine FlyTampa, FSDG, JustSim, and aaall the other ones would do something similar. It'd be a nightmare. And no flight would be completed anymore because of some CTD caused by some faulty .dll. Here I basically fully agree with your last sentence. Stop messing with the core sim to stop piracy. There are better ways to achive this.

Another try to contribute to the original topic: It could make sense for ASOBO/MS to prevent 3rd parties from touching the mesh, as elevation issues are one of the biggest (and most common) issues with the current FSX base.

 

[ThrottleUp 617]

I completely agree with people before me - Xplane 11s file structure is just the BEST most streamlined out there. Period. 

Its entirely self contained, in effect the entire sim is one big portable installation. Just drop planes, scenery, sounds, scripts into ONE folder only. Done.

Please Microsoft, take a leaf out of Laminars book and quit this messy nonsense of files all over the place (my Documents, Appdata, Program files,blah blah blah). 

[virtuali 4,419]

8 hours ago, maggussje said:

Again, I'm not getting into this discussion (to avoid the next lengthy try to justify yourself); your extensions (whether it's the Addon Manager, Couatl or whatever) are interfering way too much with the core sim, period. Imagine FlyTampa, FSDG, JustSim, and aaall the other ones would do something similar. It'd be a nightmare. And no flight would be completed anymore because of some CTD caused by some faulty .dll. Here I basically fully agree with your last sentence.

This was exactly the kind of reply I tried to prevent with my reference to SODE, which is another .DLL module used by many developers (us included) and, in case of airplanes, FSUIPC, which is another .DLL module.

Any HONEST software author will tell you that, a .DLL module, just for the fact it's a .DLL, CAN possibly crash the sim. Let's hear it from SODE author himself:

Which of course it's the only thing an HONEST developer can tell you, since it's the plain reality. A .DLL CAN crash the sim, an .EXE *CANNOT*.

Same for FSUIPC, and if you search for reports of SODE or FSUIPC crashes, I'm sure you'll find many.

Quote

Stop messing with the core sim to stop piracy. There are better ways to achive this.

The issue is that, we are NOT, regardless how many times you keep repeating it. Wouldn't be easier to just said "Hey, I didn't know the Addon Manager doesn't do DRM anymore ?" instead of keep trying to prove your point.

- The Addon Manager, which is a .DLL, is the only part of our software which CAN crash the sim, like any other .DLL

- The Addon Manager DOESN'T DO DRM, since about 2015, it's only a dumb interface to send the serial number you type to Couatl, which will know what to do with it.

- Couatl does our DRM, which is about 1% of its features. It's not "a DRM", it's a Python interpreter in which the whole GSX program is written into, so it does so many things *and* it handles DRM. Which is obviously more efficient compared to have a 3rd software doing just that.

- Couatl, being an .EXE, CANNOT CRASH THE SIM.

Hope is clear, now...

 

Edited November 24, 2019 by virtuali