[1.0.5] Surface Mounted Stock-Alike Lights for Self-Illumination (v1.2.2 - 11/15/15)

[hvacengi]

4 hours ago, IgorZ said:

• [Internal] Migrate spot and omny lights to the stock LightModule.

... snip ...

• [Internal] Drop unused SurfaceLight module.

Doesn't dropping the previous module mean that the light's lens color does not change with the light's color?

[meyerweb]

6 hours ago, IgorZ said:

These lights are physics parts so, technically they can affect craft behavior. Did you place the parts symmetrically?

It’s a single light, but the problem turns out not to have anything to do with either SurfaceLights or kOS.  I had inadvertently created a permanent yaw trim with a keyboard shortcut to open the AnyRes mod.  @hvacengi figured it out for me over in the kOS thread, and provided a fix:

Quote

Trim is set by pressing the modifier key (alt on windows) and one of the translation controls.  You can reset it using the modifier key and "x".  This is not a control listed in the KSP settings, but you can find it on the KSP wiki.  I verified that on the save file provided [Alt]+[X] stopped the errant yaw.

Sorry for the errant bug report!

[Jacke]

1 hour ago, meyerweb said:

It’s a single light, but the problem turns out not to have anything to do with either SurfaceLights or kOS.  I had inadvertently created a permanent yaw trim with a keyboard shortcut to open the AnyRes mod.  @hvacengi figured it out for me over in the kOS thread, and provided a fix:

Sorry for the errant bug report!

It's not hard to get these keyboard control collisions, as well as have problems with inadvertent trim.  (Trim is very useful in fine aircraft and rocket control. As well, the new Unity 5 UI helps by making the stock attitude control needles in the lower left larger and easier to read by default.)

That's because another common source of issues is that in KSP, functions linked to [Key] will also be triggered on pressing [Mod]+[Key] (in addition to the functions linked to [Mod]+[Key]); in other words on Windows, pressing Alt-[Key] also acts as if [Key] was pressed.  For example, @sarbian's excellent GCMonitor toggles the display of its control window with Alt-F1.  This issue means bringing up and dismissing GCMonitor's window by pressing Alt-F1 twice also creates two screenshots, just as if F1 was pressed twice.

So inadvertently triggering multiple actions is not just a problem with functions with the same keypress, it's also functions with similar keypresses differing only by whether they include using [Mod].

[JeffreyCor]

2 hours ago, hvacengi said:

Doesn't dropping the previous module mean that the light's lens color does not change with the light's color?

