SCASM Lights Cause dots

[mdm248111]

Using SCASM to make runway lights, I'm getting "dots" instead of nice looking lights. I've read and re-read these:

http://www.fsdeveloper.com/forum/showthread.php?t=21793&page=2
http://www.fsdeveloper.com/wiki/index.php?title=SCASM_Runway_Overlays

Here is our SCASM code:

Header( 0  N32:19 N32:02 W083:02 W083:10 )
LatRange(  N32:19 N32:02 )

Area( 5 32.21640341 -83.1286861 12 )

Runway( 32.21640341 -83.1286861
Alt 92.657 ; in meters
Heading 15.29
Length 6506 ; in feet
Width 112 ; in feet
ID 2
Lights 02
Surface -1
ThrLightsN 01
AprLN 02
StrobesN 5
ThrLightsF 01
)
EndA

The runway heading is 15.29, but when we use that, we get the bad dots. However, if I move it over a degree or two, the lights work normally and there isn't a performance hit.

Anyone have any ideas?

 

[Aviasim]

Well I think I can see a problem, if you look at the PAPI lights and the runway threshold lights, you can see some lights extremely close, as if there is an existing file already giving lights, plus the file you are adding.

If there is a duplicate (some how), that will explain for the very strange appearance of these lights or "dots".

So do a test, remove the BGL that contains your scasm lights, make sure there is no runway lights or anything applied to the runway in the AFCAD.

I think this may be due to human error as it really does look like there is another file for the same location, to display lights, with a very slight offset.

 

[jonmkj]

The PAPI lights are generated by the normal FSX runway under the ground poly. There are no duplicate SCASM runways, we've made absolutely sure of that. It appears to be entirely related to the heading of the SCASM runway. At 15.22 it works and displays properly, at 15.29 it does not.

 

[Aviasim]

Have you tried 15.21 or 15.20? go up or down see how close you can get it, even if it has to be something like 15.21999

 

[jonmkj]

15.227 was as close as we could get. it's a slight bit skewed but it's not too bad. it's all we can do.

 

[rhumbaflappy]

The problem is that the numbers the sim reads from the BGL are 16-bit pseudodegrees.

Here's the formula that should be used by SCASM to encode the number properly for degrees:

( 15.29 / 360 ) * 65536 = 2783.4595555555555555555555555556

The number then must be encoded as a whole number:

2783 ( this is 0ADF hex )

when converted back to actual degrees:

( 2783 / 65536 ) * 360 = 15.2874755859375

So, 15.2874755859375 is about as close as you could get, as long as SCASM is not giving rounding errors. The sim runways were never set up to handle decimal angles.

Dick