[1.12.x] IndicatorLights v1.8.3: Small, convenient, informative.

[KocLobster]

Once again @Snark, for the millionth time, you have had a positive impact on this community with your contributions. I appreciate the work you do and time & effort you put in.

This mod looks awesome, I can't wait to install it tonight, and I look forward to future updates.

[Snark]

Hi gang,

I've posted pre-release v0.4 of IndicatorLights.  New features with this pre-release:

• Status indicators added to reaction wheels.
• All colors that the mod uses are now user-configurable. Thus, if you'd like the indicator lights to be dimmer, or you have color-blindness issues and my color selection doesn't work for you, or whatever other reason: you can tweak this now.

• Color shows mode: green (normal), yellow (SAS-only), blue (pilot-only).
• Turns off when the reaction wheel is disabled.
• Dimmer when not in active use (i.e. no SAS or player input).
• Blinks brightly if electricity-deprived while turned on.

 

Enjoy!

[Snark]

4 hours ago, NecroBones said:

Quick questions-- Does "emissiveName" point to the mesh object with the emissive, or to the emissive material's name? And is "target" a path to the model's MU?

A bit of side context for anyone who's reading this who isn't a mod author:

What you're seeing here is a mod author who's wondering how he could configure his parts to use IndicatorLights, if he were so inclined.

Technobabble answer in spoiler section.

Spoiler

In answer to NecroBones' question:

• The "target" is the run-time path to the mesh with the emissive, within the part model.
  • For "native" parts, in which the mesh is part of the object itself, then this will just be the mesh object's name within the model, without any pathing.  Here's an example.
  • For cases where you've used ModuleManager to add an emissive mesh to an already-existing part:  then this will be the full path to the model within the GameData tree.  Here's an example.
• You can use any name you want for "emissiveName" ... the only requirement is that the name you use in your ModuleControllableEmissive has to match the name you use in your controller module.

So, the complete process of instrumenting a part to use IndicatorLights:

1. Make sure that the part has at least one emissive mesh on it (either "natively" in the part itself, or added on via ModuleManager config).
2. Add a ModuleControllableEmissive, whose "target" must exactly match the name of the emissive mesh. (If it doesn't match exactly, it won't work.)
3. Give the ModuleEmissiveController any emissiveName you like, this is just for your own consumption.
4. Add an appropriate ModuleEmissiveController subclass (e.g. ModuleResourceIndicator, ModuleToggleLED, etc.), and point it at your ModuleControllableEmissive by giving it the same emissiveName.
5. Profit!

Note that the above allows a lot of flexibility.  For example, one ModuleControllableEmissive can point at multiple meshes (as long as they're using the same material name). Or you could have multiple indicators that work independently to show different things; that's fine, just give them differently-named meshes in the model, each one gets its own ModuleControllableEmissive, then you add a controller for each one.

(Eventually I'll put together some documentation as part of the mod.  That's where this sort of information really belongs.)

[NecroBones]

 

Next SapceY update will have this functionality now.

 

 

[Starbuckminsterfullerton]

On 4/25/2016 at 5:35 PM, Snark said:

One way is to mod the part itself, like what I've done with batteries.  (As far as the game's concerned, batteries are just electricity tanks.)  In that case, they're resource-specific.

Another way is to have a part that you can attach to anything, which auto-detects what's available in the thing you're attaching it to, and uses that.  A generic resource indicator would therefore be a lot more general-purpose and flexible, but would require more fiddling with on the player's part to get it to work (i.e. they'd have to pick which resource, if there's more than one; pick a color; etc.)

Agreed on no tank/engine lights. 

Would it be possible to have a place-anywhere light and set what information to display via tweakable instead of what it is attached to? If possible, this would help avoid Christmas-tree syndrome because instead of having lights on every reaction wheel, engine, etc. you could have one for the whole ship, since many parts like reaction wheels are usually in the same state shipwide. Could also provide information on parts with disallowed surface attach, and tell us about the state of the vessel as a whole. 

Can you hook into science parts at all? Except for power and science, I generally know what's going on in a ship without indicators. You've solved batteries, but I can think of a ton of scenarios where I could use a quick reference for the state of an experiment / antenna. 

Edited April 27, 2016 by Starbuckminsterfullerton

[jlcarneiro]

Thanks, @Snark, this mod looks VERY promising!

Is it possible to add blinking functionality on the standalone parts?

[Snark]

