Sign in to follow this  
Guest Tosh

Those Dummy RotatedCalls - Again!

Recommended Posts

Hi All,I for one am having a real problem getting my head around the use and mis-use of the "Dummy RotatedCalls".I have read the forum threads until I am blue in the face but still am unable to formulate a definitive rule that makes this "trick" work and why. At best it seems to be nothing more than guesswork.I have followed all suggestions as listed in the threads and indeed most do have the effect of maintaining Autogen surrounding airports BUT in all my tests they also introduce weird coloured polys usually within a kilometre or so of the airport, that most often extend several thousand feet into the sky when viewed from certain positions. Obviously this is not so good.I have included a sample edited macro below. I would really appreciate it if someone more knowledeable than I on this subject could firstly, explain the theory behind this dummy call and why it works and secondly insert the correct code into the sample below;;ASDesign Compatible Macro;Name=xxxxxxxx, Type=xxx, Bitmap=xxxxxxxx.bmp, ;FixedLength=234, FixedWidth=54, autoscale, ;Latitude, Longitude, Rotation, Scale=1, Density=1, ;Visibility=0, Range=10, Elevation=0, Shadow=0, ; Area( 5 %1 %2 %7 ) PerspectiveCall( :Pos ) Jump( : ):PosPerspective:Shadowsmif( %8 ) RefPoint( 2 :SubEnd 1 %1 %2 E= %8 )melse RefPoint( 7 :SubEnd 1 %1 %2 )mifendSetScaleX( :SubEnd %6 0 13 ) ; Scale=0.125RotatedCall( :Begin 0 0 %3 ):SubEnd Return :Begin;I HAVE TRIED THE DUMMY ROTATEDCALL HERE! "RotatedCall( :RR 0 0 0 )" Call( :part000 ) ;Cube 1 TransformCall( :part001 0 24 0 0 0 0 0 0 0 ) ;Cube 1_02 TransformCall( :part002 0 0 -90 0 0 0 0 0 0 ) ;Cube 3 TransformCall( :part003 0 0 90 0 0 0 0 0 0 ) ;Cube 3_02;etc, etc TransformCall( :part150 62 0 -62 0 0 0 0 0 0 ) ;Cube 3_04;I HAVE ALSO TRIED THE DUMMY ROTATEDCALL HERE, BOTH SEPERATELY AND;IN CONJUCTION WITH THE ONE ABOVEReturn ; I HAVE TRIED WITH AND WITHOUT THIS RETURN!!!!!;-------:part000; cube - Cube 1Points( 0 -60 0 -88 ; 0 60 0 -88 ; 1 60 0 88 ; 2 -60 0 88 ; 3 -60 24 -88 ; 4 60 24 -88 ; 5 60 24 88 ; 6 -60 24 88 ; 7)LoadBitmap( 0 L6 EF 0 0 0 "xxxxxxxx.bmp" )TexPoly( 0 0 -32767 88 0 3 53 4 3 77 5 119 77 1 119 53 ) ;TexPoly( 0 0 32767 88 2 3 53 6 3 77 7 119 77 3 119 53 ) ;TexPoly( -32767 0 0 60 3 3 28 7 3 51 4 173 51 0 173 28 ) ;TexPoly( 32767 0 0 60 1 3 28 5 3 51 6 173 51 2 173 28 ) ;Return;-------:part001; cube - Cube 1_02Points( 8 -184 0 -64 ; 0 184 0 -64 ; 1 184 0 64 ; 2 -184 0 64 ; 3 -184 4 -64 ; 4 184 4 -64 ; 5 184 4 64 ; 6 -184 4 64 ; 7)LoadBitmap( 0 L6 EF 0 0 0 "xxxxxxxx.bmp" )TexPoly( 0 0 -32767 64 8 3 113 12 3 118 13 241 118 9 241 113 );TexPoly( 0 0 32767 64 10 3 113 14 3 118 15 241 118 11 241 113 );TexPoly( -32767 0 0 184 11 3 113 15 3 118 12 88 118 8 88 113 );TexPoly( 32767 0 0 184 9 3 113 13 3 118 14 88 118 10 88 113 );TexPoly( 0 32767 0 4 12 134 6 15 134 21 14 144 21 13 144 6 );TexPoly( 0 -32767 0 0 9 144 21 10 144 6 11 134 6 8 134 21 );Return;-------:part002; cube - Cube 3Points( 16 -64 0 -2 ; 0 64 0 -2 ; 1 64 0 2 ; 2 -64 0 2 ; 3 -64 10 -2 ; 4 64 10 -2 ; 5 64 10 2 ; 6 -64 10 2 ; 7)LoadBitmap( 0 L6 EF 0 0 0 "xxxxxxxx.bmp" )TexPoly( 0 0 -32767 2 16 122 53 20 122 64 21 238 64 17 238 53 ); TexPoly( -32767 0 0 64 19 116 6 23 116 23 20 124 23 16 124 6 ) ;TexPoly( 32767 0 0 64 17 116 6 21 116 23 22 124 23 18 124 6 ) ;TexPoly( 0 32767 0 10 20 116 6 23 116 23 22 124 23 21 124 6 ) ;Return;-------:part003; cube - Cube 3_02Points( 24 -64 0 -2 ; 0 64 0 -2 ; 1 64 0 2 ; 2 -64 0 2 ; 3 -64 10 -2 ; 4 64 10 -2 ; 5 64 10 2 ; 6 -64 10 2 ; 7)LoadBitmap( 0 L6 EF 0 0 0 "xxxxxxxx.bmp" )TexPoly( 0 0 32767 2 26 3 79 30 3 111 31 226 111 27 226 79 ) ;TexPoly( -32767 0 0 64 27 115 7 31 115 24 28 126 24 24 126 7 ) ;TexPoly( 32767 0 0 64 25 115 7 29 115 24 30 126 24 26 126 7 ) ;TexPoly( 0 32767 0 10 28 115 7 31 115 24 30 126 24 29 126 7 ) ;Return;etc, etc;-------:part150; cube - Cube 3_03Points( 51 2 0 -26 ; 0 2 0 26 ; 1 -2 0 26 ; 2 -2 0 -26 ; 3 2 10 -26 ; 4 2 10 26 ; 5 -2 10 26 ; 6 -2 10 -26 ; 7)LoadBitmap( 0 L6 EF 0 0 0 "xxxxxxxx.bmp" )TexPoly( 32767 0 0 2 51 3 79 55 3 111 56 98 111 52 98 79 ) ;TexPoly( 0 32767 0 10 55 116 6 58 116 23 57 125 23 56 125 6 ) ;;I HAVE TRIED THE DUMMY ROTATEDCALL "RETURN" WITHIN THE ;LAST RETURNReturn;I HAVE TRIED THE DUMMY ROTATEDCALL "RETURN" OUTSIDE THE ;LAST RETURNEndA-------------------------------Regards,Chris Wilkes

