This is the new production version of SAS supporting P3D v3. It can be downloaded as a full manual installer from here: http://www.scruffyduck.org/simple-airport-scanner/4584282795 to replace your existing version.

I am trying to write a new utility.  I want to base it on an older one since that should save me some work.  BUT  I must have been on some sort of angel dust or jungle juice when I wrote the old one.  It is not that the old code is spaghetti or badly written.  MUCH WORSE - as far as I can tell I have used some really nifty and advanced code constructs such as dependency injection, interfaces and other glitzy stuff.  I must have understood it at one time but now it looks like something Einstein wrote on his way to E = MC squared.  I think it will take me longer to re-learn all these clever stuff than re-write it in my bog standard uninspiring and inelegant code.  Ho Hum

Don and I have spent the last few weeks trying to track down a nasty bug in ADE.  As part of the investigation we added extra code to help us understand what might be going on.  I also added some code to allow me to manipulate some data quickly.  This code should have been removed before we released the last update but in all the excitement (or frustration) I forgot.  Well that code was quite hidden so I could deal with it in the next update - fat chance!

Within hours of the release the log reports started to appear that came from this code so the users concerned had found it and could not resist having a go.  Why is it that we spend much time pointing out what is right in front of people but they can find that which is well hidden.

Mind you I am not one to speak about this since I am well known (to my wife at least) as not being able to find the requested bottle in the refrigerator even when it is on the front row.

Which brings me with no particular link to bugs - especially those that remain resolutely hidden for months.  Any programmer or developer will know the ones I mean.  Users can activate them at will without trying and can apparently describe how they got to them in great detail.  Meantime with all our tools and knowledge of the code we cannot replicate the behavior - in fact we cannot imagine how the bug could be triggered.  We follow the users description in detail - and end up nowhere.  We then look at the logs and find the user was doing something entirely different at the time - they swear blind they were not doing what the log says they were,

And the final non-sequitur concerns the users who swear blind they did not do something which we can clearly see they have.  On at least one occasion recently it took three of use several days before the guy admitted the inevitable and that somehow he must have done what we knew all along he had.

I think perhaps that I do need a hiding place after all.

I was taken to task this morning by my favorite user for describing the act of decompiling (reverse engineering) Flight Simulator stock files, modifying them and using the modified files in place of the original as hacking. Also that hacking is generally used to describe criminal activity such as breaking into bank computer systems to steal.  If the above is hacking then it hacking for the benefit of the community - rather than some criminal enterprise - and is therefore good hacking.  Also that if the said hacking results in problem for designers of other tools and software that may be adversely affected by said original 'hack' then those designers should perhaps become better 'hackers' themselves.

This got me to looking at various definitions for hacking.  My user - being a detailed and meticulous sort of person - indeed had done the necessary homework in respect of the sense of good and bad hacking.

I can't help feeling though that the act of opening up a copyright file, reverse engineering it and then putting back something different is a hack.  Mind you if I were a genetic engineer then I guess opening up a gene. reverse engineering it, modifying it and putting it back together would be splicing and not hacking - so maybe we are splicers!

Anyway I know I am one of those folks who contributes to the reverse engineering of said files and I need to decide if I am a hacker or a splicer...................

credit for this picture is to http://ghr.nlm.nih.gov/handbook/basics/dna

After much hard work Helli has completed the new ADE English Manual including all the 1.65 features, This manual is a substantial re-write over the last version and contains new and enhanced information. At more than 300 pages it contains much information of general interest to airport design alongside how to use ADE.

ADE has had the ability to move airports for a long time (provided you have a ProKey).  Recently we got a number of reports from users who either could not move the airport or got some duplications.  This seemed rather erratic and in testing we found that changing the parameters of the move even slightly would get the move to happen.

Some folks worked out that not moving the airport reference point (these are the coordinates stored in sim for the airport) but moving the rest of the airport facilities worked.  Well this is true but it is not actually moving the airport but rather re-arranging the elements of the airport in the existing location.  This does not work because the sim still thinks that the airport is in the original position and lots of things don't work including displays like GPS that rely on the airport reference point.

What we think is actually happening is the same as we find for stock navigational aids.  Microsoft did not provide us with a method to exclude the stock navaid so trying to delete it does not work.  Moving one results in some odd behaviors.  Over some distances the move works.  Then the navaid might duplicate and then it might not move at all.

Microsoft gave us exclusion flags and tools to hide stock airport data so that it can be replaced with our own.  However they didn't give us a way to exclude the airport reference point.  I guess they never thought that we might want to actually move an airport. 

So if you have problems moving a stock airport in FSX/P3D then chances are you are running into this problem.  You can try moving the airport reference point around a bit within the new airport location to see if that will help but it is all trial and error.

There is always something new to learn and not all of it good!

It's always the same.  No matter how much testing we do, as soon as we release ADE to production the bugs start flooding in.  Worse is the unforced programmer errors and general SNAFUs that follow.  The rule is never change functionality when you make a new release - so why am I incapable of sticking to it without tinkering?  Case in point was a small change that enabled a function for one version of the simulator.  The trail of chaos and destruction that followed makes me hate what I do.  The change generated the usual cascade of unexpected consequences followed  by apologetic posts on the forums and a rash of daily updates.  It must drive users nuts to get a new update every day - it would me.

Ho hum - well right now I am going to do something else - destroy a bit more of the house so that we can start again I think.  Nothing like wielding a crowbar and sledge hammer to get out the frustrations with one's own failings.

Ah - well I feel better having written this so I think I don't hate programming after all!

I don't know if anyone read my old blog.  I don't think so since the software went poof a while ago and no one has reported it to me.  Anyway the old blog is dead and here is the new one.

The old blog ran on one of my servers with its own software.  Since I can't figure out how to fix it and I am a dunce with web apps  I decided it would be better to use an on-line service.  I chose Post Haven.  It seems very good to me but then I have only just started playing with it.  In any case the history of it is interesting and I think these guys deserve support.

So here we are and if there is anyone out there - Welcome to my new Blog :)