Sign in to follow this  
Guest GerrishGray

Any news on the Autogen bug?

Recommended Posts

Hi. Has anyone discovered anything new on the autogen problem with FS2004? I'm talking about the problem where the XML-defined autogen objects and vector objects cause slowdowns after flying for a while, forcing you to refresh the autogen, or delete the default.xml file and disable vector objects (=FS2002 style autogen - welcome to late 2001!) There was a thread here some time ago, where the conclusion was that it might be possible to fix once the scenery is out but it isn't likely. Has anyone dug deeper into the problem? Has anyone heard anything from Microsoft at all? I would really like see this problem fixed so I can re-install FS2004. In its current state, it's simply not fun to fly.

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Jimmi, this has been pretty quiet for a while. There probably won't be a complete solution until Microsoft releases the you-know-what. But, based on their past track record, it's still many months away. But I have had one thought. At the time there was discussion on whether the visibility distances are set by the library or the individual object, or whether it's determined by the actual autogen system. I placed several autogen objects (fast food restaurant, light poles) with Airport 2.60 after converting the objects to macros. I then measured the visibility distances. What I found was quite intriguing. The on distances (the distance at which the object appears) were controlled by the Airport settings. If I doubled the Airport setting, the on distance doubled. However, the calibration was wrong. If I set 20 km in Airport then the actual on distance was about 7 km. The same error ratio of 2.8 occurred with standard Airport API's, so there appears to be a calibration error in Airport. The calibration error also occurs when using standard Airport API's. However, I found that, when placed with Airport, the off distances were the same as when the objects are used as autogen. It would appear that the off distance is set either by the library or the individual object, while the on distance can be set in Airport. Either way, the off distance (the cause of the problem) is most likely *not* set by the autogen system. This strongly suggests that the problem could be fixed by making a new library containing replacement objects with sensible visibility distances. So if anyone has ten minutes to spare.... Best regards, Chris

Share this post


Link to post
Share on other sites

This is very interesting Chris. I would have no idea how the library could control the off distance (there is no command for this, as far as I know). The only parameter for the distance is the v1 range in the RefPoint.I will try to check what you have seen with my own AutoGen macros and report if I see the same results. Sounds like a nice challenge to me :D.

Share this post


Link to post
Share on other sites

Arno, I tried another experiment. I had previously made several objects in Gmax and put them into a library using Fsregen. They work fine when placed with Airport. I changed the guid's in default.xml so all the fast food restaurants called up one of my objects. In theory my object would appear. In practice, the fast food restaurant had vanished, as expected, but there was no sign of my object. Unless I made a mistake with the guid numbers, this strongly suggests that FS2002-style libraries cannot be used as autogen. If so, then the idea of making replacement autogen objects would not work as it would require knowledge of the new library format. If my measurements are correct, and you can confirm them, then logically it seems likely that the off distance is indeed set by the library. After all, when placed in Airport there should be no connection with autogen, so the only common thing is the library. Could it be that Microsoft have indeed added visibility settings to the libraries specifically to support the new version of autogen in FS2004? Best regards, Chris

Share this post


Link to post
Share on other sites

Very interesting Chris. I wished I wouldn't have that much other things to do first, otherwise I would jump into some testing right away :).Where did you place your library BGL? I don't know if that has any influence on it, but did you place it in the same folder as the default autogen?I will try to do some tests of my own as soon as I find some time, because this is a really interesting problem :).

Share this post


Link to post
Share on other sites

Arno, I'm not quite sure which is the autogen folder, but I tried the following:addon scenery, scenerybase, scenerygeneric and sceneryworld. I think the guid was correct, so almost certainly FS2002 libraries won't work as autogen. Assuming the FS2004 library does influence the off-distance then it's not surprising, as I assume FS2002 libraries don't have any visibility information and therefore would not be compatible. By the way, I'm looking forward to progress on the other thread, as having a comprehensive list of FS2004 library guid's would be dead handy! Best regards, Chris

Share this post


Link to post
Share on other sites

Yes, the progress in the other thread is great news. I also hope that the new things we learn there will help us in understanding better what goes wrong here.And an easy way to use the default objects is always welcome to a lot of scenery designers :).I looks like you tested all posibilities with the Fs2002 library, so your conclusion looks correct then. Just an idea, have you tried using one of the default Fs2002 libraries (not sure if Fs2004 uses the same GUIDs everywhere, otherwise it could give trouble with duplicate GUIDs)? I am wondering if the information you can enter in the header of the library object (scale, power, etc) might have an influence. In the custom libraries I have made I ussually left them at 0 as I saw no real difference, maybe this is part of the problem (just guessing of course at the moment :D).

