• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

SEPERATION_PLANE - how to ??

fog

Messages
48
Country
norway
Hi all!

I have a simple question...

I have made a triangled poly, which I have used LIGHT_NAV as material..

Code:
    IFMSK       nolgt_1, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, -0.167, 1.000, 0.000, 20, 0.60, 0.40, 0FFFF0000h, 0.000000, 0.000000, 1.000000 ; source poly num = 1
    nolgt_1       label BGLCODE
    BGL_RETURN

I have read to make this light i need to comment out the line beginning with IFMSK with an ";".. So all ok so far.. light i showing in FS,,

BUT, now I only want it to be showing when I am i relation 001 to 179 degrees to the light... (east of the light)..

I have read that Seperation_plane must be inserted,. but im not 100 % how to set the different numbers to get what i want..

PLs any1?

Rgd

Freddy
Norway
 
Messages
72
Country
norway
Here is an excample of the separation_plane command:
Code:
    ;IFMSK       nolgt_2, dict_0_g_lightStates, LIGHT_NAV_MASK
    SEPARATION_PLANE nolgt_2, 28796, 0, 15635, 32000
    BGL_LIGHT LIGHT_NAV, -0.017, 0.000, 0.017, 20, 0.60, 0.40, 0FFFAFAC8h, 0.000000, 0.000000, 1.000000 ; source poly num = 3
    BGL_LIGHT LIGHT_NAV, -0.017, 0.000, 0.017, 20, 0.60, 0.40, 0FFFAFAC8h, 0.000000, 0.000000, 1.000000 ; source poly num = 3
    BGL_JUMP_32 nolgt_all
    nolgt_2       label BGLCODE
I use Gmax to find the values.
I draw a line from 0,0,0 with the length of 32000 and the Pivot on 0,0,0.
Then I rotate it the number of degrees I want, and get the values from the end vertex of the line.
separation_plane.jpg

When you are on this side of the plane you see the light, when you are on the other side you dont.
 

fog

Messages
48
Country
norway
Superb...! thx a lot...

Since you all probably got a good head start of me, I choose to post my thoughts, for verification, and maybe some help to other nOObs like myself: (havent tried this in FS yet... I am still at work..)

My gmax file:
fwlys.jpg


Theese lights are 5 green light that should be visible when I am east of the lights (oriented with 5 green LIGHT_NAV towards the X positive axis, and 3 red LIGHT_NAV towards the negative X-axis)

When I export my code I get the following from the *_0.asm file (LIGHT_NAV section is cutout from the rest of the ASM file)
lysasm0.jpg


After adding the two PLANES in the file and comenting the lines beginning with "IFMSK..." the ASM file looks like this:
lysasm0_edit.jpg


Now I use bglc_9.exe on the fw-light.asm (not the just edited fw_light_0.asm) to convert it into MDL.. Then I edit the coordinates in my XML and compile to BGL..

So.. let me get the verdict here... Am I way off, ore ? :)

Freddy
 
Last edited:

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Looks good :). The only thing you need to remember is that the SEPARATION_PLANE command does not rotate with the rotation in your XML file. So you need to make sure that the direction in the SEPARATION_PLANE command matches the heading at which you will use it.
 

fog

Messages
48
Country
norway
arno said:
Looks good :). The only thing you need to remember is that the SEPARATION_PLANE command does not rotate with the rotation in your XML file. So you need to make sure that the direction in the SEPARATION_PLANE command matches the heading at which you will use it.

Thx for that last tip :):) didnt know this!

Freddy
 

fog

Messages
48
Country
norway
Just have to complete this thread with the following:

The last number in the SEPARATION_PLANE (should be 32767 not 32000 as my excample above), must be multiplied with X if you want to set a SEPARATION_PLANE thats offset from the 0,0 REF-point in your GMAX file... I did all my runway lights in one GMAX file using the runway centercoordinate as the center of the GMAX file...

So if your object is 230 meters offset the REF point in gmax, the last number us then 32767 x 230 = 7536410

Freddy
 
Messages
12
Country
italy
Hi all, I'm new to this amazing forum.
Freddy, I had a look at your edited code above, I still have to try that but I'm sure it will work.
I just have a technical curiosity about that: since the nolgt_1, nolgt_2, nolgt_3 etc. label calls have been deactivated by commenting out the IFMSK command line, is there any technical reason to keep into the code the corresponding destination labels? Of course they should stay as 'dead code' if there're no labels calling for them, so the fact they're still there shouldn't affect the code at all, anyway I just would like to know if they can be 'cleaned up' as well.

