MSFS Tracking where Asobo Models are from?

[lionheart]

Is it possible to find out where a model is located in the sim, that I might know which airport its from?

I am wondering about selling my airports, if I might be in danger of selling airports that might have hangars or even plants in them that might need permission to be used.

Most of all I have used is Asobo. But some I found by Search and I need to find out what airport packs they are from. No idea how to backtrack where a model is from.

Many thanks in advance.

Bill
LHC

 

[mamu]

Hey Bill
Using the Debug model lods the Package name can be shown
(It is also shown iirc in the Scenery editor, hovering with the mouse in its name)

You are right, some Devs don't like others to reference their models (really not understand this because to see something that has been referenced the end user must have the Package where stuff are referenced from, making it a win win situation imho)

 

[rhumbaflappy]

Why would you need permission? All you are doing is placing a GUID. You are not copying anyone's models. Referencing is a core characteristic of the sim. The only problem with referencing a model or a texture is that the end-user may not have that addon loaded, and then your addon might not display properly.

 

[Christian Bahr]

Why would you need permission? All you are doing is placing a GUID. You are not copying anyone's models. Referencing is a core characteristic of the sim. The only problem with referencing a model or a texture is that the end-user may not have that addon loaded, and then your addon might not display properly.

That's not right, Dick.

Various partners are now working on MSFS and these partners are creating their own 3D models and submitting them to Asobo/Microsoft. The rights to these models remain with the partner and referencing is generally not allowed. I would therefore be very cautious about using models from other developers if permission has not been obtained. Therefore, if at all, I only use models from the FSBase Lib.

 

[Christian Bahr]

Is it possible to find out where a model is located in the sim, that I might know which airport its from?

I am wondering about selling my airports, if I might be in danger of selling airports that might have hangars or even plants in them that might need permission to be used.

Most of all I have used is Asobo. But some I found by Search and I need to find out what airport packs they are from. No idea how to backtrack where a model is from.

Many thanks in advance.

Bill
LHC

To be absolutely sure that there are no problems, use the models from the FSBase Lib. The assets in it are from Asobo/Microsoft and can usually be used without any problems

 

[rhumbaflappy]

The rights to these models remain with the partner and referencing is generally not allowed.

They do have the rights to the models and textures. They do not have the rights to placing of the GUIDs. They may not like it, but they should take that up with Asobo and Microsoft, as the SDK was developed with exactly that idea in mind... you can place objects and simobjects from Devmode or xml code wherever you like. No one is copying the model or textures. Your code is just displaying them. If the end-user does not own the package where the GUID is originated, then the object won't appear.

 

[Christian Bahr]

I don't want to argue with you, do what you think is right. Please remember that younger developers are reading this and if they get into trouble because of a wrong assessment, then it could mean the end of their young careers. So please don't use the models or the GUID of the models. I know what I'm talking about. And if you want to split hairs, then yes, even the GUIDs are the intellectual property of the developer because he created them. Even the smallest code snippets can become problematic, there was actually a dispute that became very unpleasant for the company. And rightly so.

You, Bill and I are experienced developers who can deal with a lot of things because of our reputation when there are arguments.

In the end, you can ask the developer, at least that's what I always do. For the current project, I needed gliders and trailers, I asked 2 colleagues and both gave their permission, very straightforward. For my Jena project, I asked ORBX if they would make the large tower building available to me. I got the models and textures, no big deal. It's always an honor when you're asked or when you get permission

 

[rhumbaflappy]

A GUID cannot be copyrighted, or claimed as intellectual property. It is a number. The modeler does not create the GUID, he merely uses it as he uses any other number.

When we use xl code to display an object, we basically request the sim to display that whatever is represented by that GUID. The sim displays or not as it chooses. The sim doesn't display if the code is wrong or not allowed. In the case we are discussing, the sim will not allow the display of a model or simobject if it does not exist in the virtual file system of the sim, as shown in the DevMode. If it shows in the Devmode, it's fair game to place anywhere. We all agree to the use of the Sim and the SDK, and the SDK allows any object represented by a GUID to be placed where ever we wish in a package.

It would be up to the original modeler to bypass the placement of an object by GUID in their created package. In that case, the display would be protected.

 