Share this post


Link to post
Share on other sites

Hi guysArno is quite correct when he says that a library object does not contain a visibility setting as such, but (as I have explained before) it DOES, and always has, included a range setting - the PWR value in the SCASM LibObj() syntax. When an object is called via a section 9 CallLibObj(), this value is effectively overridden by the 'range' of the Area() in which the CallLibObj() command is located, but it may well be used by the new Autogen system for placing objects. Your testing also suggests that it may have some significance in determining how long each object is retained in memory, whichever way it has been called.It is also important to understand that the Area() range does not normally control visibility - it determines when the full code of the Area() block is loaded into memory. Actual visibility is determined by the V1 value in RefPoint() (and other factors ...?). This difference between range and visibility is intentional and has nothing to do with any error or mis-calibration in AFW, nor in FS.In the case of Autogen-placed objects, however, visibility can only be controlled by the range (PWR) value (and by all those other factors that FS seems to use to determine actual visibility).In the past, most of the default library objects were given a PWR value of 0 and so a default value would have been used where necessary. I would guess that this has not been corrected in the new-format objects, although we won't know this for certain until we get the SDK and can 'read' the new BGL's. If my guess is right, this could account for the excessive 'persistence' of these objects. ------Chris. As regards your failure to get your own Autogen objects to appear, can I suggest that you try calling them via an old-style CallLibObj() macro and verify that they do appear that way. If they work OK that way, but don't appear via the Autogen mechanism, there may indeed be a difference - but note that we CAN place the new default objects fine using CallLibObj(), so they can't be very different.------CheersGerrish

Share this post


Link to post
Share on other sites

About the range settings, I assumed that Chris had changed the v1 settings when he writes about Airport. The scale error factor of about 3 makes me wonder if that might have something to do with the metric/feet conversion. I have never noticed such an error before.

Share this post


Link to post
Share on other sites

Hi ArnoI don't think that there is any error here, nor anything to do with feet/metres. If Chris has been trying to set both the Area() range AND the RefPoint() V1 to 20km+, the objects are probably still not going to become visible that far away. In my experience, most 3D objects (whether they are library objects or 'normal' section 9 visible objects) rarely become visible beyond about 7-10km, however hard one tries to increase their visibility. But my experience is fairly narrow - what do you find with NL2000 - have you managed to persuade objects to appear at a greater distance on a consistent basis? This is why I believe that FS uses other factors, apparently not under our control, for setting the actual visibility distance, not just V1.The exception is the new Autogen mechanism, where some of the objects can be visible at a much greater distance, as Chris has reported.CheersGerrish

Share this post


Link to post
Share on other sites

Hi Gerrish,I think we have discussed here more often that the maximum range of the RefPoint is about 20 km or so. If you enter a higher value it has no influence. We have also noticed that with the NL2000 scenery (mainly because I can't convince them to use mesh scenery and we use section 9 polygons for the cities etc).But when I wrote that I never noticed this problem I meant that I have never seen a big difference between what I enter in Airport/FSSC/GroundMaker and what happens in the scenery.What still surpirses me is that Chris writes that the off distance of the objects is much bigger then the on distance. I have never seen this with normal objects (and i can't think of a reason why this would be helpful). So I think that must be something different then the Area or RefPoint range.

Share this post


Link to post
Share on other sites

