I’m way behind on documentation, and there isn’t any documentation for this yet, but to clarify:
In the named lights list, spill (casting light on the ground and other stuff in HDR mode) and billboards (a square that faces the camera with a picture of the light from a light bulb) are always separate!
Typically the spill light has the same name as the billboard with an _sp suffix, or the billboard has _bb.
Why did we do it this way?
The lights are kept separate because:
- We do not have enough information from the billboards to know how to make a spill. For example, you have a v9 parameterized landing light billboard on your aircraft OBJ. How big (in meters) should the spill be? We don’t know! The billboard params never included enough information to know things like the size and cone ark for a spill light.
- There may not even be a 1:1 correspondence of spill to billboards. For example, any time there is a multi-lightbulb enclosure, it can be a win to use more billboards than spills; overlapping spills hurt fill rate.
Spills are therefore “opt-in” at the named light level; you opt in by adding a _sp variant.
Note that if you use Plane-Maker’s light level, you get spill for free; that interface is a higher level, simpler “I want this thing” type of interface. It only knows about the basic airplane light types, but it is fairly powerful. For example, you can create multiple landing lights (controlled by multiple switches), and you can use the “generic” lights for utility purposes, like inlet ice lights, leading edge lights, logo lights, etc.
I’m not being facetious here but how does an aircraft spill light know when it’s on or off. I see a bunch of non-writeable datarefs but no actuators for them. Never mind… I won’t be touching them until we get new object lights in ac3d. One step at a time — looking forward to b6 first.
Like all named lights, the definition of the spill light (in lights.txt) tells when the light is on and how bright. Some spill lights are simply always on, while others are tied to particular systems/datarefs.
Sometimes the spill lights have parameters for further customization, e.g. a landing spill light lets you specify how big it is and which systems index it “listens” to for turning on and off.
Like named lights, spill lights also obey show-hide and movement animations, so you can always turn a light off by hiding it, and you can aim it with animation – this all works the same as billboards.
Finally, there _is_ a documented command LIGHT_SPILL_CUSTOM which lets you create a completely customized spill light. You provide all parameters and optionally a dataref (which can come from X-Plane or a plugin) to further manipulate it.
Hi Ben,
I’m struggling to understand the post. My (probably incorrect) understanding is that the preferred method for putting lights into scenery is by named lights, and named lights are only defined in Resources/bitmaps/world/lites/lights.txt, which developers have no control over. Lights defined in that file seem to use all sorts of suffixes. Are you implying that we can define our own named lights? That would be great!
Cheers
I think you have this mostly right:
– For scenery, the only way to add lights (spill or billboard) is via lights in an OBJ.
– Lights.txt defines the named lights you can use. You cannot modify this file.
But:
– Some named lights take parameters! (Others do not.)
For example: the light named “taxi_b” (a blue taxi light billboard) takes no parameters. You just name it, and it is added to your OBJ.
But the light: “airplane_strobe_size” (a strobe light for use on an an airplane) takes 3 parameters: a size (which controls the light billboard size), “focus” (which controls the range of view angles the strobe is seen from) and “index” (which controls which X-Plane system must be on for the strobe to flash). You cannot control what the light does (flash when the strobes are on) or what color it is, but you can control a few of its parameters.
– The OBJ8 file has two commands to make custom billboards with your texture and custom spills where you control all parameters and pick a dataref. The custom spill is just as good as editing the lights.txt file in terms of flexibility.
Hi Ben,
I’ve been using WED 1.2 to create an airport and everything has been going without a hitch, but today I come to open the scenery and WED is telling me “Unable to open XML file: not well-formed (invalid token)”.
Is there anyway to recover this?
Thanks
Garry
There is, but depending on what tools you are comfortable with it may not be easy.
Most likely there is a non-UTF8 character in your XML file somewhere. If you can run it through an XML validator that will give you a file/line number you can then hand-edit the file – you may find an airport with a funny diacritic mark. The problem happens when you import an apt.dat that has illegal chars into WED.
And please file a bug against WED here!!
http://dev.x-plane.com/bugbase/login_page.php