1 hour ago, Starbuckminsterfullerton said:

Would it be possible to have a place-anywhere light and set what information to display via tweakable instead of what it is attached to? If possible, this would help avoid Christmas-tree syndrome because instead of having lights on every reaction wheel, engine, etc. you could have one for the whole ship, since many parts like reaction wheels are usually in the same state shipwide. Could also provide information on parts with disallowed surface attach, and tell us about the state of the vessel as a whole.

Yup.  What I have in mind is the ability to create fairly arbitrary bindings between parts.  i.e. you place the indicator light, and then you right-click the part and on the menu there's a "Select Target" button, that when you click it puts you into some mode where you can click on another part and let the indicator light be "watching" that part.  Then you'd have a set of options for what the indicator can display, depending on what the capabilities are of the target part, which would cycle via another button.  So, for example, if you'd targeted a command pod, the display options presented to you could be "Electric Charge Level", "Monopropellant Level", "Reaction Wheel Status", and "Crew Occupancy, Slot 0", something like that.

But I have no idea what the editor will let me do, or how big a deal it would be to try to implement the sort of experience I'd like, so that's a feature that's on the back burner until I've taken care of a bunch of low-hanging fruit.

1 hour ago, Starbuckminsterfullerton said:

Can you hook into science parts at all? Except for power and science, I generally know what's going on in a ship without indicators. You've solved batteries, but I can think of a ton of scenarios where I could use a quick reference for the state of an experiment / antenna.

Yup, science instruments are on my list, too.  Those are kind of tricky, because they're so tiny, it may be hard to add an indicator light on them without visually overwhelming the part.  This is one of those places where having a "bind indicator A to part B" function would be handy.

In any case, even though I haven't completely decided how I'm going to deal with science instruments, they're certainly on my list of areas I'd like to cover.

One piece of functionality I'm considering (for parts that are potentially useful with lights, but have the potential to annoy people who don't want 'em) would be a "show indicator" option in the vehicle editor, which if turned off would hide the indicator lights for that part.

22 minutes ago, jlcarneiro said:

Is it possible to add blinking functionality on the standalone parts?

Yep, that's on my list, too.  Would be nice to have some different modes so that people could make them look like, say, navigation lights for example.

The main question is how to factor the UI for it.  I don't want the UI for the part to turn into a big complicated thing with dozens of buttons and sliders on it.  So there's a tradeoff between giving flexibility for power users who want to make it do all kinds of tricks, versus keeping the UI as simple as possible to make it easy to use for most people.

But yes, if I can figure out the kind of UI to have, it's on my list.

[jpinard]

Wow, great news above!  Love how it's being integrated into SpaceY!

Snark I really wouldn't have you try to do it with smaller science payloads.  For the thermometer, baromoter and other payloads that size you might be looking at a size of 4 pixels lol, and at that point it may look more like a graphic artifact than a functional light.  However I do have an idea if you really want to do all science experiments.  Create a "panel".  The panel would be a series of lights with initials above similar to how mission control boards looked in the 1960's.  Thus you could have initials for each science part with a light above it.  I can visualize how this would work nice with Universal Storage Manager because you could have a "slice" fit in one of the pod doors, so when you open it, you can see all your experimental lights at a glance.  I'm not quite sure how it could be made to looks stockalike.  Maybe have a panel that looks like a circuit breaker (like what you have in  your house) and then that would look pretty stockalike when compared to other things you slap on the side of a rocket.  The panel would have all stock science projects (or split it in half if that's too many and then do two panels based on their position on the tech tree).  I think that'd look pretty cool.

[Snark]

10 minutes ago, jpinard said:

Snark I really wouldn't have you try to do it with smaller science payloads.  For the thermometer, baromoter and other payloads that size you might be looking at a size of 4 pixels lol, and at that point it may look more like a graphic artifact than a functional light.  However I do have an idea if you really want to do all science experiments.  Create a "panel".

Yah, that idea had also occurred to me-- the trick being to make it generally useful with as little required effort from the user as possible, while being as flexible as possible to deal with ship designs that can be practically anything.  My ideal would be a thing you can place and it just magically works and the user doesn't have to futz with it.  Not worth it if the user has to go through some long, tortuous, arcane process to "wire up" the control board-- that's the point at which it's easier for the user to just do it old-school by right-clicking the instruments.