Arno - and Gerrish: Here's some clarification (hopefully!) First, I haven't done anything in SCASM - I wouldn't know how to! I simply load the API into Airport, double-click on it and type in the visibility distance. Ooooops, I made a mistake on the Airport calibration. I set the distances in kilometers but measured the results in miles. When converting from miles to kilometers I divided instead of multiplying! Now the distances agree quite wll. Sorry about that. I'm actually pleased, because it confirms my distance measuring method works correctly! At least I'm in good company. I believe NASA lost a Mars probe due to a similar mistake! Here's an example: the light pole. The API:*************************************************************; ------ Lightpole------------------------------ Area( 5 %1 %2 %3 ) mif( %12 ) IfVarRange( : 0x0346 %12 5 ) mifend CrashIndirect( :Object :Shadow :Rotate 0 0 ) PerspectiveCall( :Persp ) ShadowCall( :Shadow ) Jump( : ) :Persp Perspective :Shadow mif( %11 ) RefPoint( 2 :EndP %4 %1 %2 v1= %10 E= %11 V2= 190 ) melse RefPoint( 7 :EndP %4 %1 %2 v1= %10 V2= 190 ) mifend :Rotate RotatedCall( :Object 0 0 %5 ) :EndP Return :Object CallLibObj( 0 47c97ced 4e4bc4e6 10b19f8e 62ea9e98 ) Return EndA******************************************************************* If you see a couple of smileys they were added by the forum, not me. Maybe the forum knows something I don't! In Airport I made five copies with distances set to 1,2,4,8 and 16 kilometers. Here are the measured on and off distances in km:1km set: 0.9 352km set: 1.8 354km set: 3.7 358km set: 7.6 3516km set: 13.3 35 As you can see, the on distances are fine, but the off distance is always 35km. As autogen, I measured the on and off distances at 21.8km and 34.9km. The record was held by the power station, with 11 and 38km. The off distance is the same, whether it's autogen or placed with Airport. But the on distances are correctly set by Airport. Hopefully others will be able to confirm these measurements. If these measurements are correct, then Airport has no control over the off distance. Autogen is not involved when placed with Airport, so autogen can't be controlling the off distance. Therefore it seems likely that it is the actual object or the library that controls it. Different autogen objects have different on and off distances, so it's unlikely there's a global setting for the entire library. I would conclude from this that perhaps the data structure for each individual object in the library includes data that sets the visibility distance. The off distance is the key to the whole thing. Because the autogen off distances are *much* larger than the on distances, it explains rather neatly the fundamental problem reported by lots of people: that the frame rates only drop when you either look back or turn around. This all comes from one basic observation: that the off distance is the same whether placed as autogen or placed from Airport. Any other theories to explain it? Best regards, Chris

Share this post


Link to post
Share on other sites

Arno, yes, I have used FS2002 libraries in FS2004. In my Karakam scenery I had 'borrowed' some of the great historical buildings from Rome. In FS2004 I found fsregen didn't work, obviously because of the change in format, so I couldn't find the guid's. I simply copied over the Rome library and the textures into FS2004 and it worked fine. As the buildings didn't show up initially in FS2004 I assume the guid's are different. I don't know how to change the header, I've only used fsregen to work with libraries. My observations suggest that libraries made with Gmax/fsregen won't work as autogen. But it might be worth trying a FS2002 default library as autogen....imagine the roads lined with Coliseums instead of those boring old light poles! Best regards, Chris

Share this post


Link to post
Share on other sites

>>Chris. As regards your failure to get your own Autogen>objects to appear, can I suggest that you try calling them via>an old-style CallLibObj() macro and verify that they do appear>that way. If they work OK that way, but don't appear via the>Autogen mechanism, there may indeed be a difference - but note>that we CAN place the new default objects fine using>CallLibObj(), so they can't be very different. Gerrish, I'm using a CallLibObj() macro to place it in Airport - I've quoted the macro further down the thread. It appeared perfectly with the correct visibility distances. But when its guid was inserted into default.xml to replace the fast food restaurants, it didn't appear. My library was made with Gmax/fsregen. Best regards, Chris

Share this post


Link to post
Share on other sites

>Hi guys>>Arno is quite correct when he says that a library object does>not contain a visibility setting as such, but (as I have>explained before) it DOES, and always has, included a range>setting - the PWR value in the SCASM LibObj() syntax. Gerrish, one question occurred: does the PWR setting affect the whole library or is there a separate setting for each object? Different autogen objects have different on/off distances. Assuming they're in the same library - definitely an assumption - then if there's only one PWR setting in each library, that would imply the PWR setting is not involved, at least directly.... Best regards, ChrisPS: pardon my ignorance!CallLibObj( 0 47c97ced 4e4bc4e6 10b19f8e 62ea9e98 ) The first parameter is zero - is this the PWR value in the LibObj() syntax that you mentioned?

Share this post


Link to post
Share on other sites

