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

[Snark]

2 hours ago, mikerl said:

I was messing around with changing the color on the BL-01 in the VAB when i realized I was changing the color of it when off.  I noticed that I could then give it two different colors based on on\off.  Not sure if this is intended

Yes, it is. 

2 hours ago, mikerl said:

it gave me an idea for a simple fuel indicator that could be green when on. and red when off when the tank is empty.  I'm not sure if the BL-01 can be set up to do this.

The BL-01 can't do that, because all of the controllers I've currently implemented only look at modules on the same part (though that may change in the future, I have some ideas).

However, you can fairly easily mod the stock fuel tanks to show indicators like that, it just takes some ModuleManager config.

If you look at IndicatorLights' config for the Z-1K battery, you'll notice that it has a ModuleResourceLevelIndicator and a ModuleResourceEnabledIndicator on it.  You can add the same kind of indicator to a fuel tank.  If you're using an LFO tank, you'll need to provide a bit more information to those modules, to let them know which resource to track (LF or O)-- the battery doesn't need to do this, since it only contains one resource.  For example, if you wanted your indicator to track liquid fuel, you'd do like this (note the added resourceName field):

MODULE {
    name = ModuleResourceLevelIndicator
    resourceName = LiquidFuel
}

MODULE {
    name = ModuleResourceEnabledIndicator
    resourceName = LiquidFuel
    enabledColor = ModuleResourceLevelIndicator
    disabledColor = blink(ModuleResourceLevelIndicator, 900, $Off, 300)
    emissiveName = indicator
}

...you get the idea.  You'd need to adjust the positions of the indicators themselves (the "MODEL" blocks in the config) based on the size and shape of the fuel tank.

[mikerl]

I knew your mod could do that, should've guessed it wouldn't be as easy as put one on the tank.  I wanted to do this to help with fuel flow tracking, although i think 1.2 might help with this.  Great mod though, really does so much under the hood.

[Jiraiyah]

Hello sir

Can we ask for some mod support? Impossible Innovations has two batteries that after I saw what is their capacities, I decided to remove every stock battery from my game folder to reduce the part count, can you please support those two batteries? one is named II-batPack that is a radial mount battery, and the other one is called II-stackBattery that is a stackable battery. this second one is much like normal stock batteries that can stack but the other one is custom modeled. I would appreciate if you would support these two batteries or at least give me a code to use as module manager patch for them. thanks

[Snark]

32 minutes ago, Jiraiyah said:

Can we ask for some mod support? Impossible Innovations has two batteries that after I saw what is their capacities, I decided to remove every stock battery from my game folder to reduce the part count, can you please support those two batteries? one is named II-batPack that is a radial mount battery, and the other one is called II-stackBattery that is a stackable battery. this second one is much like normal stock batteries that can stack but the other one is custom modeled. I would appreciate if you would support these two batteries or at least give me a code to use as module manager patch for them. thanks

Unfortunately, I don't really have the time to do 3rd party module support myself (fiddling with it to get the indicator placement just so takes time), particularly when it's a mod I don't use myself.  However, it's pretty straightforward to add ModuleManager code to mod it yourself.

If you have a stack battery that's a cylinder that's one of the standard KSP sizes, you can just copy the config from one of the existing batteries in IndicatorLights, and I expect it'll likely work:

• 0.625m:  Z200 battery config
• 1.25m:  Z1K battery config
• 2.5m:  Z4K battery config

...basically, just copy the relevant .cfg file to a new file with some name of your own, then change the part name in the @PART[...] line at the top of the file to be whatever the part name is of the battery you're modding.

If you've got a battery that's custom-modeled, then you'll need to do some tinkering to get indicator placement how you like it.  I have no clue what that might look like (no idea what the battery's appearance is), but if you can find one of the stock IndicatorLights batteries which has an indicator placement that's at least approximately like what you'd want, you can do the same deal with copying the .cfg, except that then you'll have to do some trial-and-error tinkering to get the indicator placement just so.

