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

[Snark]

17 minutes ago, KerbOrbiter said:

Wow! Nice continuation of @pizzaoverhead's idea 

You're talking about BatteryIndicator, which actually I had never heard of until I posted this mod and someone mentioned it.

It's worth noting that this is not a "continuation" of that idea-- aside from the fact that I'd never heard of it, my own mod is implemented differently.

Interestingly, the ironic part is that that mod mainly works with the Z100 battery (because it has a light on it already) ... and having that little light already is precisely why the Z100 battery was such a royal pain in the posterior to get working in my own IndicatorLights. 

Technical mumbo-jumbo that's only of interest to modders placed in a spoiler section.  The TL;DR is that the internals of my mod work somewhat differently from BatteryIndicator.

Spoiler

The problem is that my mod works specifically with emissive shaders, and the Z100's lamp is actually not an emissive shader-- it's an unlit one, which is different.  So to get it to work in my own mod, I basically had to hack it:  I made a little lamp that's exactly the same shape as the stock Z100's lamp, but just an invisibly tiny smidgeon bigger, and then use it to "cap" the other one and hide it from view.

The difference between an "emissive" shader and an "unlit" one:

• An emissive shader has a "glow" color that can be on or off; setting the color to "black" doesn't make it black-colored, it just turns off the glow.  The important thing is that such a color isn't just a glow.  It still has a regular color that's there when the glow is off.  (In other words, when you turn a lightbulb off, it has a "native" gray color and looks like a normal object-- it doesn't turn into a black "hole in the universe".)  When you see KSP engines glow when they get hot, what you're seeing is an emissive texture.
• An unlit shader is much simpler:  you assign it a color, and that's the color that it's drawn on the screen.  It completely ignores light and shadow conditions, just draws in that color.

Lights that use emissive versus unlit textures look pretty similar when they're turned on.  It's when they're turned off that you see the difference.  You'll note that in BatteryIndicator, when the light gets turned off, it doesn't look like an extinguished lightbulb-- it actually turns inky dark black.  Whereas in IndicatorLights, turning the light off just makes it look like a  normal, dull-gray object that responds to the lighting conditions around it.

 

 

[KerbOrbiter]

16 minutes ago, Snark said:

-snip-

Thanks for explanation

May I request a LED that is smaller and more bubble-ish, like Z100's or Z400's?

[Snark]

16 minutes ago, KerbOrbiter said:

Thanks for explanation

May I request a LED that is smaller and more bubble-ish, like Z100's or Z400's?

I assume you mean, as a standalone part that you can toggle on/off, like the BL-01 that's currently in the mod?

Yes, I'm definitely going to be adding a variety of shapes and sizes of lights like that.  Right now I'm focusing on expanding the functionality to cover the bases, i.e. indicator lights that work for a variety of different uses.  The problem is that there are just too many nifty things to add, it's hard to pick which to do first.  I guess it's a nice kind of problem to have. 

Anyway, yes, I'll definitely be providing some small lights like that, it just might be a little while before I get to them, since I have other stuff I'd like to add first.  Haven't completely settled on which thing comes next, but I'm kind of leaning towards occupancy indicators for crewed parts.

[Starbuckminsterfullerton]

2 hours ago, Snark said:

You're talking about BatteryIndicator, which actually I had never heard of until I posted this mod and someone mentioned it.

Interestingly, the ironic part is that that mod mainly works with the Z100 battery (because it has a light on it already) ... and having that little light already is precisely why the Z100 battery was such a royal pain in the posterior to get working in my own IndicatorLights. 

I always liked that mod, but never used it because there was only one battery with a light, so what you've done here is great.

Like you say, there are a lot of potential applications for emissive-only lights.  Performance friendly nav lights might be well received. 

You say you have plans for more stock parts, and you mention helping other modders hook in to this, but have you thought about building in some third party compatibility? RLA and NFE in particular add a lot of stockalike electrical parts that fit in perfectly with what you already have, could an MM patch add existing indicator assets to other mod parts?

Edited April 24, 2016 by Starbuckminsterfullerton

[Snark]

23 minutes ago, Starbuckminsterfullerton said:

Like you say, there are a lot of potential applications for emissive-only lights.  Performance friendly nav lights might be well received.