Thanks so far,
Raffaele
 

fog

Messages
48
Country
norway
Didnt actually think of this, but should work without the code also, as it is commented out :)

Freddy
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Hi Raffaele,

It should indeed also work without them, because they are not called anymore. But for the final MDL/BGL file it does not matter, as the labels are only used to calculate the jump sizes in byes by the compiler. They do not end up in the final file.
 
Messages
12
Country
italy
Thanks both, Guys.
I posted my question just to check if my understanding of the code's logic was still the same I had with SCASM........as a personal disposition, I prefer to understand something rather than copying that. ;)
 
Messages
12
Country
italy
Arno,
I've read somewhere a posting of yours where you said the SEPARATION_PLANE vector is not affected by the heading set into the xml file, so it's needed to rotate the vector to its true heading into Gmax directly.
Well, this didn't work with me.........so I rotated the vector 180° down (x=0, y=-32767) and the lights are displayed accordingly with the heading of the object set into the xml wrapper (the whole object has been exported as a library object). The object is oriented more or less 060°, and the lights are displayed within the arc 150° to 330°, just like I wanted them to be.
Have I did something different? Maybe the difference is that I'm using the object as a library object? :confused:

Here's the relevant piece of the *_0.asm code:
Code:
SEPARATION_PLANE nolgt_1, 0, 0, -32767, 32767
and the corresponding piece of the xml 'wrapper':
Code:
heading="60.3"
 
Messages
12
Country
italy
It's the BGLC successor of SCASM's VectorJump command, if reading this thread from its beginning you'll realize it's used to make lights to be visible from one direction only.
It performs an angular check using a vector, and, if the observer is within the angular range the following piece of code is executed, otherwise it's skipped.
So it's also useful for docking visual systems, PAPI/VASI lights etc.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Hi Raffaele,

raf777 said:
I've read somewhere a posting of yours where you said the SEPARATION_PLANE vector is not affected by the heading set into the xml file, so it's needed to rotate the vector to its true heading into Gmax directly.
Well, this didn't work with me.........so I rotated the vector 180° down (x=0, y=-32767) and the lights are displayed accordingly with the heading of the object set into the xml wrapper (the whole object has been exported as a library object). The object is oriented more or less 060°, and the lights are displayed within the arc 150° to 330°, just like I wanted them to be.
Have I did something different? Maybe the difference is that I'm using the object as a library object? :confused:

The SEPERATION_PLANE command does indeed not respond to the heading you set in the XML file. So you should always calculate the vector as if it is placed with a heading of 0. This is not something you can do in GMax.

But what you describe sounds like this is not true :). Can you maybe sent me the total source of your object, it would be interesting to take a look. Maybe you found some code that does rotate :).
 
Messages
12
Country
italy
No Arno, I was meaning I need to calculate vector's coordinates by drawing a line in Gmax, having the same vector's lenght, than rotate the line and getting the coordinates of its endpoint. Of course such a coordinates will have to be handwritten into the *_0.asm file. I know it's impossible to have a SEPARATION_PLANE command line automatically generated by MakeMdl.

I've experienced such an odd vector's behavior while testing the RGL animated lights made by bpahe (Hans), you can download it here:http://www.scenerydesign.org/forum/showthread.php?t=1601&highlight=rabbit
it's at the 10th posting of the 1st thread's page (Hold_Short_ESMK.zip).
I've simply exported it and changed quite nothing, apart adding the SEPARATION_PLANE command and a distance trigger. Here are both of the sections I've modified:
Code:
rgl_RotateAroundX_2 label BGLCODE
rgl_anim_1 label BGLCODE
    BGL_SET_MATRIX_INDIRECT	2
    VAR_BASE_32   VAR_BASE_PARAMS

    ; Node 10 - Tick18_LIGHT_NAV_L transform:

     BGL_SET_MATRIX_INDIRECT	3

;    IFMSK       nolgt_1, dict_0_g_lightStates, LIGHT_NAV_MASK
[COLOR=DarkRed]SEPARATION_PLANE nolgt_1, 0, 0, -32767, 32767[/COLOR]
    BGL_LIGHT LIGHT_NAV, 0.000, -0.000, -0.001, 20, 0.60, 0.40, 0FFD5C34Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 141
    nolgt_1       label BGLCODE
