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

[Drew Kerman]

4 minutes ago, Beetlecat said:

Chiming in here -- I tried the patch file in both variations (with and without the @), but the actual part lights are still showing solid black.

the error I reported that this patch fixed was for the agency logo. It shouldn't have anything to do with part textures

[Beetlecat]

1 minute ago, Gaiiden said:

the error I reported that this patch fixed was for the agency logo. It shouldn't have anything to do with part textures

Ah, thanks for the clarification.

[Snark]

Hi all,

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

• Indicator lights on science instruments (see details below).
• Added a TextureReplacer patch to prevent an exception in the log. (Thanks to @Gaiiden for tracking down both the problem and the fix!)

How the new science indicators work:

• They have three states:  Solid glow, blinking, off.
• Solid glow is when the instrument contains science.  The color is according to value:
  • Bright green = high value, i.e. it's fresh science that has never been acquired before.
  • Medium yellow = partial value, i.e. you've transmitted it before, but not physically recovered.
  • Dim red = negligible value (zero, or close to it), i.e. you've physically recovered it before.
• Blinking is when the instrument is empty, but a useful measurement is available in the current situation.
  • Bright, quickly flashing green = "High-value science here! Take a measurement now!"
  • Intermittent, dim yellow blinks = medium-value science available (per description above).
  • Note that the blinking doesn't happen if you've got the science aboard, see below.
• Off is when the instrument is empty and not currently useful for anything, i.e. one of the following situations:
  • The science value in the current situation would be low (zero, or close to it) if you took a measurement now-- i.e. you've recovered science from this situation before.
  • You already have a copy of this science result stashed somewhere on the ship.

The TL;DR:  On = "has science";  Blinking = "wants science"; Off = "never mind".

Like all colors in IndicatorLights:  the three colors used here (for high, medium, and low value science) are configurable.  For example, if you find all these instrument lights to be too bright and distracting, you can tone them down by editing the configuration file to make the colors something dimmer.  (Or, of course, if they really bother you, just delete the config files for the instruments from the Parts directory, to un-mod them.  But I'm hoping you won't want to do that!)

Just a side note:  This update may not look any more impressive than the various previous updates... but it's much more complex under the hood.  (Holy mackerel, that was a lot of work.  Don't even ask me what it was like to debug.)  There's a whole lot of code with all sorts of fiddly bits to handle various edge cases and so forth.  Like any complex piece of machinery, the more moving parts there are, the easier it is for something to go wrong.  I've poked and prodded at it and think that I've got it running smoothly, but it wouldn't surprise me if I somehow managed to miss a spot.

So, a plea to my loyal fans:  if you're using this and the science indicators seem to be acting wonky (turn the wrong color, aren't on when they should be, are on when they shouldn't be, etc.)-- please let me know so I can fix it! 

Enjoy!

[Kerbart]

I think I like the previous release better. I wonder why...

I'm fairly structured with my scientific readings so I won't get a lot of mileage out of this, but it looks like a fun extension of functionality. What was it like to debug, by the way?

 

 

[Snark]

10 minutes ago, Kerbart said:

I'm fairly structured with my scientific readings so I won't get a lot of mileage out of this

I'm pretty structured and methodical myself, but there's one aspect of this that I'll really enjoy.  I take up orbit around a new planet, and I want to gather all the measurements from the gravioli detector (which is per-biome).  I hate having to keep doing "right-click... oh, same biome.  Time warp... okay, right-click again... dang."

This way... I just go until it starts flashing at me, meaning "take a measurement now!" and then I take the measurement. 

[Drew Kerman]

Optional next step for you Snark with this new science functionality - integration with SCANsat so the indicator lights don't fully function (for the new science detection, not storage) until a biome scan of the body has been made. Should still always work for high/low/flying/etc tho

Edited June 11, 2016 by Gaiiden

[DStaal]