Sorry I can't be of more assistance-- basically, I've got my hands full just keeping IndicatorLights itself up-to-date, adding features, etc.  I simply don't have the bandwidth to keep up with other mods' models.

Hope this helps!

[Jiraiyah]

No worries, the stack one is just a duplicated model from the stock part with tweaked configs, but for the radial one, I was thinking more in the lines of adding a little vertical strip to it, here is it's picture :

Can you at least guide me to any possible config you may have for adding a vertical or horizontal strip light to this one? because as you can see the texture has a nice placeholder for vertical charge indicator that we could easily replace with a model light, i hope there is at least a model like that to be used, then i can easily sit and fiddle with numbers to find a proper setting.

Edited October 3, 2016 by Jiraiyah

[Snark]

6 minutes ago, Jiraiyah said:

Can you at least guide me to any possible config you may have for adding a vertical or horizontal strip light to this one? because as you can see the texture has a nice placeholder for vertical charge indicator that we could easily replace with a model light, i hope there is at least a model like that to be used, then i can easily sit and fiddle with numbers to find a proper setting.

Ah, okay.  Technical details in spoiler section:

Spoiler

You'll need config to add some various IndicatorLights modules to the part (ModuleControllableEmissive, ModuleResourceLevelIndicator, ModuleResourceEnabledIndicator.  You can probably just crib those modules from an existing IndicatorLights stock battery patch (for example, the Z4K).