Hi Chris.Thanks for confirming this. The object is "acquired" at a defined distance, but is not "released" until a set distance. That the release distance is variable suggests we will be able to eventually decompile and correct the release distances, once we understand the library structure.I haven't checked yet, but I wonder if setting the sim's visibility distance would affect the behavior of the "release". It may... not that that would be of any great use, but it would suggest the release could be manipulated.Dick

Share this post


Link to post
Share on other sites

OK Chris, thanks for that last clarification. I am still not sure why that should happen because I don't believe that there is any great difference between the new generic objects such as the fast food restaurant and any of our other objects, or those created with fsregen. It will need some further investigation. I could understand if the Autogen mechanism doesn't support old-style objects with non-floating-point rendering, but I would have expected gMax objects to work fine.As regards the latest test results, the first thing I am interested in is that you ARE now getting the 'on' distance consistent with V1. This is very encouraging, but does not always seem to happen when flying - did you do your tests in flight mode or slew mode (which behaves differently sometimes)? A number of other factors also seem capable of affecting when an object will first come into view in some circumstances.The universal persistence of the objects to a range of 35km before they disappear is very interesting. What happens if you back away from the objects in slew mode, or if you fly away from them obliquely and use one of the side views to see them. Also, how about flying away from them in the normal manner but using spot view from in front of the aircraft to view the scenery behind? In other words, is the persistence affected by the viewing direction/mode, or does it happen under all circumstances?This is difficult to explain if FS behaves in the way described in the existing SDK's. One would expect objects to disappear at more or less the same distance as they appear - as determined by V1. If I read your test results correctly, this persistence is happening even when the objects are placed by traditional means, not merely the new Autogen objects. It would appear that FS2004 may actually be failing to cull objects as they go out beyond the V1 visibility distance - although we should be able to confirm that one way or the other by some further systematic testing. Indeed, I am sure that plenty of users can already comment on this. If you are reading this thread guys, please let us know! I'll have to check it out with my own trees_v3 objects ...CheersGerrish

Share this post


Link to post
Share on other sites

Hi ChrisThe PWR setting is individual for each object and is (or, at least, can be) set in its LibObj() header. It is not set in any way by the calling command - that initial zero in the CallLibObj() syntax is a bit of a 'red herring' and merely reserves space for an otherwise unused parameter in the equivalent command within a compiled BGL. When SCASM was first updated for FS2000, it probably wasn't clear whether this parameter would eventually be required by later versions, so it was included in the SCASM syntax to ensure future compatibility, but unnecessarily as it has turned out so far.Traditionally, the default library objects have not bothered to provide a value for PWR either - and that could well be the cause of the current Autogen problem because FS would then be using a default value resulting in the 35km 'persistence'. But before we pursue this line of thought any further we need more data on just how consistent this persistence is, whether it always happens under any viewing conditions, whether the 'off' distance is fixed at 35km or whether it is actually variable, and also some firm data on the actual effect on frame rates under different conditions. You will need to do tests with a lot of objects in the scenery to get meaningful figures for frame rate effects.CheersGerrish

Share this post


Link to post
Share on other sites

By the way, to ensure consistent results and remove any possible side-effects from the code by getting it as simple and up-to-date as possible, can I suggest that you simplify your calling macro toArea( 4 %1 %2 100 )PerspectiveCall( :Obj )ShadowCall( :Obj )Jump( : ):ObjRefPoint( 7 :EndP %4 %1 %2 v1= %10 V2= 190 )Transform_Mat( a 0 0 0 0 0 %5 )CallLibObj( 0 47c97ced 4e4bc4e6 10b19f8e 62ea9e98 )TransformEnd:EndPReturnEndANote that I am suggesting that you hard-code the Area() 'range' as the high value of 100 to prevent any extraneous effects from that. If you find that this has changed the 'off' distance, then see what happens with Area() ranges of, say, 20, 40 and 60 instead.I would also be interested to know if you can extend the 'on' distance beyond ~13kms by setting the v1 value to 32000m, as well as the 1000, 2000, 4000, 8000 and 16000 values that you are presently trying.ThanksGerrish(and now, like Zebedee, I think that it is probably time for bed ...)

Share this post


Link to post
Share on other sites

