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

[Brigadier]

4 hours ago, Fwiffo said:

Just a heads up, been 7 hours and for some reason the new one is still not showing up on CKAN.  Usually it grabs your updates pretty quickly...

It's certainly there now.

[SchwinnTropius]

So I'm having issues getting the indicators to show up in my game. I downloaded fresh untouched versions of KSP 1.2.1 x64 and your Indicator Lights 1.2.4 to verify the issue wasn't another mod (though it seems to have worse issues with the latest Trajectories installed). I put the output_log, a test .craft, and some screenshots from the Launch Pad on dropbox. When you find a moment, want to take a look?

[link disabled]

EDIT: the dropbox stuff has information from the clean game with just IL installed. I can put in Trajectories and show you the log from that if you'd like.

EDIT2: your bundled copy of ModuleManager is included in my test.

EDIT3: so after doing some folder cleanup and only using the latest MM installed in GameData, the issue cleared up and everything looks good and shiny. It's amazing what one can figure out when tinkering with other things.

 

EDIT4: disabled the dropbox link

Edited November 11, 2016 by SchwinnTropius

[Snark]

On 11/9/2016 at 4:33 PM, SchwinnTropius said:

EDIT3: so after doing some folder cleanup and only using the latest MM installed in GameData, the issue cleared up and everything looks good and shiny. It's amazing what one can figure out when tinkering with other things.

Great, glad to hear it worked out for you! 

From glancing at the dropbox stuff you'd posted, I saw that it looked like everything was working exactly as expected... except that the indicator meshes were simply missing.  My guess was going to be that the mod was somehow installed wrong-- i.e. not in the correct folder location (it needs to be located "just so", because the config that adds the meshes depends on what the path is to the mesh files from the GameData root, which means installing the mod in the wrong place will break the meshes.)

Anyway, glad to hear it's straightened out!

[steedcrugeon]

forgive me for being a bit dim but is it possible for me to pus about 10 ModuleCustomBlink under a single toggle? the last few bits I've worked on have a few resources and they are either toggled by their in game function or lack of. i have a series of emissives as a single part that I wish to Define separately so i can phase them against each other.

So far i have achieved this with a two LED part and i get the result i desired, although i end up with 2 LED toggles, where i'd rather have one to toggle both (decorative function).

[Snark]

15 hours ago, steedcrugeon said:

forgive me for being a bit dim but is it possible for me to pus about 10 ModuleCustomBlink under a single toggle? the last few bits I've worked on have a few resources and they are either toggled by their in game function or lack of. i have a series of emissives as a single part that I wish to Define separately so i can phase them against each other.

So far i have achieved this with a two LED part and i get the result i desired, although i end up with 2 LED toggles, where i'd rather have one to toggle both (decorative function).

If I'm understanding correctly, you want to do something like this?

1. Have a set of emissives on the part that all work together.
2. You want their activation to be controllable by the player.
3. The player has a single on/off switch that's available.
4. When "off", the lights are simply off.
5. When "on", the lights fire in sequence (i.e. they all blink with the same period, but with staggered phase).
6. The player doesn't have control over the speed of blinking, or length of on/off parts of the blink cycle; that's baked into the part.  All the player can do is flip the master on/off switch.

Is that the effect you're trying to achieve?  If so, then yes, you can do this.

A couple of ways.

The simplest way is to use the ModuleEmissiveArrayController that I recently added.  Here's an example of some of the effects that can be achieved with it:

...note the sequence-blinking lights over on the right side.  That's a single controller, which is controlling an array of emissives, such that each subsequent emissive has a phase added to it.  Here's example config showing how to do it.

Caveat:  I've marked this controller as "experimental", i.e. you should think of it as a "beta" release-- I've released it preliminarily to give people a taste of it, and the current design may not be final, meaning I may make breaking changes in an upcoming release.  So it's good for playing-around at this point, but if you're actually releasing something, you might want to hold off.  That said:  your scenario is basically exactly the kind of reason why I produced this controller in the first place, so I'd love to find out whether it actually addresses your need.  If it turns out that "yeah, it almost does what I want, except that I need it to do this", then that's exactly the kind of feedback I'd like to hear, so I can update the controller.