Next, you'll need config to add a mesh for the vertical strip indicator.  You can probably just re-use the squareLamp mesh included with IndicatorLights, and just apply some scaling factors to it to make it tall and skinny.  For an example, take a look at what I did with the atmosphere analyzer in the science instruments.  It's at bottom left in this screenshot (the instrument's turned sideways):

The completed config for the battery will need to have:

1. A mesh added, as described above
2. A ModuleControllableEmissive, that points at the mesh (look at the config example I give)
3. Some controller modules (see what I did with the Z4K example above)

...and that's pretty much it.  The tedious part is going to be getting the placement right for the mesh, since that involves a fair amount of trial and error unless you're a dab hand with Blender.  For example, here's what the mesh placement looks like for the atmosphere analyzer:

MODEL
{
    model = IndicatorLights/Meshes/squareLamp
    scale = 0.3, 2, 0.3
    position = 0, 0.11416, -0.30133
    rotation = 0, 180, 0
}

...you'll need to tinker with the "scale" line to get the size and shape what you want, and with the "position" line for the positioning (those three numbers are the X, Y, Z coordinates).  Try some numbers, load up KSP, see how it looks, it'll be wrong, fiddle with the numbers and restart KSP.  Repeat until it looks right.  (There's a good chance you may not have to tinker with the rotation.)

Anyway, good luck!

[Jiraiyah]

Thanks sir, That is more than enough and when i am done with it, i will inform you so that you can add the code for a patch config to have the support file added to mod  and from now, if i see any part that would get benefit from this, i may add more and more to stock and non stock files, also, I think instead of playing around with numbers, putting few minutes to learn blender's basics for me would be a better approach, i am well familiar with maya and just need to wrap my mind around the little difference in UI with blender, that should at least help me find base numbers to begin with, and in future, if you would like to add stuff to a specific part, don't hesitate to send me a pm and i will see what i can do, who knows, maybe even adding indicators to tanks would be supported in near future

[Jiraiyah]

Hi sir,

I am almost done with positioning the light on the spot, but something is wrong, the light is not respecting the battery charge level, take a look at the picture :

and here is the module manager patch i have so far :

@PART[II-batPack]:FINAL
{
	MODEL
	{
		model = ImpossibleInnovations/Parts/Utility/II-batPack/model000
	}
	MODEL
	{
		model = IndicatorLights/Meshes/squareLamp
		scale = 0.5,1.3,0.5
		position = -0.295,-0.13,-0.075
		rotation = 0,0,0
	}
	%MODULE [ModuleControllableEmissive]
	{
		target = IndicatorLights/Meshes/squareLamp
		emissiveName = indicator
	}
	%MODULE [ModuleResourceLevelIndicator] {}
	%MODULE [ModuleResourceEnabledIndicator]
	{
		enabledColor = ModuleResourceLevelIndicator
		disabledColor = blink(ModuleResourceLevelIndicator, 900, $Off, 300)
		emissiveName = indicator
	}
}

did i do something wrong or did i forgot something?

[Jiraiyah]

interesting, got it working, take a look at final code :

@PART[II-batPack]:FINAL
{
	MODEL
	{
		model = ImpossibleInnovations/Parts/Utility/II-batPack/model000
	}
	MODEL
	{
		model = IndicatorLights/Meshes/squareLamp
		scale = 0.55,1.7,0.8
		position = -0.294,-0.133,-0.075
		rotation = 0,0,-1
	}
	MODULE
	{
		name = ModuleControllableEmissive
		target = IndicatorLights/Meshes/squareLamp
		emissiveName = indicator
	}
	MODULE 
	{
		name = ModuleResourceLevelIndicator
		resourceName = ElectricCharge
	}
	MODULE
	{
		name = ModuleResourceEnabledIndicator
		enabledColor = ModuleResourceLevelIndicator
		resourceName = ElectricCharge
		disabledColor = blink(ModuleResourceLevelIndicator, 900, $Off, 300)
		emissiveName = indicator
	}
}

I thought when you would use % sign in module manager it would create the module if it was not existing?

and here is the result :

took me near an hour but was worth it, this little baby is now eye candy and 1000 electric charge in the same space normal radial battery would take for 400 electric charge? sure i will keep this  your mod is so awesome

by the way, a little suggestion, i know that you are using a very small and square texture for lights but how about something like this?

this little dot and line texture would add tons more beauty to your mod's look. would look really cool specially when changing color or flashing

[Jiraiyah]

Here we go sir, here is your compatibility patch with Impossible Innovations mod, first an eye candy for you :

Now here is the module manager patch in the spoiler, please add it to the mod if you like it

Spoiler

@PART[II-batPack]:FINAL
{
    MODEL
    {
        model = ImpossibleInnovations/Parts/Utility/II-batPack/model000
    }
    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.55,1.7,0.8
        position = -0.294,-0.133,-0.075
        rotation = 0,0,-1
    }
    MODULE
    {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/squareLamp
        emissiveName = indicator
    }
    MODULE 
    {
        name = ModuleResourceLevelIndicator
    }
    MODULE
    {
        name = ModuleResourceEnabledIndicator
        enabledColor = ModuleResourceLevelIndicator
        disabledColor = blink(ModuleResourceLevelIndicator, 900, $Off, 300)
        emissiveName = indicator
    }
}

@PART[II-stackBattery]:FINAL
{
    MODEL
    {
        model = ImpossibleInnovations/Parts/Utility/II-stackBattery/model
    }
    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.5, 0.5, 1
        position = -0.442, 0, 0.442
        rotation = 0, -45, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.5, 0.5, 1
        position = 0.442, 0, -0.442
        rotation = 0, 135, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.5, 0.5, 1
        position = 0.442, 0, 0.442
        rotation = 0, 45, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.5, 0.5, 1
        position = -0.442, 0, -0.442
        rotation = 0, 215, 0
    }

    MODULE {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/squareLamp
        emissiveName = indicator
    }

    MODULE {
        name = ModuleResourceLevelIndicator
    }

    MODULE {
        name = ModuleResourceEnabledIndicator
        enabledColor = ModuleResourceLevelIndicator
        disabledColor = blink(ModuleResourceLevelIndicator, 900, $Off, 300)
        emissiveName = indicator
    }
}

