Follow-up Question - Odd Massive Exclude of Autogen

[1st fltsimguy 466]

My earlier question is found in this post. Remake of Kahului Apt, Maui using older scenery and undertaking a decompile and recompile after edits.http://forums1.avsim.net/index.php?showtopic=286931I have decompiled the file, took out the offending trees and vegetation along with some other objects that were also problematic. I recompile the file and then added new trees and planes and hangers and odds and sods to clutter up the airport. The product is looking quite good!.However, I was so absorbed in the airport remake that I failed to notice that the airport had somehow created a huge exclude of autogen for miles around.If I use the original files or the new ones I have created and modified it doesn't matter, there is this huge area where the autogen has been suppressed.I removed all exclude files from the scenery and it still had the same effect.Does anyone know anything about this phenomenon?The first screenshot is of default FSX, note autogen working fine.The second screenshot is of my reworked older scenery file, work still in progress, but notice that all autogen out side of the airport area is removed for a considerable distance, on all sides.I have the same older scenery working in my FS9 and there is no exclude of autogen.Any ideas as to why this is occuring?

[LuisFelizTirado 33]

Hello Bryan,I have had the same problem when also taking apart other people's work in order to modify it. Take a look at the decompiled file and you might find that the visibility radius (V2) is enormous for many objects. This value should basically just cover the dimensions of the object so that it is visible from any angle, but sometimes designers (or perhaps it is the tools they use) assign very large values. As it happens, I believe that V2 excludes autogen and when the value is very large, it excludes a lot of autogen!By the way, here is an example of old-style objects with very large V2:

Area( 5 N19:24:22.20 W070:36:16.70 10 )	LayerCall( :L0007AC 16 )	Jump( : ):L0007AC	RefPoint( rel :L00080E  0.10 N19:24:22.22 W070:36:16.70		V1= 10000 V2= 2360 )	LoadBitmap( 0 5 E0 0 0 0		asphalt.bmp )	Smoothing( 1 )	TaxiwayStart( -236 -11441 0 2892 )	TaxiwayCont( 11436 0 -2886 )	StartSurface ; use only for polygons flat on the ground	MoveTo( 0 0 0 )	EndSurface	Smoothing( 0 ):L00080E	ReturnEndA

Best regards.Luis

[1st fltsimguy 466]

Hello Bryan,I have had the same problem when also taking apart other people's work in order to modify it. Take a look at the decompiled file and you might find that the visibility radius (V2) is enormous for many objects. This value should basically just cover the dimensions of the object so that it is visible from any angle, but sometimes designers (or perhaps it is the tools they use) assign very large values. As it happens, I believe that V2 excludes autogen and when the value is very large, it excludes a lot of autogen!By the way, here is an example of old-style objects with very large V2:

Area( 5 N19:24:22.20 W070:36:16.70 10 )	LayerCall( :L0007AC 16 )	Jump( : ):L0007AC	RefPoint( rel :L00080E  0.10 N19:24:22.22 W070:36:16.70		V1= 10000 V2= 2360 )	LoadBitmap( 0 5 E0 0 0 0		asphalt.bmp )	Smoothing( 1 )	TaxiwayStart( -236 -11441 0 2892 )	TaxiwayCont( 11436 0 -2886 )	StartSurface ; use only for polygons flat on the ground	MoveTo( 0 0 0 )	EndSurface	Smoothing( 0 ):L00080E	ReturnEndA

Best regards.Luis

Very good insight into this issue. I had thought that there was some sort of code in there that might be causing the effect but I am just not that familiar with this code. Now I can get in there and muck about and see what might be possible to fix this issue.What would be useful is to get the bible on the code so I can understand the variables. IE V1 and V2, and the relative significance of the number value to, say, the lat and long in your example.I will take a look and mine and see what its showing and see if I can deduce how to adjust.Thanks for you reply, I was stalled and did not know what to try next. As always this community is so helpful.

[1st fltsimguy 466]

