[0.23] Runway PAPI array - Version 0.3.2

[The Destroyer]

This is so nice!

But for the love of god, it's ugly xP

[TheCanadianVendingMachine]

Now add a part which allows CAT II and CAT III auto landing systems!

Anyhow, good job on the PAPI lights!

[MK3424]

The lights doesn't seem to work on 0.21

[whaaw]

can confirm that doesnt work for 0.21 (only mechjeb in my modlist)

[asarium]

I will try to fix that as soon as possible.

[Devo]

Downloaded and testing, great stuff!

[asarium]

The plugin is now again working with the newest version of KSP, link in the first post has been updated.

[whaaw]

The plugin is now again working with the newest version of KSP, link in the first post has been updated.

just awesome!!! THX

[CaptainKipard]

Hey Asarium. Thanks for this mod. If you would like me to make some models for this I'd be happy to. PM me if you like.

Edit. I can do the ALS models too.

Edited July 25, 2013 by Cpt. Kipard

[asarium]

I have just uploaded version 0.2 which adds configurable light arrays.

[RoboRay]

6* is a bit suicidal IMO. IRL these are configured to something arround 3.

IRL, they aren't configured for returning spacecraft. The space shuttle flew an 18-20 degree glideslope right up to the flare over the runway.

I think 6 is a reasonable compromise but adjustable would be great.

I have just uploaded version 0.2 which adds configurable light arrays.

Thanks, will check that out!

[whaaw]

I have just uploaded version 0.2 which adds configurable light arrays.

very nice thx cant wait to test it:-)

[KwirkyJ]

This is a very promising idea. Well overdue, in my opinion, and what a fine start you've made on it.

A request as of 0.2, an example of a configuration file seems prudent. While your explanation probably makes perfect sense to you, there is any number of ways it can be interpreted to a user. Perhaps include the 'given' PAPI array in a configuration file to start, rather than them being hard-coded. (This also allows editing of the glidescope.) To allow a reset, have the config file generated if it is missing from the PluginData folder, much like FAR's screen position information for those familiar with it.

Also, I have a bug to report, present in both versions 0.1 and 0.2: the array tends to become unresponsive between some combination of timewarp, switching vessels, and orbiting the planet. I have yet to pin it down exactly (partly because I'm lazy and don't want to sit around for 20 minutes to complete an orbit in real time), but completing one orbit will sometimes trigger the issue. Also associated with repeated switching between vessels. I am unsure if this is due to additional lights being spawned at some point, and must admit that I have not poured over your code to point and say 'yes, probably here.'

Lastly, I will repeat in interest in a 'meatball' type option, giving alignment in two axes. Rotating the camera to confirm alignment during final approach is irksome.

[Avalon304]

This is one of THE mods I have been waiting for If you can make it look more like the USAF 'Meatball' it would be awsome.

The 'Meatball' is not controlled by anyone. The position of the marker in the center is completely autonomous and dependent on viewing angle. The only 'active' part is a few degrees of tilt to compensate for deck movement.

And the wave-off and cut-off lights, which are controlled by the LSO on deck.

[asarium]

This is a very promising idea. Well overdue, in my opinion, and what a fine start you've made on it.

A request as of 0.2, an example of a configuration file seems prudent. While your explanation probably makes perfect sense to you, there is any number of ways it can be interpreted to a user. Perhaps include the 'given' PAPI array in a configuration file to start, rather than them being hard-coded. (This also allows editing of the glidescope.) To allow a reset, have the config file generated if it is missing from the PluginData folder, much like FAR's screen position information for those familiar with it.

Also, I have a bug to report, present in both versions 0.1 and 0.2: the array tends to become unresponsive between some combination of timewarp, switching vessels, and orbiting the planet. I have yet to pin it down exactly (partly because I'm lazy and don't want to sit around for 20 minutes to complete an orbit in real time), but completing one orbit will sometimes trigger the issue. Also associated with repeated switching between vessels. I am unsure if this is due to additional lights being spawned at some point, and must admit that I have not poured over your code to point and say 'yes, probably here.'