Can you describe what you mean by "nav lights"?  If it's just "a thing that lights up in a desired color, and can be activated via action groups", then the mod basically already has that now.    It would be pretty easy to add blinking as an option to the light, and I'll certainly be adding additional form factors besides the little BL-01 that's in there now.  Can you describe what the requirements would be for something to be useful as a nav light?

26 minutes ago, Starbuckminsterfullerton said:

You say you have plans for more stock parts, and you mention helping other modders hook in to this, but have you thought about building in some third party compatibility? RLA and NFE in particular add a lot of stockalike electrical parts that fit in perfectly with what you already have, could an MM patch add existing indicator assets to other mod parts?

Wall of text is below, but the TL;DR is:  Yes, MM patch could add, and yes, I've thought about adding third-party compatibility once I'm done adding major functionality to the mod.

Okay, here's the verbose part with technical details.  Putting in a spoiler section because it's probably only of interest to modders.

Spoiler

Yes, I've thought about it.  It's on the "future horizons" part of my plans.  I figure, get the functionality and my own parts added first, make sure to be modder-friendly while doing so, and then after it's more or less "complete," start adding in third-party compatibility patches (or approach mod authors to see if they'd like to put the patches there).

The way I've designed it, it's very easy to add indicator assets to other mods' parts with just MM config.  Here's what's available to work with:

• A set of indicator models (.mu), located in the /Meshes subfolder of IndicatorLights, which can easily be placed on any other part's model.  This is exactly what I do when I mod stock parts such as batteries and fuel cells, for example.  Just do the exact same thing to the other mod's part.  (Or if the part already has an emissive texture on it, you can use that, don't even need to add an indicator mesh.)
• A set of controller modules that can take input from some aspect of the part they're on, and use that to control the lighting.  I currently have the following controllers available (and will be adding more):
  • ModuleToggleLED:  This is what the BL-01 uses.  Manually controlled light with action groups. Colors customizable in the editor.
  • ModuleResourceIndicator:  This is what I use on batteries.  Works for any resource container.  Color-coded light based on how full it is, with animations (pulsating for almost-empty, blinking for disabled).
  • ModuleConverterIndicator:  This is what I use on fuel cells.  Works for any resource converter. Simple on/off light that indicates when the converter is active.

So, to enable lights on any arbitrary mod part, for any supported type of control, it just needs ModuleManager config to do this:

1. Add an indicator mesh to the part, if it doesn't have a usable emissive piece already.
2. Add a ModuleControllableEmissive pointing at that emissive bit.
3. Add a controller module (as described above) pointing at the ModuleControllableEmissive.
4. Profit!

The only thing that would prevent adding an indicator for a given purpose would be if it's for some type of control that isn't supported by any of the controllers included in IndicatorLights.  However, by the time I'm "done" with IndicatorLights, I expect to have controllers for just about every common type of indicatable status that the stock parts have, so that will cover a pretty broad swath of potential functionality.  And even if you've got some really exotic part that has no stock equivalent for its actions, there may be some possibilities there (which I won't go into at the moment because I haven't fully designed them in my head, but I have some ideas about it.)

 

[Starbuckminsterfullerton]

11 minutes ago, Snark said:

Can you describe what you mean by "nav lights"?

Okay, here's the verbose part with technical details.  Putting in a spoiler section because it's probably only of interest to modders.

I think you pretty much covered it, all the functionality for a navigation light is already there (although blinking would be cool I hadn't even thought of that), just need a form factor that fits on the end of a wing.  If you're aiming to make a part specifically for use as a nav light, you could model it so that the emissive is only visible from the correct angle, but that might cross the line from 'bonus functionality' to 'new feature'. 

Thanks for taking the trouble to provide technical details, I might write some patches.

[Snark]

8 minutes ago, Starbuckminsterfullerton said:

Thanks for taking the trouble to provide technical details, I might write some patches.

Quite welcome!  If you make some interesting patches, post them here?  Would love to see them. 

Also, be advised:  IndicatorLights is still a pre-release, I'm expanding the functionality rapidly and making it up as I go along, so it's possible there could be mod-breaking changes if you've made patches that use it.  Once I declare it "released", then it'll be reliably stable and won't break backwards compatibility.

Not that I plan on making breaking changes, and in general I try not to (in particular, I'm trying to design it carefully as I go along so that I can try to minimize the chance that I'll need to do so)... but I can't promise that I won't.

[Vorg]

Lights for electrical/electronic parts, good idea, I like it. For engines, maybe green for active, red for active but starved and blue for active but throttled. Not active, no light.

But for parts like tanks? don't see a point to it.

[Snark]

30 minutes ago, Vorg said:

For engines, maybe green for active, red for active but starved and blue for active but throttled. Not active, no light.

I thought about that, but I'm not sure how useful it would actually be to people. One thing I want to be careful about is not to turn the ship into a Christmas tree with little colored lights all over everything all the time.  Too many indicator lights = distracting, bad.  So I'd like to avoid putting lights on things that don't necessarily need them-- or, at the very least, if I do put them on something that may not need them so much, make it toggleable via an option or something.

In the particular case of engines, they already have a pretty good indicator:  just look at the fuel bars next to the engines in the staging display.  Given that that display exists, I think it's somewhat marginally useful to add indicator lights to engines, and likely doesn't pass the less-is-more test.

I'd be more likely to do something like make a separate part that can be an indicator, and provide some way to tie that to an engine, so that if a user especially wants blinkenlights that show engine status, they can place the lights how and where they want them.  But that's a low-priority feature at the moment, I've got other stuff to do first.

35 minutes ago, Vorg said:

But for parts like tanks? don't see a point to it.

Frankly, I agree with you, at least as a standard, put-it-on-everything type of solution, which is why I haven't done it. 

But I could see it being useful in certain cases for certain people, like the engine status mentioned above.  So I may eventually look at some easy-to-use, optional solution that would allow people to have this if they want it, without getting in the way of the probably large majority who don't.

[Jacke]

2 hours ago, Snark said:

Can you describe what you mean by "nav lights"?  If it's just "a thing that lights up in a desired color, and can be activated via action groups", then the mod basically already has that now.    It would be pretty easy to add blinking as an option to the light, and I'll certainly be adding additional form factors besides the little BL-01 that's in there now.  Can you describe what the requirements would be for something to be useful as a nav light?

Here's some information to help you decide what to do about putting nav lights in Indicator Lights.  Wikipedia has a good page on Navigation Lights.

https://en.wikipedia.org/wiki/Navigation_light

The current best mod for this is Aviation Lights.  I've used it for a while.  The lights in the package are sources of illumination, at least at short range.

@MOARdV has recompiled the plugin for KSP 1.1.  I think he may be maintaining the mod in the future (it's very static and doesn't need much attention between KSP version upgrades) but I'm not sure.

 

[Reiver]

1 hour ago, Snark said:

I thought about that, but I'm not sure how useful it would actually be to people. One thing I want to be careful about is not to turn the ship into a Christmas tree with little colored lights all over everything all the time.  Too many indicator lights = distracting, bad.  So I'd like to avoid putting lights on things that don't necessarily need them-- or, at the very least, if I do put them on something that may not need them so much, make it toggleable via an option or something.

In the particular case of engines, they already have a pretty good indicator:  just look at the fuel bars next to the engines in the staging display.  Given that that display exists, I think it's somewhat marginally useful to add indicator lights to engines, and likely doesn't pass the less-is-more test.

I'd be more likely to do something like make a separate part that can be an indicator, and provide some way to tie that to an engine, so that if a user especially wants blinkenlights that show engine status, they can place the lights how and where they want them.  But that's a low-priority feature at the moment, I've got other stuff to do first.

Frankly, I agree with you, at least as a standard, put-it-on-everything type of solution, which is why I haven't done it. 

But I could see it being useful in certain cases for certain people, like the engine status mentioned above.  So I may eventually look at some easy-to-use, optional solution that would allow people to have this if they want it, without getting in the way of the probably large majority who don't.

Would tank indicators be generic, or fuel-specfic? Generic would be handy in unusual places - tracking food supplies, or ore content, as opposed to simply LFO.

[Snark]

Just now, Reiver said:

Would tank indicators be generic, or fuel-specfic? Generic would be handy in unusual places - tracking food supplies, or ore content, as opposed to simply LFO.

There are basically two ways to do tank indicators.

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.)

Other than batteries, I can't think off-hand of any type of tank I'd want to make an indicator be present by default (I really don't want my ships lit up like Christmas trees).  But I do have in mind to implement the general-purpose, attach-anywhere sort of indicator at some point.  I'm leaving it for later because it's more complex to implement (have to muck around with symmetry groups and so forth).

[Godot]

Great ... actually since encountering such an LED-Light feature in Empyrion, I was wondering if such a feature could be implemented in KSP as well.

Your mod is the answer to this question

[jpinard]

Dang Snark - I can't believe you did the battery lights already!

I agree with no tank indicators.  Maybe the only one would be RCS because in that case you're always focusing on the ship/individual itself and not the "big picture" for launch and orbit.  And that's why I suggested the battery indicators in the first place because it's not just eye candy, but is also a crucial gameplay element.  For those of us that suck at the game still, those battery indicators (and maybe RCS) will be kerbal and prove life savers.

Now I hate to even ask this... but had you considered (is it even possible) to do a slightly more subdued shade of red/yellow?  As it stands it is maybe a tad too festive.  The green works, and as soon as we see that beautiful bright green go away we know we've electrical drain issues to attend to so the brightness would not be quite so critical (in others words if it takes our eyes 1/10 of a second instead of 1/1000 of a second to see the state we will be OK, but of course the the two colors will still be necessary).  Does that make sense?  Also, I don't know if you are up for this, but wow would I love to use those ASAP.

I also agree with not using square lights.  It's probably the anti-aliasing in your screenshot so maybe it looks a lot better on ship, but compared with the other lights a circular or even oval one would look better.

[Beetlecat]

Okay -- I may have figured out why the lights were showing black (the nose and mouth on the far bug should be colors) -- Texture Replacer. I think there's a simple way to force it to exclude your items. It also could be buggy in a not-quite fully 1.1 state as well as I see some other props showing up with solid black models in the craft editor.

The battery indicators on the craft in the foreground *do* work, however. They aren't glowing above because I still had ver .2 installed.

Edited April 25, 2016 by Beetlecat

[Snark]

11 hours ago, jpinard said:

Dang Snark - I can't believe you did the battery lights already!

Heh, you're welcome. 

11 hours ago, jpinard said:

Now I hate to even ask this... but had you considered (is it even possible) to do a slightly more subdued shade of red/yellow?  As it stands it is maybe a tad too festive.  The green works, and as soon as we see that beautiful bright green go away we know we've electrical drain issues to attend to so the brightness would not be quite so critical (in others words if it takes our eyes 1/10 of a second instead of 1/1000 of a second to see the state we will be OK, but of course the the two colors will still be necessary).  Does that make sense?  Also, I don't know if you are up for this, but wow would I love to use those ASAP.

No, that's a totally reasonable point, and I'd actually thought of it myself.  In fact, the yellow and red are already toned down a bit from max brightness, for that very reason.  I could perhaps tone them down some more.

The basic problem is that if I make the lights too much dimmer, they'll become almost impossible to see when they're in sunlight.

What you really need is "apparent brightness", which is not just the brightness of the indicator light itself, but its contrast with what's around it.  I even thought about adding some code to auto-detect "is the ship currently in daylight", and adjust the brightness according to that (it wouldn't be all that hard to code)-- except that even that wouldn't really solve the problem, because when you are in daylight, half the ship is typically in dark shadow, and there's no easy way to account for that.

I also thought about possibly adding some sort of animation (pulsating, blinking, whatever) for the non-happy-green cases... but that can get really annoying and distracting to people who don't like it, so I'm trying to keep that sort of thing on an absolute-bare-necessities-only basis.  I've added pulsating to the extremely-low-charge case, which I think is about the limit of what's reasonable.  So I plan on sticking to constant uniform brightness.

That said, I could probably crank 'em down a notch more.

Another thing I plan on doing is making the "base colors" (i.e. the high, medium, and low colors, currently green / yellow / red) configurable via ModuleManager, rather than hard-coded as they are now.  That way, if you don't like the default brightness settings, all you'd have to do would be to add a single snippet of MM config to adjust the brightness levels of whichever parts you wanted to tinker with.

(Such a feature is important not just for brightness issues such as you mention, but also to be friendly to color-blind people who may have trouble distinguishing red from green-- let folks pick whatever colors work for them.  A surprisingly large percentage of the population has some form of color blindness.  It's an important UI design principle never to make color the only indicator of crucially important information, particularly if the color is hard-coded and not user-settable, and especially if the colors involved are red and green, which are the most commonly problematic colors for folks with such issues.)

 

11 hours ago, jpinard said:

I also agree with not using square lights.  It's probably the anti-aliasing in your screenshot so maybe it looks a lot better on ship, but compared with the other lights a circular or even oval one would look better.

(Not sure about the "also agree" comment-- has someone else mentioned this?  Apologies if I've missed this, but I've been reading back through the thread and haven't been able to find any prior references to the issue.)

I'll be giving the various lamps and such a cosmetic pass later on; the modeling is currently very crude, given my limited skills with Blender.  I actually prefer the square look for indicators on the rims of disks, it just seems to "fit" better aesthetically.  But any cosmetic tinkering with that will have to wait until I'm done with the major functionality, unless there's a major chorus that the current implementation is unusably bad.  I'm just excruciatingly slow and awkward at modeling, relative to coding (can bang out hundreds of lines of code in the time it takes me to model and import one very small, rudimentary part)-- it's hard to convey just how badly I suck at that.  So I'd really rather get the thing up-and-working-with-cosmetic-rough-edges before circling back to address fit-and-finish.

[jpinard]

Nice Tardigrade Snark

I think you've got everything nailed.  If the pulsing looks too hectic with "on-off-on-off" like a turn signal blinker, then I'd go for a tempo of:  ooofffffff on oooffffff.  This would give it a more airplaney strobe light kind of sensation that would fit style.

If I use your mod in its current alpha/beta state (not assigning anything special) can it break my save game?  I'm too eager and want to get your awesome new batteries running.  Am I assuming correctly that they will now be stock with lights and I won't have to do any special action group things?

Edited April 25, 2016 by jpinard

[Snark]

8 hours ago, Beetlecat said:

Okay -- I may have figured out why the lights were showing black (the nose and mouth on the far bug should be colors) -- Texture Replacer. I think there's a simple way to force it to exclude your items. It also could be buggy in a not-quite fully 1.1 state as well as I see some other props showing up with solid black models in the craft editor.

Thanks for the heads-up!

I glanced at the main post for TextureReplacer, but there was nothing that immediately jumped out at me as "here's how to make it ignore your parts."  (Doesn't mean there isn't one, just that I couldn't find anything obvious in a minute or two of hunting around.)

Unfortunately, I simply have no bandwidth for chasing down this sort of issue (particularly since I don't use TextureReplacer myself).  What with having a day job and other IRL issues, I have my hands completely full just trying to get IndicatorLights basically working, and really don't have any time to chase down the O(N²) potential interactions with other mods, at least not until primary development of IndicatorLights is done.

On the other hand, if somebody else could figure out how to address this issue, and spoon-feeds the solution to me, then I'd be happy to include it.  Hint, hint.    (My definition of "spoon-feed" includes:  1. specific repro steps so I can observe the bug myself, and 2. a snippet of MM config or whatever to address the problem, ideally with a reference to documentation about the issue.)  Without something like that, frankly it's likely to be a long time (read: "possibly never") before I get around to addressing the matter.  It's not that I don't care, just that I simply don't have unlimited time.

[Snark]

1 hour ago, jpinard said:

I think you've got everything nailed.  If the pulsing looks too hectic with "on-off-on-off" like a turn signal blinker, then I'd go for a tempo of:  ooofffffff on oooffffff.  This would give it a more airplaney strobe light kind of sensation that would fit style.

Fortunately, the fact that IndicatorLights implements all color changes directly in code (rather than using Unity animations built into the parts) means that it's easy to customize the behavior exactly how I like it.  I currently have two kinds of animations programmed, which may be sufficient for everything.  One is blinking (with a customizable period:  "N milliseconds on, M milliseconds off"), the other is pulsating (smooth fade between two colors, with customizable period and color selection).

Blinking is much more attention-grabbing than pulsating is.

My general philosophy will be to try to keep blinking to a minimum, since it has the potential to seriously annoy people.  I plan to reserve it only for the following situations:

• deliberate user choice (e.g. "I want this lamp to blink when I turn it on")
• a definite indicator of something wrong that needs the player's attention (e.g. "hey! your science lab can't research because it's filled up its science buffer!")
• fairly infrequent and user-controllable situations (e.g. disabled resource containers such as batteries)

Pulsating is much "gentler" than blinking, and I can be a little more liberal with it.  I think it's still important not to go overboard, but there are situations where I think pulsating is okay even when blinking is not.  For example, I'm currently using it for "critically close to empty" for the battery indicators-- get a battery below 3% charge and you'll see what I mean.

 

1 hour ago, jpinard said:

If I use your mod in its current alpha/beta state (not assigning anything special) can it break my save game?  I'm too eager and want to get your awesome new batteries running.  Am I assuming correctly that they will now be stock with lights and I won't have to do any special action group things?

Details below, but the TL;DR is that generally, you should be okay.

Caveat:  I'm addressing you as a player here, not as a modder.  I really, really want to not break people's save games, and I will give that top priority.  I would prefer not to break modders, either (i.e. if someone writes a mod that depends on IndicatorLights, I would prefer not to break their mod), but as long as IndicatorLights is still in pre-release, I can't promise that.  For any modders that may be reading this, I'll include a "For modders only" explanation in a spoiler section at the end of this post.

So, you're a player, and you're worried about breaking a save game, and you're interested in IndicatorLights.   There are two categories of potential issues to be aware of:  modifications to stock parts, and new IndicatorLights parts.

Regarding modifications to stock parts (for example, indicator lights on stock batteries, that sort of thing):  You're completely safe, there.  For example:  Install IndicatorLights, and open up a pre-existing save.  All your batteries for your already-launched ships will magically have indicators on all their batteries.  Now uninstall IndicatorLights.  All the indicators go away, but the ships are otherwise unaffected.

The reason it's completely safe is that it doesn't actually touch your save file.  All of the modifications to existing parts are purely run-time ModuleManager tweaks to the parts themselves, and don't have any persistent data that's actually written to your save file.  You could crack open your .sfs game or your .craft ships, and you'd be completely unable to tell whether IndicatorLights is even installed, because it doesn't write anything there, for the stock parts.

Regarding the new, standalone IndicatorLights parts (currently just the BL-01, but I'll be adding more):  These ones do have a presence in your save file, so like any parts pack, there's the potential for save-game breakage if the author (i.e. me) makes some really incompatible change (like deleting a part) after you've already launched ships that have that part on them.  Therefore, there's a bigger onus on me to be careful about that sort of thing, and a greater risk to you (i.e. you're at my mercy, if I screw up and accidentally break something; basically, you have to trust me to be both virtuous and vigilant).

I can say there that you ought to be fairly safe.  I really want to avoid the possibility of breaking people.  That's one of the reasons why I'm waiting until relatively late in the mod-development cycle to add a bunch of new parts, because I have to be mindful that once I've released a part out into the wild, folks are gonna be using it in their saves and I'll then have to worry more about breaking people if I touch it.  The times when I'm more likely to need to tinker with things are in the early stages, since I'm making all this up as I go along and things are in a much greater state of flux.  So I'll likely wait until things have stabilized pretty well before adding a bunch of parts.

That said:  the BL-01 is currently pretty minimal, and although I'll likely add some new functionality to it at some point (which would be harmless to you), I don't anticipate taking away or changing the existing functionality (which would be potentially save-breaking), so it ought to be safe for you to use.

So, the bottom line for you:  you should be fine. 

Okay, now the promised advice for modders who may be thinking of taking a dependency on IndicatorLights in their own mods:

Spoiler

From a modder's perspective, IndicatorLights provides the following assets that may be of use to you:

• A set of indicator meshes in the "/Meshes" subfolder of IndicatorLights, which you can use for decorating your parts, if you like.  (They're just there for convenience-- you don't have to use them.  As long as your part has a mesh somewhere on it that has an emissive shader, you can use that.)
• A set of PartModules for specifying and controlling the behavior of the emissive light.

In general, I will try not to break you, where possible-- that is, I'm proceeding on the assumption that with each new pre-release version of IndicatorLights, there may be other mods that were based on the preceding version, and I'll generally make a good-faith effort not to break such mods.

However, since I'm still actively coding and rearranging things, I can't guarantee that I won't break your mod, at least not while I'm in pre-release.  During pre-release, "get the architecture of IndicatorLights right" takes a higher priority than "make sure that I couldn't possibly break any other mod ever", so I'll make changes for the greater good of IndicatorLights (including breaking ones) if I feel they're necessary.

(Once I'm out of pre-release and declare 1.0, then that rule will change, and the priorities will be swapped.)

So, I do encourage you to write mods that use IndicatorLights-- I would love for folks to do this, I want my mod to be as useful as possible to people, and if lots of modders use it, then that's fertile ground for me to receive feature requests and usability improvements and such.  But I do have some recommended best practices while IndicatorLights is still in pre-release:

• First and foremost, let me know if you're releasing or pre-releasing a mod that has any dependency on IndicatorLights.  I'll be happy to add a link to your mod in my thread post.
  • Reason why this is a good idea:  If I know who's using IndicatorLights in their mods, I can coordinate better.  If I'm considering making a change that might break folks, I can contact them to ask how they're using it, so as to better determine potential breakage.  I can issue warnings in advance, before making the change, so that people have a chance to get prepared.
  • It also helps me gauge just how cautious I need to be, based on how heavily (or not) IndicatorLights is getting used.  If I know that lots and lots of people are using it in their mods, then I'll know to devote a lot more caution to making potentially mod-breaking changes.  Whereas if it turns out that nobody's using it at all, then I can just do whatever the heck I want. 
• Second, at least during pre-release I would recommend that you take a soft dependency via ModuleManager, rather than a hard dependency with modules integrated directly into your parts.
  • In other words:  Design your parts so that they work just fine without IndicatorLights, it's just that they happen to not have any indicator-light functionality on them without it.  Then add some ModuleManager config to add in the IndicatorLight functionality, the same way that I've modded the stock parts (here's an example of how I modded a battery); the only difference is that your MM config will have a "NEEDS[IndicatorLights]" in it so that it'll only apply when my mod is installed.
  • Put another way:  treat IndicatorLights as an optional "patch" to your mod, and include the patch with your mod.
  • That way, not only do your users have the option of playing without IndicatorLights if they don't want the extra dependency, but also, the worst possible scenario if I screw up and break something is that I simply break the lights on your parts, rather than breaking your mod's savegames or whatever.

I hope I've addressed any potential concerns-- please let me know if you have questions!

 

[jpinard]

What an awesome response.  My life would be so easy if everyone had such an amazing grasp of high/low personage discussions.  Once again, it is great to see you have really honed in on exactly what I was hoping to hear.  Basically stock working that will look great, not be annoying, and will really help people.  Can I please replace all my crazy anti-science, anti-logic relatives with you?

Edited April 25, 2016 by jpinard

[Beetlecat]

2 hours ago, Snark said:

Thanks for the heads-up!

I glanced at the main post for TextureReplacer, but there was nothing that immediately jumped out at me as "here's how to make it ignore your parts."  (Doesn't mean there isn't one, just that I couldn't find anything obvious in a minute or two of hunting around.)

Unfortunately, I simply have no bandwidth for chasing down this sort of issue (particularly since I don't use TextureReplacer myself).  What with having a day job and other IRL issues, I have my hands completely full just trying to get IndicatorLights basically working, and really don't have any time to chase down the O(N²) potential interactions with other mods, at least not until primary development of IndicatorLights is done.

On the other hand, if somebody else could figure out how to address this issue, and spoon-feeds the solution to me, then I'd be happy to include it.  Hint, hint.    (My definition of "spoon-feed" includes:  1. specific repro steps so I can observe the bug myself, and 2. a snippet of MM config or whatever to address the problem, ideally with a reference to documentation about the issue.)  Without something like that, frankly it's likely to be a long time (read: "possibly never") before I get around to addressing the matter.  It's not that I don't care, just that I simply don't have unlimited time.

Cool beans -- I'm now realizing I was probably thinking of Active Texture Management when thinking there's a way to "whitelist" your parts. I'm less clear on what TextureReplacer is doing. Hopefully someone can help figure this out.

[Jacke]

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

2 hours ago, Snark said:

Regarding the new, standalone IndicatorLights parts (currently just the BL-01, but I'll be adding more):  These ones do have a presence in your save file, so like any parts pack, there's the potential for save-game breakage if the author (i.e. me) makes some really incompatible change (like deleting a part) after you've already launched ships that have that part on them.  Therefore, there's a bigger onus on me to be careful about that sort of thing, and a greater risk to you (i.e. you're at my mercy, if I screw up and accidentally break something; basically, you have to trust me to be both virtuous and vigilant).

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).

Edited April 25, 2016 by Jacke

[Snark]

5 minutes ago, Jacke said:

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).

Oooh, nice one!  Didn't know about that.  Thanks, I'll add that to my bag o' tricks.

[NecroBones]

30 minutes ago, Snark said:

Oooh, nice one!  Didn't know about that.  Thanks, I'll add that to my bag o' tricks.

 

What I did for the deprecated parts in FTP was to set both the category and the tech node to "-1". That seemed to work pretty well too.

[NecroBones]

 

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?