[lionheart]

Many thanks guys. Excellent advice. Things I hadnt thought about.
If I could somehow track the hangar, or restaurant, or tower that I found through a general search, find out what airport it was done for, then I could try to track down who did it and get permission from them.
The alternative is, release and wait to see if someone comes out and says 'Hey! Thats my scenery. You didnt ask permission!' and I can then ask, now they I know who did it, and if needed, take it down, change it out with something else. But it could also go well with the developers, as they can be shared in the spotlight, their work being made 'more known' to people, and hopefully that will help launch them to higher levels in this field, helping each other.

 

[superspud]

There's payware that uses plenty of MSFS assets outside of fs-base, many of which are made by third parties, but I presume Asobo owns the rights for them since they commissioned it.

I certainly wouldn't add an item from another payware developer's work.

If there's an item that that's important to the thing you're making then you really need to have it in your own package, or reference items that are in the base install only. So that means no world update stuff or any of the hand made airports.

The package you're using a model from might update and remove the items.

Lots of people who download anything you make will never read anything you write so won't know there are other things they should download.

Others may read it and refuse to allocate several gigabytes of space to store an otherwise irrelevant mountain of info.

 

[rhumbaflappy]

 

[lionheart]

Thanks Dick. I just found this and went to bring the info here, and you already posted, lol...
I just hover the mouse over it and it shows which package its from.

Nice..! and thank you. I may not have found that.

 

[rhumbaflappy]

In the example I gave, note there are 2 packages. The each have the same name and GUID. Naughty Microsoft often reuses GUIDs, model names and identical models in their packages. But that does insure the airport will display the model if other packages are not in the virtual file system. However, Microsoft sometimes includes the identical models in packages that don't even use the models. Mostly, it's just sloppy work.

In the case of microsoft-modellib-airport-generic, The Asobo version is a base file everyone has in the VFS. I think there is one model they added to Asobo's package. No need for nearly 200 models redundantly clogging up the end-users storage. The same can be said for microsoft-modellib-texture package. Redundant. 2213 textures not needing to be used. 523MB!!! Microsoft does not use the texture.cfg Instead they use a bogus "texture.bgl" in their texture folder, which forces all those textures into the VFS. Odd.

 

[lionheart]

In the example I gave, note there are 2 packages. The each have the same name and GUID. Naughty Microsoft often reuses GUIDs, model names and identical models in their packages. But that does insure the airport will display the model if other packages are not in the virtual file system. However, Microsoft sometimes includes the identical models in packages that don't even use the models. Mostly, it's just sloppy work.

In the case of microsoft-modellib-airport-generic, The Asobo version is a base file everyone has in the VFS. I think there is one model they added to Asobo's package. No need for nearly 200 models redundantly clogging up the end-users storage. The same can be said for microsoft-modellib-texture package. Redundant. 2213 textures not needing to be used. 523MB!!! Microsoft does not use the texture.cfg Instead they use a bogus "texture.bgl" in their texture folder, which forces all those textures into the VFS. Odd.

Thanks for that information Dick.

You wrote: Instead they use a bogus "texture.bgl" in their texture folder, which forces all those textures into the VFS. Odd.

What is VFS?


I am so grateful to find out how to track the location of those parts. One of my airfields use two hangers that I practically built the entire airfield around. All afternoon and deep into the night, I spent going through all hangers in the sim, trying to find 2 that would fit in the two slots. The hangars were by a private firm that do payware. So glad I found out. I figured they would not want to negotiate. I prayed about it and set out to find replacements and around 10PM, found the last one.

Thanks for your help. Massively grateful.

Bill
LHC

 

[GaryGB]

Hello:

Dick makes some very important points in his assertions on this topic, and I am inclined to agree with his viewpoint.


A previous thread on related issues is here:

https://www.fsdeveloper.com/forum/threads/can-we-legally-create-or-sell-fs-addons.124202/


Some of use here recall efforts made by OrbX years ago to restrict use of GUIDs for placing their scenery content in 3rd party addons.

