Jump to content

[1.11.x] IndicatorLights v1.7: Small, convenient, informative.


Recommended Posts

The ISRU model (but not the miniISRU) gets rotated by 60 degrees, so the lights end up floating in midair in the empty space between the panels.  That nastiness with old and new X and Z is my implementation of rotation matrix multiplication in Module Manager, to rotate all of the lights' position vectors by 60 degrees (actually, by -60 degrees, but it works either way).  Same for the Mk1-2 pod, except the rotation is by 29 degrees, so that the lights get re-centered over the (newly-centered-by-VSR) hatch.

Link to post
Share on other sites

Excellent that all this is going on-- but it really needs to be in a mod, with a github repository backing it, rather than just pasted into forum posts.  :)

Are one of you fine folks gonna set up an "IndicatorLights Community Patches" mod for all this great stuff to live in?

Or do I need to set it up myself and then authorize you as contributors?  (and if the latter, what's your Github name?)

Link to post
Share on other sites

So a brief followup on the TextureReplacer issue -- installing the latest version of IndicatorLights to check out all the new features, all of the *new* indicators on parts, etc. work just fine. Only the standalone part still appears solid-black in the part list and in-game.

Still a puzzlement.

Edited by Beetlecat
Link to post
Share on other sites

Hi gang,

Well, as promised, I've produced documentation for IndicatorLights.

IndicatorLights Wiki

The main sections of the wiki are the player's guide and the modder's guide.

The latter section has by far the lion's share of the content; it's a detailed technical reference that should tell modders everything they need to know in order to work with IndicatorLights.

Enjoy!

Link to post
Share on other sites

Hi all,

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

  • Resource indicators refactored for greater configurability. Sorry, everyone, this means another (sigh) breaking change. Details below.
  • Added crew indicators to the science lab, with custom animations.
  • Added a crew indicator to the Mk1 cockpit.
  • Added a science data animation to the Science Jr. materials bay.
  • Added a feature to help modders debug config problems.

First things first, about the breaking change, which affects batteries:

Sorry to do this to you again.  The resource-indicator module was one of the very first ones I implemented, when I was still very much just making stuff up as I went, and hadn't yet settled into my current architecture.  It was showing its age, and the inflexibility was limiting options.  Thus the change.

For players:  It won't break your save-game, you can still play just fine.  However, all batteries on any ships you launched (or saved in the editor) before installing v0.9 will have status indicators that don't work right.  For ships in the editor, you can fix the problem by deleting the pre-v0.9 batteries and adding fresh ones from the parts tab.

For modders:  Sorry, if you've added IndicatorLights interop with the battery indicators, you'll need to update your config.  Take a look at the config files for batteries in IndicatorLights, you can see what I did.  The change is pretty straightforward.

 

Okay, now on to the fun bits.

The crew indicators on the science lab are special:

  • If you've got a non-scientist in the lab, then that indicator will be dim and blinking, to show "hey, what's this useless doofus doing in here."
  • When the science lab is in operation (i.e. researching), then the indicators for scientists aboard will pulsate brightly to show that it's running.

I have further plans for the science lab, but that'll have to wait for a future update.

(Just gotta take a moment for some nerd-preening:  I'm pretty proud of what I did with the indicators on the science lab, mainly because IndicatorLights is built in such a way that they didn't need any custom code.  I've put a lot of thought and effort into designing a flexible controller model for IndicatorLights that's entirely config-driven.  There's not a single line of specialized, science-lab-specific code in IndicatorLights anywhere.  The lab is just using the same resource-converter module that the fuel cells do, and the same crew-indicator module as all the other parts.  All the customized behavior comes from a few bits of clever "wiring" in the config.  What this means is that any modders out there who want to do something neat with IndicatorLights can achieve a really broad spectrum of creative effects with config only, without requiring a single line of code.  Lots more details about this on the IndicatorLights wiki.)

I added a custom lights animation to the Science Jr. materials bay.  Didn't have to strap on any extra meshes-- it had some emissive textures in there already.  When the device contains science data, then its internal lights will pulsate.  (The code for this will also be useful in the future, if-and-when I do something with other science instruments.)

Finally, I added a feature to help modders debug problems with their config.  If you're trying to add config to enable your part for IndicatorLights and you screw something up so that the mod can't parse what you've done, it will display a standard "ERROR" pattern:  a 1200-millisecond cycle of flashing red-green-blue-pause, red-green-blue-pause.  If you ever see that, you immediately know two things:

  • there's something wrong with your config
  • if you look in the debug log, you'll find a warning message, starting with "[IndicatorLights]", with highly specific details about exactly what's wrong.

This is a departure from what the mod used to do in such circumstances, which was to try to "keep running at all costs and just show some not-too-horrible default", such as just leaving the lights off.  The problem with that was that it tended to leave the modder in the lurch-- you'd end up with a "why isn't this working?" situation, and it could be hard to tell whether you did something wrong, or what.  Now you know.

 

Anyway, that's the round-up for this version.  Enjoy!

Link to post
Share on other sites
2 hours ago, SteveD80 said:

I would like the docking port lights to be on by default, or at least a setting to add this behavior.

That's a good idea, thanks for the suggestion!  I'll add a config setting for that to the next update.  The initial default will still be "off", but if you like 'em on all the time, you can just go in and adjust the config setting to "on", just like the crew indicators are now.

It doesn't come up for me when I'm playing KSP, because I've got DefaultActionGroups installed (naturally! of course I run all my own mods) ...

...and IndicatorLights includes a DefaultActionGroups patch so that the docking port indicators get added to the Light group by default.  So when I play KSP, the docking-port lights are off by default, but they all come on when I turn on the lights via the U key, which is how I like to play.

But I can totally see that if you're not playing with DAG, having them all-on-by-default would be handy.  Easy to add a config setting, will do!

Link to post
Share on other sites
On 5/3/2016 at 8:22 AM, hab136 said:

Instead of trying to detect and dynamically show alignment, you could just provide some static visual representation of what is "up" vs "down", like MRS's docking helper does:

...

Using my leet MSPaint skills, I made a mockup:

...

See also the completely static Docking Target (which is actually two layers; watch the video)

By the way, hab136:  I realize this post of yours was from a couple of weeks ago, and I never really addressed it.

I don't have any current plans to color-code the docking port indicators the way you've shown.  However, the good news is:  it's totally doable with MM config, so if you'd like 'em to do that, you can make it happen.  :)

Detailed modder guidelines are here:

https://github.com/KSPSnark/IndicatorLights/wiki/Modder-Guide

No plug-in code needed, can do what you want with just ModuleManager.

Sorry it took so long to respond-- wanted to wait until I got the documentation up, so I'd have something concrete to point you at instead of just telling you "it's possible". 

5 hours ago, SteveD80 said:

Are the docking port lights tied to the lights button by default? If so that is more than good enough for me.

They are if you install DefaultActionGroups. :)

Link to post
Share on other sites
22 hours ago, Snark said:

I added a custom lights animation to the Science Jr. materials bay.  Didn't have to strap on any extra meshes-- it had some emissive textures in there already.  When the device contains science data, then its internal lights will pulsate.  (The code for this will also be useful in the future, if-and-when I do something with other science instruments.)

Finally, I added a feature to help modders debug problems with their config.  If you're trying to add config to enable your part for IndicatorLights and you screw something up so that the mod can't parse what you've done, it will display a standard "ERROR" pattern:  a 1200-millisecond cycle of flashing red-green-blue-pause, red-green-blue-pause.  If you ever see that, you immediately know two things:

  • there's something wrong with your config
  • if you look in the debug log, you'll find a warning message, starting with "[IndicatorLights]", with highly specific details about exactly what's wrong.

 

I'm so glad you're doing these quality of life type things, I think it will allow this mod to become really widely adopted because creating support won't be a pain. 

Curious since I brought it up before you'd looked into it, are there any other aspects of the science module you can hook into? For example, can an experiment tell you when it can be run, or whether it's been done before?

 

Link to post
Share on other sites
3 hours ago, Starbuckminsterfullerton said:

Curious since I brought it up before you'd looked into it, are there any other aspects of the science module you can hook into? For example, can an experiment tell you when it can be run, or whether it's been done before?

Oh yes, plenty!  I'm pretty sure that everything you describe is easily accessible.

Science instruments are one of those areas that I'd definitely like to give some attention (you'll note they're on my planned feature list), but they need some careful design thought.

On the one hand, they're rich in information, they're one of the areas that there's some "player pain" (i.e. keeping track of status and what they can do) ... and also, they're perhaps one of the best "thematic" fits for this sort of thing.  If there's one kind of gizmo that you'd kind of expect to be encrusted with blinkenlights, it's a science instrument.  All of which argues for me to go totally gung-ho on 'em.

On the other hand... most of the science instruments are pretty tiny, and don't have a lot of elbow room for slapping on additional meshes and such.  (Consider the thermometer, for example... there's practically nothing there.)  And aside from the "physical" design challenge, there's also coming up with a reasonable scheme for any lights added there-- there are so many different ways one could display info on such an instrument, I think it's important not to go overboard, i.e. try to show too much and end up just making a gaudy mess.

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

