Any news on the Autogen bug?

[rhumbaflappy 113]

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

[Guest GerrishGray]

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

[Guest GerrishGray]

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

[Guest GerrishGray]

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

[Guest cwright]

>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

[Guest cwright]

> 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

[Guest GerrishGray]

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

[arno 1]

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.

[Guest cwright]

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

[Guest GerrishGray]

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