At that time, I already viewed the use of GUIDs for placement of OrbX objects that required a purchase to even be available for display when placed, as something that did not infringe on any ones rights; use of such GUIDs for placement merely offered an option to display something -IF- one had purchased and installed the payware addon containing the objects associated with such GUIDs.

IMHO, attempting restriction of GUIDs makes about as much sense as attempting to restrict Geographic coordinates; in principle they are "look-ups" that can be cited, and when entered in the FS2Kx Map or MSFS Teleport dialogs, a user A/C can 'jump' to that location and spawn.

Local GUIDs in FS2Kx' active Scenery.Cfg- or within MSFS' Virtual File System (aka "VFS")- may be displayed if processed during FS flights.

But, if an entity "called" by a placement BGL is not installed / set 'active', it is not "present and accounted for", thus it will not be seen.

While I suspect that Asobo may be working on a copyright enforcement mechanism for payware content in MSFS 2024, and MSFS 2020, in the mean time, FS Developers may wish to look into how FS Dream Team / Cloud-9 dynamically moves their payware scenery objects underground out of view after a limited demo time period expires during each unique FSX flight session, via a clever 3rd party SimObject display engine.


BTW: I just saw this:

https://devsupport.flightsimulator.com/t/eula-sdk-using-default-assets/6757


...IIUC, that session may also discuss this:

https://docs.flightsimulator.com/html/Introduction/SDK_EULA.htm

MSFS 2024 SDK Live Q&A planned for October 2 at 9:30am PDT (1630 UTC).

Ask your questions here

GaryGB

 

[rhumbaflappy]

VFS = Virtual File System. It's how MSFS keeps track of packages and their priorities. Although referencing an already loaded 3rd party model or texture is legal, if you distribute a package, you may well get hassled by a sensitive and uninformed developer. The best course would be to not reference their wonderful model, and stick to Microsoft or Asobo packages when using a pre-made. Shame, of course, as you are promoting the sale and use of their work. Also, the end-user may not own their package and the model or texture won't display in the sim.

Referencing is common in making liveries of aircraft. Many livery developers make liveries of other 3rd party aircraft, seemingly without any legal threatening. It's part of the sim's capabilities, and is promoted by Microsoft/Asobo as evidenced by the SDK example.

This thread is the very first time anyone has made some sort of objection to use any legal referencing of a premade texture, model or simobject that I have read since FSX was released.

 

[lionheart]

Its good to know. I want to do everything right. I think we have the right to use built in stock parts in the sim that are 'Microsoft' and 'Asobo'. I talked with one of the high ups at MS today. She said that so long as it's not a Tier 2 or Tier 3, but Tier 1, I should be fine, and they prefer that I sell it in the MS Store, or at least launch it in the MS Store before selling it in other locations, which I am fine with. Makes great sense to me.


Bill

 

[Christian Bahr]

There's payware that uses plenty of MSFS assets outside of fs-base, many of which are made by third parties, but I presume Asobo owns the rights for them since they commissioned it.

I certainly wouldn't add an item from another payware developer's work.

If there's an item that that's important to the thing you're making then you really need to have it in your own package, or reference items that are in the base install only. So that means no world update stuff or any of the hand made airports.

The package you're using a model from might update and remove the items.

Lots of people who download anything you make will never read anything you write so won't know there are other things they should download.

Others may read it and refuse to allocate several gigabytes of space to store an otherwise irrelevant mountain of info.

Do you believe that everything must or should be included in a scenery? I see it exactly the same way. That is another good argument for creating or buying your own models and then using them in your "own" scenery.

If I were to build a scenery that predominantly or largely contained elements from other developers, it would no longer be my scenery. It would be a scenery from other developers, I would have just put the elements together. I would be careful if insensitive developers made incorrect statements; the principle is to ask the developer for permission beforehand ;-)

It was not about standard models from the Asobo/Microsoft library. It was about the question of models outside of this library and the question of which package these models are included in. Default hangars, cars, trees, etc. are no problem. But referencing third-party models in your own scenery is not allowed without permission and can cause a lot of trouble.

I don't think it's a good selling point to point out that this or that model library is needed to display the scenery correctly. It just looks a bit strange when the whole airfield is suddenly empty just because the customer hasn't installed this or that package