Link to post
Share on other sites
  • 2 weeks later...

Hi Snark!

The indicator lights are functioning wonderfully! I've now equipped most of my ships with aircraft style strobes and port/starboard indicators, a dorsal indicator "streak" (consisting of three yellow lights) and rescue ships have their door corners outlined (because as we all now, 99% of rendez vous happens at the night side for some sinister reason).

One request, and this can easily be relegated to the bottom of the priority list (or moved to the "no way, bro" pile) — how feasible would it be to have the blink frequencies correspond to game time, and not real world time? If I set up a light to flash with a frequency of 1s, it will do so regardless of time warp (I can understand that it would be impossible to do this in regular time warp, but it would be a nice touch in physics warp -- and perhaps in animate the lights in regular warp up to 10× speed, and above that simply keep them on?)

Link to post
Share on other sites
7 hours ago, Kerbart said:

One request, and this can easily be relegated to the bottom of the priority list (or moved to the "no way, bro" pile) — how feasible would it be to have the blink frequencies correspond to game time, and not real world time? If I set up a light to flash with a frequency of 1s, it will do so regardless of time warp (I can understand that it would be impossible to do this in regular time warp, but it would be a nice touch in physics warp -- and perhaps in animate the lights in regular warp up to 10× speed, and above that simply keep them on?)

