The ScruffyDuck Blog

It may be difficult to get there and no stock airports do, but we recently came across another limitation of the Microsoft Scenery Bgl Compiler (BglComp.). That is the number of taxi paths that may exist at a single airport - the answer being 4,000. In truth that is a pretty large airport but nevertheless the limit is there in the compiler.

We have just had reports that a very long runway got truncated in FS9. On investigation we found that there is indeed some sort of limitation of around 24,000 feet. It appears that it is the Sim itself that does the shortening if the length exceeds this. The length in the compiled bgl file is the same as that set in the design tool. The same issues sems to exist in FSX.

We have just released LOM2ADE. This is a small utility for those who have Library Object Manager (LOM) and would like to import the information about Library Objects and their thumbnails into Airport Design Editor. You can download it from LOM2ADE Download

We have just updated our web site and given it a bit of a make-over. Nothing exotic but take a look and see what you think Airport Design Editor for FS9 and FSX

Up to the current version of ADE we have not included any tools to move (or rotate) an airport. This was due to the possible issues that moving can lead to especially for the unwary. the AFD information that editors such as ADE (or AFCAD, AFX or FSX Planner) generate is both visual and hidden scenery. At larger airports we have Approach code that links waypoints and navaids (pretty much fixed in space in FSX) to the runways. Moving, or rotating an airport can easily result in Approaches missing the runway altogether or causing unexpected doglegs and turns. Another issue is buildings and other facilities. Do you move them with the airport? if not then the terminal will sit nicely at the old location while the passengers at the new will be out in the rain. With ADE 1.50 you will be able to move and rotate both the airport and the buildings together so that the whole stucture maintains its integrity and relationships. It is quick and easy to check the effects of the changes on approach code in the visual Approach Editor.

However that is not the end of it. Moving may well result in part of the airport now hanging off the flattens and excludes or airport background so runways may disappear or go into the air. Trees may grow in the middle of the apron and so on. There is a great desire to place airports as accurately as possible and there do seem to be some in both FS9 and FSX that are out pf place. They can also get out of place if new terrain scenery or photo scenery is introduced. Finally the altitude of the airport may no longer match the terrain that it is moved to and may in total be on a plateau or in a ravine.

Not show stoppers but something to think about before just grabbing the runway and shifting in a few hundred meters to the south............

Now and then we cannot replicate a problem raised by a user. It seems that whatever we do things go right and whatever they do things do not. Even when we send a file that we know works for us it does not work for them. So now it is a case of unpicking the layers. I have stock standard installations of FS9 and FSX - no addons. Now many users naturally add layers of third party scenery - better terrain, photo scenery, enhanced airports and so on. Recently we could not replicate what a user is seeing when adding a terrain stream. Works for us - not for him. We now suspect mesh enhancements. Another user has trees and scrub all over the runway - turns out it is special autogen from the Acceleration Pack and not amenable to exclusion by the normal methods.

I suspect sometimes that users think we are not much help but the reality is that we cannot replicate every setup with every set of addons so now and again we get stumped and perhaps can't fix the problem.

Lot of people seem to be moving to Windows 7 and the question keeps arising as to whether FS9 and FSX will run well under this operating system. My experience is yes. As part of the development environment I use both FS9 and FSX are installed under Windows 7 64bit. Both run well.

Since the introduction of User Access Control (UAC) with Vista users have had problems when installing FS versions in the default directories. We strongly recommend that FS9 and FSX are installed in folders away from the default C:\Program Files folders. There is no problem in doing this and it gets away from problems that arise when UAC stops files being added or updated. Some users turn off UAC but I would not recommend doing that, and there is no need if the sims are installed away from default folders.

A question was asked recently as to whether FS will run under 64bit operating system - the answer is, of course, yes. Most addons and other applications designed for 32bit operation will also run just fine. I have used a 64Bit operating system now for a couple of years and cannot think of only one or two instances where an application will not run. These have been device oriented programs rather than end user applications. There are indeed advantages in a 64Bit operating system if you have 4Gb of memory. Under a 32Bit system you will not see all the RAM - maybe only around 3Gb. This is because the maximum amount of memory that can be addressed by a 32Bit operating system is 4Gb. This has to include all the other memory such as graphics and that required by device drivers and the operating system. Thus the amount left for your applications will be reduced and some RAM is just wasted. With 64Bit you will get just about all the 4Gb and easily more depending on how many memory slots your computer has. Since I don't think there is any price differential between 32and 64 Bit versions of Windows 7 it makes a lot of sense to get the 64Bit if you have 4Gb in your computer. Unfortunately some manufacturers do ship a 32Bit version with 4Gb.....

JetBrains have just released version 5 of ReSharper. In a previous post I blogged about ReSharper and how useful it has been in helping me to create clean code. I find it indespensible and the good news is that Version 5 supports Visual Studio 2010. So it is pretty much goodbye to VS 2008 for me (and the development of our Flight Sim utilities) and hello VS 2010. ADE is already moved over and the other applications are on their way

Microsoft announced the release of Visual Studio 2010 yesterday. Today I was fortunate enough to be able to get my copy. Still early days yet but I am confident enough that I have moved the development of ADE from Visual Studio 2008 to 2010!

We have been having problems with automated emails from FSDeveloper to users. This has resulted in no activation emails for new users and no notification emails for existing users. We are working on a solution but it involves changing the FS Developer email server.

In the meantime if you have registered recently and not received an activation email please check if you can log in. We have manually activated valid new users so you should have access.