@PART[II-largePod]:FINAL
{
    MODEL
    {
        model = ImpossibleInnovations/Parts/Pods/II-largePod/Model001
    }
    MODEL
    {
        model = IndicatorLights/Meshes/nubbinLamp
        scale = 0.6, 0.6, 0.5
        position = -0.2767, 0.21, -1.2
        rotation = 15, 15, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/nubbinLamp
        scale = 0.6, 0.6, 0.5
        position = -0.0923, 0.21, -1.225
        rotation = 15, 0, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/nubbinLamp
        scale = 0.6, 0.6, 0.5
        position = 0.0923, 0.21, -1.23
        rotation = 15, -7.5, 0
    }
    MODEL
    {
        model = IndicatorLights/Meshes/nubbinLamp
        scale = 0.6, 0.6, 0.5
        position = 0.2767, 0.21, -1.2
        rotation = 15, -15, 0
    }
    MODULE {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/nubbinLamp:0
        emissiveName = indicator0
    }

    MODULE {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/nubbinLamp:1
        emissiveName = indicator1
    }

    MODULE {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/nubbinLamp:2
        emissiveName = indicator2
    }
    MODULE {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/nubbinLamp:3
        emissiveName = indicator3
    }
    MODULE {
        name = ModuleCrewIndicatorToggle
        toggleName = indicatorToggle
    }
    
    MODULE {
        name = ModuleCrewIndicator
        emissiveName = indicator0
        toggleName = indicatorToggle
    }
    
    MODULE {
        name = ModuleCrewIndicator
        emissiveName = indicator1
        toggleName = indicatorToggle
    }
    
    MODULE {
        name = ModuleCrewIndicator
        emissiveName = indicator2
        toggleName = indicatorToggle
    }
    MODULE {
        name = ModuleCrewIndicator
        emissiveName = indicator3
        toggleName = indicatorToggle
    }
}
@PART[II-strongSAS] {
    MODEL
    {
        model = ImpossibleInnovations/Parts/Control/II-strongSAS/model
    }
    
    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.5, 0.5, 1
        position = -0.442, 0, 0.442
        rotation = 0, -45, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.5, 0.5, 1
        position = 0.442, 0, -0.442
        rotation = 0, 135, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.5, 0.5, 1
        position = 0.442, 0, 0.442
        rotation = 0, 45, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.5, 0.5, 1
        position = -0.442, 0, -0.442
        rotation = 0, 215, 0
    }

    MODULE {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/squareLamp
        emissiveName = indicator
    }
    
    MODULE {
        name = ModuleReactionWheelIndicator
        emissiveName = indicator
    }
}

@PART[II-strongSASLarge] {
    MODEL
    {
        model = ImpossibleInnovations/Parts/Control/II-strongSASLarge/Model003
    }
    
    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.8, 0.8, 1
        position = 0, 0, 1.25
        rotation = 0, 0, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.8, 0.8, 1
        position = 0, 0, -1.25
        rotation = 0, 0, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.8, 0.8, 1
        position = 1.25, 0, 0
        rotation = 0, 90, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.8, 0.8, 1
        position = -1.25, 0, 0
        rotation = 0, 90, 0
    }

    MODULE {
        name = ModuleControllableEmissive
        target = IndicatorLights/Meshes/squareLamp
        emissiveName = indicator
    }
    
    MODULE {
        name = ModuleReactionWheelIndicator
        emissiveName = indicator
    }
}

 

The only things I could find useful to add your mod integration was the command pod, two batteries the pack had, and 2 reaction wheels it provided for us.

have fun

[Snark]

3 hours ago, Jiraiyah said:

Here we go sir, here is your compatibility patch with Impossible Innovations mod

Excellent, thank you!  I'll include this as a compatibility patch with the next release, as soon as KSP 1.2 releases. 

4 hours ago, Jiraiyah said:

by the way, a little suggestion, i know that you are using a very small and square texture for lights but how about something like this?