Also, if it comes down to a "panel" instead of putting indicators on the parts themselves... that's the point at which I gotta ask, why is this even a physical game object at all, instead of a flight UI component?  I'm sure there are mods that already have those kinds of things.  So if that's the answer, then it might be that it actually doesn't really belong in IndicatorLights, which is all about physicality.

[jpinard]

1 hour ago, Snark said:

Yah, that idea had also occurred to me-- the trick being to make it generally useful with as little required effort from the user as possible, while being as flexible as possible to deal with ship designs that can be practically anything.  My ideal would be a thing you can place and it just magically works and the user doesn't have to futz with it.  Not worth it if the user has to go through some long, tortuous, arcane process to "wire up" the control board-- that's the point at which it's easier for the user to just do it old-school by right-clicking the instruments.

Also, if it comes down to a "panel" instead of putting indicators on the parts themselves... that's the point at which I gotta ask, why is this even a physical game object at all, instead of a flight UI component?  I'm sure there are mods that already have those kinds of things.  So if that's the answer, then it might be that it actually doesn't really belong in IndicatorLights, which is all about physicality.

In that case I'd really push you for the circuit breaker design panel with abbreviated letters.  You plop it on the side of your capsule.  That would be tremendously helpful as you wouldn't have to keep searching for the temp gauge and then right clicking that little thing etc etc.. If you have all the stock science experiments on there, then it's fantastic that we don't have to fiddle with it.  If we don't have that specific experiment as a payload, no worries, the light is just off or a "null" color.  I for one would LOVE to have this.

Edited April 28, 2016 by jpinard

[jlcarneiro]

6 hours ago, Snark said:

[...].

The main question is how to factor the UI for it.  I don't want the UI for the part to turn into a big complicated thing with dozens of buttons and sliders on it.  So there's a tradeoff between giving flexibility for power users who want to make it do all kinds of tricks, versus keeping the UI as simple as possible to make it easy to use for most people.

But yes, if I can figure out the kind of UI to have, it's on my list.

What about something like "sequencial sliders"? The first would select the main function (e.g. light or a destination part), the second would refine that (e.g. in case of light, blinking or toggle, in case of destination part, its title), etc...

This way, two maybe three UI items would be able to do many things...

[sebi.zzr]

Thank you,this is really great mod,but i have a request.Can you move the light on Z-400 battery little more out,like on the square?

Edit:Never mind,you can ignore the above,i just figured it out how to move it(it's really simple),but i thought it depends on model.So basically we can add these lights to any part,but what about the functionality,are those autodetected(resource level,state of probes(on/off)...)?
So if i whant this light to tell me if docking port has enabled crossfeed?

Edited April 28, 2016 by sebi.zzr

[Artfact]

Really enjoying this one so far; it has huge potential. Keep it up.:)

[Snark]

9 hours ago, jlcarneiro said:

What about something like "sequencial sliders"? The first would select the main function (e.g. light or a destination part), the second would refine that (e.g. in case of light, blinking or toggle, in case of destination part, its title), etc...

This way, two maybe three UI items would be able to do many things...

That's a good idea, and actually I'm already doing it.    If you look at the right-click menu of the BL-01 light in the editor,

...you'll see that it has RGB sliders for only the current mode.  For example, in the picture above, the light is "on", so only the sliders for the "on" color are displayed.  If you toggle it to "off", then it shows the sliders for the "off" mode.  That way, only three sliders at a time are displayed, instead of six.

So I'll definitely use contextual leverage to simplify UI, where possible.  Choosing one-of-several modes is an easy thing with a "cycle" control:  this is where you have N different possible states, and there's a button where each time you click it, the currently selected state moves on to the next one.  (You can see this in action in the stock game when you select the mode for a reaction wheel, for example).  So if I want a control to have multiple possible modes, I can easily put a cycle button for the mode, and then have a set of mode-specific controls that appear based on which mode is active.

What I'm saying is, even with such simplification, there is still a lot of unavoidable complexity, if I were to completely open up the UI to allow letting it do anything.  There's a certain point at which adding more complexity to the UI is a net negative rather than a positive.  Using contextual switching, such as described above, can raise that complexity "tipping point" somewhat, but not eliminate it.

So yes, I'll be adding more options, and yes, I'll use every trick in my toolbox to try to pack the most flexibility into the smallest and easiest UI footprint I can manage.  But there are tradeoffs I'm going to have to evaluate; figuring out where to draw the line will take some careful design thought.

5 hours ago, sebi.zzr said:

