Lights One More Time – Flashing

Ok – I was going to deal with lights that don’t shine next but they seem more complicated and are pretty much useless as aircraft lights in DX10. So I thought I would do flashing instead. This post is very dull – you might want to skip to the conclusions.

I am using this setup

 

[LIGHTS]

//Types: 1=beacon, 2=strobe, 3=navigation, 4=cockpit

light.0 = 1, -2.76, 18.00, 2.97, TESTREDF

light.1 = 2, -2.76, 10.11, 2.97, TESTBLUE

light.2 = 3, -2.76, 4.11, 2.97, TESTGREEN

light.3 = 1, -2.76, -4.11, 2.97, TESTREDF

light.4 = 2, -2.76, -10.11, 2.97, TESTBLUE

light.5 = 3, -2.76, -18.11, 2.97, TESTGREEN

 

All textures are fx_2.bmp

The red lights have been altered to flash both the shine emitter and the orb

 

Test 10

So as expected, since all the “orbs” have the same texture they don’t appear. My two red lights were flashing, rather out of phase so in the picture the port one is on and the starboard off.

Test 11

For this test I introduced one of my invisible lights with a different blend setting as the first light to make the orbs visible.

New setup is

[LIGHTS]

//Types: 1=beacon, 2=strobe, 3=navigation, 4=cockpit

light.0 = 1, -2.76, 0.00, 2.97, ballast

light.1 = 1, -2.76, 18.00, 2.97, TESTREDF

light.2 = 2, -2.76, 10.11, 2.97, TESTBLUE

light.3 = 3, -2.76, 4.11, 2.97, TESTGREEN

light.4 = 1, -2.76, -4.11, 2.97, TESTREDF

light.5 = 2, -2.76, -10.11, 2.97, TESTBLUE

light.6 = 3, -2.76, -18.11, 2.97, TESTGREEN

 

I expect to see all the lights, the reds will flash but I suspect the blues and maybe the greens will too (but not I think the shine)

Not quite! The reds flash the others are steady. SO there is no leakage of the flashing property! (Sorry got that one wrong!)

Test 12

Since I am sure I saw issues with flashing when using textures I then swapped out the ballast light which uses the different blend technique for a new light using the fx_2SJP.bmp

[LIGHTS]

//Types: 1=beacon, 2=strobe, 3=navigation, 4=cockpit

light.0 = 1, -2.76, 0.00, 2.97, TESTGRSJP

light.1 = 1, -2.76, 18.00, 2.97, TESTREDF

light.2 = 2, -2.76, 10.11, 2.97, TESTBLUE

light.3 = 3, -2.76, 4.11, 2.97, TESTGREEN

light.4 = 1, -2.76, -4.11, 2.97, TESTREDF

light.5 = 2, -2.76, -10.11, 2.97, TESTBLUE

light.6 = 3, -2.76, -18.11, 2.97, TESTGREEN

 

No issues same as above!

So my suspicion that the blend technique is better is looking shakey – it seems that instead it’s the concept of a sacrificial non flashing light as the first entry that works. In the scenarios where I previously had problems the first light was a beacon with multiple emitters with different textures.

Test 13

Before going that far I changed the first light the TESTGRSJP to flash and swapped back the flashing reds for standard ones.

[LIGHTS]

//Types: 1=beacon, 2=strobe, 3=navigation, 4=cockpit

light.0 = 1, -2.76, 0.00, 1.97, TESTGRSJPF

light.1 = 1, -2.76, 18.00, 1.97, TESTRED

light.2 = 2, -2.76, 10.11, 1.97, TESTBLUE

light.3 = 3, -2.76, 4.11, 1.97, TESTGREEN

light.4 = 1, -2.76, -4.11, 1.97, TESTRED

light.5 = 2, -2.76, -10.11, 1.97, TESTBLUE

light.6 = 3, -2.76, -18.11, 1.97, TESTGREEN

 

Ok when I turned on the beacon I had the green shine flashing, the red shines were constant and the red orbs were flashing in synchronization with the green shine!

When I put the rest of the lights on, all the lights appeared and started flashing in sync. But none of the shines were then flashing – but it was hard to tell as I had placed the green flashing shine near another green.

 

 