rgl_anim_2 label BGLCODE
    BGL_SET_MATRIX_INDIRECT	4
    VAR_BASE_32   VAR_BASE_PARAMS

    ; Node 11 - Tick18_LIGHT_NAV_L transform:

     BGL_SET_MATRIX_INDIRECT	5

;    IFMSK       nolgt_2, dict_0_g_lightStates, LIGHT_NAV_MASK
[COLOR=DarkRed]SEPARATION_PLANE nolgt_2, 0, 0, -32767, 32767[/COLOR]
    BGL_LIGHT LIGHT_NAV, 0.000, -0.000, 0.000, 20, 0.60, 0.40, 0FFD5C34Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 142
    nolgt_2       label BGLCODE
rgl_anim_3 label BGLCODE
    BGL_SET_MATRIX_INDIRECT	6
    VAR_BASE_32   VAR_BASE_PARAMS

    ; Node 12 - Tick18_LIGHT_NAV_R transform:

     BGL_SET_MATRIX_INDIRECT	7

;    IFMSK       nolgt_3, dict_0_g_lightStates, LIGHT_NAV_MASK
[COLOR=DarkRed]SEPARATION_PLANE nolgt_3, 0, 0, -32767, 32767[/COLOR]
    BGL_LIGHT LIGHT_NAV, 0.000, -0.000, 0.001, 20, 0.60, 0.40, 0FFD5C34Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 143
    nolgt_3       label BGLCODE
rgl_anim_4 label BGLCODE
    BGL_SET_MATRIX_INDIRECT	8
    VAR_BASE_32   VAR_BASE_PARAMS

    ; Node 13 - Tick18_LIGHT_NAV_R transform:

     BGL_SET_MATRIX_INDIRECT	9

;    IFMSK       nolgt_4, dict_0_g_lightStates, LIGHT_NAV_MASK
[COLOR=DarkRed]SEPARATION_PLANE nolgt_4, 0, 0, -32767, 32767[/COLOR]
    BGL_LIGHT LIGHT_NAV, 0.000, -0.000, 0.000, 20, 0.60, 0.40, 0FFD5C34Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 144
    nolgt_4       label BGLCODE
    BGL_RETURN


bgl_riff_end_rgl	label	BGLCODE

As you can see, the vector has a neutral x value and a full lenght (negative) y value.

This's the distance trigger, nothing that should affect the vector but, since it has been added by me, here it is as well:
Code:
bgl_riff_start_rgl	label	BGLCODE
    db	'B','G','L',' '
    dd	bgl_riff_end_rgl - $ - 4
LOD_0_rgl	label	BGLCODE

; NonAlpha
rgl_NonAlpha label BGLCODE
[COLOR=DarkRed]IFIN1 noshow, 033Bh, 0, 400[/COLOR]

    ; Node 1 - RotateAroundX transform:

     BGL_SET_MATRIX_INDIRECT	0
    BGL_CALL_32 rgl_RotateAroundX_1        ; Node 1 - RotateAroundX

; Alpha
rgl_Alpha label BGLCODE

    ; Node 1 - RotateAroundX transform:

     BGL_SET_MATRIX_INDIRECT	1
    BGL_CALL_32 rgl_RotateAroundX_2        ; Node 1 - RotateAroundX
[COLOR=DarkRed]noshow label word[/COLOR]
    BGL_END
    BGL_RETURN

The heading of the object in the XML wrapper is "60.3".
I can grant you the lights do disappear when I'm exactly (90 degrees) on the left or on the right of the object's reference point. :eek:
Hope I've unintentionally discovered something being unknown before...... :D

Btw: I'm also trying and make a custom PAPI approach light system using the SEPARATION_PLANE command. In such a case, vectors are behaving 'normally' (i.e. they're not affected by the XML heading)....... :confused: :confused:
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Hi Raffaele,

OK, you confused me with the GMax remark. I also do the simple maths to calculate the vector on a piece of paper :).

I have never tested the SEPERATION_PLANE with an animated object like this. The fact is that the command always checks around the reference point (0,0), so that might lead to a certain error if the object is moving.

I will try to run your code later, to see if I can spot how it works. If this one would rotate that would be perfect of course :).
 
Messages
12
Country
italy
Yep Arno, if in some way a method to rotate vectors accordingly with the XML heading can be retrieved, this would allow to spare a lot of vector calculations.
The fact the animation seems not to be affected by the SEPARATION_PLANE command might be due to the fact the animation itself is moving along the x axis only, while the vector is acting along the y axis only.........I don't know, mine is just a conjecture...... :confused:

Looking forward to see if you can discover something more abouth this.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Hi,

It is not the SEPERATION_PLANE command that does your hidding at certain angles, it is the 3D model of the lamp. Just remove all the polygons and you will see that the light does not dissapear as you would expect.
 
Messages
12
Country
italy
Mh........I'm not so sure about what do you say here.........
I was convinced object's faces hadn't the capability to hide BGL_LIGHTs........but maybe I'm wrong about that.

If things shouldn't be as you say, perhaps could be enough to place a box below the ground level (so only the light would be visible) and have it exported within the same file, in order to avoid vector's calculations....... :confused:
I'll have some try.
 
Last edited:
Messages
172
Country
netherlands
hello,
I've been messing with some approach lights with scenery lights and all is working well, except for one thing.
This is my runway setup:

planehelp.jpg


Kinda awkward, but ill have to do. I've worked and tested 2 planes, one for rwy 10 approach (from left) and one for rwy 28 approach (from right). The code for the two point are:

P1: SEPARATION_PLANE nolgt_rwyredlights, 32725, 0, -1652, 14070795
P2: SEPARATION_PLANE rwy28redlights, 32725, 0, -1652, 58143754

I only want to see the red lights for the respective runway approach. because both points are right of the origin the rwy 28 (from the right) approach works well, because i can see the P1 lights at the end of the rwy (which is supposed to happen), but also the P2 lights! Conversely, when I approach from the left, i see neither!

I also have the problem with the rwy 10 (from left) approach lights. I am supposed to see them going left to right, but i can only see them right to left! Inverting the coordinates simply put the plane on another location, which isnt right. So i cant see it on approach, only after i pass P1, when its supposed to be the other way around.

here is my code for the red lights:


Code:
approach_lights_red_rows_MasterScale_1 label BGLCODE
IFIN1 lbl_endrwyredlights, 07C0h, 1115h, 1115h
SEPARATION_PLANE nolgt_rwyredlights, 32725, 0, -1652, 14070795
;    IFMSK       nolgt_1, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 434.896, 1.357, 98.199, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 1
    nolgt_1       label BGLCODE

;    IFMSK       nolgt_2, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 434.765, 1.357, 95.602, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 2
    nolgt_2       label BGLCODE

;    IFMSK       nolgt_3, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 434.633, 1.357, 93.005, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 3
    nolgt_3       label BGLCODE

;    IFMSK       nolgt_4, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 434.502, 1.357, 90.409, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 4
    nolgt_4       label BGLCODE

;    IFMSK       nolgt_5, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 434.371, 1.357, 87.812, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 5
    nolgt_5       label BGLCODE

;    IFMSK       nolgt_6, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 434.240, 1.357, 85.215, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 6
    nolgt_6       label BGLCODE

;    IFMSK       nolgt_7, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 433.978, 1.357, 80.022, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 7
    nolgt_7       label BGLCODE

;    IFMSK       nolgt_8, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 434.109, 1.357, 82.619, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 8
    nolgt_8       label BGLCODE

;    IFMSK       nolgt_9, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 433.847, 1.357, 77.425, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 9
    nolgt_9       label BGLCODE

;    IFMSK       nolgt_10, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 433.716, 1.357, 74.829, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 10
    nolgt_10       label BGLCODE

;    IFMSK       nolgt_11, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 433.585, 1.357, 72.232, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 11
    nolgt_11       label BGLCODE

;    IFMSK       nolgt_12, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 433.453, 1.357, 69.635, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 12
    nolgt_12       label BGLCODE

;    IFMSK       nolgt_13, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 433.320, 1.357, 66.992, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 13
    nolgt_13       label BGLCODE
BGL_JUMP_32 nolgt_rwyredlights
nolgt_rwyredlights label word
SEPARATION_PLANE rwy28redlights, 32725, 0, -1652, 58143754
;    IFMSK       nolgt_14, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1777.482, 1.357, 17.577, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 14
    nolgt_14       label BGLCODE

;    IFMSK       nolgt_15, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1778.138, 1.357, 30.560, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 15
    nolgt_15       label BGLCODE

;    IFMSK       nolgt_16, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1778.006, 1.357, 27.963, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 16
    nolgt_16       label BGLCODE

;    IFMSK       nolgt_17, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1777.875, 1.357, 25.367, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 17
    nolgt_17       label BGLCODE