I would imagine so, as this was the reason the module was created in place of using the stock system.:( But given the choice of losing surface lights entirely or losing the feature, I chose losing the feature Unless the stock system changed, I haven't tried anything with lights yet.

[IgorZ]

4 hours ago, hvacengi said:

Doesn't dropping the previous module mean that the light's lens color does not change with the light's color?

 

2 hours ago, JeffreyCor said:

I would imagine so, as this was the reason the module was created in place of using the stock system.:( But given the choice of losing surface lights entirely or losing the feature, I chose losing the feature Unless the stock system changed, I haven't tried anything with lights yet.

Colors still can be changed. Light color was always in the stock light module but in 1.0.5 it was not available via UI. Now , when it's available for the stock lights the original module of this mod looses its benefits.

Spoiler

 

[IgorZ]

6 hours ago, hvacengi said:

Doesn't dropping the previous module mean that the light's lens color does not change with the light's color?

Sorry, I misunderstood your comment about the len's. Yeah, len's coloring will gone. I missed it when was deprecating the module. Never used coloring, though. Created a regression bug. Shouldn't be a problem to bring it back for omni and spot lights, but 4-way is a problem.

[hvacengi]

1 minute ago, IgorZ said:

Sorry, I misunderstood your comment about the len's. Yeah, len's coloring will gone. I missed it when was deprecating the module. Never used coloring, though. Created a regression bug. Shouldn't be a problem to bring it back for omni and spot lights, but 4-way is a problem.

Glad you caught that, I sat down to type it up an make you an image explaining it and then got tied up here at work.  

As an alternative, kOS is intending to eventually (Maybe this makes it as good a time as any) expose out our kOSLightModule (the thing that backs the light effects on our processors and the cherry light) for external use.  It is able to do the same thing, so you could make a MM patch to add our module if that's installed.  (I say that, however for some reason my testing earlier didn't work, so I have to figure out an exact patch).

[JeffreyCor]

5 hours ago, IgorZ said:

 

Colors still can be changed. Light color was always in the stock light module but in 1.0.5 it was not available via UI. Now , when it's available for the stock lights the original module of this mod looses its benefits.

  Reveal hidden contents

 

You misunderstand. In stock the light emitted changes color, but the light itself remains white (just tested with a stock light). What the plug in did was allowed the light to match the light emitted. Thus a red light emotion setting would cause the light itself to be red, not a white light with red light illuminating off of it.

EDIT: Which I see I was beaten to pointing this out

Edited May 6, 2016 by JeffreyCor

[Stone Blue]

1 hour ago, JeffreyCor said:

You misunderstand. In stock the light emitted changes color, but the light itself remains white (just tested with a stock light). What the plug in did was allowed the light to match the light emitted. Thus a red light emotion setting would cause the light itself to be red, not a white light with red light illuminating off of it.

EDIT: Which I see I was beaten to pointing this out

Pardon my ignorance, as I'm no coder or modeller, but cant you just make separate textures for the lens part of the light, each a different color to match the light emitted color choices, and just use the Firespitter or B9 texture switch in a .cfg to automatically switch the lens texture to the light emitted color?

This seems to be pretty much what the AviationLights/Deadskins textures do...

Edited May 7, 2016 by Stone Blue

[IgorZ]

8 hours ago, Stone Blue said:

Pardon my ignorance, as I'm no coder or modeller, but cant you just make separate textures for the lens part of the light, each a different color to match the light emitted color choices, and just use the Firespitter or B9 texture switch in a .cfg to automatically switch the lens texture to the light emitted color?

This seems to be pretty much what the AviationLights/Deadskins textures do...

Color is made of three components, each ranges from `0.0` to `1.0`. How many textures do you think will cover all the values?

[Stone Blue]

6 hours ago, IgorZ said:

Color is made of three components, each ranges from `0.0` to `1.0`. How many textures do you think will cover all the values?

I realise you assign the emitted colors with sliders, but what about textures just for a few base colors?... They wont match the emitted light exactly, but a red for reddish, blue for blueish, green for greenish, yellow for yellowish, and white for whiteish.... So maybe 5 or 6 textures?

[IgorZ]

7 hours ago, Stone Blue said:

I realise you assign the emitted colors with sliders, but what about textures just for a few base colors?... They wont match the emitted light exactly, but a red for reddish, blue for blueish, green for greenish, yellow for yellowish, and white for whiteish.... So maybe 5 or 6 textures?

It may be a good workaround for 4-way light. I still hope to find a better solution. The other lights are working fine with changed emissive color.

[IgorZ]

v1.2.3 alpha 3 is available

Cumulative updates from the stock version:

• [Change] Minor code adjustments to compile under KSP 1.1
• [Change] Disable animation on 4-way light since it doesn't work properly anyways.
• [Change] Rename GUI action and event names in 4-way light to identify which light they control.
• [Internal] Create a multipoint light module and use it in 4-way light.
• [Internal] Migrate spot and omny lights to the stock LightModule.
• [Internal] Drop incomplete SurfaceNavLight module.
• [Internal] Drop unused SurfaceLight module.
• [Internal] Rename multi point light module to a more KSP name.
• [Internal] Improve reliability of multi point light module when config paremetrs or model are bad.
• [Internal] Create a new module based on old SurfaceLight to support colored lens on the light.
• [Change] Expose setting "Lens brightness" to allow customizing light's minimum brightness level.

This state I consider stable. If not major complains arise on the release I'll start a new forum topic and try to upload the new version on CKAN.

Spoiler

 

Edited May 8, 2016 by IgorZ

[Booots]

That looks great! Is it possible to get a MM patch to make the stock lights use this system so their lenses change colour too?

[Svm420]

Awesome! Thanks for the update.

On a side note. The Navlight module you removed from the code. What state was it in? I had been hoping Why485 would have had in in a working condition considering the thread he posted here.

[IgorZ]

3 hours ago, Booots said:

That looks great! Is it possible to get a MM patch to make the stock lights use this system so their lenses change colour too?

I tried to replace module on the stock lights but it didn't work. Changing of the emission color on the material just has no effect. I have a theory that it gets overridden in the animation.

2 hours ago, Svm420 said:

Awesome! Thanks for the update.

On a side note. The Navlight module you removed from the code. What state was it in? I had been hoping Why485 would have had in in a working condition considering the thread he posted here.

To be honest, I have no idea on the state of this module. I tried to figure out what was the idea behind it and eventually gave up. Though, now with this link I at least have some idea of what was it. May be I'll get back it it. Restoring the deleted module is a trivial task.

[lajoswinkler]

This is a really nice mod, essential to me because stock lights are clunky and not nice. These look stock, but aren't in the way and look much better.

[Enceos]

@IgorZ and @Everyone There's a cool and simple B.U.L.B. mod by Mr. @Alshain, which enables the stock light module to have RGB sliders in flight.

Edited May 9, 2016 by Enceos

[IgorZ]

36 minutes ago, Enceos said:

@IgorZ and @Everyone There's a cool and simple B.U.L.B. mod by Mr. @Alshain, which enables the stock light module to have RGB sliders in flight.

Hmm, they use the same approach which I tried:

emi.material.SetColor("_EmissiveColor", new Color(red, green, blue, 1));

It didn't work for the stock lights. Will check it again.

Edited May 9, 2016 by IgorZ

[Enceos]

8 hours ago, IgorZ said:

Hmm, they use the same approach which I tried:

emi.material.SetColor("_EmissiveColor", new Color(red, green, blue, 1));

It didn't work for the stock lights. Will check it again.

WBITools from Pathfinder by @Angel-125 have WBILight module, which also has inflight sliders.

[Angelo Kerman]

9 hours ago, IgorZ said:

Hmm, they use the same approach which I tried:

emi.material.SetColor("_EmissiveColor", new Color(red, green, blue, 1));

It didn't work for the stock lights. Will check it again.

Here's how WBILight does it: https://github.com/Angel-125/WildBlueTools/blob/master/Parts/WBILight.cs

[IgorZ]

@Enceos @Angel-125,

Guys, have you actually tried to apply this technique on the stock lights? In ModuleColoredLensLight I use exactly the same approach as you suggest but it just does not work on the stock lights.

11 hours ago, Enceos said:

@IgorZ and @Everyone There's a cool and simple B.U.L.B. mod by Mr. @Alshain, which enables the stock light module to have RGB sliders in flight.

Btw, this mod does light color and material emissive color updates in every `Update()` call. If your craft has many lights of this kind the performance can suffer significantly.

Edited May 10, 2016 by IgorZ

[Enceos]

@Angel-125 I haven't looked, but I presume there's a fundamental difference between the models of your lights and the models of the stock lights. Which is why WBILight doesn't work on stock models. Do you think there's a workaround to enable your module on the stock lights?

[IgorZ]

Given there were no major complains or bugs for the alpha 3 I did a release. here is the new topic:

Not sure of this topic should be requested for the close or left open "just in case". Suggestions?

[Frybert]

Locked for above reason.