>That the release distance is variable suggests we will be able>to eventually decompile and correct the release distances,>once we understand the library structure. Hi Dick, that occurred to me. Gerrish is surprised that Gmax/fsregen libraries appear to behave differently to FS2004 libraries, so I need to do more measurements to confirm that. But, assuming there is a significant difference, once we understand the library structure it would be possible to make replacement objects with sensible vis distances. But then, as you point out, if we understood it we could simply go in and correct the vis distances. Hopefully....>I haven't checked yet, but I wonder if setting the sim's visibility >distance would affect the behavior of the "release". THat's an interesting thought. Oh dear, more testing to do.... Best regards, Chris

Share this post


Link to post
Share on other sites

> did you do your tests in>flight mode or slew mode (which behaves differently>sometimes)? Gerrish, I used slew mode for all the measurements. I note the latitude of the object/objects (usually just the minute value) and then slew southwards. I note the minutes readout when each object vanishes. When they've all vanished I slew some extra distance southwards. Then I move northwards and note the minutes when the objects re-appear. One curious thing. If they're default.xml or vector autogen objects they will vanish together at 35km. But if I instantly stop slew and then move towards the objects, sometimes they will all re-appear together essentially at the same 35km distance. However if, after they vanish, I slew a bit further southwards, they will then re-appear according to the distances set in Airport. Could that be a clue?>>The universal persistence of the objects to a range of 35km>before they disappear is very interesting. What happens if>you back away from the objects in slew mode, or if you fly>away from them obliquely and use one of the side views to see>them. Also, how about flying away from them in the normal>manner but using spot view from in front of the aircraft to>view the scenery behind? In other words, is the persistence>affected by the viewing direction/mode, or does it happen>under all circumstances? I'll do a few checks for consistency in normal flying mode. Also I'll try Dick's idea of checking to see if the sim's visibility distance setting has any influence.>>This is difficult to explain if FS behaves in the way>described in the existing SDK's. One would expect objects to>disappear at more or less the same distance as they appear ->as determined by V1. If I read your test results correctly,>this persistence is happening even when the objects are placed>by traditional means, not merely the new Autogen objects. It>would appear that FS2004 may actually be failing to cull>objects as they go out beyond the V1 visibility distance ->although we should be able to confirm that one way or the>other by some further systematic testing. Indeed, I am sure>that plenty of users can already comment on this. If you are>reading this thread guys, please let us know! I'll have to>check it out with my own trees_v3 objects ... This problem only appears to apply to the autogen objects called up in default.xml and to vector autogen (bridges also had a very large off distance). But the autogen trees are fine, with on/off distances of 5km. In general, the difference between on and off distance for well-behaved objects is about 0.3 km, which is reasonable. Non-autogen objects placed with Airport appear with the correct on/off distance as set in Airport, again with a difference of about 0.3 km. There's definitely something odd about those default.xml objects! Best regards, Chris

Share this post


Link to post
Share on other sites

Hi ChrisReading your post from 11:20 this morning clarifies a lot. So it is only the default generic.bgl objects that display this 'persistence' behaviour, and it doesn't matter whether they are called via the Autogen mechanism or a normal CallLibObj() macro. All other objects behave correctly, with 'on' and 'off' distances matching the V1 visibility range of the calling sequence, and other types of Autogen objects, such as the standard trees and buildings, also behave correctly.That reassures me because I have to say that was my own impression and I was wondering why I had not seen the 'persistence' behaviour myself on all sorts of objects.So we can now confirm that the problem lies within the coding of the default objects in the FS2004 version of generic.bgl (and perhaps vehicles.bgl and other similar libraries in FS2004). And it is not related to the Autogen mechanism, but rather to the objects themselves. Does anyone disagree?CheersGerrish

Share this post


Link to post
Share on other sites

Yes, I think that is the correct conclusion to draw now.I am wondering what kind of new command or parameter they are using in these libraries to control the off distance separate from the v1 range (or the equivalent autogen range).And if this has something to do with the fact that FsRegen libraries don't show up on the autogen. I want to try the NL2000 library I am maintaining in the autogen, it isn't made with FsRegen, but with SCASM, maybe there is a slight difference in the code used. Just to verify that the FsRegen library is not causing that problem.

Share this post


Link to post
Share on other sites