Anyway:  If you don't use the experimental ModuleEmissiveArrayController, you can also achieve the same effect with other lights on a part; it just takes somewhat more cumbersome setup.  You'd put a "master toggle" UI in place with a ModuleIndicatorToggle.  Then, each of the lights would get its own ModuleBooleanIndicator, specifying the master toggle as the on/off switch, and including a phase argument in the blink syntax for the active color.

That ought to work, but not only will it be cumbersome to set up, but also I'm not sure what the performance implications would be if you have so many controllers on one part-- particularly if the player has a large number of instances of the part out there.  The ModuleEmissiveArrayController is a much more efficient implementaiton of that, which is why I'd love to find out whether it addresses your use case, and whether there are any additional features it needs.

Does this answer your questions?  Have I correctly understood your use case?

[steedcrugeon]

That's prefect @Snark not only have you made things clearer but I have now (thanks to this explanation) implemented what i actually originally wanted it do do before I resorted to decorative function. Your mod really adds a lot of information to my parts. in the GIFs below there are 2 separate parts:

Lower part - Escape Pod: features a compact set of Three emissives, one is the Crew Indicator, one is the Reaction Wheel State (quite important on this part as you only really want it active when you are actually powering the retro-rockets or RCS). and the third one is the Resource Level indicator, set to EC in this case.

Upper Part - Fuel Cell: Features three emissives although thank to the array module the flashing two are paired. It has the Resource Converter to indicate when the Fuel Cell is active and the Array Emissive is driven by a Resource Level indicator targeting mono prop (the medium used by the fuel cell). The array behaves exactly as i wanted it to (i setup custom colours for this resource Level indicator on this part using the config).

It's also allowed me to do this although it was a bit more tricky, i got it setup under one ModuleToggleLED but originally they were all one Emissive, i had to split them into 2 sets of five because of how they were automatically allocated. 

Edited November 13, 2016 by steedcrugeon
added another gif

[Snark]

8 hours ago, steedcrugeon said:

I have now (thanks to this explanation) implemented what i actually originally wanted it do do before I resorted to decorative function.

Whoa, that is seriously cool.  Thank you for posting those shots-- that looks awesome!  Really glad to hear that it's coming together for you. 

[scorpion451]

Just wanted to say I'm digging this mod a lot, and that I'm particularly looking forward to the custom status LEDs and panels.

I can imagine the amount of coding that needs to done to make those happen, but in the meantime any preliminary thoughts on how you want to implement those? (plans for what the interface might look like, what sort of things the first generation might be able to monitor, could I change what a given light is showing in-flight, etc?)

I know you mentioned that you don't want to get too much into whole-ship feedback, but one thing I'd love to see options for is dynamic flight feedback- say, I could set up an LED to turn green when my spaceplane is tilted to the perfect angle of attack, or when I'm on the right heading to a navigation waypoint. Minor in-game scripting would be cool too: say, being able to use some math and boolean statements to make a bright red flashing LED telling me I'm getting close to the minimum "enough delta-v to get home" threshold.

[Snark]

On 11/20/2016 at 11:50 AM, scorpion451 said:

Just wanted to say I'm digging this mod a lot, and that I'm particularly looking forward to the custom status LEDs and panels.

I can imagine the amount of coding that needs to done to make those happen, but in the meantime any preliminary thoughts on how you want to implement those? (plans for what the interface might look like, what sort of things the first generation might be able to monitor, could I change what a given light is showing in-flight, etc?)

To be clear, I don't have any plans for "custom status LEDs and panels".  I'm not completely sure what you're referring to, but I'm guessing you're talking about these?

...If so, then, I can talk about some of my thoughts about arrays of lights, and how those might work:

• At some point I'll have some "cosmetic" parts that are just big panels of random blinkenlights (like the 4x4 array on the left side of the above image), with a few UI buttons or sliders for customizing the appearance, so people can decorate their ships if they're so inclined.
• I'd like to implement a "bar graph" type of array controller for indicating a scalar quantity such as "how full is a container".  Imagine a thing like the graphical equalizer display on a stereo-- i.e. a row of LEDs, such that the number of them that are lit up is tied to whatever scalar quantity the thing is tracking.  (For example, I think that would look cool as an indicator on the science lab, showing how full it is of science or data).  It may be that the only place I'd actually use that would be on the science lab, but making the controller available would allow other modders to leverage it as they like.
• Possibly add some dynamically-controlled blinkenlights to specific parts.  Would want to keep this to a bare minimum, to avoid the dreaded "Christmas tree" effect.  But, for example, I think it would be kinda cool if the science lab had some, and they blink only if it's actively doing research, and something about the speed of the blinking could be controlled by how rapidly it's researching science.

