Object libraries, again

A few weeks ago I made a post about the problems that arose with not so experienced EZ-Scenery users trying to change/alter object libraries. In the past few days I come across a few more discussions that relate to this and what I read there worried me a lot. So therefore this new post about the subject.

What worries me the most is that some people think about (or maybe even put into practice) the idea of decompiling libraries, to then put the objects back into new libraries that are organized according to their preference. So for example all hangars together.

Having a way to organise your objects is not bad of course, that is a very useful feature. But you should NEVER alter existing libraries during that process. There are quick a few good reasons for this.

  • When you create your new library, all objects will get a different identification number (GUID).  This is certainly not prefered. Think of the chaos that would appear when we end up with one object having dozens of different GUIDs in the end, because a lot of users made their own personalized library. You would never know from which library you are reading that object at the moment.
    It is also just against the reason of libraries in the first place. There are meant to be as a collection of objects, that can then easily be used in different sceneries.
  • In the end if would cost you a lot of disk space as well (and thus more downloading for the users of the scenery as well). Would you be happy if you had to download the same objects again and again? Of course not, it is much easier to download one library containing them all once and after that any scenery can make use of them.
  • By changing the GUID that the origional author has assigned you also break his backwards compatibility. Imagine that he uploads an improved version of his library. Any user that uses his origional one wouldn’t have to change anything, their placements refer to the GUIDs of the author and they can thus automatically use his new objects. But if you have assigned a new GUID to the object, you loose this.
  • When compiling the work of somebody else, you are usually breaking his copyright/user license. So you could get in trouble if you distribute this new library.

I am not saying that those EZ-Scenery users that come up with these ideas are to blame here. They probably just miss a bit of “education” about what an object library is and how you can use it. So maybe it would be worthwhile to put some effort into that. Maybe it should even be part of the documentation of object placement tools, especially if they aim at a broad public that does not only contain hardcode scenery designers.

I also want to give some attention to another issue that came up in recent discussions. EZ-Scenery does scan your entire scenery library for object libraries. And they are then all added to the list you can choose from. But what happens if you have an addon scenery installed that also makes use of an object library? It will also appear in the list of course. If that library has been designed for one specific airport that is not something that you want and if the library is part of a commercial scenery you don’t want it either. In both cases you could never distribute your scenery if it uses objects from such libraries. Simply because you can not distribute the libraries with it.

So I think it is better if object placement tools would only show objects from generic libraries that are part of FS and object libraries that have been designed and distributed with the purpose of being used as a general object library. For example all those libraries that have been created for use with Rwy12.

For the moment we should trust the user of EZ-Scenery and hope he has enough knowledge to make the shift between those generic libraries he can use and the specific or commercial libraries he can’t use. But as they all appear in his list, I am afraid this will go wrong some day.

That brings me to a last point. There is absolutely no difference between an object library designed for Rwy12, EZ-Scenery or ObPlacer XML. The only difference is how those tools read their information about the library. So wouldn’t it be nice if we could get some sort of collaboration between users of all those tools. I would hate to see more Rwy12 libraries or EZ-Scenery libraries appear at the big download sites. We should see object libraries for Fs2004. And it should not matter which tool you use in the end to place the objects.

SCASM is bad and GMax is good, or is it?

Ever since GMax was included with Fs2002 discussion like SCASM is bad and GMax is good have appeared now and then. Now that FsX has been announced I have noticed that I appeared again. I saw questions of people wondering if SCASM BGL files would still work.

But people that ask such questions don’t seem to understand what SCASM is. It is just a compiler that creates a BGL file from a source code with a list of commands that you provide to it. The file that is produced is not something special that only SCASM could make, any other compiler like FreeSC or BGLC can make exactly the same BGL file. So to ask if a SCASM BGL file would still work is nonsense, as there is no way to tell which compiler created the BGL file.

Most people that this question are worried about the support of older scenery commands that they still use. And this is a valid question, but it should not be linked to the compiler used. If the old Fs5/Fs98/Fs2000 commands will still work in the future is something that is a good point of discussion. The introduction of the floating point commands in Fs2002 for example, makes the integer point commands used before almost useless. So it is logical to assume that support for them will be dropped somewhere in the future.

To return to the SCASM question, it is very well possible to make a BGL file that is identical to a BGL file created with the Fs2002 gamepack for GMax. So in that case SCASM is just as good as GMax. For Fs2004 this is no longer valid, as SCASM has not fully been updated to the Fs2004 format. SCASM is able to create mesh elements (VTP/LWM polygons for example) and do object placement (like we can do with BGLComp as well), but it is not able to create the MDL scenery object files. This is because the structure of these files would require quite a big change in the internal workings of SCASM and it is rather unlikely that this change will be made. So in the future we might see that SCASM is no longer equal to the other compilers we can use and maybe then we can start asking if SCASM is “bad”. But not because it is SCASM, because it does not support the latest formats.