Gerrish - and Arno and Dick, yes, the situation does seem fairly clear now, particularly after clearing up my mistake with the Airport calibration. I did some more measurements yesterday which I'll briefly describe. I repeated measurements of on/off distances for the light pole with maximum Airport settings. For an Airport setting of 16km the measured on distance was 15.3km. But for settings of 32 and 50km (the maximum allowed) the measured distance was 24km for both, so that appears to be the maximum on distance. As always, the off distance was not affected by the Airport setting. I tried to measure in normal flight, just in case slew mode influences it. The problem is that when measuring very large distances I have to use enormous zoom values such as 48 - this would require an expert pilot to keep the object in view! I slewed to within 2 kilometers of the off point and checked the light poles were still visible. Then I flew another three kilometers and then looked back. Sure enough they had vanished, so the off distance was essentially the same as when measured in slew mode. I tried changing the visibility settings as per Dick's suggestion. I changed both the main weather setting and the max visibility setting in fs9.cfg. Basically, this appears to have no affect on the off distance. Of course, with lower visibility the objects became softer or were completely obscured by the fog. However, when the object was not obscured by fog the off distance was unchanged. I used the FS2002 Rome library in FS2004. It works perfectly when placed from Airport, but does not show up from default.xml. I tried all the obvious locations for the library. Is scenerygenericscenery the most likely location? Thinking about Rome, I visited that beautiful city (sadly, only virtually!) The visibility effect is striking. Go to the centre and then slew away. Lots of buildings and trees in the centre vanish as you retreat. Finally all that's left is the long-distance autogen - and the historical buildings (which are library objects). It looks as if Rome has vanished - except for the historical buildings and the fast-food restaurants! I measured the on and off distances for the historical buildings at 28 and 29km respectively. The distances are very large, but the difference of 1 km is sensible. If I knew the guid of a Rome building I'm sure it would work as autogen - it would be interesting to measure the on/off distances! I would expect them to be the same, if the theory is correct. If, as I hope, there is progress in deriving the guid numbers, then we would have more clues. Using the recently posted guid numbers from vehicles.bgl, I pasted the guid for a ship into default.xml. The ship replaced the fast food restaurant without complaint. The ship's off distance was 27km. As an aside, you can try a very simple experiment in any dense area such as Los Angeles. Simply set autogen to max, look at the horizon and crank up the zoom level to, say, 48. The land is not completely empty at this large distance because it is populated by light and telephone poles, fast food restaurants, power stations - all the usual suspects. There's another piece of evidence: fsregen. fsregen can't read the FS2004 libraries. For the city libraries it reports there's no data at all. It reports generic.bgl and vehicles.bgl have a non-valid bgl format. The one exception I found was dynlib.bgl, which fsregen reads correctly, probably because this is identical to the FS2002 version. So it does look like there's a large or small difference in the new libraries that has a major impact on their use (by us, that is!) I see the first four SDK's came out today. If the pattern from FS2002 is repeated then the scenery SDK will be the last in the queue. But I guess we've got used to being patient.... Best regards, Chris

Share this post


Link to post
Share on other sites

Hi Chris & allYes, it's pretty clear now. The recompiled objects in the FS2004 default libraries seem to have something different about them that we will not learn about until we get the Scenery SDK (and perhaps the appropriate part of the Autogen SDK). We can place these objects OK via the CallLibObj() mechanism, but we can't do the reverse and place older objects via the default.xml mechanism. We already knew that there was something different about the vector objects that allows VTP vector Autogen to place them in lines, so I shouldn't have been so surprised about this :-)So there is no workaround for the Autogen object persistence problem (and it is pretty likely that is what causes the large memory use and drop in frame rates) other than disabling default.xml. To be honest, I don't find it too much of a problem anyway, but I don't do long flights, or many accurate procedure turn approaches (which are particularly likely to provoke this problem).Once we can edit, replicate, or replace the default library objects it will be easy enough to cure the problem.Thanks for your great work, Chris. Your methodical approach was the key. So often we try to diagnose a problem or 'feature' in this forum and everyone tends to go off on tangents and does inconclusive testing changing half-a-dozen different things at once with no systematic methodology. We can all be guilty of it - the time it takes to reboot FS doesn't exactly encourage us to do it properly!!!So we've got the first batch of SDK's, but I for one won't be holding my breath waiting for the Scenery SDK - let's face it, it is always the last to appear. Best way to view it is as something to look forward to!I'm going to try and get my head down back into the next version of my trees - I can worry about the new format later, and in the meantime the present format has the advantage of backward compatibility with FS2002.CheersGerrish

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this