What I don't have plans for is to make a "control panel" with specific lights tied to specific things.  No real reason why not, just that it's not my style.  Though I've tried to make IndicatorLights flexible enough via config that another modder could implement such a panel using IndicatorLights, if they wanted to. 

So, taking my best guess about what you were asking about:  the answer is, I'm not doing any of that.

On 11/20/2016 at 11:50 AM, scorpion451 said:

I know you mentioned that you don't want to get too much into whole-ship feedback, but one thing I'd love to see options for is dynamic flight feedback- say, I could set up an LED to turn green when my spaceplane is tilted to the perfect angle of attack, or when I'm on the right heading to a navigation waypoint. Minor in-game scripting would be cool too: say, being able to use some math and boolean statements to make a bright red flashing LED telling me I'm getting close to the minimum "enough delta-v to get home" threshold.

Well, aside from my general aversion to whole-ship indicators being put on a part, there's also the fact that the things you're mentioning would themselves be quite complex to implement-- you're talking about essentially coding what amounts to a whole other mod, just to drive one light.  (Things like "how much delta-V is there" and "what's the perfect AoA" are really hard to code.  I wrote BetterBurnTime, so I have some idea what I'm talking about, here). 

So the things you mention here are definitely in the "not gonna happen" category... sorry.

[Vorg]

Anyone who understands how to do these cfg's want to do one for the science parts in RoverDudes Sounding Rockets mod?

[Snark]

55 minutes ago, Vorg said:

Anyone who understands how to do these cfg's want to do one for the science parts in RoverDudes Sounding Rockets mod?

Sounds like a great idea to me! 

...And if you do, please post about it over here, instead:

I'll happily incorporate patches for additional mod compatibility into IndicatorLights Community Extensions-- that's what it's for. 

[mikerl]

So @Snark, would it be possible to add support for the mod "Colonists" to the crew indicator.  It adds a new class of Kerbal, but the crew LED just gives an error.

[Snark]

39 minutes ago, mikerl said:

So @Snark, would it be possible to add support for the mod "Colonists" to the crew indicator.  It adds a new class of Kerbal, but the crew LED just gives an error.

Hm, interesting.  I don't know anything about the implementation of "Colonists" specifically, but just to verify-- when you say "the crew LED just gives an error", you mean that it's displaying the standard red-green-blue-pause, red-green-blue-pause "error" animation, yes?

In that case, looking at the code, I believe I see exactly what's going on here.  So, there are a couple of options for what I could do, here:

1. Update the crew indicator so that config can specify arbitrarily many kerbal "classes", with a color for each, so that the appropriate config will let it handle any combination of mods that may get thrown at it.
   • 1a.  Actually author the specific config necesssary to make the parts compatible with "Colonists".
2. Update the crew indicator so that it allows specifying an optional "Other" fifth color, to be used for any kerbal that isn't a pilot, scientist, engineer, or tourist.

I'm leaning towards #2, at least for now.  Reasons:

• It would be super quick and simple to code, with no impact on anything else.  Whereas option #1 would require quite a lot of refactoring (whole bunch of code, lots of impact on existing code, need to do lots of testing, etc.)
• Provides an instant "out-of-the-box" solution for someone who happens to be running a mod that adds a kerbal class-- any such mod.  Whereas #1 would require authoring the actual config for "Colonists", specifically.  And I'm unlikely to take the time to do that config-authoring myself (since I don't run Colonists), which means even if I did this, it wouldn't help anybody until someone stepped up and handed me the config so I could publish it in IndicatorLights Community Extensions.
• Is needed, even if #1 were done-- there will always be the need to handle an "other" case.
• Doesn't actually preclude also doing #1-- there's always the option to circle back later on and add that as a feature, if there's enough demand.

