That is if you only have the light in your object yes. But it my case it was an entire light pole with the lights added to. Would be a bit strange to rotate that entire scene :).

Mr Flappy strikes again!Maybe another option for mdl tweaker Arno?Rellek

Good idea, I will put it on the wishlist for v2.0 :).

I have no idea why this "Small Ramp Light" is leaning, why it is nearly twice the modeled size, nor why the bottom of it is bent 90

>Hi Arno.>>You can also change the pitch, bank and heading with XML>placement code. I don't know if the light bgl can be attached>to another object...Dick, you simply create two objects, and link them together. Use the top level object to "aim" the light... :)BTW, both objects need to have the LIGHT_LAND Material applied for this to work... I don't know why, but it won't work otherwise!http://forums.avsim.net/user_files/101431.jpg

But if you look at your source now you have the light defined twice? Would it not be enough to use only one of them?It is true that linking the two triangles adds the rotation code to the ASM file for you. Although I doubt it is really efficient now, your code shows 11 eleven translation/rotations defined, while you need only 1 for the light. But maybe I still don't expect the linking good enough :). This is certainly a good step in the direction of getting all lights to work.

Hi Bill.With Scenery Design, you don't need the two triangles. As shown above, one defined as a LIGHT_BEACON works fine, then edit the ASM code to redefine the type, strip the excess junk added by MakeMDL, and rotate as Arno indicates.Or we can skip Gmax entirely and just insert the BGL_LIGHT command, and rotation, directly into the ASM code.The attachment I refer to is by making a library object of the light, and then using the attachtool of Gmax to place it in another object. In that way, you make one light that is reusable in many projects.My biggest irritation with the whole process is that we are stuck with the default spotlight.bmp.Dick

Hi Dick,But the advantage of the method of Bill is that you get the rotation code directly from GMax. It is almost impossible to write all the code in the TRAN, ANIC and SCEN section yourself. That only seems to work if you make two linked triangles. But I think that you can later remove one of the BGL_LIGHT commands from the source code.Maybe it is indeed easier to make one object of a simple light and attach that to your scenery project when needed. Might save a lot of source tweaking all the time, as it is only needed once then.

>But the advantage of the method of Bill is that you get the>rotation code directly from GMax. It is almost impossible to>write all the code in the TRAN, ANIC and SCEN section>yourself. That only seems to work if you make two linked>triangles. But I think that you can later remove one of the>BGL_LIGHT commands from the source code.>>Maybe it is indeed easier to make one object of a simple light>and attach that to your scenery project when needed. Might>save a lot of source tweaking all the time, as it is only>needed once then.First, I solved the problem with the really strange upside-down pole and other skewed parts. Apparently scenery does not take kindly to "Linked parts," in spite of that the SDK says... I removed the top level link and the Small Street Light compiles and displays perfectly now.I'm not sure why there is so much .asm code for "animation," since there is no animation in this model... @-@ You can in fact eliminate either of the BGL_LIGHT commands, but it will cut the light source by 50%. Obviously, both triangle objects are serving as light emitters, even though the alleged purpose of the top node triangle is to serve as a "direction control node," making "aiming the light" a piece of cake.The only problem I immediately see with your proposed "attachment" is that it would be more difficult to control the direction, I should think.OTOH, it is a trivial matter to make this entire "Small Street Light" an "attachable object" in any GMax scenery project through use of the Attachpoint Tool. ;)Attached is the modified .gmax source, along with the tweaked .asm and _0.asm files.

Bump!

