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

[Snark]

On 1/3/2017 at 8:29 AM, Snark said:

So I took a look at the Glowstrips OP, and the imgur album.

...

Anyway, it bears mulling over; gimme some time to think at it.  No promises.

Okay, folks, I've mulled it over (including spending a few hours tinkering with Blender, Unity, and IndicatorLights).

I'm sorry, but I've come to the conclusion that no, this is pretty firmly in the "will never happen" category, at least not as stated, and not in IndicatorLights itself.

Before I go into my reasons, let me summarize what you won't get, may someday get, and will get:

• You won't get glowstrips (by which I mean "long, glowing streamline decals for snazzy effects") on your ships as part of the IndicatorLights mod, ever.
• You might get glowstrips as part of a separate mod, if there's ever anyone enterprising enough to take on such a task themselves.  IndicatorLights has all the necessary hooks to allow such a mod to work.  But if someone does ever implement this... that someone will not be me.
• You will get additional IndicatorLights parts besides just the BL-01, "eventually" (i.e. when I get the time and motivation to do so; no promises about specific schedule, but probably not super soon; they're still in the "someday" category).  I've always planned to do this, and those plans haven't changed.  The additional parts will likely include some long and skinny ones.  But those long-skinny lights will be designed as "a standalone part that you can place on a spot", not as a meters-long strip that acts as a "streamline" along a part.

I'm sorry to have to say "no", but I think it's for the best.  Lengthy rationale in spoiler section, for anyone who's interested.

Spoiler

There are a few reasons for this, but it boils down to three things.  Size of job; utility of feature; and personal motivations.  The latter is the most important-- it would be a total showstopper even if the other two weren't there.

First, the modeling job proved to be significantly more complex than I assumed, and also there will likely be some procedural work required.  What I tried was "hey, just model a simple 1-meter glowstrip".  I did that, and it worked just fine (in terms of its IndicatorLights behavior).  The problem is... it was stupid and not super usable.  It doesn't fit anywhere.  KSP stock parts don't have any particular standards about exactly how big they are.  Can't put it on the size of a Mk1 capsule (it's too long).  Can't put it on the side of most spaceplane parts (they have curving surfaces, the straight "meter stick" part I made just looked stupid).  It's too short for the long fuel tanks and too long for the short ones, and getting it placed right so that it doesn't get buried in the model requires futzing around with the offset tool with snap turned off.  Can it be coaxed and cajoled into looking approximately reasonable?  Yes... but only with irritatingly fidgety fiddling in the editor.  If I were a user and I tried to use this thing, I'd be quitting in disgust pretty quickly.  I don't want to produce a part unless I think it will delight rather than frustrate the user.

I'm convinced that there is no right answer unless someone either puts a lot of work into figuring out some super-clever way to make standard part sizes and shape work when placed on all the different stock parts, or else someone codes up some clever procedural parts so that users can actually make the things do what the users are likely to want to do with them.  Neither of those things is something I'm willing to do, at least not in IndicatorLights.

Then there's the question of utility.  I have an "anti-clutter" fixation, and adding any part to the part list is clutter, which in my world is a large cost.  So I'm not going to do that unless there's a benefit that's sufficiently large to offset the cost.  An example of a large benefit is "many many users really want the part and would use it a lot if it were there," and I'm not getting that vibe from glowstrips-- if it were that vital, I suspect someone would have mentioned it long ago (IL has been out the better part of a year, and has thousands of users).  That's not to play down the desires of the folks who would want something like this... just that adding a part to please 5% of IndicatorLights users, while annoying the other 95% by cluttering things up with a part they have no use for, doesn't seem like a good tradeoff.  So "glowstrips for decoration" sounds like a great part set to me, but I think it belongs in a separate mod, not as part of IndicatorLights itself.

And then, finally, there's the personal aspect, and this one's the real kicker.  I mod for my own amusement.  I mod because I'm a hopeless KSP addict, and I play this game all the time, and I want the game to be exactly how I like it.  The thing that gives me the motivation to spend time modding is my own enjoyment of playing the game.  I publish the mod because I figure "If I like this, maybe someone else will, too."  Anyone else who likes the same things I do is welcome to come along for the ride.    But ultimately, I don't mod for other people, I mod for me.