...So, the TL;DR of the above is:  yes, I think it's both easy and a really good idea to add a configurable "anything else" color to the crew indicator, so that it could handle your case.  This solution would not handle the case of "I've added N new classes of kerbal and I want all of them to be distinct from each other".  But it sounds to me as though this simple solution would handle your particular use case-- am I right?

[mikerl]

Yes by error i do mean red-green-blue-pause, I figured that's what it was for was when exception cases get thrown in like a new class of kerbal.  This mod is made by @maculator, and seems like the only one to add a new class, although i have seen talk of others on the forum.  If the particular code for this is modular then it would just need a simple config, if not, then a simple none-of-the-above color is fine.

[Snark]

11 minutes ago, mikerl said:

Yes by error i do mean red-green-blue-pause, I figured that's what it was for was when exception cases get thrown in like a new class of kerbal.  This mod is made by @maculator, and seems like the only one to add a new class, although i have seen talk of others on the forum.  If the particular code for this is modular then it would just need a simple config, if not, then a simple none-of-the-above color is fine.

Thanks, that's pretty much what I was expecting.

I'll add a simple none-of-the-above color.  It's a simple, trivial addition to the code, with minimal chance of breaking anything else.

I'm not-- at least, for now-- going to add code that allows doing config mappings of "for each one of N arbitrary kerbal classes, specify a color for each one."  Reason why not:  because it would be a fairly large, high-impact code change.  Much more complex than just the none-of-the-above solution.  (And even if I implemented this, I'd still need a none-of-the-above solution anyway.)

So, I'll include the none-of-the-above fix in the next update of IndicatorLights.  Someday I may consider circling back to add the more complex "N colors for N classes" solution, but likely not anytime soon (there are a lot of other things that are higher up my priority queue than that).

The new none-of-the-above color will be globally configurable in the settings file.  It'll also be possible to override the color for specific, individual parts via .cfg files.

[mikerl]

Sounds good.  I've done coding before so I know it can be a lot of work to rewrite it.

[DStaal]

Actually, with the current internal shift from classes to skills, how much work would it be to key off that instead?  I'd catch Colonists automatically then, as they are just a re-distribution of the same skills.  (Though you might need to do things like decide which skill you're going to highlight by preference, and you'd still want a 'unknown' skill color.)

[Snark]

10 hours ago, DStaal said:

Actually, with the current internal shift from classes to skills, how much work would it be to key off that instead?  I'd catch Colonists automatically then, as they are just a re-distribution of the same skills.  (Though you might need to do things like decide which skill you're going to highlight by preference, and you'd still want a 'unknown' skill color.)

In this case, it's not a question of how hard it would be, but whether I think it's the right behavior, and in this case, the answer is no-- that is, I want the crew-indicator lights to indicate what the crew is, not what it can do.  i.e. "Which one is it?"  If the colonist is a colonist, it should have a color saying so-- and not color it the same as a pilot because it happens to have some pilot abilities (or whatever).

The issue you mention-- "decide which skill you're going to highlight by preference"-- is a complete and utter showstopper, it seems to me.  It makes the feature impossible, because no skill is going to be "the" right one for every circumstance.

So the crew indicators will continue to be based off the name of the kerbal class, not on any of the skills.  Right now, it's just: pilot, scientist, engineer, tourist.  After the next IndicatorLights update, it will be:  pilot, scientist, engineer, tourist, other.  At some future date, I might add the ability to have an arbitrary set of N colors for N classes, as has been discussed above.  But it will never be the case that they're skills-based.

That said, though, you do raise a good point that in general, when one is making decisions based on a kerbal's "nature", it's important to decide whether one cares about the kerbal's identity (i.e. "is it an engineer?") versus the kerbal's ability (i.e. "can it repair stuff?")