this little dot and line texture would add tons more beauty to your mod's look. would look really cool specially when changing color or flashing

I've certainly got "do prettier things with modeling" on my list of Things To Do.  However, it has to get in line behind "become a better modeler" (I'm embarrassingly bad at it-- I'm a coder, I'm really not an artist), as well as various feature implementations I'm working on.  But yes, eventually I do plan on making some stuff prettier.

[Starbuckminsterfullerton]

@SnarkI know it's early since 1.2 isn't out yet but I was wondering if you have any conceptual plans for indicator lights on the new antennas, I can definitely think of a few uses for them there. 

Edited October 4, 2016 by Starbuckminsterfullerton

[Snark]

2 hours ago, Starbuckminsterfullerton said:

@SnarkI know it's early since 1.2 isn't out yet but I was wondering if you have any conceptual plans for indicator lights on the new antennas, I can definitely think of a few uses for them there. 

Not early at all!    Heck, updating IndicatorLights for 1.2 is practically all I've been doing lately, I can't wait for KSP 1.2 to release so I can turn it loose on you guys.  I've already got the new science container hooked up so it has lights to indicate when it has science in it.

Yes, I've thought a bit about antennas.  Still thinking about it, no specific plans or decisions yet.  But yes, they're on my radar, so to speak. 

[Jiraiyah]

Hmm if you would include antena and connection settings in your modules, it opens a door for remote tech antenas too. alsi it would be nice if we could set a light to track on off situations, like rsr is on, or some solar is open. it shouldn't be that hard in code using reflection, but not sure how it would work in code for modding

regarding your lack of your modeling exp, it's ok, imo, models are fine and you should be able to rise graphic quality with better textures

Edited October 4, 2016 by Jiraiyah

[Snark]

6 hours ago, Jiraiyah said:

Hmm if you would include antena and connection settings in your modules, it opens a door for remote tech antenas too. alsi it would be nice if we could set a light to track on off situations, like rsr is on, or some solar is open. it shouldn't be that hard in code using reflection, but not sure how it would work in code for modding

Lots of possibilities with antennas, yes.  Like I said, still mulling it over.  One thing to bear in mind is that IndicatorLights is best suited for information about the part rather than about the ship-as-a-whole.  For example, "Do I have a connection for this ship" is really better suited to some sort of flight UI than it is to having a thingy on an actual part, except as pure eye-candy.  That's not to say it has to be a hard-and-fast rule, just that when I'm focusing on what to add to a part for IndicatorLights, my priority is on things that are about the part itself.

As for modding the miscellaneous stuff you mention:  KSP is very moddable.  Pretty much every PartModule has public accessors for all the interesting stuff about it, so generally reflection isn't needed.

6 hours ago, Jiraiyah said:

regarding your lack of your modeling exp, it's ok, imo, models are fine and you should be able to rise graphic quality with better textures

They go hand-in-hand.  I'm not modeling-challenged, I'm art challenged.  (Actually, I suspect I'd probably be better at modeling than texturing.  Or, a better way of phrasing it, I'd be even worse at texturing than modeling.) 

[Jiraiyah]

well, if you liked that screen shot of the electronic strip, it's part of a texture on the radial battery of impossible innovations and i don't think the mod developer mind you stripping that part of his texture to use, after all, that is part of a whole texture for the part that uses propper uv maps

I tried it myself but i am not sure how are you using your two textures (the white one and the other one) i replaced them with a higher resolution texture but they didn't show up on the lamps so i don't know how you are handling them, do they even use a texture?

Edited October 4, 2016 by Jiraiyah

[Snark]

Hi all,

Just wanted to let you know that I've released a new mini-mod called IndicatorLights Community Extensions:

There's no code in it-- it's just compatibility patches supplied by you fine folks.  Currently, it just has support for two mods:

• Ven Stock Revamp (thanks to @Kerbas_ad_astra)
• Impossible Innovations (thanks to @Jiraiyah)