As a feature request, would it be possible to have a placeable (independent) light that is tied to the overall level of a particular resource in the ship?  (Green: Full, Yellow: getting empty, Red: We're out.)  I'd like to place lights on my ships to help me know when I'm going to run out of Supplies for USI-LS. 

[Artfact]

Love the mod. The science indicators look awesome! I pretty much only fly in first person, so I'm finding ways to make it work.:P

[swjr-swis]

3 hours ago, Snark said:

I hate having to keep doing "right-click... oh, same biome.  Time warp... okay, right-click again... dang."

Something you could've avoided by using the new stock option in 1.1.x to pin a rightclick menu. Pack a Surface Scanning Module, and in orbit, rightclick once on it, and pin that menu somewhere. Notice the 'Biome: <biome name>' in that menu, which updates live. Voilá, easy continuous indicator of the biome one is flying over at any given time, to give you the heads up of when to trigger your experiments (something I usually place under an action group to do all of them at once).

 

That said, I love the indicator lights.

[eightiesboi]

This is terrific! Thank you!

 

[Snark]

11 hours ago, Gaiiden said:

Optional next step for you Snark with this new science functionality - integration with SCANsat so the indicator lights don't fully function (for the new science detection, not storage) until a biome scan of the body has been made. Should still always work for high/low/flying/etc tho

That's a neat idea, but I suspect it's probably in the ain't-gonna-happen category, for a few reasons:

• I'm not really much of a SCANsat user myself-- I occasionally use it for some careers, but for most of them I don't.  So my personal payoff for my own game time in terms of developing such a feature is pretty minimal. 
• Less "bang for the buck" in terms of the number of players who would get a benefit-- it would only help folks who use both SCANsat and IndicatorLights, i.e. only a fraction of IndicatorLights users (a fraction that, alas, I'm typically not one of).  That wouldn't matter so much if it was just a simple add-a-config-line-here kind of change, but this is the sort of thing that takes serious work and debugging to produce.
• It would be a big chunk of work.  Making two mods interoperate at the code (rather than config) level, when neither one of them is willing to take a dependency on the other, is a significant coding challenge.  It's doable, but really non-trivial.  If I'm going to invest that kind of work, I expect I'd choose to invest it elsewhere-- I have a lot more ideas than I have time to put into code, so I have to pick and choose.  Doing one thing means not doing something else.

Thank you for the suggestion, though!

 

10 hours ago, DStaal said:

As a feature request, would it be possible to have a placeable (independent) light that is tied to the overall level of a particular resource in the ship?  (Green: Full, Yellow: getting empty, Red: We're out.)  I'd like to place lights on my ships to help me know when I'm going to run out of Supplies for USI-LS. 

That would certainly be possible to implement, and from time to time I've thought about doing something like that.  However, I tend to lean away from implementing it-- even though I think it would be kinda cool, and I think it would be good to have such functionality somewhere, I'm not convinced that this is the right place for it.

The thing that makes IndicatorLights compelling, for me, is that it's a way to provide locality of information:  e.g. this battery visually shows that this battery (and not one of the many others you have) has a problem or whatever.  Ships are made up of lots of parts, and having each part able to visually communicate about itself is a very powerful tool that lets you take in lots of information very intuitively at a single glance.

What you just described isn't really about any particular part-- it's about the overall state of the whole ship.  It's a vessel thing, not a part thing.  And it seems to me that for vessel things, it makes more sense to have some sort of flight UI, instead of decorating a physical part of the ship.  It's conceptually cleaner, it avoids practical issues such as "now I have to rotate the camera around to a certain angle to look at part X to find out the status", and it makes it easy to use in a variety of situations (such as being visible even when in map view, etc.)

I've had a few ideas for flight UI that I think would be nifty, but I've never tried to implement any of them-- mainly because I'm still pretty green at Unity, and coding UI would be a steep learning curve that would take a lot of time for me to climb, and also because I tend to be biased towards "less UI" in my games.  I expect I'll get around to it at some point, but haven't yet.

11 hours ago, Snark said:

I hate having to keep doing "right-click... oh, same biome.  Time warp... okay, right-click again... dang."

 

7 hours ago, swjr-swis said:

Something you could've avoided by using the new stock option in 1.1.x to pin a rightclick menu. Pack a Surface Scanning Module, and in orbit, rightclick once on it, and pin that menu somewhere. Notice the 'Biome: <biome name>' in that menu, which updates live. Voilá, easy continuous indicator of the biome one is flying over at any given time, to give you the heads up of when to trigger your experiments (something I usually place under an action group to do all of them at once).

Actually, I do already use the Surface Scanning Module for that purpose.    However, that solution still leaves much to be desired, IMHO:

• I don't always have the module on board.  It's the kind of thing that's easy to forget to put on there.
• It's bulky and awkward and doesn't fit nicely in a lot of places.  It kinda spoils the lines of the ship, for me.
• If I don't leave its UI pinned, then I have to go hunting for the darn part with camera & mouse every blessed time to bring up the UI.  Including when I'm in the dark, which is often.
• If I do leave the UI pinned, that has issues of its own.  "Okay, I'm going to transfer fuel now between these two tanks, and... hey!  where's the transfer button?  <various fussing and fuming>  ....Oh, it's doing that because I have a non-fuel-tank thing's UI open."  Plus it means I have to go through the pinning-and-moving rigamarole to get it set up just how I like it every blessed time I switch to the ship, which is often.  I fly lots of concurrent missions and tend to switch frequently between ships.
• It also means I have extra UI floating on the screen, which I am violently allergic to.  I really, really like to avoid solutions that involve extra UI displays.  It's why I don't run mods like KER, and why I pour a lot of effort into my own mods to find ways to do things or convey information without needing any UI at all.
• It's a text-based display rather than graphical.  I like visually intuitive things.
• It still doesn't solve the problem of remembering which biomes I've already grabbed or not... multiplied by situation (e.g. high versus low space)... multiplied by "do I already have that stashed on this ship so I don't need to bother with it."

Put all that together, and it just, well, bugged me.  Which is why I took the (stupidly large amount of) time to produce this feature, though I'm kinda glad I didn't realize ahead of time just how much of a pain it would be to code, or I might have been a bit daunted. 

[DStaal]

5 minutes ago, Snark said:

That would certainly be possible to implement, and from time to time I've thought about doing something like that.  However, I tend to lean away from implementing it-- even though I think it would be kinda cool, and I think it would be good to have such functionality somewhere, I'm not convinced that this is the right place for it.

The thing that makes IndicatorLights compelling, for me, is that it's a way to provide locality of information:  e.g. this battery visually shows that this battery (and not one of the many others you have) has a problem or whatever.  Ships are made up of lots of parts, and having each part able to visually communicate about itself is a very powerful tool that lets you take in lots of information very intuitively at a single glance.

What you just described isn't really about any particular part-- it's about the overall state of the whole ship.  It's a vessel thing, not a part thing.  And it seems to me that for vessel things, it makes more sense to have some sort of flight UI, instead of decorating a physical part of the ship.  It's conceptually cleaner, it avoids practical issues such as "now I have to rotate the camera around to a certain angle to look at part X to find out the status", and it makes it easy to use in a variety of situations (such as being visible even when in map view, etc.)

I've had a few ideas for flight UI that I think would be nifty, but I've never tried to implement any of them-- mainly because I'm still pretty green at Unity, and coding UI would be a steep learning curve that would take a lot of time for me to climb, and also because I tend to be biased towards "less UI" in my games.  I expect I'll get around to it at some point, but haven't yet.

In my example case, there already is a central UI for that, from USI-LS.  What I want is more locality - something that says 'this ship needs attention now, or soon.'  For that matter, the information is in the stock toolbar if I really need it.  But I'd like to have the information at a glance, so it's easier to access.    I don't really see the 'have to rotate the camera to see the part' as a problem you should be worrying about - that's the ship designer's problem in this case, making the light easy to see and use, if they want it for a specific ship.

Really, why I'm asking for this is so that I'll have deal with less UI - just a light I can notice when I'm focused on the ship.  Instead of having to pull up a UI dialog and read through it for the information I'm looking for.

[swjr-swis]

6 minutes ago, Snark said:

It's bulky and awkward and doesn't fit nicely in a lot of places.  It kinda spoils the lines of the ship, for me.

Translate and rotation gizmos are our friends (not food!). Not very much of the module needs to be visible to be able to click on it, and being surface attachable, it doesn't need to be in the default orientation either. I often leave nothing but the top of the red filter thing showing. All helps to minimize line-spoiling.

10 minutes ago, Snark said:

If I don't leave its UI pinned, then I have to go hunting for the darn part with camera & mouse every blessed time to bring up the UI.  Including when I'm in the dark, which is often.

Speaking of which: would it be a scary amount of work to add an indicator light to this particular module, and extend the new code to make that blink the same ways as for the science instruments? Reason is, while on the surface, it too is biome specific when it can run a surface scan. As a side effect, it would then conveniently have gained a light to find it in the dark...

14 minutes ago, Snark said:

If I do leave the UI pinned, that has issues of its own.  "Okay, I'm going to transfer fuel now between these two tanks, and... hey!  where's the transfer button?  <various fussing and fuming>  ....Oh, it's doing that because I have a non-fuel-tank thing's UI open."

Yeah that's a nuisance, I agree. Although, when one settles the sat/ship orbiting in science-gathering mode, with UI open to catch them all, does one really need to do fuel transfers all that often while still gathering, or is that something that one tends to do after...?

17 minutes ago, Snark said:

It's a text-based display rather than graphical.  I like visually intuitive things.

I do usually as well. In this case though, I'll likely still have the surface scanner UI pinned open to see the actual biome name, which, unless the blinky light is going to learn morse code, it cannot tell me. Reason being, that the one edge case you excluded (near-but-not-quite-zero science to be had), I personally still want to fetch anyway - it irks me no end seeing close-but-not-quite-100% reports in the R&D science archives.

All that may sound like I'm complaining, but I'm really not! The stupidly large amount of time spent on the blinky light is appreciated.

[Snark]

20 minutes ago, DStaal said:

Really, why I'm asking for this is so that I'll have deal with less UI - just a light I can notice when I'm focused on the ship.  Instead of having to pull up a UI dialog and read through it for the information I'm looking for.

Thanks, that's a pretty good rationale.

A big part of which features I get around to implementing first is "how much work is it to implement?"; I'm more likely to go for low-hanging fruit first.  FWIW, the barrier-to-entry for the feature you're proposing just got somewhat lower in v0.10, so I suppose that raises the chances a bit. 

The biggest technical hurdle to implement your feature is the fact that the individual part would need to display some information that's gleaned from the whole ship.  Conceptually that's a simple idea, but doing it in a way that performs well (i.e. can be called dozens of times per second, on every update cycle), and scales to very large ships with hundreds or even thousands of parts (which some players do), without tanking the performance, takes a lot of careful design thought.

As it happens, I actually needed that very thing in v0.10.  I make the science instruments blink when there's juicy science to be gotten... but I want them not to blink if the science-to-get happens to be already on the ship somewhere.  And answering that "is it on the ship somewhere?" question was a royal pain in the fundament.  That's one of the major time sinks I had to deal with in getting v0.10 out the door.

But now that it's there... I can re-use it.  Being the clever software-engineery sort of guy that I am, I designed it with a reusable base class that will make my life much easier in the future any time I need to track any state that's associated with the whole ship rather than with a particular part.  So a feature like you describe just got a lot easier, since I've already done a big chunk of the work.

10 minutes ago, swjr-swis said:

Translate and rotation gizmos are our friends (not food!). Not very much of the module needs to be visible to be able to click on it, and being surface attachable, it doesn't need to be in the default orientation either. I often leave nothing but the top of the red filter thing showing. All helps to minimize line-spoiling.

Except that I have an irrational prejudice against clipping things, even when it's not an exploit, is purely cosmetic, and has no chance of actually summoning the Kraken. 

10 minutes ago, swjr-swis said:

Speaking of which: would it be a scary amount of work to add an indicator light to this particular module, and extend the new code to make that blink the same ways as for the science instruments? Reason is, while on the surface, it too is biome specific when it can run a surface scan. As a side effect, it would then conveniently have gained a light to find it in the dark...

Heh, you're way ahead of me.  The resource scanner's pretty high on my to-do list.  Lots of interesting possibilities there-- have I scanned this biome yet?  What's the ore concentration like?  What biome am I over?  Am I within scanning range of the surface?

Will need to sort out just what information I want to display, and how, but yes: this part is definitely going to be getting some love.

[bpiltz]

Great update and love this project!

3 ideas:

1.  Indicator lights for parachutes - deployment risk

2.  Indicator lights for deployed landing legs - safe landing speed or blink pattern indicating real distance to ground ("radar ping")

3.  For the extra part stand alone indicator light, can it be set up in VAB/SPH with an action group like interface or logic rules where the player can program certain behaviors to the light (i.e. blink green when certain science condition, or solid green when dV < x, or solid blue when <10 sec from ascending node....)?

[Snark]

Hi bpiltz, thanks for the suggestions!

2 hours ago, bpiltz said:

Indicator lights for parachutes - deployment risk

Actually, I'd thought about that.  It wouldn't be hard to implement, and (this is important to me) pretty easy to design to avoid visual "noise"-- I really don't want to turn ships into "flying Christmas trees".  Just set up the indicators so they're off whenever they're in vacuum.  (Perhaps even off unless the ship is descending, so they shut up during ascent.)

However, there are few issues that could limit the usefulness / necessity.  First and foremost:  they actually have indicators already-- in the staging UI.  And the staging UI is, in most cases, actually a much better place to have this information than as an indicator on the actual part.  That's because, when I'm considering activating parachutes, what I really care about is not "will that parachute that I'm looking at get ripped apart if I activate?"  Rather, what I really want to know is "will whatever parachute I activate get ripped apart?"  Because it might not be totally obvious which one is meant, if I've got different parachute groups.  The staging display tells me what I really want to know, in a way that the indicator on the parachute wouldn't.

The only case where knowing about "that chute that I'm looking at" would matter would be if I were manually clicking on the chute to activate it.  But not only do I practically never do that (nor, I expect, do most KSP players)... but if I were doing that, I'd have a display in its context menu anyway.

About the only valid use case I could come up with would be if, for example, if you have a repeat Duna lander where you re-pack the chutes, and are therefore relying on action groups rather than staging to activate them.  But to me, that seems like a pretty narrow use case, not really enough to justify the feature.

2 hours ago, bpiltz said:

Indicator lights for deployed landing legs - safe landing speed or blink pattern indicating real distance to ground ("radar ping")

Doable but rather labor-intensive to implement.  Also, IMHO not really the right tool for the job-- this is something that I think BetterBurnTime is much better suited for.  It has pretty much just what you're asking for, or its moral equivalent:  a countdown to touchdown, and a safe-or-not indication.    Also... my experience from implementing the safe-or-not feature in BetterBurnTime is that it's actually much less useful in practice than you'd think it would be.  So, probably won't be implementing something like this for IndicatorLights.

2 hours ago, bpiltz said:

For the extra part stand alone indicator light, can it be set up in VAB/SPH with an action group like interface or logic rules where the player can program certain behaviors to the light (i.e. blink green when certain science condition, or solid green when dV < x, or solid blue when <10 sec from ascending node....)?

Possibly, but it would be labor intensive to cover all the possible permutations of "things somebody might be interested in."  Also, IMHO this sort of "situational" stuff is better suited to some sort of flight UI, e.g. NanoGauges or its moral equivalent specialized for other purposes.

[charliepryor]

I'm assuming that using Ven's Stock Revamp will cause the science experiment part of this to not work.... right?

[Snark]

1 hour ago, charliepryor said:

I'm assuming that using Ven's Stock Revamp will cause the science experiment part of this to not work.... right?

Well, it's like pretty much everything else in this mod (other than the BL-01 indicator light), as far as Ven's is concerned.  The short answer is:  Yes, I expect it will run into difficulties, but could be easily patched not to do so.

My understanding of what Ven's Stock Revamp does is to simply replace the meshes of various stock parts.  That is, no actual plugin-code, it's just a re-skinning.

Since all of my tweaks to stock parts involve carefully placing my indicator meshes so they fit "just so" on the surface of the stock parts, that means that any modification to those stock parts that changes the location of the surface, will likely make my meshes' placement wrong.  Either they'll be buried inside the new model (and thus invisible), or else floating unsupported in space where the old surface used to be.

That said, though, it's purely a geometry problem.  Everything in IndicatorLights should still work just fine from a behavior perspective, it's just that the indicator meshes are placed wrong.  This is the sort of thing that is easily fixed with a patch file to make the needed adjustments to mesh placement if Ven's is installed.  It's simply a matter of some dedicated and persistent individual going through and figuring out what the new placement would be.

That individual would not be me. 

...simply don't have the time to do all that.  However, if some public-spirited person would like to take the trouble to do this, I'd gladly add a patch to IndicatorLights for it.  Any volunteers?

@Kerbas_ad_astra has already done some work there (see his post here), it would basically be a matter of continuing that to other parts.  One suggestion I would make, for anyone inclined to go down that path:  Kerbas' config file will work, but it's specifying the new location by applying a multiplier to the old location.  I would strongly suggest not doing that-- rather, just work out the new numbers and specify them that way explicitly.  Rationale:  if for any reason I ever need to tweak the locations of the original meshes on the stock parts, it would break the Ven patch if that patch is based on top of the stock numbers.

[NecroBones]

 

BTW, Kottabos did a review/overview:

 

 

[Starbuckminsterfullerton]

 

On 6/10/2016 at 8:50 PM, Snark said:

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

• Indicator lights on science instruments (see details below)

How the new science indicators work:

On 5/18/2016 at 8:29 PM, Snark said:

So yeah, I'd like to do a lot with them, and I'll almost certainly be doing something with them... but keeping it usefully informative and visually attractive without crossing the line into "confusing" or "distracting" is going to take some pondering.  But if-and-when inspiration strikes, I'll be there with a whoop and a holler. 

Just dropping by to say I think you succeeded in striking a good balance with the science equipment; all the information I would want is there, but it's definitely not confusing or distracting. 

Edited June 15, 2016 by Starbuckminsterfullerton

[Snark]

5 hours ago, NecroBones said:

BTW, Kottabos did a review/overview:

Woot!  Thanks for the heads-up!

(and thanks for the review, @Kottabos)

[StrandedonEarth]

All those indicator lights help my station glow like a xmas display! Thanks!

Edited June 19, 2016 by StrandedonEarth

[Snark]

14 minutes ago, StrandedonEarth said:

All those indicator lights help my station glow like a xmas display! Thanks!

Heh, great, glad it's working out for you! 

My own favorite effect is when I've got a big space station and I press "U" to toggle its lights on/off, and all the docking ports light up.  (I'm running DefaultActionGroups, so the docking port lights get added to the Light group by default when I build anything.)

[macgufo]

Hi, 

0.10 version work on 1.1.2 ? If not where i can find v.0.9, please?

Thanks for the great mod 

[Snark]

4 hours ago, macgufo said:

Hi, 

0.10 version work on 1.1.2 ? If not where i can find v.0.9, please?

Thanks for the great mod 

IndicatorLights 0.10 works just fine on KSP 1.1.2; actually, I wrote it on 1.1.2.  No changes were required for it to work on 1.1.3, so I just updated its compatibility flag.

So you don't need to grab 0.9.  However, if for any reason you ever want to (for my mod, or any other mod that's hosted on SpaceDock):  that's easy.  All previous versions of the mod are available on SpaceDock.  From the mod's main page, click on the "Changelog" tab, which will not only list all the previous versions (with descriptions of what changed in each one), but also give you an easy download link for each one.  So you can easily get any version you like.