• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Scenery Library Standards

S

sfrenchie

Messages
1,043
Country
us-northcarolina
I am starting this thread following 2 email conversations I had in the past month, 1 with a user and 1 with a known scenery developer.

Here is what they say:
1.
as a consequence of my ron_ez...problem I wonder how to inform and convince the FSdesigner community that we need standards ....
It is nonsence if we have identical libs (and textures) spread all over the addons...
Click to expand...

2.
I'm not in favor of these collections like ezoliv33.zip. You have no way of knowing if the person who put them together knew what he was doing, made sure to have the latest versions of the libraries & textures, etc. I know there are a lot of libraries out there, but you only have to download a library once. You'll quickly have 90% of the ones you'll need and rarely have to download new ones. I don't see why people think this is such a chore. My other pet peeve is scenery designers who include entire object libraries in their scenery downloads. This practically guarantees that the user will end up with duplicate libraries and problems with objects not displaying. The designer thinks he's doing the user a favor when in fact he's fucking things up.

What I'd really like is a free web site with a shitload of storage space. I'd set up my own site for all my sceneries and objects. The user would be assured of having the latest versions, corrections, whatever.
Click to expand...

I too have ran into problems due to duplicate bgl and my disks are cluttered with multiple copies of the same textures, hundreds if not thousands.
It is an obvious problem known by scenery developers and advanced users but for someone that just discovers FS enhancements through installation of sceneries it is unknown. As they gear towards becoming advanced users they discover the issue and it's too late at that point.

Libraries compilations and/or distribution of libraries along with sceneries indeed seem attractive since it reduces the work load during installation but they are the tree hiding the forest.

So what exactly is this post about? It's about asking this community if they think we could come up with guidelines (don't tell me they already exist) and apply them to show the example. This community has enough notoriety that ,imo, most others would slowly follow. Wouldn't it be possible to have a simple sticky thread exposing guidelines we all came up with? It doesn't have to be a complicated memorandum of strict rules but instead a 5 or 6 bullets sticky.

I think it would be beneficial to all if we could come up with naming convention, library content and distribution guidelines.

Please participate in this thread, give your opinion and bring in your personal ideas as I believe it would benefit the whole sim community.
I am asking for 2 things here, your personal opinion on the need for guidelines (yes we need, no we don't, let's keep it wild) and for inputs on the guidelines content in case it would be decided to officially publish them.

Thanks,
 
I'll be first to share my ideas and dreams of standardization.

Library
  1. Libraries should be named meaningfully so we can tell at a glance what they contain. Naming a library 'sncntr' only makes sense to the author, not the user.
  2. Library names should start with the description so they will be in the alphabetical order. If you want your name or company name put it at the end. A good example is: ga_hangers_ss_v3. I would even modify it further to hangers_ga_ss_v3. That way all your hangers libraries show up together in object placers.
  3. Avoid meaningless naming such as, "MyName's stuff"
  4. Libraries should be distributed with a reference text file containing the GUID and a short descriptive. Example:
    EBA99A3BC04D4BE997F7AAD63134C6A2 small house A frame
    EBA99A3BC04D4BE997F7AAD63134C6A3 medium house 2-story
  5. Libraries should not contain different types of object. I.e. 2 hangers, 3 cars, 5 phone poles, etc. If those were created for a particular scenery then name the library as you named the scenery.
  6. Test your objects before distributing them. If they don't act/look right then refrain to include them in your library.

Scenery
  1. Do not include object libraries that are not yours when you distribute your scenery/project. If you do there are great chances duplicates will end up being installed on some systems.
  2. Instead do include a text file in which you name the libraries you used in your project (including yours), possibly the BGL name and the ZIP name if they are different. Ideally you would include a link to download web site (not only a link as web site sometimes go under).
    A good example: http://edtruthan.com/sirp/sirpmanual.htm#EZFiles
    [*]If possible try giving installation alternatives when your scenery uses modification of original files. Some users do not want to replace original files.
    [*]This point really is a question of personal taste. I hate and usually don't bother installing scenery that come with an installer. We don't know what's in it and where it's installed so good luck to uninstall.
    [*]Include a way to get in touch with you, in case of need to report issues