Lastly, I will repeat in interest in a 'meatball' type option, giving alignment in two axes. Rotating the camera to confirm alignment during final approach is irksome.

The light definitions are all done with a config file, there are no hard coded lights. I added a link to the config file in the first post (or just use this one https://github.com/asarium/PAPIPlugin/blob/master/assets/lights.cfg).

I will try to reproduce that bug though I could image that it is related to the ScaledSpace bug that is occurring in the latest version.

I am not familiar with the meatball system so I will have to read through some articles to get it implemented correctly but that may take a while as I'd like to add a GUI first to allow dynamic editing of the glideslope. If you have coding experience you could try to implement it yourself, I would be glad to include any changes. Make sure that you use the develop branch as that includes the latest changes, the default master branch only contains the latest release.

[KwirkyJ]

Ah, so you do include a config file. That noted, I think I can better state my confusion: there is no config present with the mod distribution (just the PAPIPlugin.dll in appropriate folder), and I still have had lights. This is perplexing.

A nitpick: while there is good logical sense to combine arrays into groups (namely, pairs, one for each end of a runway), I find it silly to enforce a grouping rather than allowing one to freely define the arrays. There is no right or wrong to the idea, but it strikes me as odd to have separate categories - surely the users will mentally categorize their entries without the need of explicit groups, to say nothing of the added complexity when loading. While on the subject, I object to your use of 'BadGlidepath.' It does very little describe what it actually means. Perhaps 'GlideslopeTolerance' would be more in keeping with the intent?

While looking over your code, I wish to comment that you use quite a bit of rather dense organization that, while probably sensible to the initiated and practical in large projects, makes such a trivial project as this difficult to approach at first. (Namely, separating interfaces, "internal" [what?], and implementation not just in classes but also namespace, in addition to seemingly - at first, anyway - bizarre treatment of exception handling.)

I apologize for pulling things apart more than being directly helpful, but my time is sufficiently scattered (and, as mentioned above, project entry is nontrivial) that there is little, at least at this point, that I can contribute otherwise.

[asarium]

Ah, so you do include a config file. That noted, I think I can better state my confusion: there is no config present with the mod distribution (just the PAPIPlugin.dll in appropriate folder), and I still have had lights. This is perplexing.

I just checked the 0.2 download on github, it includes the lights.cfg file at the path GameData/PAPIPlugin.

A nitpick: while there is good logical sense to combine arrays into groups (namely, pairs, one for each end of a runway), I find it silly to enforce a grouping rather than allowing one to freely define the arrays. There is no right or wrong to the idea, but it strikes me as odd to have separate categories - surely the users will mentally categorize their entries without the need of explicit groups, to say nothing of the added complexity when loading. While on the subject, I object to your use of 'BadGlidepath.' It does very little describe what it actually means. Perhaps 'GlideslopeTolerance' would be more in keeping with the intent?

The groups are present to specify the body of the light array and as I already had the arrays grouped in the code I just used that pattern in the config file too. I agree that it may be a bit verbose but it's better than having to specify the body of every light array separately. I also made the Name property of a light group optional to reduce the number of required values if there is no good name to assign.

I also renamed the BadGlidepath to your proposed GlideslopeTolerance, that really was a terrible name for that field...

While looking over your code, I wish to comment that you use quite a bit of rather dense organization that, while probably sensible to the initiated and practical in large projects, makes such a trivial project as this difficult to approach at first. (Namely, separating interfaces, "internal" [what?], and implementation not just in classes but also namespace, in addition to seemingly - at first, anyway - bizarre treatment of exception handling.)

I have to disagree with you here, I made the experience that even in small projects the usage of well dosed abstraction can reduce the need for maintenance, especially when the performance overhead is negligible which is the case here. It also allows to plug in another implementation e.g. for testing purposes when needed.

I understand that it makes the project hard to understand at first but really help in the long run. Care to elaborate what you mean with "bizarre treatment of exception handling"? It's very well possible that I'm doing something wrong somewhere so it could help me.

I apologize for pulling things apart more than being directly helpful, but my time is sufficiently scattered (and, as mentioned above, project entry is nontrivial) that there is little, at least at this point, that I can contribute otherwise.

You're already helping me with just looking over the documentation and the code and I'd like to thank you for this

[KwirkyJ]

I just checked the 0.2 download on github, it includes the lights.cfg file at the path GameData/PAPIPlugin.

Problem resolved. The link on page 1 still directs to v0.1.1, and that is what I had been using. No wonder the config was absent! Went and found the current version on github, and have the actual 0.2 version. I'll take a closer look soon (read: use it). Though, to follow protocol, consider moving the file to PAPIPlugin/Plugins/PluginData/filename.cfg.

For anything else that is not pertinent to the release of this mod or issues thereby associated, I'll pm you with further minutiae.

[asarium]

Gah, yeah that explains why there is no config file, I updated the link...

I tried moving the lights.cfg into the PluginData folder but the GameDatabase seems to be unable to find the config nodes in there so I'll have to leaft it where it is.

[asarium]

I just updated the link in the first post with a new version of the plugin which now allows interactive editing of the target glideslope (the edited values are currently not saved).

[CaptainKipard]

Well, I don't see a dev thread for this mod so I'll just post this here.

Here's the model I promised. It's 506 triangles with a 512² texture. I'll try to make a bump map and a specular map for it too. I haven't textured the "lights" because You'll need to decide how you want to do them. Actually I'm not entirely sure spheres are the way to go. I'd suggest some static circles (that don't follow you) that fit inside the model where the white circles are right now.

