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.
Thanks, guys. I appreciate the differing file formats. I trying to see if I can offer SCASM lights as an alternative in AFLT. (Apparently, SCASM lights - at least in some configurations - still work with P3Dv2 whereas I've confirmed that BGL_LIGHTs and effects controlled by BGL coding don't.)
It's basically just the LIGHT command that I'm interested in. The models themselves (to which the light is attached) display just fine.
Hopefully, MCX won't simply convert SCASM lights to BGL_LIGHTs, because I already know they won't work.
yesWould I be correct that when you use the terms "altitude specified absolutely" you are referring to elevation / altitude relative to Mean Sea Level (aka "MSL")
Perhaps. But, at this point, I suspect not. In fact, the AGL/MSL discussion now seems to be a "red herring". The problem I discovered only a couple moments ago is that visibility of SCASM Lights is severely limited in elevation. The light is visible only so long as the view point is < 10-15 degees above. Above that, the lights seem to disappear into the ground/runway. (What started as a circular light dot develops a flat bottom that progresses upwards until the entire dot disappears - as if being lowered into a plane.) There seems to be no limit below. Lights placed AGL are in fact visible. But to see them you've got to be very low. Only P3Dv2 exhibits this behavior. FS9/X seem OK.Also, since others here have previously discovered some quirky behavior when using integer (rather than floating point) and certain numeric value ranges in SCASM source code with degrees of "RWY Heading", might "Altitude" be yet another parameter where a floating point value (to a specified decimal places) needs to be utilized ...in one's parameter value units ?