In the case of crew indicators (at least, for parts that are just "crew holders" and don't care who inhabits them), I contend that identity is what's important.

On the other hand, for parts that do care about who's crewing, such as the science lab... I should probably revisit the way that they're implemented.  Right now, it has a visual animation to show you when you've got the "wrong kind of kerbal" (i.e. "anybody other than a scientist") in a crew slot.  Since all that really matters in that case is "can the kerbal research science?" rather than "is the kerbal a 'Scientist'", then I should really key that off the relevant skill rather than the "Scientist" identity.

It's an interesting problem.  I have a few ideas about how to approach this, will mull it over. 

[DStaal]

No problem.  Just wanted to raise the 'identity vs ability' issue for thought.    (Partly because where I think of crew indicators I think of the one stock part with crew that I use on a regular basis - the science lab.)

[scorpion451]

On 11/21/2016 at 3:34 PM, Snark said:

I'd like to implement a "bar graph" type of array controller for indicating a scalar quantity such as "how full is a container".  Imagine a thing like the graphical equalizer display on a stereo-- i.e. a row of LEDs, such that the number of them that are lit up is tied to whatever scalar quantity the thing is tracking.  (For example, I think that would look cool as an indicator on the science lab, showing how full it is of science or data).  It may be that the only place I'd actually use that would be on the science lab, but making the controller available would allow other modders to leverage it as they like.

This as a set of standalone parts is basically what I was trying to describe- like the decorative ones, but blinking based on some arbitrary variable that the player tells it.

Say, if that standalone LED could be set to a script mode, so that it will light up when {place to insert player-defined code} is equal to 1, or a graphic-equalizer-type strip that tracks the scalar value of {output of hideous player script involving raw variables from three different mods and the current distance from EVE to Minimus}for values between 0 and 1.

The magic-lamp wish would be to have an In-game gui to build this stuff in and maybe some examples/templates to streamline common uses, but so long as there's some way (in game or out) that I can spend way too much time making a light that blinks when whatever it's attached to is pointing 24* north, 110* east I'm happy.

Edited November 30, 2016 by scorpion451

[Bit Fiddler]

could the lights on the Mk1 crew cabin be moved a bit...  there is a mod out there that adds a crew hatch to the top of the Mk1 cabin.  however this puts the LED right on top of the hatch window.  if the LEDs could be move to the sides, above the windows for instance this would be great.

 

also not sure why this is happening but...  my Mk1 pod has 2 small LEDs floating off to the left side of the part.  I can post screen shots for both of these issues if  you want.

[Snark]

On 11/30/2016 at 10:32 AM, scorpion451 said:

This as a set of standalone parts is basically what I was trying to describe- like the decorative ones, but blinking based on some arbitrary variable that the player tells it.

Say, if that standalone LED could be set to a script mode, so that it will light up when {place to insert player-defined code} is equal to 1, or a graphic-equalizer-type strip that tracks the scalar value of {output of hideous player script involving raw variables from three different mods and the current distance from EVE to Minimus}for values between 0 and 1.

The magic-lamp wish would be to have an In-game gui to build this stuff in and maybe some examples/templates to streamline common uses, but so long as there's some way (in game or out) that I can spend way too much time making a light that blinks when whatever it's attached to is pointing 24* north, 110* east I'm happy.

Unlikely that I'll be building anything like this, just don't have the time-- or, more importantly, the inclination.  Not that it's a bad idea, just that I mod for myself, first and foremost:  I write mods because they make the game do what I want it to do when I'm playing.  This means that my bar for "do I spend the time to implement X" is not "is X a cool idea" but, rather, "would I use it myself when playing KSP."  If the answer is no, then I let someone else work on it. 

That said, though, IndicatorLights is open enough that I suspect it wouldn't be too hard for someone else to build a mod on top of IndicatorLights to do this stuff, if they wanted to.  If anyone's inclined, more power to you! 

10 hours ago, Bit Fiddler said:

could the lights on the Mk1 crew cabin be moved a bit...  there is a mod out there that adds a crew hatch to the top of the Mk1 cabin.  however this puts the LED right on top of the hatch window.  if the LEDs could be move to the sides, above the windows for instance this would be great.

Nope.  I put them where they are because that's the best, most visible place for them, IMHO.  The reason they're colliding with the hatch on that other mod is pretty simple-- it's also putting the decoration in the prime spot.

Moving the indicators would be good for the people who happen to be using that mod... but bad for the people who aren't.

Also, there's the maintainability issue-- I don't own that other mod, I have no control over (or knowledge of) when it might update (perhaps moving the hatch, perhaps requiring a tweak to my patch...); makes it hard to stay on top of that.  Not to mention the fact that I don't actually use that mod myself, which rather dampens my enthusiasm for debugging interactions with it.

That said, though... I feel your pain, and this sort of thing is exactly why I set up IndicatorLights Community Extensions:

...it's a library of community-supplied compatibility patches for IndicatorLights to make it play nice with other mods.  That way, folks who want to use some mod that doesn't play nice with IndicatorLights don't have to be blocked by the fact that "Snark won't take the time to do this himself."  I'm basically just a curator, there.

So, if this bugs you and you want to fix it, you can do it yourself!  Just make a ModuleManager patch to move the IndicatorLight indicators when that other mod is installed, and send it to me.  I'll happily include it in IndicatorLights Community Extensions and post an update.  Everybody wins! 

10 hours ago, Bit Fiddler said:

also not sure why this is happening but...  my Mk1 pod has 2 small LEDs floating off to the left side of the part.  I can post screen shots for both of these issues if  you want.

No clue.  My guess would be that it's an interaction with some other mod.  Do you actually know that it has anything to do with IndicatorLights?  For example, do those other LEDs light up like IndicatorLights indicators?  What do they indicate?  Maybe some other mod is adding those things on its own?

Try temporarily running with nothing but IndicatorLights installed.  If they're still there, then it's an IL issue-- please post a screenshot.  If they're not, it means they had something to do with another mod, so you can use process-of-elimination to figure out which mod it is, then contact the author of that mod.

[Fwiffo]

On 11/13/2016 at 8:13 AM, steedcrugeon said:

Spoiler

 

It's also allowed me to do this although it was a bit more tricky, i got it setup under one ModuleToggleLED but originally they were all one Emissive, i had to split them into 2 sets of five because of how they were automatically allocated. 

 

 

Love that docking bay, @steedcrugeon

[Fwiffo]

@Snark I know how much you just love suggestions about moving the out-of-the-box indicator positions.  Everyone's got an opinion ;-).

Nevertheless I'm curious, did you consider putting one here?  Those static little "indicators" in the default Z-4K art always get me (it looks so much like one of your indicators, I keep thinking that's the real one and all's well).

Bonus points if you could make the lightning bolts and their square frames glow (but I know, that would take some new art assets) ;-).

