Well someone has to be first to do thatI sincerely don't understand how you all guys (I mean those who use graphic clients) are landing without lighting... Or do you time your reentries so it will be day landing?
Well you don't have to anymore
Just install this client and enjoy 
More cool stuff is coming, so stay tuned!
They are to be added in Config\Earth\Base\Canaveral.cfg file into first RUNWAYLIGHTS section after all standard ones. Of course they are being applied symmentically to both rwy ends, but they are only visible when you look at them in direction towards rwy center.
), so would it be possible to support them by disabling some of the more powerful effects like HDR etc if needed.Nice. If you want the real colors of the lights at the SLF: http://images.ksc.nasa.gov/photos/1976/high/KSC-376C-0042.22.jpgI've improved runway lighting. Here is what it looks like now:
View attachment 9085
Also I've discovered that stock Orbiter's config file parser is smart enough to ignore parameters it can't recognize, which allowed me to add some client-specific attributes. Here is what they mean:
View attachment 9086
I was experimenting on a KSC runway, so I've set up custom paramaters for it. Here they are:
They are to be added in Config\Earth\Base\Canaveral.cfg file into first RUNWAYLIGHTS section after all standard ones. Of course they are being applied symmentically to both rwy ends, but they are only visible when you look at them in direction towards rwy center.
I'm planning to make approach lights blinking like "running lights" towards runway, but that will be a bit later
That's it for today :tiphat:
This client's minimum requirement is DirectX 10-level hardware, and this will not change. So for integrated gI have a suggestion, most of the current clients have some sort scalability built in for lower end computers and gpus(intel onboard
Thanks
Well - every laptop is a compromise - it's either fast, but not quite "mobile" (in the sence that it's heavy and eats up battery almost faster than OS is able to boot up), or slow but mobile. I've got Alienware M17R3 laptop (i7, 16Gb RAM, GFX 460M 1.5 GB GDDR5, 3D-monitor, it costs nearly a fortune
), so I know what I'm talking about But that's the thing - if you purchased a laptop to use MS Office - yes, it can be cheap and have quite long on-battery time, but no games. If you want to play games - you either get a desktop with discrete video card, or a laptop like the one I've got - because games are all about performance, gigahertz and gigabytes. Anyway, as I said, we will be supporting DirectX 10-compatible integrated chips to the best we can, but please keep in mind that running this client on such systems is just using the system for something it wan't designed for... Besides - it is a well-known fact that some of the best hardware designers are working in Intel (I know that for a fact, since my major is in Electronic Engineering), however their drivers are, politely saying, far from perfect - see below.It's their drivers - they are just a garbage. You should try using DirectX instead - their DirectX drivers are far better than those for OpenGL, possibly since Microsoft has very strict requirements for compatibility, while in OpenGL world there is no authority which would set and enforce quality standards.
Thanks. Currently my lighting looks quite close to the real thing, allthough I see some incompliance with FAA regulations in your picture (I used them as a reference to implement lighting). Also there is no VASI on the photo - and I know for fact that it does exist there in a real life. I prefer to follow FAA standards - because this implementation is for all RUNWAYLIGHTS objects, not just specific for KSC - so it will look a bit different than your picture, but those of us who are fans of FSX (which I am
) will be pleased with familiar picture, and should be able to understand its meaning right away, without reading any Orbiter-specific things
Also there is no VASI on the photo - and I know for fact that it does exist there in a real life. I prefer to follow FAA standards - because this implementation is for all RUNWAYLIGHTS objects, not just specific for KSC - so it will look a bit different than your picture, but those of us who are fans of FSX (which I am
Now you know what I meant when I was talking about "familiar picture"
If VASI is not where the pilot expects it to be - it's the same thing as its' absence Here's the VASI for the 33-end as it was seen by the STS-115 crew:Now you know what I meant when I was talking about "familiar picture"
Here's the VASI for the 33-end as it was seen by the STS-115 crew:
And here it is in Google Earth:
And here's the PAPIs for RWY33:
, but I know that they are there - that's why I was a bit puzzled by this photo, as there are no VASI nor PAPI visible. And there are red lights along the edges in the beginning of the runway, which is also wrong - red lights in the beginning are meant to mark out a "burnout" zone, which does not exist in KSC RWY33/07 for obvious reasons.
Yes, it is - it's a part of standard Orbiter's base config options for RUNWAYLIGHTS object - check out OrbiterConfig.pdf file in Orbiter's "Doc" folder, search for "RUNWAYLIGHTS" word - you'll see complete description of all standard properties for that object - among other things, you can change VASI and PAPI angles, their offsets from the beginning of a runway, aperture angle for PAPI, distance between two VASI blocks, etc. As I've said earlier, I've added some custom properties, but those are only for lighting configuration - since "stock" client just uses hardcoded lighting scheme - but VASI and PAPI support is a standard function.