Can you move the light on Z-400 battery little more out,like on the square?

Not a bad point.  I don't want to move it too far out, because I don't want the light to be too prominent, but I could certainly nudge it slightly further out than where it is now.

5 hours ago, sebi.zzr said:

So basically we can add these lights to any part,but what about the functionality,are those autodetected(resource level,state of probes(on/off)...)?
So if i whant this light to tell me if docking port has enabled crossfeed?

The short answer to your question:

• There's no auto-detect feature. There are a set of controllers for different types of function, and you have to pick the controller that you want to apply.
• There has to be a controller that does what you want, or you can't add your desired functionality to a part.
• For example, I don't currently have a "detect crossfeed enabled" controller, so right now, you can't have that as a feature for docking ports.
• However, I plan on adding a lot more controller flexibility to IndicatorLights, so you will be able to do that in the future, just not right now.
• In the meantime, you could kind of "fake it" by putting some BL-01 lights around the docking port, and then tying both them and the docking port's "crossfeed enabled" action to the same action group.  That way, pressing the action group's hot-key would toggle both the docking ports and the lights. Yeah, I know, it's not as good as having real indicators for the state, but until that feature's available, this is perhaps better than nothing. 

Lengthy explanation in spoiler section.

Spoiler

The mod works based on two kinds of "things" that can be attached to a part via config:  emissives, and controllers.