Share this post


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

Hello Chris...Re: "At best it seems to be nothing more than guesswork."I think it's safe to say that that's the way use of the 'dummy' rotated call started-out -- because 'logical' SCASM usage doesn't seem to call for the need for it. HOWEVER, I've experienced that it's 'unconventional' usage does indeed prevent loss of autogen objects nearby to user added Ground Polygons and 3D objects called with TransformCall opcodes.Therefore, the rule of thumb I use is to apply it immediately after those sequential portion(s) of code which 'literally draw' the objects -- and it usually works to save the AGN when applied this way. So to me, that changes it from 'guesswork' to a (new - peculiar to FS2002) rule.We all want to know the 'Reason-Why' unconventional things work in FS2002, but I've yet to understand a solid explanation for why it works that way there. At least two theories I've seen offered for this condition are: 1) It's an anomoly in the Scenery Engine; to this, in honesty, I think we must say "Compared to What?" and 2) It causes the Scenery Engine to "double-clutch" at the applied point, allowing a re-draw of the AGN bitmaps. In view of the way AGN is 'seemingly' drawn, based on (many) 'land-class' conditions for the LOD area where the user's scenery resides, my "gut-feel" lends towards the latter assumption.Finally, I've never experienced the other problems you mentioned by adding the 'dummy' rotated calls.Regards;J.R

Share this post


Link to post
Share on other sites

Just like J.R. says I have never seen the strange things you describe. And also for the reason why it works I have no real clue. It makes absolutely no sense (from SCASM logic point of view). I think that the extra Rotation (of nothing) confuses the part of the scenery engine that determines the size of the object and therefore saves the autogen.Have you tried to place the call like I do in this code below? I think that is the best place. Only that one line needs to be included then.[tt]Area( 5 %1 %2 %7 )PerspectiveCall( :Pos )RotatedCall( :SubEnd )Jump( : ):PosPerspective:Shadowsmif( %8 )RefPoint( 2 :SubEnd 1 %1 %2 E= %8 )melseRefPoint( 7 :SubEnd 1 %1 %2 )mifendSetScaleX( :SubEnd %6 0 13 ) ; Scale=0.125RotatedCall( :Begin 0 0 %3 ):SubEndReturn:Begin[/tt]

Share this post


Link to post
Share on other sites

Thanks J.R. and Arno,I have followed Arno's simple suggestion and indeed it works perfectly. I am not sure that I understand any better as to why it works but I have been able to repeat it enough times to think that I have formulated a rule ( Kinda! ) and I got rid of the flying poly's as well which turned out to be something unrelated to the dummy call.Many thanks for your collective input.Regards,Chris Wilkes

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