Very good insight into this issue. I had thought that there was some sort of code in there that might be causing the effect but I am just not that familiar with this code. Now I can get in there and muck about and see what might be possible to fix this issue.What would be useful is to get the bible on the code so I can understand the variables. IE V1 and V2, and the relative significance of the number value to, say, the lat and long in your example.I will take a look and mine and see what its showing and see if I can deduce how to adjust.Thanks for you reply, I was stalled and did not know what to try next. As always this community is so helpful.

OK I ran though my file and found values similar to the codes below, very high V1 and much lower V2, so I am left to wonder, what is V1 doing? vs. V2?

; LatRange(  N20:46:09.23  N21:01:04.86 ); ----------------------------------------; ----------------------------------------; Object # 1, offset: 0x000A size: 190 bytes (0x00BE) ;; Lat: 000236EBEh Lon: 090C185A2h; ----------------------------------------Area( B N20:53:43.20 W156:26:13.03 30 )	LayerCall( :L000020 8 )	Jump( : ):L000020	RefPoint( abs :L0000B0  1.00 N20:53:43.20 W156:26:13.03		V1= -25536 V2= 194 E= 16 )	Bitmap( ASPHALT.R8 0 0 0 0 ) 	Smoothing( 1 )

Any further advice would be helpful? And if I could be pointed to where I could find the code that would be useful?

[GaryGB 10]

Hi Bryan:Just had a moment to post this link:http://www.scasm.de/doc/sca_cmd1.htmSee:"RefPoint( type :Label scale Lat Lon [...] )"and..."SetScale( :Label V1 V2 scale )ReScale( :Label V1 V2 scale )"...on that page. :( BTW: The main page for the SCASM Documentation is:http://www.scasm.de/doc/index.htmHope this gets you to the next step ! :( GaryGB

[LuisFelizTirado 33]

Thanks, Gary, that is very helpful and I should have mentioned Manfred's documentation. It is as good a place as any other to get an idea of the SCASM commands, particularly since he wrote SCASM!Anyway, here is the short description he gives (and all the descriptions he gives are short):v1= ## visibility range of this object in meters (int)v2= ## radius of this object in design units (int). This is in meters if scale factor is 1.So, Bryan, V1 is the maximum distance at which the object will become visible. It is probably best to keep this rather low for small objects since it does not make a lot of sense to have traffic cones visible from 10 kilometers out (since they are too small to be seen from there anyway!) and the larger the amount of objects visible from great distances, the worse the performance. That negative value is rather common and I suspect due to whatever tool was used, although I shall not name names, as all software has bugs and we are all grateful for past and present developers who provide us with wonderful tools.V2 is a rather more complex value and is the visibility radius, that is the minimum area around the object that will allow it to display. If set too low, then the object will disappear and re-appear as one rotates around it - very annoying. If the value is too high, then it wipes out autogen, as per your screenshot. Gerrish once gave me an easy formula for calculating this - it must be in my archives somewhere if I could only find it, but generally multiply all dimensions squared, extract square roots, or something, simple right? Probably all you really have to do is set V2 to the largest dimension of the object and that should cover the radius while eliminating the minimum amount of autogen, which should be none in an airport anyway.As a general comment, thank God for FS X that has eliminated the need for all that excessively complex manipulation, not just as far as objects are concerned, but also terrain and aircraft. Plus there are so many more possibilities (for example, materials in an endless array and variety that nobody is yet exploiting to the fullest) and it all leads me to say that those who criticize FS X have no idea what they are talking about. It is wonderfully coded to make life for us much simpler and give us much more choice and future development options. Thanks to those great guys at ACES (R.I.P.)Best regards.Luis

[Guest NoNewMessages]

I've exchanged a few emails with Bill, with the last a couple of years ago IIRC? I was inquiring about FSX and his FS9 scenery, which I have always been a fan of. He mentioned he had most all of it working in FSX, with a few niggles along the way. It might be wise to try and contact Bill and see if there is a revised package almost done, that could be the basis for any work? Or at least to ask for permission to release any modified versions, before all the work is done and he says NO! The impression I got of the man is that while he may not be doing scenery work anymore, that I know of, he would probably enjoy seeing his work continue.