The emissives are the physical objects that can light up.  They could be "integrated" as a native piece of a part (e.g. like what NecroBones is doing in SpaceY), or they could be tacked on via ModuleManager config (such as what I'm doing when I add indicators to the stock batteries and so forth).  Looks like you've already figured out how to play with these.

The controllers are the things that tell the emissives what to do (turn them on and off, set the color, etc.)  Controllers are just packages of computer code, not physical objects in the model.  For an IndicatorLights emissive to light up, it needs to have a controller to tell it what to do.

IndicatorLights provides a variety of controllers to choose from.  For you to achieve the effect that you want with an indicator light, there has to be a controller that does what you want.  You can use ModuleManager config to choose a controller, but you can't make a controller-- that has to be in plug-in code.

Currently (as of version 0.4), I have the following controllers available:

• ModuleToggleLED:  For manually-controlled lights.  Two states, "on" and "off".  You can pick the color that goes with each state.  It has action groups for "turn on", "turn off", and "toggle".
• ModuleResourceIndicator:  Shows the content of a resource on the part.  Currently, the only place I'm using this is to show the charge level of batteries.  But you could use this controller for any part that has resources in it (on a fuel tank, for example).
• ModuleConverterIndicator:  A simple on/off light that indicates whether a resource converter is active.  Currently I'm only using this for fuel cells, but you could use it for any resource-converter part.
• ModuleReactionWheelIndicator:  Indicates the status of reaction wheels.  I currently use this only for the actual reaction-wheel parts, but you could use this on any part that has ModuleReactionWheel on it (probe cores, for example; NecroBones is doing this in SpaceY).

So, if you're looking to add additional indicator-light functionality via ModuleManager, you can do it if the behavior you want is one of the above-listed controllers.  If what you want to do is something else (such as adding "probe core is alive" or "docking port cross-feed on/off"), then you're out of luck for now-- there's no way to do it via MM.

However, I will be adding more controller module types in the future, so the above list will grow to cover more areas of functionality.

One type of controller module I plan on adding is a very flexible "control-by-anything" one, i.e. a GeneralBooleanIndicatorController (or whatever I end up calling it).  The basic idea is that it will work with any KSP module that has a boolean property on it.  The part config (or MM config) would tell the controller "here is the module I want you to watch, and here is the boolean property on that module that I want you to use for controlling the indicator."

Having a general-purpose controller like that will open up a lot of flexibility to people who want to mod the dickens out of IndicatorLights.  For example, with such a controller, you could use MM config to mod "crossfeed enabled" indicators onto docking ports:  the controller config would set the control source to be ModuleDockingPort, and the source field as isCrossfeedEnabled (or whatever it's called), and then there ya go. 

The "final" form of the IndicatorLights mod will therefore include a large set of powerful-but-specifically-targeted controllers (such as the ones I already have), plus a small number (maybe just one) of general-purpose controllers that are not super sophisticated, but are very flexible to allow people to do lots of interesting things that I haven't thought of myself.

...I really oughta take some time to put together documentation pages for IndicatorLights. 

[sebi.zzr]

Thank you for the clarification.
regards

[bonyetty]

On 25 April 2016 at 5:40 AM, Jacke said:

I appreciate the care and attention to detail you have, Snark, as well as explaining things in enough detail.

This is why I like mods to be as partless as possible.  I've even written Module Manager scripts to make mods like MechJeb partless and add their functions to stock parts like Command Pods.

If you ever wanted to delete a part, instead you could depreciate the part so old craft files would have them but they wouldn't be available in the editors.  I believe the standard way to do that is change the part .cfg file so that the "category" value is "none" (it's what SCANsat did when it depreciated the MapTraq part).

Partless mechjeb I so want this please. I haven't used mechjeb for a year or so. Wish to use mechjeb on a existing save. I'm too stupid to copy and paste the correct folder or file to get the embedded mod to work. Searching only resulted in lots of coping, pasting and deleting folders and files with no success. My only knowledge of modual manager scripts and .cfg thingies are that they are computer code thingies. Assistance for a KSP loving dummy would be greatly appreciated. 

[Jacke]

14 minutes ago, bonyetty said:

Partless mechjeb I so want this please.

Spoiler

I haven't used mechjeb for a year or so. Wish to use mechjeb on a existing save. I'm too stupid to copy and paste the correct folder or file to get the embedded mod to work. Searching only resulted in lots of coping, pasting and deleting folders and files with no success. My only knowledge of modual manager scripts and .cfg thingies are that they are computer code thingies. Assistance for a KSP loving dummy would be greatly appreciated. 

 

It's getting away from Indicator Lights, and you should have PM'ed me for it, but briefly....   Don't call yourself stupid or a dummy.  You are not.  All of have things we just don't know or are not familiar with.  When we need to, we can all learn.   More in the spoiler....

Spoiler

If you're modding KSP, you should learn a bit more about computer directory systems and changing and copying etc. and how to keep it all straight.  Will help you in the long run.

Don't know what you mean by "...the embedded mod...".  Do you mean partless MechJeb?  That needs a Module Manager script written and that's computer coding.   I've done it and you can use what I coded.

To get partless MechJeb, install MechJeb as described here and then do the following I describe in this post on the MechJeb topic.

 

 

[NecroBones]

 

Someone suggested over in the SpaceY thread that I make the labels illuminate on the probe cores, with the IndicatorLights integration. So check this out.

 

The labels are lights now, which can be toggled via right-click or an action group. There's a "deploy limit" so you can set the brightness of them, if you want. In the screenshot below, the middle probe core has the brightness pulled back to about half.

 

[bonyetty]

Thank you jacke. I will follow you wise advice and directions. And thank you for sharing you code. I will endeavor (and will thanks to you)to learn more about and become more familiar with modding systems. Although I do not which to lie, this wonderful game with its now more familiar systems is more appealing right now. This game has encouraged me to learn so much since discovering it. Some coding actually. Oh the other thread is locked and silly probably but I just felt it a bit to forward and didn't want to come across as entitled by sending a private message. 

Thanks again

And appologies snark for dropping in on your thread. 

[Snark]

13 hours ago, NecroBones said:

The labels are lights now, which can be toggled via right-click or an action group.

Nice!  Looks really cool.   

How do you have them implemented?  Is it using ModuleToggleLED from IndicatorLights?

Just so you know:  I'm currently re-working some of the interior plumbing of IndicatorLights, such that the next update (possibly this weekend, we'll have to see how much time I have) is likely to be a breaking change for that one module.

Not a breaking change for players-- I'll be changing my code, and also changing my part config to match the new code, so anybody who's playing a game with IndicatorLights wouldn't even notice any difference-- but if you've created a part in your own mod that relies on ModuleToggleLED, you're likely to be affected.

Basically, what's going on is that I've had a little brainstorm that allows me to make IndicatorLights' module architecture much more powerful and flexible by allowing the output from one controller to flow into the input from another controller.  This will allow wiring sets of controllers together in creative ways, which will do a couple of things.  First, it will make my life easier, because I'll be able to build much more interesting behaviors without having to write lots of extra code.  Second, it will make modders' lives easier, because you'll have tons of flexibility to customize the behavior of the light exactly how you want it.  Basically, you'll be able to connect controllers together like Lego blocks.