I do appreciate the fact that authors share their hard work with the community. Following a few guidelines with very little extra work though would make the sharing experience even better.

Thanks to all,
 
Last edited:
Thank you Guenther. I think that would be a good idea.

This is not an enterprise solely by and for sfrenchie. I know I like to do things right and if I share something with someone I want it to reflect that quality, so personally I feel I'm set.

If the FSDevloper community feels a need to at least give a try at becoming more tidy then I don't mind doing my share of work to achieve the goal.

If to the contrary the consensus is 'meh' and the leaders in the field don't see a point then that's fine too. I'm not out to change the world.
I'll just go on eliminating from my collection some of the library/scenery that can be found out there.
 
I just tested Jon's DOF with my FS9 installation.

I got 739 pages in print preview ...

A "Duplicate Object Cleaner" would be great (only keeping the newest (or biggest library))?

I must confess I have 1086 layers in the scenery.cfg gathered ...

:(
 
Last edited:
Whoohoo, my report comes up with 3 or 4 false positives from default libraries :)

Anyway, I guess that makes my point that things can become crazy very fast.
Duplicate object BGL can create display issues.

And let's admit that cleaning up a system of duplicate BGL's isn't too difficult, it's just about findind and deleting them...although 739 pages of them is going to keep you busy for a while :p

Once you are done do you count on cleaning up the corresponding textures too?
Haaa, interesting problem there, how do you find them? Are they under the general Texture folder, the Ez-Scenery folder, the Runway12 folder, the Peter Paul & Mary folder and wherever else. I don't know of any tool that reports duplicate textures and will probably write my own application to do that. Just dump everything in a DB and run a find duplicate query.

Duplicate textures though aren't such a big deal EXCEPT if you have a report of 740 pages, say 5 duplicates per page (and I'm very conservative there) and say each library uses average of 5 textures (probably more) you are basically storing on disk 18500 files for nothing.
A 1024 x 1024 compressed in DXT3 is roughly 1 MB. So your duplicate texture are munching between 15 & 18 GB of storage space...just saying :D
 
Hi,

This is a interesting topic. I agree with Jon that if we can work out some general rules here we should put them on the Wiki.

Now back to the subject......

Yes, libraries is always a tricky subject. If you are not careful with them you end up in a big mess. So I think it would be very helpful to make some guidelines to help developers and users preventing that.

I think a common approach is to put objects that are only used in one scenery in a library for that scenery only. Such a library can then be distributed with that scenery without problems.

If you have objects that need to be shared between different sceneries, they should go into a separate library that is distributed as a library only package. The many EZ-Scenery, Rwy12, IS library packages available also show how this works.

Below are my comments/suggestions for the rules you proposed:

Library
  1. Libraries should be named meaningfully so we can tell at a glance what they contain. Naming a library 'sncntr' only makes sense to the author, not the user.
    Although I agree with this, I find this hard to enforce. So I would make this a suggestion.
  2. Library names should start with the description so they will be in the alphabetical order. If you want your name or company name put it at the end. A good example is: ga_hangers_ss_v3. I would even modify it further to hangers_ga_ss_v3. That way all your hangers libraries show up together in object placers.
    Although I agree with this, I find this hard to enforce. So I would make this a suggestion.
  3. Libraries should be distributed with a reference text file containing the GUID and a short descriptive. Example:
    EBA99A3BC04D4BE997F7AAD63134C6A2 small house A frame
    EBA99A3BC04D4BE997F7AAD63134C6A3 medium house 2-story
    I would prefer to request some proper documentation. So a document with thumbnails and details of the objects. With ModelConverterX this can be made for example. The TXT file you refer to seems to be the file that was needed by EZ-Scenery (and also Instant Scenery I think) for FS2004 libraries, since these have no names in the MDL files and else you only know the GUID.
  4. Libraries should not contain different types of object. I.e. 2 hangers, 3 cars, 5 phone poles, etc. If those were created for a particular scenery then name the library as you named the scenery.
    I am not in favour of this one. If I make a collection of objects to be used at a GA airport I don't want to have to split it into 10 different libraries for different types of objects. I think that would only make things worse because you get more and more libraries. But it would be a good idea to group them by theme or so.
  5. Test your objects before distributing them. If they don't act/look right then refrain to include them in your library.
  6. Never include objects in your library that are already part of another library.
  7. Never decompile an existing library to distribute the objects again in a different library or with a different GUID. (So won't believe it, but this happened a lot in the past. People decompiling a library made with Rwy12 and then recompiling it to make it EZ-Scenery compatible and giving the objects different GUIDs in the process. Or decompiling them to group the objects differently and more to their liking. This is the recipe for disaster.)

Scenery
  1. Do not include object libraries that are not yours when you distribute your scenery/project. If you do there are great chances duplicates will end up being installed on some systems.
  2. Instead do include a text file in which you name the libraries you used in your project (including yours), possibly the BGL name and the ZIP name if they are different. Ideally you would include a link to download web site (not only a link as web site sometimes go under).
    A good example: http://edtruthan.com/sirp/sirpmanual.htm#EZFiles
    [*]If possible try giving installation alternatives when your scenery uses modification of original files. Some users do not want to replace original files.
    Although a good recommendation, this is not related to object libraries is it? So I would remove it here.
    [*]This point really is a question of personal taste. I hate and usually don't bother installing scenery that come with an installer. We don't know what's in it and where it's installed so good luck to uninstall.
    This is a tricky one. Personally I do indeed prefer a ZIP file when possible and most object libraries are simple so they should not need an installer (only tricky part can be installing the effects). But on some projects you really need an installer. For the NL2000 project I am a member of we had to make one, as else people just had too much trouble installing the scenery. Not everybody is such a serious FS users that he knows how to install everything manually. Let alone that some people already have trouble operating their PC. So I would not require this in rules like this.
    [*]Include a way to get in touch with you, in case of need to report issues
 
I will add my first comments to this in Green

Library
  1. Libraries should be named meaningfully so we can tell at a glance what they contain. Naming a library 'sncntr' only makes sense to the author, not the user.
    Although I agree with this, I find this hard to enforce. So I would make this a suggestion.
    I agree with Arno. There are groups such as AIG who have naming conventions which members stick to. I would propose that we set out some 'best practice' naming conventions
  2. Library names should start with the description so they will be in the alphabetical order. If you want your name or company name put it at the end. A good example is: ga_hangers_ss_v3. I would even modify it further to hangers_ga_ss_v3. That way all your hangers libraries show up together in object placers.
    Although I agree with this, I find this hard to enforce. So I would make this a suggestion.
    See Above
  3. Libraries should be distributed with a reference text file containing the GUID and a short descriptive. Example:
    EBA99A3BC04D4BE997F7AAD63134C6A2 small house A frame
    EBA99A3BC04D4BE997F7AAD63134C6A3 medium house 2-story
    I would prefer to request some proper documentation. So a document with thumbnails and details of the objects. With ModelConverterX this can be made for example. The TXT file you refer to seems to be the file that was needed by EZ-Scenery (and also Instant Scenery I think) for FS2004 libraries, since these have no names in the MDL files and else you only know the GUID.
    Agreed
  4. Libraries should not contain different types of object. I.e. 2 hangers, 3 cars, 5 phone poles, etc. If those were created for a particular scenery then name the library as you named the scenery.
    I am not in favour of this one. If I make a collection of objects to be used at a GA airport I don't want to have to split it into 10 different libraries for different types of objects. I think that would only make things worse because you get more and more libraries. But it would be a good idea to group them by theme or so.
    I am not in favor of this either. One of the issues are the 'thousands' of libraries around, many contain only a few objects; a number as we know duplicate each other. I would say that we should encourage the use of the minimum number of libraries with the maximum objects per library consistent with common sense and usage
  5. Test your objects before distributing them. If they don't act/look right then refrain to include them in your library.
    I think that is a given!
  6. Never include objects in your library that are already part of another library.
    Agreed
  7. Never decompile an existing library to distribute the objects again in a different library or with a different GUID. (So won't believe it, but this happened a lot in the past. People decompiling a library made with Rwy12 and then recompiling it to make it EZ-Scenery compatible and giving the objects different GUIDs in the process. Or decompiling them to group the objects differently and more to their liking. This is the recipe for disaster.)
    Agreed

Scenery
  1. Do not include object libraries that are not yours when you distribute your scenery/project. If you do there are great chances duplicates will end up being installed on some systems.
    Absolutely should be applied. In fact unless you have specific objects for the scenery concerned I would recommend that object developers release their libraries as separate entitied
  2. Instead do include a text file in which you name the libraries you used in your project (including yours), possibly the BGL name and the ZIP name if they are different. Ideally you would include a link to download web site (not only a link as web site sometimes go under).
    A good example: http://edtruthan.com/sirp/sirpmanual.htm#EZFiles
    [*]If possible try giving installation alternatives when your scenery uses modification of original files. Some users do not want to replace original files.
    Although a good recommendation, this is not related to object libraries is it? So I would remove it here.
    [*]This point really is a question of personal taste. I hate and usually don't bother installing scenery that come with an installer. We don't know what's in it and where it's installed so good luck to uninstall.
    This is a tricky one. Personally I do indeed prefer a ZIP file when possible and most object libraries are simple so they should not need an installer (only tricky part can be installing the effects). But on some projects you really need an installer. For the NL2000 project I am a member of we had to make one, as else people just had too much trouble installing the scenery. Not everybody is such a serious FS users that he knows how to install everything manually. Let alone that some people already have trouble operating their PC. So I would not require this in rules like this.
    Offer an alternative. This is common in the software world. If you do use an installer make sure that it does not silently change things. The ADE installer tells the user what is being installed and where and in some cases offers them not to install something. I do not have a problem with an installer that installs only to a single directory and does not make changes to FS or the Registry etc. My experience is that some users have the most awful difficulty in copying files correctly from a zip.
    [*]Include a way to get in touch with you, in case of need to report issues
    Personally if that is not obviously present then I would not install the item whatever it is. Sites like AVSIM rightly require contact details.
 
Last edited by a moderator:
Thank you Arno for stepping in and giving us your opinion and sharing your ideas.

I think a common approach is to put objects that are only used in one scenery in a library for that scenery only. Such a library can then be distributed with that scenery without problems.
Agreed, there are specific libraries and distributed libraries.

If you have objects that need to be shared between different sceneries, they should go into a separate library that is distributed as a library only package. The many EZ-Scenery, Rwy12, IS library packages available also show how this works.
I suppose you are referring to packages libraries such as Ezoliv33.zip, those are the ones making the biggest mess. I used to have many libraries that were installed both from EZ-Scenery & Rwy12 packages. SS bgl's were duplicated all the way.
Good point.

Below are my comments/suggestions for the rules you proposed:

Library
  1. Libraries should be named meaningfully so we can tell at a glance what they contain. Naming a library 'sncntr' only makes sense to the author, not the user.
    Although I agree with this, I find this hard to enforce. So I would make this a suggestion.
    It was my understanding that all would only be suggestions.
  2. Library names should start with the description so they will be in the alphabetical order. If you want your name or company name put it at the end. A good example is: ga_hangers_ss_v3. I would even modify it further to hangers_ga_ss_v3. That way all your hangers libraries show up together in object placers.
    Although I agree with this, I find this hard to enforce. So I would make this a suggestion.
  3. Libraries should be distributed with a reference text file containing the GUID and a short descriptive. Example:
    EBA99A3BC04D4BE997F7AAD63134C6A2 small house A frame
    EBA99A3BC04D4BE997F7AAD63134C6A3 medium house 2-story
    I would prefer to request some proper documentation. So a document with thumbnails and details of the objects. With ModelConverterX this can be made for example. The TXT file you refer to seems to be the file that was needed by EZ-Scenery (and also Instant Scenery I think) for FS2004 libraries, since these have no names in the MDL files and else you only know the GUID.
  4. Libraries should not contain different types of object. I.e. 2 hangers, 3 cars, 5 phone poles, etc. If those were created for a particular scenery then name the library as you named the scenery.
    I am not in favour of this one. If I make a collection of objects to be used at a GA airport I don't want to have to split it into 10 different libraries for different types of objects. I think that would only make things worse because you get more and more libraries. But it would be a good idea to group them by theme or so.
    I didn't express my self properly. I should have said "If those were created for a particular scenery then you can put any type of objects together but name the library as you named the scenery and distribut it only with your scenery, not as a reusable library."
  5. Test your objects before distributing them. If they don't act/look right then refrain to include them in your library.
  6. Never include objects in your library that are already part of another library.
  7. Never decompile an existing library to distribute the objects again in a different library or with a different GUID. (So won't believe it, but this happened a lot in the past. People decompiling a library made with Rwy12 and then recompiling it to make it EZ-Scenery compatible and giving the objects different GUIDs in the process. Or decompiling them to group the objects differently and more to their liking. This is the recipe for disaster.)

Scenery
  1. Do not include object libraries that are not yours when you distribute your scenery/project. If you do there are great chances duplicates will end up being installed on some systems.
  2. Instead do include a text file in which you name the libraries you used in your project (including yours), possibly the BGL name and the ZIP name if they are different. Ideally you would include a link to download web site (not only a link as web site sometimes go under).
    A good example: http://edtruthan.com/sirp/sirpmanual.htm#EZFiles
    [*]If possible try giving installation alternatives when your scenery uses modification of original files. Some users do not want to replace original files.
    Although a good recommendation, this is not related to object libraries is it? So I would remove it here.
    Correct, it's related to scenery distribution which is why I put it under this topic :)
    [*]This point really is a question of personal taste. I hate and usually don't bother installing scenery that come with an installer. We don't know what's in it and where it's installed so good luck to uninstall.
    This is a tricky one. Personally I do indeed prefer a ZIP file when possible and most object libraries are simple so they should not need an installer (only tricky part can be installing the effects). But on some projects you really need an installer. For the NL2000 project I am a member of we had to make one, as else people just had too much trouble installing the scenery. Not everybody is such a serious FS users that he knows how to install everything manually. Let alone that some people already have trouble operating their PC. So I would not require this in rules like this.
    The subject we are discussing like many others is not black or white and in some cases, you are right to mention that an installer is necessary (i.e. NL2000 or SIRP). I was thinking more in the line of:
    • If your scenery or library is simple you don't need to show us you know how to use a packager. (phrased differently of course :D)
    • If you are distributing a collection of libraries please provide both an installer and a simple zip so we can decide what to install and that way avoid duplication
    [*]Include a way to get in touch with you, in case of need to report issues
 
Hi Jon, appreciate your inputs.

I mostly agree on all you said.

Library, item #4 is a difficult one to solve.
I have downloaded libraries to realize they only contained 2 flowers.
I have libraries named Hanger_Whatever that only contain 1 hangar and the rest is whatnots that have nothing to do with hangers.

Library, item #5, might be a given but I can tell you of at least one library developer that needs glasses to check his work. Mass production of garbage.

Looks like everybody has good ideas of what could be done to improve distribution of libraries and scenery.

Oh I forgot in the naming convention topic and will add it to my original post:
Please, please, pretty please don't name your libraries MyName's stuff.
 
Hi Patrick,

sfrenchie said:
I suppose you are referring to packages libraries such as Ezoliv33.zip, those are the ones making the biggest mess. I used to have many libraries that were installed both from EZ-Scenery & Rwy12 packages. SS bgl's were duplicated all the way.
Good point.
Click to expand...

I think it took some time for people to understand that there is no Rwy12 library, EZ-Scenery library, etc. They are all the same libraries. So indeed packing multiple libraries in a "tool specific" package makes no sense at all, especially duplicating them easily makes a mess.

I am not referring to that. So I mean here that if the objects are for reuse on many airports they need to go in a library only package.

sfrenchie said:
I didn't express my self properly. I should have said "If those were created for a particular scenery then you can put any type of objects together but name the library as you named the scenery and distribut it only with your scenery, not as a reusable library."
Click to expand...

That's not what I meant. Even if you make a reusable library of generic GA airport objects, I would not be in favour to split the hangars from the control towers from the platform objects, etc.

sfrenchie said:
The subject we are discussing like many others is not black or white and in some cases, you are right to mention that an installer is necessary (i.e. NL2000 or SIRP). I was thinking more in the line of:
  • If your scenery or library is simple you don't need to show us you know how to use a packager. (phrased differently of course :D)
  • If you are distributing a collection of libraries please provide both an installer and a simple zip so we can decide what to install and that way avoid duplication
Click to expand...

Agreed, it would be a good suggestion to encourage as simple as possible distrubtion. Not an installer because it just looks nice with your logo there :).
 
sfrenchie said:
....
And let's admit that cleaning up a system of duplicate BGL's isn't too difficult, it's just about findind and deleting them...although 739 pages of them is going to keep you busy for a while :p

Once you are done do you count on cleaning up the corresponding textures too?
Haaa, interesting problem there, how do you find them? Are they under the general Texture folder, the Ez-Scenery folder, the Runway12 folder, the Peter Paul & Mary folder and wherever else. ...
Click to expand...

Renaming duplicate bgls and moving the newest to a folder is not the problem.

The corresponding textures are really hard to find, if it is not a library which was distributed seperatly.

:confused:
 
Won't let me post because I'm typing in the quote so disregard this line.

arno said:
I think it took some time for people to understand that there is no Rwy12 library, EZ-Scenery library, etc. They are all the same libraries. So indeed packing multiple libraries in a "tool specific" package makes no sense at all, especially duplicating them easily makes a mess.
And see, I'm just learning that now. I had no idea

I am not referring to that. So I mean here that if the objects are for reuse on many airports they need to go in a library only package.
Gotcha, if you have a tower you are using on 5 airports then distribute a library of airport objects instead of distributing the same tower 5 times in 5 different scenery. Yes, that makes perfectly good sense.

That's not what I meant. Even if you make a reusable library of generic GA airport objects, I would not be in favour to split the hangars from the control towers from the platform objects, etc.
Hum, let me approach the matter in a different way and say I agree, if you distribute say GA_Airport_Objects_Frenchie and include hangars, towers, etc. BUT, I'm fussing about distribution of the same library if named Hangars_Frenchie. Let me take back what I said originally and state that the content of a library should be reflected in the name and if/when possible keep objects of the same type grouped in the same library. I honestly don't care much about finding people objects, few static aircrafts, few hangars, few ground markings in the same library. In the end I just disregard them and go in favor of those that are more organized.


Agreed, it would be a good suggestion to encourage as simple as possible distrubtion. Not an installer because it just looks nice with your logo there :).
Click to expand...
 
I was just looking at some library zips and thought it was worth mentioning what I find to be an exemplary distribution file, see file ga_hangars_ss_vol_2_v1.zip.
 
You must log in or register to reply here.
Back
Top