;    IFMSK       nolgt_18, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1777.744, 1.357, 22.770, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 18
    nolgt_18       label BGLCODE

;    IFMSK       nolgt_19, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1777.613, 1.357, 20.173, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 19
    nolgt_19       label BGLCODE

;    IFMSK       nolgt_20, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1777.220, 1.357, 12.383, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 20
    nolgt_20       label BGLCODE

;    IFMSK       nolgt_21, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1777.351, 1.357, 14.980, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 21
    nolgt_21       label BGLCODE

;    IFMSK       nolgt_22, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1777.089, 1.357, 9.787, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 22
    nolgt_22       label BGLCODE

;    IFMSK       nolgt_23, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1776.958, 1.357, 7.190, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 23
    nolgt_23       label BGLCODE

;    IFMSK       nolgt_24, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1776.827, 1.357, 4.593, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 24
    nolgt_24       label BGLCODE

;    IFMSK       nolgt_25, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1776.695, 1.357, 1.997, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 25
    nolgt_25       label BGLCODE

;    IFMSK       nolgt_26, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 1776.562, 1.357, -0.647, 20, 0.60, 0.40, 0FFE32A2Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 26
    nolgt_26       label BGLCODE
rwy28redlights label word
lbl_endrwyredlights label word
    BGL_RETURN

Ive also added Nav1 conditions, but thats working fine so no worries there :D !

Here is the rwy 10 approach lights code:

Code:
approach_lights_rwy_10_lights_MasterScale_1 label BGLCODE
IFIN1 lbl_endrwy10lights, 07C0h, 1115h, 1115h
SEPARATION_PLANE rwy10lights, 32725, 0, -1652, 14070795
;    IFMSK       nolgt_1, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 434.997, 1.357, 106.004, 20, 0.60, 0.40, 0FF52E56Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 1
    nolgt_1       label BGLCODE

;    IFMSK       nolgt_2, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 434.341, 1.357, 93.020, 20, 0.60, 0.40, 0FF52E56Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 2
    nolgt_2       label BGLCODE

;    IFMSK       nolgt_3, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 432.635, 1.357, 59.217, 20, 0.60, 0.40, 0FF52E56Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 3
    nolgt_3       label BGLCODE

;    IFMSK       nolgt_4, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 432.766, 1.357, 61.813, 20, 0.60, 0.40, 0FF52E56Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 4
    nolgt_4       label BGLCODE

;    IFMSK       nolgt_5, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 432.897, 1.357, 64.410, 20, 0.60, 0.40, 0FF52E56Ah, 0.000000, 0.000000, 1.000000 ; source poly num = 5
    nolgt_5       label BGLCODE

.............MORE AND MORE OF THE SAME.......................

;    IFMSK       nolgt_70, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 81.609, 5.369, 99.278, 20, 0.60, 0.40, 0FFEDDB79h, 0.000000, 0.000000, 1.000000 ; source poly num = 70
    nolgt_70       label BGLCODE

;    IFMSK       nolgt_71, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 67.065, 5.809, 102.431, 20, 0.60, 0.40, 0FFEDDB79h, 0.000000, 0.000000, 1.000000 ; source poly num = 71
    nolgt_71       label BGLCODE

;    IFMSK       nolgt_72, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 66.943, 5.809, 100.018, 20, 0.60, 0.40, 0FFEDDB79h, 0.000000, 0.000000, 1.000000 ; source poly num = 72
    nolgt_72       label BGLCODE

;    IFMSK       nolgt_73, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 52.358, 6.094, 103.173, 20, 0.60, 0.40, 0FFEDDB79h, 0.000000, 0.000000, 1.000000 ; source poly num = 73
    nolgt_73       label BGLCODE

;    IFMSK       nolgt_74, dict_0_g_lightStates, LIGHT_NAV_MASK
    BGL_LIGHT LIGHT_NAV, 52.237, 6.094, 100.760, 20, 0.60, 0.40, 0FFEDDB79h, 0.000000, 0.000000, 1.000000 ; source poly num = 74
    nolgt_74       label BGLCODE
lbl_endrwy10lights label word
rwy10lights label word
    BGL_RETURN

Sorry its so long :( ... :banghead: :banghead: :banghead:

If anybody knows how to "switch" the plane around or how to set a condition: "when on the wrong side of the plane display the lights, and vice versa."

Thanx already! :wave:
 
Top