Test 14

I moved the first light backwards so I could observe its flashing better and I changed the definition so that its flash was twice the rate of the green light we don’t see. I wanted to see which emitter determines the behaviour of the other lights.

The results were as before. I could clearly see that the tempo of flashing came from the invisible green orb not the faster green flash. It was also clear that the green flash stopped when I turned the other lights on. Experimentation showed that turning any light off restored it, so I think it’s a limit of either the number of visible shining lights, visible lights or flashing lights. NUM_LIGHTS is 8 in my config so it seems too low. Further experiments seem to show that its the number of shining effects that counts.

 

Test 15

For this test I changed light 3 to be a light using the fx_2SJP texture – the same as the first light but different to the others.

[LIGHTS]

//Types: 1=beacon, 2=strobe, 3=navigation, 4=cockpit

light.0 = 1, -7.00, 0.00, 3.97, TESTGRSJPF

light.1 = 1, -2.76, 18.00, 1.97, TESTRED

light.2 = 2, -2.76, 10.11, 1.97, TESTBLUE

light.3 = 3, -2.76, 4.11, 1.97, TESTGRSJP

light.4 = 1, -2.76, -4.11, 1.97, TESTRED

light.5 = 2, -2.76, -10.11, 1.97, TESTBLUE

light.6 = 3, -2.76, -18.11, 1.97, TESTGREEN

 

The two reds and first blues flashed, the others were steady. So it seems to me that for the first light effect that has a shine. If the orb in it is flashing then that property extends across the next two texture changes?! To try another way if that first light is flashing, then the flashing is passed to the next visible orb and continues as a property until the next texture change.

 

Test 16

In some trepidation I changed the first red to use a totally different texture fx2_SJP2.bmp to see what occurred. Happily as predicted by that the first red flashed but the other lights from the 2nd texture change didn’t.

 

Test 17

I changed the first red light to use the same texture as the TESTGRSJPF light. The result was that the first light didn’t come on. The others didn’t flash this time.

 

DX10 Flashing Lights Summary

 

Note this is about light effects with “shines” – I haven’t looked at effects without a light=1 emitter yet!

  • Rule 1 The “orb” emitter of the first light is never visible and nor are following emitters with the same blend and texture.
    At the first change in these that light and subsequent lights are visible.

     

  • Rule 2 If the orb emitter is flashing and the next emitter is the same texture then it’s the same as rule 1. Only lights from the first texture or blend change are visible.
  • Rule 3. If the orb emitter is flashing and the next emitter is a different texture then it flashes as do following emitters with the same texture. Only at the next texture change do lights become normal

The order is based on the sequence in which buses are powered on and then by the ordering in the lights section of the aircraft.cfg

 

Additional Notes:

I haven’t checked if there is any difference with multiple emitters in the same effect – I have assumed not

Additionally there appear to be limits it seems on the number of visible “shines” at any one time which are lower than the configured number of LIGHTS in fsx.cfg? Need to look into that.

When first trying to fix lights by adding extra textures into lights I am sure that at one point I saw the nav light “shine” that was not meant to flash, start flashing. The FSX lights sometimes use textures for the shine emitter and sometimes not, so it might be worth exploring that.

About stevefsx

I don't use FSX that much. But I am very annoyed when it doesn't work properly!
This entry was posted in DX10, Nav Lights. Bookmark the permalink.

3 Responses to Lights One More Time – Flashing

  1. mike ryder says:

    My AI landing lights are flashing…and so are some lights at add on airports…

    • stevefsx says:

      Flashing or going off and on as you move your head? Is it the same in VC and spot view? – is it the same in the default Cessna in spot view with the landing lights on?

      You can try a light field at the addon airports – see manual – but there are I am afraid very very occasionally people who suffer flashing lights presumably because of something in their scenery that triggers it – but I have never been able to track it down.

  2. Paul Johnson says:

    Yes!. Thanks, Steve. It works both in W or FS mode, reverting back to the default control setup. This is a developer’s dream tool isn’t it. One never stops learning.

Comments are closed.