See the FAQ on the new mod's thread for why I decided to package these packages separately from the main IndicatorLights mod.  The short answer is, 1. maintenance, 2. keeping clear who wrote what, and 3. license friendliness.

Regarding point #3:  This will become relevant within the next few days.  Details in spoiler section.

Spoiler

KSP 1.2 is on the verge of releasing, and when that happens, I'll be posting an update to IndicatorLights which not only adds 1.2 compatibility, but has a bunch of other stuff rolled up into it as well.  One of the changes I plan on making is to move to a more restrictive license (likely one of the Creative Commons ones), rather than the current MIT license, which is extremely permissive.  Since the community-supplied content is stuff I didn't write myself, that would make it awkward to put a more restrictive license on my mod.  I've solved this problem by keeping the community-supplied stuff separate from the stuff I wrote.  That way, I can keep a super-permissive license on the community-supplied material, without limiting what kind of license I can put on IndicatorLights itself.

In case you're wondering why I'm moving to a more restrictive license:

An issue came up within the last couple of weeks, where an enthusiastic and well-meaning person who just couldn't wait for a 1.2-compatible version of my most popular mod (BetterBurnTime) cloned my source code, patched it himself, and released it with an announcement on reddit.  I really, really don't want that sort of thing to happen-- it's a nightmare for mod authors.

Why is it a nightmare?  Because folks downloading the mod don't pay much attention to where they're getting it from, or notice the crucial distinction that "the code I'm installing isn't actually the original code".  Suppose a player downloads a version of one of my mods that some other person has patched without my knowledge or consent... and then the player hits a bug or something.  They're going to come to me with a bug report, and there will be all sorts of confusion because it's not my code but that important fact has gotten lost in the shuffle.

Basically, it boils down to this:  I'm happy for folks to download my mods for free.  I'm happy for them to copy them all over the place.  Heck, I don't even mind if they re-host them on other web sites.  However, I'm not okay with two things in particular:

1. if anyone ever tries to make money off of my mods
2. if anyone actually modifies my mods and then publicly posts the modified versions.

So that's why I'm moving to a more restrictive license.  Don't worry, I won't be going super-restrictive; just adding enough restriction that prevents the above two scenarios.

Thank you for your understanding, and I'm sorry that this has proven necessary.

Anyway, going forward, if anyone wants to supply patch content for third-party part support (or has questions about doing so), please use the other mod's thread for that purpose.

Stay tuned for the imminent IndicatorLights update!  Changelog's gonna be pretty long on this one. 

 

[Kerbas_ad_astra]

I urge you to consider the GPL rather than anything Creative Commons for code.  I've got a very long-winded post linked in my signature that goes into more detail, but here's the short version:

1. CC licenses aren't meant for software and are dubiously compatible at best with real software licenses.
2. With the GPL specifically, you can require that forks/redistributions change the name and otherwise mark revised versions as being revised and not by you.
3. Probably nobody else will actively try to make (much) money from your mods.  If you use GPL, they can't (legally) withhold any source revisions, so that means the only ways to make money are to provide some useful service...you're already giving away support and compiled object code for free, so they can't beat you there, and even if they tried, that's not a necessarily bad thing for the community.  One could theoretically set up a mod distribution website and run ads on it or the like, but you're not linking to them, so they're not going to get much traffic without investing much more effort than it's worth into building a support base.

[Beetlecat]

On 10/4/2016 at 8:14 AM, Snark said:

Lots of possibilities with antennas, yes.  Like I said, still mulling it over.  One thing to bear in mind is that IndicatorLights is best suited for information about the part rather than about the ship-as-a-whole.  For example, "Do I have a connection for this ship" is really better suited to some sort of flight UI than it is to having a thingy on an actual part, except as pure eye-candy.  That's not to say it has to be a hard-and-fast rule, just that when I'm focusing on what to add to a part for IndicatorLights, my priority is on things that are about the part itself.