[1st fltsimguy 466]

I've exchanged a few emails with Bill, with the last a couple of years ago IIRC? I was inquiring about FSX and his FS9 scenery, which I have always been a fan of. He mentioned he had most all of it working in FSX, with a few niggles along the way. It might be wise to try and contact Bill and see if there is a revised package almost done, that could be the basis for any work? Or at least to ask for permission to release any modified versions, before all the work is done and he says NO! The impression I got of the man is that while he may not be doing scenery work anymore, that I know of, he would probably enjoy seeing his work continue.

Yes, thanks, I know the drill. Been around a long long time. It did strike me that his work, which I also find very good, might be useable in FSX and nobody had yet tackled the challenge. If he is around and reading this he could save me a bunch of work by offering up anything he has made compatible to FSX.If I get it working how I want it with my own improvements, then its use begins with me having some scenery for MY use. Any freeware distribution comes after that. Plus, with the help I getting from the very competent folks here on this forum I am learning some new technical things that might help me with future sceneries.I have not emailed Bill. I have an old email address but not tried it yet. Most freeware designers, like me, are happy to have others work with their freeware work especially if it means improving the product or making it compatible with other sceneries and broaden its usage. If I get something that I think the broader community would like then I will pursue talking with him, if he is contactable.In this case Bill's work on the main terminal is more realistic than the default scenery and its that bit that I want to capture without having to design up an new terminal object.So far I have had to almost completely tear apart his original code and recompile, then I have prepared new bgl's for trees, hangers, vehicles, planes and other airport clutter.

Thanks, Gary, that is very helpful and I should have mentioned Manfred's documentation. It is as good a place as any other to get an idea of the SCASM commands, particularly since he wrote SCASM!Anyway, here is the short description he gives (and all the descriptions he gives are short):v1= ## visibility range of this object in meters (int)v2= ## radius of this object in design units (int). This is in meters if scale factor is 1.So, Bryan, V1 is the maximum distance at which the object will become visible. It is probably best to keep this rather low for small objects since it does not make a lot of sense to have traffic cones visible from 10 kilometers out (since they are too small to be seen from there anyway!) and the larger the amount of objects visible from great distances, the worse the performance. That negative value is rather common and I suspect due to whatever tool was used, although I shall not name names, as all software has bugs and we are all grateful for past and present developers who provide us with wonderful tools.V2 is a rather more complex value and is the visibility radius, that is the minimum area around the object that will allow it to display. If set too low, then the object will disappear and re-appear as one rotates around it - very annoying. If the value is too high, then it wipes out autogen, as per your screenshot. Gerrish once gave me an easy formula for calculating this - it must be in my archives somewhere if I could only find it, but generally multiply all dimensions, extract square roots, or something, simple right? Probably all you really have to do is set V2 to the largest dimension of the object and that should cover the radius while eliminating the minimum amount of autogen, which should be none in an airport anyway.As a general comment, thank God for FS X that has eliminated the need for all that excessively complex manipulation, not just as far as objects are concerned, but also terrain and aircraft. Plus there are so many more possibilities (for example, materials in an endless array and variety that nobody is yet exploiting to the fullest) and it all leads me to say that those who criticize FS X have no idea what they are talking about. It is wonderfully coded to make life for us much simpler and give us much more choice and future development options. Thanks to those great guys at ACES (R.I.P.)Best regards.Luis

Thanks for helping me with this learning experience, this along with Gary's input has me moving rapidly into these technics.

Hi Bryan:Just had a moment to post this link:http://www.scasm.de/doc/sca_cmd1.htmSee:"RefPoint( type :Label scale Lat Lon [...] )"and..."SetScale( :Label V1 V2 scale )ReScale( :Label V1 V2 scale )"...on that page. :( Excellent I should have done a google searh on this, helpful again. Thanks.BTW: The main page for the SCASM Documentation is:http://www.scasm.de/doc/index.htmHope this gets you to the next step ! :( GaryGB