A few weeks ago FsX has been announced and now and then new screenshots appear. And until now I haven’t even mentioned this great news on my blog. But I do not want to discuss the released screenshots here, there is enough discussion going on about that on general FS forums. And I think most people will agree that they look great.

Since the announcement of FsX I have already seen a few discussion about the backwards compatibility of scenery. And on that subject I would like to give my opinion. The question is always will my old addons still work? Of course it is a good thing that we have some backwards compatibility, because we don’t want to redesign everything for each new version of FS. But I think now is a good time to clean up some of the compatibility for really old code.

Almost each addon scenery designed since Fs5 does still work in Fs2004. It is really surprising to see that most of these old commands still work, although not all. If all those commands worked fine together, this would not be a problem of course. But in reality that is not the case. Quite often you see people that have created an apron in a tool like FSSC or Airport for Windows and they are looking for a way to get it below their AFCAD created runway. Unfortunately for them the answer is that that is not possible. This is just one example where the Fs2004 scenery code and the pre-Fs2004 code does not really work together that well.

For a new scenery designer this is also very confusing. He finds a load of tools he can use, but he has no idea if and how they work together. Quite often this results in new people making the wrong choices (for example EOD, Airport for Windows, etc). I am sure this is a big frustration for a lot of them and makes them give up scenery design, while it should be fun to do.

So although it might mean some extra work for us, I really hope that MS is going to clean up the supported commands. Please stop supporting all those Fs5, Fs98 or Fs2000 commands, as in general trying to use them together with Fs2004 gives more trouble than it solves. This would also reduce the jungle of scenery design tools we can use automatically.

There is one exception I want to make here. If we only want to use the Fs2004 techniques for airports (so the XML commands) they need to become a bit more flexible. At the moment these commands are too restricted to make a realistic looking airport. You can’t make markings in different colors than yellow, you can’t use custom apron textures and you can’t control the mapping of these textures. So MS please make the XML format a bit more flexible for users who want to create an airport that does not look like the default scenery and then I am sure nobody will miss those antique Fs5, Fs98, Fs2000 commands.

Texture and material blend

At work we have recently updated our image generation software and the models that I had converted from GMax models suddenly looked a lot darker in the visual. To dark actually. So after a bit of searching we found out that the new version of the IG blends the material and texture, while the old on did not. So because the ambient color of the material was not white, but gray, it resulted in a darkening of the texture. With this extra knowledge that was easy to fix of course.

Because I was interested to see how FS behaves here, I did a few tests with blending of material and texture there as well. I posted about the results on my forum, but the main conclusion is that FS only blends the emissive color. All other colors do not have an effect on the display of the texture. Only the combination of a specular color and the power parameter seems to have some effect, but I can not create a useful visual effect with them. It only seems to distort the image.


The last few days I have been using the OGR library at work. As the website says, it is a Simple Feature Library. It allows you to rather easy read, manipulate and write vector features in different file formats (for example DXF or SHP).

This can be very useful, as you do not have to create your own file format parser, as I did for my DXF2SCA tool. And the manipulation of the vector data is really nice. At work we for example use the union function to make one  big polygon out of different taxiway segments. And the buffer function is used to calculate a grass area around all features of an airport. This way we can rather easy make some generic airports for our visual databases.

I think I will also give this library a try for my next (updated) version of DXF2SCA. That could certainly save me some coding and allows me to focus on the scenery output for FS, instead of reading a certain file format.

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.


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…

How to crash FS

I think every scenery designer will know how to do this. Just do something slightly wrong in your addon BGL file and FS will clearly tell you it does not like your new file. Especially when you start to tweak the ASM or SCASM source codes manual it is very easy to do something wrong.

But while working on MDL Tweaker II last evening I was able to make it crash even better. As you might know MDL Tweaker II does edit the MDL files directly, so I am writing the binary code to it directly. And while testing the feature to add conditions I by accident made a jump that jumped ahead 0 bytes. So it would jump to itself, and then jump again to itself, and then… Well I guess you can guess where this ends. FS clearly did not like this new MDL file (although BGLComp did not complain during compilation). Once I fired up Fs2004 the loading screen showed up for a little while and then I was back at my desktop, without any error or warning.

Now I understand a bit better why MS does not very actively encourage this kind of object tweaking. The chances that you make an error are quite large and their support will not appreciate problems like this as well. But that is no problem for me, I have already accepted that most of the crashes I get here are caused by myself. That is just the price you have to pay, when you try to extend the use of your scenery.