Any news on the Autogen bug?

[JimmiG 244]

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.

[Guest cwright]

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

[arno 1]

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.

[Guest cwright]

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

[arno 1]

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 :).

[Guest cwright]

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

[arno 1]

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).

[Guest GerrishGray]

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

[arno 1]

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.

[Guest GerrishGray]

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

[arno 1]

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.

[Guest cwright]

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

[Guest cwright]

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

[Guest cwright]

>>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

[Guest cwright]

>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?