Latest program version

They seem to be having problems on the VFR Autogen site that's hosting my program so I'll include the latest program executable in this post. This is only the program .exe and not a full install package so it's only for users that have previously installed a prior version or just so happen to have all the required runtime support files already installed on their computers.

Remember, this is still a beta program so there are risks and responsibilities to using it and any feedback about problems or recommendations should go directly to me and not the host of this website.

Art Martin


Tree size not saved

Hi Art.

just a notice - nothing too serious : when i save the treesize - and open
the program next time - the size of the first parameter is save *10 . so if
it is 0,950 then on re-open it is 9,50 - lol - i had some trees to the moon -lol

anyway - work is going on fast - my lakes are ok now also - great
enhancements until 23.4.05 - my D-Day...

Greetings from Stuttgart / Germany
Ah, see I'm from the western US. We have those giant redwoods out here so trees to the moon sounds good to me. lol. I'll look into that one.

Version 1.0.24

Latest program fix/upgrade is now posted at the VFR autogen site. This latest version addresses issues in the directory tree not saving the last visited path, fixes the problem of the program not saving the path to the default.xml when working with GUI object classes and adds in a feature I wasn't sure would work. In my mosaic selection screen you can now see all the autogen objects you've added to any visible square. On the last version all you could see was a red or green border around each tile to indicate whether an .agn file existed for it. That often fooled me because, especially during testing, I'd add an object or two to a tile that really required many objects. With the wide view of all the objects you can readily see areas where the autogen is too sparse.

Enzo, I haven't addressed your errant tree height problem yet but I know it does not show up when using the American version of the decimal numbers.

A few users have reported problems opening up scenery tiles that they've custom designed and always there's a common characteristic. They are using non-standard naming for their DXT bitmap files. Instead of working with names where the first 15 digits are the lat/long encoded, they are shorter or descriptive names. I guess I'm confused here because how in the world would FS know to display the tile if it's not using the standard naming convention. When I was creating photoreal scenery areas, the file that gets compiled into the scenery .bgl has no reference to filenames, only to the lat/long extends of the images. I just can see no way for FS to know to display a tile any other way but by sticking to that naming convention. Is it just that designers are using a temporary name that they intend to later change? If that's the case I'm sorry but my program simply won't support that. It just opens too many cans of worms.

Anyway, enjoy the new additions.

Here's a screenshot of the mosaic enhancement:



For he´s a jolly good fellow !

Hi Art,

hard working Mr. Dynamite Art Martin stroke again, eh ? :)
In your last 2 months you have established things that
i would have wished from Micro$oft since years , lol ...

I will have a drink on you (again) tonight !!! :D

If you ever come to germany - you are invited ! ( No joke ! )

By the way ... if the mosaic-tile-open would work with the
big amount of tiles in my directories - everything would be perfect for me. Too bad - it is Runtime error 9 .
Is it only the amount of tiles ? I tested it with Etienne Vauchez - LFRD -scenery ( GREAT scenery - and FREE ) and rolled down on the floor. There it works. What a COOL feature, Art - i am begging to work with it too -> cant think how much time i could save with this ...

Hasta luego - :wave:

Last edited:
I just can't think of a way to program the code to deal with a huge amount of files without taking over nearly all the memory available. Problem is that with tens of thousands of tiles you have to analyze them all to find out where they fit in the full mosaic before displaying even a subset of them. Even in best case your computer would freeze up while it's parsing through those thousands of files to figure out that info.

When I first began the process of photoreal scenery I think one of the designers told me that with huge projects they broke up the full scenery into separate smaller areas and gave the user the ability to add on only the parts they wanted so they didn't have to take the performance hit that might ensue from huge amounts of texture files having to be considered by FS in the surrounding area. That seemed like great advice to me. In the Phoenix area, covering probably 200 square miles or so, I've created 6 or 7 scenery areas, none of which have over 5 or 600 tiles. Even if your finished product needs to be grouped as a whole, maybe it's appropriate to divide areas up into smaller directories and then it appears the mosaic function works fine.

I have one other advantage in my photoreal project I'm working on. Phoenix overhead views look pretty much the same year round. We have no snowfall in the winter. Most of our plants don't change color seasonally so I'm sticking only to a summer texture. Only drawback to that is I'm unable to include lightmaps for the night views. It's another reason why I'm so interested in placing huge amounts of houses, buildings and objects on my scenery. The lights in them do a good job of defining the view at night. That factor certainly keeps down the amount of tiles I need in any area.

Yo ...

Hi Art,