I've thought about it.  The main problem is as you say-- speeding them up can cause runaway strobing.  I did it the current way deliberately just so they'd look "reasonable."  (And also because it was really quick and easy to code.)  There are plenty of other examples of stuff where animations run in real-world time rather than game-world time (e.g. extending/retracting antennas, solar panels, etc.)  Having it match physics warp, as you suggest, is something I've thought of and will probably add at some point.  It's just a feature I haven't gotten around to yet.

Here are my current ideas relating to blink timing that are on my "to do" list (not necessarily in this order):

  • Speeding up blinking for physics warp.
  • Having blink start time be keyed to a particular event start time, rather than absolute calendar zero.  (For example, having the blink cycle start at the "zero point" when you turn the light on, rather than an absolute wall-clock synchronization).
  • Having UI options for the manually-blinking lights so you can set the phase of the blinking.  (For example, if you put a couple of nav lights on your wingtips, and you want the left and right lights to blink alternately instead of in unison).

So yes, excellent suggestion, and yes, I was already planning on getting around to it.  (I've gone ahead and added it to the planned features wiki-- thanks for reminding me!)  Just not sure how soon.  So many neat things to do.  :)

2 hours ago, Gaiiden said:

heads up @Snark, fix needed for a small issue when using this mod w/TR

Thanks for the notice-- especially when I follow the link and see that there's a specific discussion about IndicatorLights there.

I don't run TextureReplacer myself at all, though, and am utterly ignorant of how it works, what it looks at, or anything else like that.  I barely even know what it does.  So I don't understand shaw's response of "add it to keepReadable"-- how would one do that?  If all I need to do is add a line to a text file somewhere, or add a new text file, then I'm happy to do that whenever I next update IndicatorLights.  But I don't have a clue what that might be, and it would take a fair amount of time for me to run it down.  Any chance you could spoon-feed me an answer?  :)

Link to post
Share on other sites
1 hour ago, Snark said:

Just not sure how soon.  So many neat things to do.  :)

Meh, don’t rush it. To be honest if you keep the features the way they are and just update it for when the new versions (1.1.3? Next Monday? I’d love to start that rumor... :P ) require it, I’d be as happy as a pig in the mud. The rest is just icing on the cake.

I did just think of one minor issue. Say, hypothetically, that I don't want my white lights perfectly white, because they're not that in reality either. So I mix in a tad of yellow, and set the “white” light to 1.0 / 1.0 / 0.95.  And say, hypothetically, that I later come back to my craft, because I left the default for the light to “on” as I discover on launch (and then switching the light on turns it off, while all others go on). I would, hypothetically of course, along the way discover that my light settings have changed to something like 1.0 / 1.0 / 0.94876394871, which causes great distracts to OCD sensitive people.

Now, I bet that is because you're storing the RGB values in the 0-255 range (“Dammit Jim, I’m a programmer, not an artist!”). Would, in the VAB, rounding to the nearest two decimals be a particular issue?