I would love a random-seeming flashing/flickering indicator on antennas--similar to a modem data indicator--during antenna transfers of science.  

[Snark]

41 minutes ago, Beetlecat said:

I would love a random-seeming flashing/flickering indicator on antennas--similar to a modem data indicator--during antenna transfers of science.  

Yeah, that would be cool!    ...I have a few ideas how I might implement that. I think the tricky bit there would be the modeling.  Two problems:

1. A lot of the antennas don't exactly have a lot of open, "flat" places where it would be easy to slap on an indicator.  Where the dickens do you put an indicator on a Communotron-16, anyway? There's practically nothing there; heck, I have trouble just targeting the darn thing with my mouse.
2. Tricky to handle animations.  I've relied on parts with static models, so that I pick an X,Y,Z position and add a mesh there.  If a part animates (such as a deployable antenna), I don't know how to make a mesh that moves with the animation, which would mean I'd need to put the mesh somewhere that doesn't move, which rather limits the choices of available locations.

But yeah, would be neat.  Also, "random stuttering flicker" as a basic light animation type could be useful in general, as a tool in the eye-candy toolbox.

[DStaal]

As a random comment - those randomly flashing lights on modems and such are being slowly removed for more constant lights.  Turns out, they are a security risk.  (You can read the data flowing through the router via those lights.)

[Beetlecat]

19 minutes ago, DStaal said:

As a random comment - those randomly flashing lights on modems and such are being slowly removed for more constant lights.  Turns out, they are a security risk.  (You can read the data flowing through the router via those lights.)

Interesting, but makes total sense.

[Snark]

1 hour ago, DStaal said:

As a random comment - those randomly flashing lights on modems and such are being slowly removed for more constant lights.  Turns out, they are a security risk.  (You can read the data flowing through the router via those lights.)

Well, my mod is going to employ security techniques to ensure that nobody can read any meaningful information out of my random blinkenlights! 

[hab136]

9 hours ago, Snark said:

1. A lot of the antennas don't exactly have a lot of open, "flat" places where it would be easy to slap on an indicator.  Where the dickens do you put an indicator on a Communotron-16, anyway? There's practically nothing there; heck, I have trouble just targeting the darn thing with my mouse.

Could you put a light at the base of the antenna, centered at the middle of the antenna, but thick enough that it extends out?  The effect would wind up being that most of the light is hidden by the mast of the antenna, but a "donut" surrounds the base.

Here is my incredibly bad approximation:

[Snark]

12 hours ago, hab136 said:

Could you put a light at the base of the antenna, centered at the middle of the antenna, but thick enough that it extends out?  The effect would wind up being that most of the light is hidden by the mast of the antenna, but a "donut" surrounds the base.

Yah, that's pretty much what I was thinking.    The main question is how it will actually look if-and-when I try it out.

Just to set expectations:  the imminent KSP 1.2 compatible release of IndicatorLights won't have any antenna indicators on it, since I just haven't had time to do that yet.  It's on my list.

I have, however, gone ahead and implemented a random-flickering animation pattern (thanks, @Beetlecat, for the suggestion), which will be included in the upcoming release.  I don't actually use it with anything (yet), but at least it's there, so any third-party modders who want to play with it will have it available.  I'll be including a new "examples" directory in the github repository, with some sample .cfg files for stuff like this (i.e. not actually used in the installed mod, but serves as a guide for anyone who wants to use it).  When-and-if I do get around to implementing something with antennas, this is what I'll use.

The random-flicker blink pattern has the following parameters (settable in config):

• the "on" and "off" colors
• period (i.e. how rapidly does it flicker)
• bias (i.e. is it 50/50 on and off, on average?  or mostly on? or mostly off?  etc.)
• seed (optional parameter; allows having multiple random blinkers that are independent from each other instead of all flickering in unison)

So, for example, if something like this were used with "antennas doing data transmission", the flicker rate could be tied to data speed of the antenna, that sort of thing.