Edited December 4, 2016 by Fwiffo

[Snark]

10 hours ago, Fwiffo said:

Nevertheless I'm curious, did you consider putting one here?  Those static little "indicators" in the default Z-4K art always get me (it looks so much like one of your indicators, I keep thinking that's the real one and all's well).

Bonus points if you could make the lightning bolts and their square frames glow (but I know, that would take some new art assets) ;-).

Heh, great minds thinking alike and all that.    Putting a mesh on that glowing-green thing on the Z4K was actually one of my first thoughts.  However, I ended up deciding not to do that-- and also, not trying to do something with the lightning-bolt thingies-- for a few reasons.

• Putting the indicator mesh over that glowing-green stock indicator would be insufficient.  There's only one of it, which means it would only be visible to the player from one specific direction.  I like having four indicators around the circumference, because it makes the indicators visible from any ship & camera orientation.
• I value visual consistency more than just about everything else, including "coolness".  I want the visual appearance of the indicator lights to be super visually intuitive and consistent, so the player doesn't have to train their eyeballs to look for different things on different batteries.  So, for all the various stack-mounted batteries (the Z200, Z1K, Z4K), I want them all to have completely consistent appearance of their indicators:  a set of square indicators around the circumference of the battery.
• That's also why I didn't try to do something fancy with the lightning bolts.  All my indicators across all the various stock parts are simple featureless squares or domes.  Aside from the fact that that's less modeling/texturing work for me, I think it's also thematically valuable.  I think throwing too much visual complexity at the player is a bad thing, and I'm already adding complexity by slathering these indicators all over the place, so it's important to make them as visually dead-simple as possible so as not to make things any more visually "busy" than they have to be.

That said, though, you make an excellent point that having that extra pseudo-indicator sitting there on the Z4K can be really confusing, given that it's glowing green regardless of whether things are okay or not.  Perhaps I can cap it with a "dead" mesh that just stays dim, in effect erasing it from existence, so at least it won't be misleading the player.

Thanks for the suggestion, I'll think about it.