Hi Bill.As an attachment, there is no problem at all controlling the direction of the light. The direction is set by the rotation of the attachpoint's surface. Usually, an attachpoint is a small planar surface, so it can be pitched, banked, and rotated any way we like.Here's the ASM code of a landinglight object educed as far as possible:

	db  'R','I','F','F'	dd  bgl_data_end - $ - 4	db  'M','D','L','9'	db  'M','D','L','H'	dd  visual_model_header_end - $ - 4	dd  visual_model_header_end - $ - 4	dd  0	dd  0	dd  1	dd  0	dd  0	dd  156	db  'F','S','8','0'	dd  2304visual_model_header_end  label dword	db  'I','S','F','T'   	dd  ver_end - $ - 4  	db  "MakeMDL - FS90 (9.00.030612.02)",0ver_end label word	   bounding_box_riff_start	label	word	db  'B','B','O','X'   	dd  bounding_box_riff_end - $ - 4	real4  -200.0, 100.000, 200.0  	real4  -200.0, -100.000, 200.0  bounding_box_riff_end label word	   model_outside	label	BGLCODEmodel_shadow label BGLCODEmodel_inside  label	BGLCODEexterior_riff_start_0 label BGLCODE	db  'E','X','T','E'   	dd  exterior_riff_end_0 - $ - 4LOD_0L	label	BGLCODEMyLight_top label BGLCODEmaterial_riff_start_MyLight	label	word	db  'M','A','T','E'   	dd  material_riff_end_MyLight - $ - 4  	MATERIAL_LIST_BEGIN	MATERIAL_DEF 1.000000,0.984314,0.513726,1.000000,  1.000000,0.984314,0.513726,  0.000000,0.000000,0.000000,  1.000000,1.000000,1.000000,  0.000000; 0	MATERIAL_LIST_END	BGL_RETURNmaterial_riff_end_MyLight label word	   bgl_riff_start_MyLight	label	BGLCODE	db	'B','G','L',' '	dd	bgl_riff_end_MyLight - $ - 4	BGL_LIGHT LIGHT_LANDING, -0.167, 0.000, 0.167, 20, 0.60, 0.40, 0FFFFFB83h, 0.000000, 0.000000, 1.000000; source poly num = 1	BGL_END	BGL_RETURNbgl_riff_end_MyLight	label	BGLCODEexterior_riff_end_0	label	BGLCODEbgl_data_end label	 BGLCODE

http://forums.avsim.net/user_files/101913.jpgNote the large Bounding Box... that's required so the image is not "cutoff" too early from the viewport. That number should have no effect on the autogen. The Material is controlling the color.Just like effect light, this light is additive in nature, as you found. Add more instances of the light, and it will increase in intensity... That can be done with XML placement, or with multiple attachpoints in another object. The above picture is placed with XML directly, but the light could have been attached to another object just as easily, if desired. Designers may consider using separate XML placement, as the lights could then have a separate scenery complexity level.I'm still not convinced we couldn't just use ground-planes, and textures, and possibly VTP2 placed textures, to fool the eye about illumination on surfaces... and that would be a bit more framerate friendly than using landing lights or effects.Dick

>Hi Bill.>>As an attachment, there is no problem at all controlling the>direction of the light. The direction is set by the rotation>of the attachpoint's surface. Usually, an attachpoint is a>small planar surface, so it can be pitched, banked, and>rotated any way we like.Ok then, model a street/ramp light complete with shade, then create a small poly and make it an AttachPoint, then use the Gizmo to rotate and "aim" the "light." That would work well for a discrete scene, but would still require many duplicated polys it you have a dozen or so street/ramp lights in the scene.My thought is that it would be more efficient to model several types of street/ramp lights, and then make each one part of a Library, so that AttachPoints would insert the entire object into the scene as many times as desired... ;)>Just like effect light, this light is additive in nature, as>you found. Add more instances of the light, and it will>increase in intensity... That can be done with XML placement,>or with multiple attachpoints in another object. The above>picture is placed with XML directly, but the light could have>been attached to another object just as easily, if desired.>Designers may consider using separate XML placement, as the>lights could then have a separate scenery complexity level.My immediate goal is to design a dozen or so types of lights, ranging from simple "street lights" to elaborate "Quad-Flood" type apron & ramp lights, and pack 'em in a Library suitable for Rwy12 placement, or inclusion by AttachPoint in other designer's scenes, all as freeware of course... ;)>I'm still not convinced we couldn't just use ground-planes,>and textures, and possibly VTP2 placed textures, to fool the>eye about illumination on surfaces... and that would be a bit>more framerate friendly than using landing lights or effects.For discrete, stand alone scenes, this is quite acceptable and in the end may well prove a better solution. I know that in my little ESDG Hanger, I've received a lot of positive response the the "pools of light" on the hanger floor, which matches the number of overhead warehouse lights.Since my "bread and butter" is earned in aircraft modeling and gauge programming, my interest in scenery is strictly limited to developing small freeware projects that may be used by the "Average Simmer" to doll up his/her own local airport(s). I needed some outlet in flightsimming that remains a "hobby!" ;)I wish to thank you and Arno especially for the invaluable hints, tips and assistance in helping me to realize that goal! All you folks here in the Scenery forum are terrific!Have a wonderful New Year!