And that's the real killer, here.  I have no personal use whatsoever for a Glowstrips-like set of parts.  I would never use them.  There's nothing wrong with the idea, it simply happens to be one that I, myself, have no personal use for.  They're all about ship aesthetics, and I'm a person who doesn't care about aesthetics.  I never do anything "cosmetic" to my ships.  Largely that's because I like the way stock KSP looks-- that hodgepodge-of-hardware look is what I associate with NASA spaceships, and that's what I'm looking for.

And I've come to the conclusion that the fact that I myself would never use glowstrips is a total showstopper for me.  Partly that's just a matter of motivation; but also it's because it means that I don't know what "right" looks like.  I can produce a thing, yes... but is it "right"?  Well, for a feature that I use myself, that's an easy question to answer.  I just play KSP and use this feature that I implemented, and pretty darn quick I'll either have a "yay, this is perfect" or "nope, this is wrong" reaction.  And I'll use it a lot, which means I'll have plenty of chances to find the edge cases where it doesn't work right, etc.  But if it's a feature I have no use for, to do a thing that I never do... how do I know if it's "right"?  I don't actually know how the users will use it, so maybe I've just written something that will make people go "meh" and toss it aside.  Or maybe I'll release it, and then end up going through an endless round of people trying to use it, then coming back with "it's not quite..." and then I'm trying to fix a thing when I myself don't have a strong feeling for what "fixed" looks like.

So, there you have it.  It's simply not going to happen, and wouldn't even if someone were to hand me the models on a platter.  It just doesn't "fit", either with IndicatorLights or with how I work.  So, sorry, folks.

 

[Beetlecat]

Even in your "refusing" to take on this extra project, you certainly illustrate an absolute clarity of vision for your mod and even an obvious opportunity in case anyone else finds themselves inclined to take it up.

Thank you for looking into it! I hope someone does continue to expand on this awesome framework you've created.

Edited January 9, 2017 by Beetlecat

[DrunkenKerbalnaut]

I remember glancing at this a few months ago, then forgetting about it. Stupid Me-from-the-past. This look pretty friggin helpful. Looking forward to trying it out. Thanks @Snark .

[smokytehbear]

Any intention of adding more crew LED colors for MKS compatibility? With guys like Technicians/Medics/Scouts/etc.?

If it's a possibility, syncing the color scheme with DMagic's portrait stats would be awesome. 

 

[DStaal]

36 minutes ago, smokytehbear said:

Any intention of adding more crew LED colors for MKS compatibility? With guys like Technicians/Medics/Scouts/etc.?

If it's a possibility, syncing the color scheme with DMagic's portrait stats would be awesome. 

 

If you go back a couple of pages, you'll see some discussion on that.  Short version: Probably, eventually, though it may not be hard-coded.  But you've got most of the tools already at this point: Someone could write a patch that lit up an MKS distribution center green whenever it had a Pilot or a Quartermaster aboard, for instance.

[Snark]

5 hours ago, smokytehbear said:

Any intention of adding more crew LED colors for MKS compatibility? With guys like Technicians/Medics/Scouts/etc.?

Yep, it got discussed a while back, starting here:

As it happens, I've already added partial support for what you describe, depending on exactly what you're trying to achieve.

First, in version 1.2.5, I added a "none-of-the-above" crew color.  So, as it currently stands:  there are five potential colors for crew indicators.  One for pilots, one for engineers, one for scientists, one for tourists, and one for anything else.  So, currently, if you installed a mod that had new kerbal types like technicians, medics, and scouts, they would get the "anything else" color.  Of course, that doesn't help you tell a medic apart from a scout.

Then, in version 1.2.7, I added code so that there's now a hasCrewEffect toggle syntax available for ColorSource fields on parts in config.  This means that, for example, suppose there's a mod that adds a "Medic" kerbal class, and that "Medic" has a particular skill ("healing" or whatever), you could jigger up some ModuleManager syntax so that a crew indicator could be something like, "if the kerbal has the heal ability, show <some color>, but otherwise just show whatever the crew indicator wants to show."

So, depending on how the mod sets up those new classes, you may very well be able to get it to do what you want, already, using just some ModuleManager config! 

5 hours ago, smokytehbear said:

If it's a possibility, syncing the color scheme with DMagic's portrait stats would be awesome.

No, I'm sorry, that's not possible because the currently configured colors are the correct ones and therefore changing them would be wrong. 

...Okay, joking aside.  Actually, you're not the first person to ask that.  Just by sheer coincidence, they're actually fairly closely aligned already.  Scientist is blue.  Engineer is green.  DMagic's mod colors pilots red; IndicatorLights uses orange.  Actually, as it happens, I was originally going to make pilots red... except that IndicatorLights uses red in a lot of places to indicate "problem" or "out of resource" or that kind of thing, and I didn't want it to look too much like a warning light, which is why I went with orange instead.

However, the good news is that if you don't like the colors I've picked, you can configure them!  See details on the IndicatorLights player's guide wiki.  Basically, find the config file, crack it open in a text editor, and edit the individual colors for pilot, engineer, etc. to be whatever you like.  (Or, for that matter, you can configure basically any of the colors in IndicatorLights, not just the crew indicators.)

[smokytehbear]

I see. Very interesting. I will fiddle with it a bit and see if I can't get the coding to work right for the USI classes. Supposing I get it working and it meshes quite seamlessly, any chance on packaging it into the main mod here or permission for a separate, additional plugin to be distributed?

[Snark]

57 minutes ago, smokytehbear said:

I see. Very interesting. I will fiddle with it a bit and see if I can't get the coding to work right for the USI classes. Supposing I get it working and it meshes quite seamlessly, any chance on packaging it into the main mod here or permission for a separate, additional plugin to be distributed?

If only there existed a mod somewhere to bring together community-supplied patches to add IndicatorLights compatibility for third-party mods...