Now I'm going to need some help with converting it to the Unity format. I've only ever modded Half Life and Half Life 2. I've never used Unity before.

[T-Pilot395]

Get it into an fbx format. Autodesk FBX is a free converteer.

[GrinchWSLG]

Here's the model I promised. It's 506 triangles with a 512² texture.

That's a lot of detail for something nobody is going to look at up close. I bet you could cut that tri count in half and forget about bump or spec mapping it.

[CaptainKipard]

The irony is that is that it used to be less than it is now, but I increased it because I was worried that people wouldn't like it. Maybe you're right though C7 said that his parts are somewhere around 1000.

Edited August 11, 2013 by Cpt. Kipard

[nothke]

Well, I don't see a dev thread for this mod so I'll just post this here.

Here's the model I promised. It's 506 triangles with a 512² texture. I'll try to make a bump map and a specular map for it too. I haven't textured the "lights" because You'll need to decide how you want to do them. Actually I'm not entirely sure spheres are the way to go. I'd suggest some static circles (that don't follow you) that fit inside the model where the white circles are right now.

Now I'm going to need some help with converting it to the Unity format. I've only ever modded Half Life and Half Life 2. I've never used Unity before.

Ha, this is funny. I like this mod and I just wanted to propose myself to build a model for it and give some suggestions. Now that's a good looking model and I wouldn't change it. I don't think specular/bump maps are necessary cause the actual model is quite obscure and there's a rare occasion someone will check them out from out close. Most of the KSP models are diffuse only too, so no need to put in more detail.

I am making an additional airports mod myself and would love to feature PAPI and full set of working airport lights. I tried making just an emissive object on top of the lights, but it fails cause when you look at them from the distance and the model is less then a screen pixel big it's invisible, so you either need to build it giant, or find a way to build 2d sprites, which I am going to talk about right now

I worked on modding racing games before and the best method for making headlights is to have 2 objects. One is the actually lit light object, emissive texture shaped as the light cover model and then put in front of the turned off light. The object would appear when it's on, and disappear when off. The other object is the "glare", a 2d sprite that is drawn on top and always points the camera. In the game there also was a way for the sprite to change size according to direction, so if you are looking directly into the light the sprite is big, if you move to the side the sprite shrinks until it disappears when looking more than 180 deg.

This is how it looks on my mod:

So, I would like to suggest if it is possible to, instead of a giant sphere, use a 2d sprite//billboard that would always be the same size on screen, no matter the distance, in this way, you can guarantee it would be seen from far away, but would not be a nuisance for up close. A similar method is used in the Microsoft Flight Simulator

I can send you the flare textures, I have plenty of them.

Edited August 11, 2013 by nothke