New York

I am already a few days back from my trip to New York and here is a little travel report. Unfortunately I also brought back a bit of flu, so that is why I have not been really active the last days.

Our trip started at Amsterdam Airport Schiphol and luckily we departed from the G-pier, so I had a good look at the recently opened H-pier (I just modeled that one, so I wanted to check if it looked right).

The flight itself was with Delta Airlines in a Boeing 767-300. Luckily I had a window seat on this flight, so I could take a good look at the scenery. I have for example been looking at the sun reflection in the ocean for some while. Really cool how all those different colors blend. I must say that the sun reflections in MSFS don’t look that bad, they certainly look better then the ones (or should I say lack of ones) in the image generator we use at work. I guess that is something we can improve in the future.

When we arrived in New York there was an overcast, so unfortunately we could not really enjoy that view from the aircraft. But we had two days left to explore the city, before our course would start. As the city is very big of course, we mainly walked around it to feel the atmosphere. Our hotel was nicely located in Manhattan, so one day we walked to the south till we reached the end of the island. And the other day we went up north  to Central Park. And the last day we walked over the bridges into Brooklyn and back again. The view from those bridges was really nice.

I was impressed by the skyline as well. I have read the book “The island at the Center of the World” from Russell Shorto. It is about the first few (Dutch) years of the city of New York (then called New Amsterdam). In it are also some drawings of the skyline back then. The highest building was probably the windmill they had constructed. If you know see all those huge skyscrappers at the same place, it makes it hard to image how it once was.

Now that I am talking about the Dutch origin of the city anyway, did you know that Brooklyn comes from the Dutch town called Breukelen? And similar to that the name Harlem comes from the Dutch city Haarlem? Those are a few things that still remind of the Dutch origin of the city. Another is Wall Street. At the location of this street, the city wall used to be in the Dutch times. But I guess that is enough history for today!



From New York city we drove by car to Binghamton. Our course was given
there at the university. At first I had never heard of that place and
it did not really make sense why we had to go especially to there for a
course on flight simulation.

But it seemed that Edwin Link
designed and constructed his first link trainer in that area. At the
local airport there is even an model displayed. So this region really
has the roots of flight simulation and that makes it easier to
understand why exactly that university has collected quite some
knowledge on the subject.



The course itself was very interesting. A lot of different aspects of
simulation where discussed. It ranged from motion systems, to visual
systems, from control loaders to image generators. And of course the
aspects of mathematical modelling for the simulation were also touched.
In the end it was a really interesting week that provided a lot of
information about simulation and all its aspects. I will certainly not
become an expert in all, but it should always help to talk better with
the colleagues who are.

Away…

Next week I will be attending the Flight and Ground Simulation Update 2006 at the university of Binghampton (NY). I am really looking forward to this course, that I will attend for my work. While I am on the other side of the Atlantic I am also going to spend two weekends over there as a sort of short holiday (going to visit New York for example). So don’t expect any new blog posts during that period.

Once I am back, I am sure that I have some interesting things to post about. Maybe I can even apply some of the things I am going to learn at my FS scenery design activities.

Object library mania

Since the release of EZ-Scenery I have seen quite a few discussion of people who asked if they could convert a Rwy12 library into a library for EZ-Scenery. Or I read about other people who started to decompile object libraries, so that they could create a EZ-Scenery library using the supplied library manager.

I find this a worrying development. EZ-Scenery is a wonderful tool, that allows someone who is not a hardcore scenery designer to place a few objects on his local airport very easily. But when those people start to decompile other libraries, it is very easy to create a complete chaos. Without knowing it, you could easily end up with the same object getting a lot of different GUIDs. You might even have the distribute different libraries with the same objects, because you chose the from library. This is certainly not the point of an object library. So therefore I want to make a few things about a library very clear:

  • An object library is an object library. There is not something like an EZ-Scenery library and a Rwy12 library. They are all the same. The only difference is that there are object libraries in the pre-Fs2004 format and in the Fs2004 (XML) format. But most modern programs (like Rwy12, EZ-Scenery, ObPlacer XML) use the Fs2004 format.
  • The purpose of an object library is that you have a collection of scenery objects, that can be used by any scenery. Just make sure that the user has all the required libraries installed.
  • Although it is very easy to extract a MDL object from a library and use them again in a different one, this is not something to encourage. Most scenery designers will see this as violating their copyright! So just ask your end users to install the same libraries you have installed and don’t start stealing stuff.

I know there are some differences in how the different placement tool use the object library. EZ-Scenery for example reads your scenery library and shows you all object libraries that are available. Rwy12 requires a special XML file that specifies which objects are available, while ObPlacer XML uses the XML source used when the library was created. But in the end they are all able to use the same object library. I really hope that we will see more general object libraries in the future, instead of libraries for Rwy12 or EZ-Scenery. It is time that people start to see they are all the same…