Hi all.Just a follow-up to illustrate attached landing lights:http://forums.avsim.net/user_files/101979.jpgFirst, the "Landing_Light.mdl" is created from some hand-made code. The material properties of that ASM file control the color / intensity of the light .It was compiled with BGLC_9 as a MDL file.The object is a cone, serving as a shade for the light. I'm including the gmax code. It's a simple cone, with a square plane inside the cone. The plane is rotated on the X axis to -89.9*( There is a bug in MakeMDL that prevents lights, and perhaps effects, from being tilted -90* !!!!! )The plane is made into an attachpoint named "LandingLight", and given a random GUID number of "0E754F4F4841F89BA721C7BC1BC15ADC"Here's the XML code to use the light with the object:

<?xml version="1.0" encoding="ISO-8859-1"?><FSData version="9.0" xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation="bglcomp.xsd">	<SceneryObject lat="47 25.89" lon="-122 18.43" alt="10" pitch="0" bank="0" heading="0" altitudeIsAgl="TRUE" imageComplexity="NORMAL">		<LibraryObject name="14BC818C4528580A089E1EA9EE23ECFC" scale="1.0" />	</SceneryObject>	<ModelData name="0E754F4F4841F89BA721C7BC1BC15ADC" sourceFile="Landing_Light.mdl" />	<ModelData name="14BC818C4528580A089E1EA9EE23ECFC" sourceFile="Shaded_Light.mdl" /></FSData>

Note that in this case, both MDLs are compiled into the Shaded_Light.bgl... no Library object BGL ( nor a corresponding placement BGL ) is needed in this case, as the BGL is "all-in-one". ========================================================================================Alternately, the XML: could have compiled the object and the light as a Library Object BGL:

<?xml version="1.0" encoding="ISO-8859-1"?><FSData version="9.0" xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:noNamespaceSchemaLocation="bglcomp.xsd">	<ModelData name="0E754F4F4841F89BA721C7BC1BC15ADC" sourceFile="Landing_Light.mdl" />	<ModelData name="14BC818C4528580A089E1EA9EE23ECFC" sourceFile="Shaded_Light.mdl" /></FSData>

In this case, placement of the Shaded_Light would need placement XML-coded BGL(s) to place the GUID "14BC818C4528580A089E1EA9EE23ECFC".The resulting scene would need the Shaded_Light_Libray.bgl and Shaded_Light_Library_Placement.bgl, as the placement locates the object ( shade + attached light ).Attached is the zip of all the related files:Dick

Nice... I'll check out your idea(s) soon. Thanks!

Hi all.Here's everything I found out about showing lights in scenery for FS9:http://forums.avsim.net/user_files/103242.htmlhttp://forums.avsim.net/user_files/103253.jpgHere's a zipped file of those spotlights:http://webpages.charter.net/ludowr/DownWardSpots.zipDick