Hi J.R.It is BGLC's POINT_VICALL ( opcode #0x46).But the SDK seems to confuse the issue by not properly listing the parameters. What the SDK says is: XYZ16 offsetis actually xx, yy, zz where each is a signed 16 bit integer, and is the distance in meters from the actual refpoint.Manfred lists those parameters as delta_x delta_z delta_ybut in the odd way of BGLC, X = longitudinal, Y = altitudinal, and Z = latitudinal. Page 7 of the FS2000 SDK goes over that. Manfred just transposed the z and y for our benefit, as we commonly refer to z as altitude.Whether BGLC or SCASM, the order of those parameters is longitude, altitude, and latitude. All parameters are integers, but rotate angles are probably translated to their integer equivalent by SCASM.

TransformCall( :call_object_label   E_W_meters   UP_DOWN_meters   N_S_meters   pitch_angle   0000   bank_angle   0000   heading_angle   0000 )

and who knows what the 0000's mean! ;)Dick

Thanks for that explanation Dick.. You have a fantastic ability to corelate the way these assemblers and compilers work (!) and I sure appreciate your being willing to share your knowlege. 'Back to the 0000's --- These crazy "Dummy" RotatedCalls in SCASM (Dummy meaning telling the object to rotate 0, 0,& 0 in the 3 coordinates) just seems like wasted code; but darned if they don't work to preserve the native autogen. That's really got me confused. I guess some day people like yourself will be able to figure that one out and hopefully, let us know what's going-on. Is it possible that these "Rotate to nothing" opcodes confuse the FS scenery engine and it's just throwing up it's hands and painting the default scenery in spite of our throwing "interfering" polygons at it ? Thanks;J.R.

So you are saying although you transform it 32767 units into the air it is still on the ground? This is a really strange thing :), maybe I must wake uo completely first and then have another look.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Hi J.R.The pitch-bank-heading rotation works just like RotatedCall, but the '0000' is some sort of "Variable".. not needed for our purposes.The odd thing is the temporary relocation of the refpoint... I'm going to play with excluding these types today, and see if that is a problem. If we normally must exclude the refpoint + v2 radius, then what and where do we exclude for these?If the relocation is too close to the object, you may see a false object shadow for the relocated refpoint!Dick

>>>The odd thing is the temporary relocation of the refpoint... I'm going to play with excluding these types today, and see if that is a problem.<<<**OK... By 'temporary relocation of the RefPt', are you considering this as in a RotatedCall or as in a TransformCall --- or are those two opcodes actually the same function-wise? I thought the TransformCall "Offsets-From" the (original) RefPt but that the RotatedCall merely Rotates-Objects-Around the original RefPt?** >>>If we normally must exclude the refpoint + v2 radius, then what and where do we exclude for these?<<<** Right... There's probably a way if one is a C+ Guru but that's beyond my present scope of ability, for sure :-). Much Thanks that people like you are willing to share your knowlege. **>>>If the relocation is too close to the object, you may see a false object shadow for the relocated refpoint!<<<**I've seen the shadows you refer-to and in all such cases the shadows were in locations where there should have been an autogen object. To "recover" that missing autogen object, use of the "Dummy" RotatedCall and keeping V2 to the lowest possible value to retain the Object-In-Work's visibility did the trick. BTW, one of the worst offenders I found that did that was the Rwy-Hold and Nav-Hold line sets (there are no doubt other equally bad offenders). **Thanks;J.R.