And this brings up another issue (please don't consider me whiner). Would it be possible to program the "toggle" action in such a way that it follows suit with the regular lights? So "toggle" doesn't really mean "toggle" but rather "go to ON when the overall light status goes to ON and vice versa for OFF?" On second thought, scratch that. That would only make sense when you couple "toggle" to the "light" action group, and would be pointless for custom action groups. The reason I didn't delete it is because you might have some valuable input on this.

Link to post
Share on other sites
9 hours ago, Snark said:

I don't run TextureReplacer myself at all, though, and am utterly ignorant of how it works, what it looks at, or anything else like that.  I barely even know what it does.  So I don't understand shaw's response of "add it to keepReadable"-- how would one do that?  If all I need to do is add a line to a text file somewhere, or add a new text file, then I'm happy to do that whenever I next update IndicatorLights.  But I don't have a clue what that might be, and it would take a fair amount of time for me to run it down.  Any chance you could spoon-feed me an answer?  :)

Rats I was hoping you'd have an idea :P but what I think it is referring to is a .cfg file that has a value of KeepReadable that is assigned that texture. I'll ask over on the TR thread for confirmation

Link to post
Share on other sites
10 hours ago, Kerbart said:

just update it for when the new versions (1.1.3? Next Monday? I’d love to start that rumor... :P ) require it

Oh, don't worry, I'll keep all my mods up-to-date whenever a new version of KSP comes out, though TBH I don't expect much upset. 1.1 needed mod updates because the internal APIs shifted around so much, but I didn't have to touch 'em for 1.1.1 or 1.1.2 at all-- just go and mark them as compatible.  But yeah, even if a change is needed, I'll update accordingly.

10 hours ago, Kerbart said:

Say, hypothetically, that I don't want my white lights perfectly white, because they're not that in reality either. So I mix in a tad of yellow, and set the “white” light to 1.0 / 1.0 / 0.95.  And say, hypothetically, that I later come back to my craft, because I left the default for the light to “on” as I discover on launch (and then switching the light on turns it off, while all others go on). I would, hypothetically of course, along the way discover that my light settings have changed to something like 1.0 / 1.0 / 0.94876394871, which causes great distracts to OCD sensitive people.

Now, I bet that is because you're storing the RGB values in the 0-255 range (“Dammit Jim, I’m a programmer, not an artist!”). Would, in the VAB, rounding to the nearest two decimals be a particular issue?

Ah, nuts.  Hadn't thought to check that.  Yeah, I'm sure it's exactly the reason you say.  That's not an OCD complaint, that's a legitimate bug.  I'll add it to the list.

Incidentally, if you do ever get in a situation where the light is out of step with the rest of the lights group... you can always get it back in sync by just right-clicking on it and choosing "Toggle Light" to sync it up again.  (Of course, if it's part of a symmetry group, you'd have to do that with each light in the group, which would be a hassle, but it's a workaround.)

10 hours ago, Kerbart said:

And this brings up another issue (please don't consider me whiner). Would it be possible to program the "toggle" action in such a way that it follows suit with the regular lights? So "toggle" doesn't really mean "toggle" but rather "go to ON when the overall light status goes to ON and vice versa for OFF?" On second thought, scratch that. That would only make sense when you couple "toggle" to the "light" action group, and would be pointless for custom action groups. The reason I didn't delete it is because you might have some valuable input on this.

No, not whining at all, it's a legitimate issue that I've run into myself recently.  (The scenario that I ran into:  I have one craft with "lights on", and it docks with another craft that has "lights off".  Okay... now try "toggle lights" after docking.  All the "real" lights sync up, but mine are now inverted on the two craft and there's no way to fix them short of individually clicking on every light.)

It's an interesting issue.  The real nub of the matter is that some of the action groups (lights, brakes, gear) have a "this group is 'active'" state, whereas the custom numbered ones are just toggles (I think).  I need to look into it a bit more.  The "real" lights kinda cheat by having the game give them special treatment for the Lights action group, and I need to mimic that.  I'd like to fix this.  I suspect that the fix may require me to tinker some with the DefaultActionGroups mod, which is what I'm using for putting these lights into the "Lights" action group.  Really, DefaultActionGroups should be able to handle cases where someone adds config to add some action to one of those "persistent" groups.  If you've configured a part to be in the Lights action group by default, then presumably you want it to really act just like the "real" lights do.

Link to post
Share on other sites
1 hour ago, Snark said:

(...)

Incidentally, if you do ever get in a situation where the light is out of step with the rest of the lights group... you can always get it back in sync by just right-clicking on it and choosing "Toggle Light" to sync it up again.  (Of course, if it's part of a symmetry group, you'd have to do that with each light in the group, which would be a hassle, but it's a workaround.)

(...)

Hence me mentioning it. Hassle? Yes, I did figure out the workaround... but...

images?q=tbn:ANd9GcRQqbY94d8BGxoo91edwwn

RHAAAAAAAGH I WANT MY MONEY BACK!!

:wink:

I really appreciate that you're looking into it!

Link to post
Share on other sites

Hi all,

I've posted pre-release v0.9.1 of IndicatorLights, a.k.a. "The @Kerbart Edition".  This is a minor bugfix release, no major new features.  New with this release:

  • All "toggle" actions have their action-group logic fixed so that they follow the action-group's activation status.  Thus, being in the "Light" group will make it always turn on when you activate lights (whether it's on already or not), and vice versa.  (Thanks to Kerbart for pointing this out.)
  • Updated the frequency of animations (e.g. blinking) so that when you're running in physics warp, they go faster.  (Thanks to Kerbart for the suggestion.)
  • Fixed a bug in the color sliders that caused them to display long ugly decimals when re-loading after saving.  (Thanks to Kerbart for catching this.)
  • Updated to most recent ModuleManager version.  (Contrary to popular belief, Kerbart had nothing to do with this.)

There, Kerbart, happy now?  :)

 

Not included with this version is a TextureReplacer fix, mainly because I don't have the repro case solid and would like someone to confirm before I add it to a shipping package.

So, a call to action to @Gaiiden and @Beetlecat, both of whom have noticed problems with TextureReplacer.  Can you please test out the following and let me know whether it, 1. fixes whatever problem you were seeing, and 2. doesn't mess up anything else that you notice in TextureReplacer?

Spoiler

Go into the "Patches" sub-folder of IndicatorLights, and create a file named IndicatorLights_TextureReplacer.cfg.

Put the following text into that file:

@TextureReplacer:AFTER[TextureReplacer]
{
	keepLoaded = ^IndicatorLights/
}

...then start up KSP and see what you see?

If I hear back favorably from you, I'll fold this in to the next IndicatorLights release.  Thanks for the help!

Link to post
Share on other sites
13 minutes ago, Snark said:

Hi all,

Spoiler

 

I've posted pre-release v0.9.1 of IndicatorLights, a.k.a. "The @Kerbart Edition".  This is a minor bugfix release, no major new features.  New with this release:

  • All "toggle" actions have their action-group logic fixed so that they follow the action-group's activation status.  Thus, being in the "Light" group will make it always turn on when you activate lights (whether it's on already or not), and vice versa.  (Thanks to Kerbart for pointing this out.)
  • Updated the frequency of animations (e.g. blinking) so that when you're running in physics warp, they go faster.  (Thanks to Kerbart for the suggestion.)
  • Fixed a bug in the color sliders that caused them to display long ugly decimals when re-loading after saving.  (Thanks to Kerbart for catching this.)
  • Updated to most recent ModuleManager version.  (Contrary to popular belief, Kerbart had nothing to do with this.)

 

There, Kerbart, happy now?  :)

Hahaha! With this version unofficially named after me I'm never going to upgrade* to later versions after this. Thank you very much, @Snark, I'm going to try it out right now!

EDIT: Confirming that everything works as announced (intended?). Snark, you're amazing. Thank you!

 

 

* Barring any awesomeness that undoubtedly will be included in said later version.

Edited by Kerbart
Link to post
Share on other sites
1 hour ago, Snark said:

So, a call to action to @Gaiiden and @Beetlecat, both of whom have noticed problems with TextureReplacer.  Can you please test out the following and let me know whether it, 1. fixes whatever problem you were seeing, and 2. doesn't mess up anything else that you notice in TextureReplacer?

Texture Replacer configs are cumulative, so it won't work with MM. It'll just run through all the configs it finds. So this works, tested:

TextureReplacer
{
	keepLoaded = ^IndicatorLights/
}

 

Link to post
Share on other sites
1 minute ago, Gaiiden said:

Texture Replacer configs are cumulative, so it won't work with MM. It'll just run through all the configs it finds. So this works, tested:

Great, thanks!

Just out of curiosity, was there some in-game odd behavior that you observed that led to your calling out this issue?  If so, what was it?  Or is it just a matter of getting that exception in the log file?

Also, I'm kinda curious to hear from @Beetlecat, who observed odd behavior with lights showing up as black when TR is present.  I wonder if this fixes that issue, too?

Link to post
Share on other sites
Just now, Snark said:

Or is it just a matter of getting that exception in the log file?

Just this. It could have never really caused any real issue but when you have as many mods as me running I like to keep things as clean as possible

Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...