ok - understood !
I looked at the scenery-folders right now and saw that one
folder has got 6000 tiles , the other one 16000 ones...

The other germany-tiles same ... sigh ...
I thought the memory is only used by the visible tiles and
deleted each time you press a left- right- up- or down-button like the clipboard-windows-thing. But perhaps this would be simply too slow - don t know.
But no problem - perhaps i will code a small proggie in
PureBasic that copies the areas around the tile that i want to a directory and back after working on them ...
Just a workaround but acceptable because this feature is
really great. I looked at LLH-1 in France and LFRD France.
Absolutely great.

Perhaps it will work when i separate the 6000 into 6 different folders ? Hmmm -.. i think NOT - the Scenery-folder must be in one- the texture-tiles in the same directories - .... or not -... ? Hmm - must try out that !

Ok - i will do this - by the way - the first vegetation-height
value is not save * 10 times - that was random when i spotted this. The first value - when i restart the program is simply ALWAYS 10.000 - it was random that MY first value was 01.000 - lol. When i have 00.050 there then next start it is 10.000 again always even with saving to defaultvalue. But when you realized it - no problem.

Ok - Art - thanks for answering - it s Monday morning again and i am going to my customers !
Yesterday going to the zoo was much nicer :laughing:

Bye - til next time

Enzo :wave:
good_old_enzo said:
In your last 2 months you have established things that
i would have wished from Micro$oft since years , lol ...

I'd like to second that, you've given us a great tool that makes autogenning almost fun. I even enjoyed the giant trees -- sometimes I just like to park my plane in a giant grove and listen to the (giant) birds singing...
Now that you have every right to be pleased with your efforts, you're probably looking at ways to make this even better?
One tool I use, for tidying up, is Richard Ludowise's TCalc2004. I can fly around looking for missing bits, faults, anything that needs to be tweaked, and TCalc2004 will give me the tile name. I then copy/paste this into annotator. I've always thought this would be good integrated into the annotator. Just press a button, load the tile under your aircraft.
Just a thought.
I've definitely considered a link into FS for slewing around and picking out tiles but here's the problem. I can calculate the tile name from the position but FS doesn't return the directory path of where it's picking up the scenery from so I'd have to either preload in all the file info from addon scenery areas or do a directory search each time someone selects a tile. Will be fun though to experiment with the functionality.

One feature I'm hoping for in the next FS release (other than them not changing drastically the way the format of their .agn files) would be the ability, while running the simulator, to immediately regenerate scenery without a program restart if any of the scenery info changes and communicate that info through their SDK.

I'd be willing to bet that the MS FS engineers have a back door to be able to do that during their design phase - be running FS, press some key combination and have FS recompute the scenery in the surrounding areas immediately to see what new editing changes look like in 3D. I just can't imagine these guys being satisfied with making an edit, restarting FS, waiting for all the scenery in the surrounding area to reload, seeing they placed the object incorrectly, and going back and doing it all over again.

Just as every game has cheat codes built into it, I'll bet FS does too. Software engineers didn't initially start putting cheat codes into their programs to entertain the game players. They did it because, when you're programming a game, you don't want to start all over again everytime your test player dies in a game so you make him invulnerable. You have to see the game as a whole during testing and be able to get past the pitfalls you've programmed.

If we could find out the cheat code to reload immediate area scenery or MS would include the hook in their SDK so that it was controllable through FSUIPC or FSCONNECT, just imagine the possibilities for scenery designers. Slew to the area you're editing and see what's missing. FS communicates to your program the files and paths it's looking into to draw the immediate view. Make your edits to photo tiles, autogen, mesh, coastlines, whatever and save the changes to the addon or default scenery area. Send the hook to FS to recalc the immediate area scenery and viola - your changes show up in 3D in front of your plane.

I'm too much of a dreamer aren't I?



Staff member
FSDevConf team
Resource contributor
Hi Art,

artmartin said:
One feature I'm hoping for in the next FS release (other than them not changing drastically the way the format of their .agn files) would be the ability, while running the simulator, to immediately regenerate scenery without a program restart if any of the scenery info changes and communicate that info through their SDK.
That is how it was in Fs2002 and before. But to improve the stability of the sim it has been changed in Fs2004 (which is something I can understand). From what I have heard the MS devellopers suffer from the same problems we do, the very often starting of FS.

As this "feature" has only been added in Fs2004, I don't expect it will be removed soon again. Although I of course hope it will.
Darn, I was really hoping the team that creates FS for Microsoft was a whole lot smarter than the bunch that came up with Windoze. Writing software that makes it tough for you to write software? Has the Gates touch.