For example:  I'm looking at adding indicator lights to docking ports.  Green/red to show "crossfeed enabled".  However, I really don't want to turn ships into Christmas trees, and it could get annoying having lights all over the docking ports all the time if you don't want them on, always.  So I figured, okay, make them toggleable via action group so that the player can turn the lights on and off (maybe put them in the Lights action group).  In the old way of doing things, I would have had to build all that into the docking port controller, which would duplicate a lot of code between that and ModuleToggleLED.  But in the new way, it's dead simple:  A basic "bi-state" controller that's wired to the crossfeed status of the docking port, and then feed the output of that to the input to ModuleToggleLED.

Most of the controllers I've written so far (for resource converters, resource indicators, and reaction wheels) are simple critters that won't be affected by the change.  However, ModuleToggleLED will be significantly rewritten, in a way that's breaking.

I'm sorry for the disruption, but that's part of the growing pains associated with being in a pre-release state.  And this is a really good change for me to be making now, early on-- I only wish I'd thought of this a few days ago. 

For one thing, the added flexibility means that it'll be less likely for me to have to make breaking changes later on.  Instead of having a few very complicated controllers (which means I'd have to tweak them all the time and it'd be hard to avoid breaking changes), I'll have a large number of much simpler controllers, and the complexity comes from wiring them together which can be done in config without having to write code.  With an architecture like that, when I need to make a change for a new feature, it's much more likely that all I have to do is make a new thing, rather than change an existing thing.

 

 

[NecroBones]

3 minutes ago, Snark said:

How do you have them implemented?  Is it using ModuleToggleLED from IndicatorLights?

Just so you know:  I'm currently re-working some of the interior plumbing of IndicatorLights, such that the next update (possibly this weekend, we'll have to see how much time I have) is likely to be a breaking change for that one module.

 

Actually for now it's just a ModuleAnimateGeneric, but I can always look into ModuleToggleLED as well. I'll wait on that until after you have that rewritten.

 

 

[Snark]

29 minutes ago, NecroBones said:

Actually for now it's just a ModuleAnimateGeneric, but I can always look into ModuleToggleLED as well. I'll wait on that until after you have that rewritten.

Ah, okay, that makes sense.  Actually, if all you're doing is toggling between two states that are hard-built into the part ("on" and "off", one color), it would probably make more sense to use ModuleAnimateGeneric, since that's stock.  The only reason to take an IndicatorLights dependency for something like that would be if you wanted custom behavior (changing colors, varying brightness, blinking or other cyclic animations, dynamic ties to ship state, etc.)

Just wanted to make sure I wasn't about to yank the rug out from under you. 

[Snark]

PSA:

• The KSP 1.1.2 patch that just came out broke ModuleManager.
• sarbian has released ModuleManager 2.6.24 for compatibility with 1.1.2.
• This means that any mods that depend on MM (such as this one) will be broken until you're updated to ModuleManager 2.6.24 or later.

 

What this means to you:

• If you've updated KSP to 1.1.2, then most of IndicatorLights' functionality will be broken for you until you update ModuleManager.
• You can get an updated version from the link above.
• When I next update IndicatorLights, I'll include the updated version of ModuleManager that's KSP 1.1.2 compatible. So if you're reading this after IndicatorLights 0.5 comes out, never mind. 

 

[Starbuckminsterfullerton]

On 4/28/2016 at 5:31 PM, Snark said:

In any case, even though I haven't completely decided how I'm going to deal with science instruments, they're certainly on my list of areas I'd like to cover.

One piece of functionality I'm considering (for parts that are potentially useful with lights, but have the potential to annoy people who don't want 'em) would be a "show indicator" option in the vehicle editor, which if turned off would hide the indicator lights for that part.

Yep, that's on my list, too.  Would be nice to have some different modes so that people could make them look like, say, navigation lights for example.

The main question is how to factor the UI for it.

Glad to hear that!

Option to hide indicator sounds like the perfect solution, as long as you have that it doesn't matter how many things have lights on them. 

UI wise an interval length and pulse length slider under the RGB would cover everything. 0 interval length creates a steady light. 

[veryinky]

Would it be possible to have indicator lights on docking ports? Like the docking collar lights from Necrobone's Modular Rocket Systems, but directly applied to the 0.625, 1.25 and 2.5m docking ports?

Spoiler

If there's anything that I've wished had indicator lights it's docking ports to help with docking alignment when the target ends up on the dark side of a planet. I usually end up putting a bunch of batteries around them for the little green lights.