(FWIW, I believe that if you did write your own patch and distribute it as a separate mod, I don't think you'd need any permission from me at all, since you wouldn't be redistributing any of my stuff with it.  So that option's wide open to you.  However, it seems to me that IndicatorLights Community Extensions would be a happier home for something like that, since putting it there would give it better visibility-- that's the go-to place for people who want compatibility patches for IndicatorLights, and I link to it from the OP in this thread.)

[smokytehbear]

Rock on. I'll see what I can do.

[Snark]

Hi all,

I've released v1.2.8 of IndicatorLights.  This is a moddability update that will have no visible effect on players who use "stock" IndicatorLights.

What it does is to improve the moddability of ModuleCrewIndicator so that it's easily possible for people to add patches to add custom colors for specific custom (i.e. modded) kerbal types, such as what MKS adds.

How it works:  It used to be that the default colors for each class were hard-coded, and the hard-coded list wasn't moddable.  Now all the default color specifications are read out of a main IndicatorLights.cfg config file instead.  The config file installed with IndicatorLights just covers the basic "stock" kerbal types, of course, but now modding it to support a new type of kerbal is as simple as writing a ModuleManager patch to add a new line to the config section.  Any new kerbal types who don't have a config entry will just get the default "unknown" color (magenta, unless configured otherwise).

Thanks to @smokytehbear for pushing me into this. 

A shout-out, too, to @mikerl, who asked a while back for essentially this exact feature.  I delivered a rudimentary, partial implementation back in 1.2.5; now here's the support for real.

Enjoy!

[Benjamin Kerman]

Love the mod, makes it so much easier for science gathering!

[martinezfg11]

	MODULE {
		name = ModuleBooleanIndicator
		// Note that you can put a "!" in front of a boolean input to invert it
		input = and(liquidFuelEnabled, oxidizerEnabled)
		activeColor = dualLevel
		inactiveColor = blink(dualLevel, 900, $Off, 300)
		emissiveName = dualIndicator
	}

Hi, would it be possible to have a light activate when landed? Would the ModuleBooleanIndicator be the correct module to use?

 

Edit: Nevermind, I think I found the correct input in one of your examples. Thanks!

Edited March 15, 2017 by martinezfg11

[Snark]

35 minutes ago, martinezfg11 said:

Nevermind, I think I found the correct input in one of your examples. Thanks!

Woot! 

...For any curious onlookers, here's the documentation with accompanying config example on how to do this.  The TL;DR is, yes, you'd use a ModuleBooleanIndicator, and then you'd use the situation() syntax (which I just linked to) in its input field.

(ModuleBooleanIndicator isn't the only way to use that syntax.  It's just one of the simplest, if that's all you want.  For folks who want to get fancy, it's possible to work the situation() syntax into just about anywhere.)

[Brent Kerman]

Cool! I will definitely download this! I hope my computer can take one more mod!

 

[Nicias]

Would it be possible to have lights on probe cores?

[Beetlecat]

33 minutes ago, Nicias said:

Would it be possible to have lights on probe cores?

Totally. Just need to create configs for each.

[Snark]

9 hours ago, Nicias said:

Would it be possible to have lights on probe cores?

Well, it depends what you mean by "would it be possible."  I can think of a couple of potential interpretations of that:

If you mean "is it possible now for a KSP player to add lights to probe cores by tinkering with config?":

As @Beetlecat says, "yes".

For an example, consider this sample config here, which illustrates the use of the "situation" syntax.  It adds some indicator lights to the HECS2 probe core, whose status is controlled by the vessel's current situation (landed, splashed, flying, orbiting, escaping, etc.)

On the other hand,

 

If you mean "This is a feature request.  Would it be possible for you, Snark, to add indicator lights to the probe cores in the future?"

The answer is, yes, it would be possible, and eventually I may very well do this; but probably not super soon.  Mainly because it's not totally obvious what the lights would display, simply because probe cores have so many things to display:  Hibernation status.  Signal-link status. Science content. Electric storage.  Reaction wheel status.  And so forth.  Different people may want different things, and it's not totally obvious just what information should be displayed, and how.

Therefore, I'd need to put in some design thought before taking on something like this.

The other thing is, there's a feature that's currently "semi-supported" in IndicatorLights (meaning that it exists, and is usable, but is considered "experimental" and is unapologetically open to breaking changes in the future), which is indicator light arrays, which allows for panels of blinkenlights like this:

...I think this feature has the potential for some cool "looks" on probe cores, especially if coded/configured cleverly so that the blinkenlights change status interestingly in response to the probe core's situation.  But, again, it would take some design thought, not just to consider how it could work, but also how to introduce such a thing without being annoying or overly conspicuous.

So, possibly-eventually-maybe on the roadmap, but since it's a non-trivial thing to figure out, it won't happen until have the time to think it through and implement it properly.  I'd rather release no feature at all than a confused or half-hearted one. 

 

[Snark]

Hi all,

I've released v1.2.9 of IndicatorLights.  No new features, this is just an update for KSP 1.3 compatibility.

The main thing that's changed is that it's now bundled with the newest version of ModuleManager, 2.8.0, so that it'll work with KSP 1.3.

One other change is that I've updated it to target .NET framework version 3.5, as a KSP mod is supposed to.  Previously it was targeting 4.5.2.  (This change is of interest only to modders who might be adding assembly references to IndicatorLights.  It has basically zero effect on players.)

Enjoy!

[DStaal]

Quick question: I was thinking about making indicator light configs for USI's 'construction ports' and wanted to know where you wanted them.  The parts themselves are a retexture of the stock docking ports, so the configs should be just 'copy the docking ports config and change the part name'.    (Which could obviously be done by adding it to the stock ports configs as well...)

[Snark]

9 hours ago, DStaal said:

Quick question: I was thinking about making indicator light configs for USI's 'construction ports' and wanted to know where you wanted them.

Excellent, thanks for taking that on! 

Continuing this discussion over on the IndicatorLights Community Extension thread, since that's generally the place to talk about IndicatorLights compatibility patches with other mods.

 

[Errol]

I've started reading the documentation for this. I had the idea of using indicator lights with windowshine (which currently has a bug that does not allow the window lights to show up) to simulate the window lights being turned on. My question is, how do I tell if a part already has a native emmissive mesh? Do the windows on stock pods count as such? And is it possible to create an indicator light that is completely invisible while it is in the off state?

Edited June 4, 2017 by Errol

[Snark]

8 hours ago, Errol said:

I had the idea of using indicator lights with windowshine

I assume you're talking about this mod, yes?

Assuming that you are, let's address the points you raise:

 

8 hours ago, Errol said:

(which currently has a bug that does not allow the window lights to show up)

Pity.  From what I can see of the mod, looks like it's playing some games with the shaders.  I'll go ahead and toss in my gut reaction to seeing this, which is:  if you like using WindowShine and want the cabin lights to show up... my guess is that overwhelmingly the simplest option would be to hope that the mod author fixes that bug.  Perhaps report the bug, unless it's already a "known issue".

Trying to "hack" this yourself is going to be a chunk of work.  It's mostly going to involve modeling and tinkering with Blender.  Also, I don't think IndicatorLights would be the right tool for the job, anyway (see notes below).

Technical details and further discussion in spoiler section.

Spoiler

8 hours ago, Errol said:

My question is, how do I tell if a part already has a native emmissive mesh?

Well, just about everything "has" an emissive mesh, in the sense that it's made out of a material, and that material can have an "emissive" color, and the things that we think of as not "being emissive" just happen to have the emissive color set to black.  So "does it have a native emissive mesh" isn't a super meaningful question-- to really answer what I suspect you're really asking, you'd need to know what code and modules are driving the various colors of the material.

If your question is "what are all the meshes on the part", then you can answer that by importing it into Blender and just looking at the meshes.

Or, if it's a part that has had any IndicatorLights modules on it at all (e.g. something deriving from ModuleControllableEmissive or ModuleEmissiveController), you can use the IndicatorLights debug console to list all meshes on the part.

However, the import-to-Blender option is probably your best bet.

9 hours ago, Errol said:

Do the windows on stock pods count as such?

They absolutely do.  That is, in fact, how the lighting-up-windows actually work.  KSP 1.2 added a new stock module, ModuleColorChanger, which allows animating the emissive color of individual meshes.  (Take a look at the .cfg files for any of the stock crewed parts, and you'll see it there.)  It's the right tool for the job.  Not only is it simpler than IndicatorLights, but it provides some handy built-in functionality such as animating a gradual fade-on / fade-off when the light is turned on or off.

The issue here is that presumably you can't use that with WindowShine.  I'll betcha I know why the cabin lights don't work with WindowShine:  I'll bet what he's doing is to replace the shaders on the windows, so there's no longer an emissive component to work from, so the stock ModuleColorChanger doesn't work anymore.  (And IndicatorLights wouldn't, either, because it's using the same mechanism that ModuleColorChanger does.)

So basically what you'd need to do to try to "hack" this would be to do something similar to what I did with the Z-100 battery.  Make your own mesh that copies the window meshes on the crewed part.  Exact same size, shape, etc.  Then add it to the part, but raised some invisibly small amount (like a millimeter) so that it's in front of the real window.  Then set up its material so that it's only emissive, i.e. it has nothing but a glow texture, and becomes invisible when not "turned on".

You'd need to do that for each individual window mesh for each individual crewable part.  So, like I said, a chunk of work-- this is why I mentioned it would be far more efficient for the WindowShine author to fix in some general fashion. 

9 hours ago, Errol said:

And is it possible to create an indicator light that is completely invisible while it is in the off state?

Yes, it's possible to create an emissive object (for use with IndicatorLights, ModuleColorChanger, or anything else) that's completely invisible except for the emissive color.  But you'd need to do that by modeling in Blender-- it's a property that's baked into the model for a part, it's not something one can tweak in .cfg.

 

[Errol]

I'm going to go ahead and guess that blender isn't free/has a large learning curve? Thank you for the detailed response, seems like you understand what I'm asking, and I realize this is probably a bit more then I can chew. I have decided to side-step the issue by removing windowshine integration on all the pods, so that only helmet visors and solar panels have reflections. I think that is a decent compromise for now. 

[Snark]

4 minutes ago, Errol said:

blender isn't free

Nope, it's totally free.  Really cool, powerful tool.

5 minutes ago, Errol said:

has a large learning curve?

Ding ding ding ding ding! 

That said, though, if all you want to do is import a thing and tinker with the material, and not go and try to do a bunch of modeling on your own, it's not too bad.  It's a matter of spending hours figuring out how to make it work, rather than weeks.  NecroBones has a great link in his signature for a tutorial where he walks through how to use it.

But yes, serious learning curve.

 

[Errol]

KSP itself has a serious enough learning curve for me as it is, thank you very much.