Until we fix the email problems we will continue with manual activation of new users. Hopefully we will be able to email you and let you know that you are activated on an individual basis from now until the email issues are fixed.

We have just had some questions about using model (mdl) files with ADE. As a result we did some tests. We found that FSX aircraft models can be added to FSX via ADEX. They show up in ADE with a proper footprint and will display in FSX provided that their textures are copied to the relevant texture folder. What did not work though was the altitude position of the aircraft, and when we raised it up a bit we found that the landing gear was missing:



So while it seems to work using aircraft models as static scenery the results do not appear to be very satisfactory.

Trying the same thing with an FS9 aircraft model fails. ADE cannot find any footprint information although it still loads the model (we need to fix this!). BglComp will not compile it and generates an error that the model data is not found.

Most of this makes sense when we think about it. In FS9 aircraft and scenery object mdl formats are different. In FSX they are the same.

We saw this first a long time ago but it has just come back as a topic for conversation. FSX has nice animated jetways. However sometimes they appear to duplcate and other times just disappear. When designing an enahanced AFD file in FSX the DeleteAllJetways flag is usually set to true. This means that FSX will not read the jetways in the stock file any more but read them from the enhanced or modified AFD. This wil work fine unless an exclusion rectangle set to DeleteAll or DeleteLibraryObjects covers one or more jetways. At this point one of two things can happen. You guessed - either the jetways go or they duplicate. They can go because they are in effect library objects and the exclusion will remove them although it should not. In other cases it seems to reverse the effect of the DeleteAllJetways so duplicates start to appear.

So if you have a problem with jetways behaving this way when modifying and airport check for an exlcusion covering some jetways. The problem is somewhat worse in ADE. Because ADE handles buildings and library objects it creates tiny exclusions for each one. This allows users to just delete or move an object in ADE and the same effect will happen in FSX. ADE uses tiny excludes to make sure that only the stock objects are excluded. The up side of this is that users do not need to create their own exclusions and can move or delete objects individually. The downside is that these excludes are not visible to the user. This is because there can be a lot of them and accidently moving or deleting one will cause the original stock object to reappear and duplicate. We have found that the problem usually arises where a stock object such as a tug or other vehicle is located under or next to an animated jetway. This causes the problem and the best answer is to move the jetway a bit.

Really it is the only answer other than deleting the micro exclude itself. For the expert this is possible but not recommended unless you do know what you are doing. Compile the airport and load it from the bgl file. Micro excludes will now show up. Find the offending micro exclude and delete it. At the same time delete the copy of the object it covered from ADE. Save the project again and compile it. The original object will now show up and you won't be able to delete or ove it any more.

The other caveat is that ADE project files store a lot of information that is not stored in the bgl file. You will lose this when loading from the bgl file. So you may need to put back background image data and some other information. Generally speaking you should never load from and save to a bgl file (as in AFCAD 2 or AFX) this way you will lose project data and also repeated load/saves in the bgl format has been reported as causing positional drift in airport elements.

I posted a while back concerning losing code and my paranoia in that respect. History Explorer helps me to revert to older code if I need to and if I mess up what I am doing. Source Control is a bit different. This is usually used by teams of programmers and allows them to work together on a single project without having people change code on something at the same time. Essentially a piece of code has to be checked out to change it and this means no one else can work on it until it is checked back in again. Another big plus is having two versions of the code. Now this affects me. I release a version of ADE (or some other program) and then start work on the next version. Bugs arrive and I am stuck with either having to modify the new code to release as a bug fix or fixing two sets of code. I have tried both and got suitably muddled up! Source control programs allow code to be branched. This means that is it possible to work on two parallel pieces of code. At some point these can then be merged back together to form a single version again. This is very useful. Source control also provides yet another back up repository for the code (never can have enough of those as long as they are suitably dated and annotated!)

There are a lot of heavy weight tools out there to do this including those based on CVS and SVN. I have tried several. Most require a good understanding of some arcane underlying commands although there are visual front ends such as Visual SVN for Visual Studio. Many need to be connected to a database server of some description either locally or on a web site somethere, There are a number of sites that provide free and paid for services.

Recently I even thought of writing my own but then I cam across Code Co-op from Reliable Software (www.relisoft.com). This does not use a central server nor rely on user to server communications. Instead it is a peer-to-peer system that uses email to transfer updates across the team. It means that each team member has a full set of code and it is therefore multiply redundant. As a team of one I don't need the cooperative stuff but I have found that it is simple to understand and integrates fine with Visual Studio. It is not cheap at $149 for the lite version and $199 for the pro. However I will be keeping it on as my source controller. It is definitely worth having and has already saved my bacon at least once!

We are back working on the next version of ADE now. A lot of new code and changes that we hope will improve performance and handling of graphics.

It seems that generic buildings in FSX do not place as expected. We already know that they 'float' at some airports but this is something different. The reference point of a generic building is at the center point of the footprint (unlike library objects where it can be located anywhere inside and sometimes even outside the footprint of the object). In FS9 placement tools will place the object exactly as it appears in the Sim. In FSX placement can result in an error so that the building itself is not located with the center of the footprint over the placement coordinates. So far we have not found a pattern that allows us to correct for the problem. This does not affect other elements like runways, taxiways etc etc. The only explanation we have so far is that it may relate to the 'round earth' model introduced in FSX. The only solution (as for the floating buildings) is to replace them with a library object.