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

[The_Joe]

Sorry, I should've been more descriptive. I'm on mobile, so my formatting may be flawed. 

Lots of mods on that page, but here is the description:

Provides new stock parts (using stock models) for the 0.625m probe diameter.
Includes mini H2/O2 fuel cell, RCS, solar panels, mini shielded docking port, new engine configs and inline probe cores.

The problem is that resized parts seem to have a ghost shell that is the original size. I'm not sure this will be fixable problem, but I like both mods. 

[Snark]

1 hour ago, The_Joe said:

The problem is that resized parts seem to have a ghost shell that is the original size. I'm not sure this will be fixable problem, but I like both mods.

Ah, okay.  As long as he's not doing something with code, and is just tinkering with part config (which is what I think he's doing), then this ought to be fixable with a ModuleManager patch to support Seti Probe Parts.

I don't use that mod myself, nor do I have the time to produce 3rd-party mod compatibility patches... but that's what IndicatorLights Community Extensions is for. 

It's a collection of community-supplied (i.e. "not written by Snark") patches to make IndicatorLights compatible with various other mods.  I just curate it, I don't write the patches.  So if you produce a ModuleManager patch for compatibility with the mod-- or can find someone to do it for you-- then just submit it to me and I'll include it there. 

 

[The_Joe]

Thank you, I will have to look deeper into seeing how hard it would be to patch this myself.  Im still a super noob, so knowing that Module manager is where to start is really helpful.  Thank you!  

[Snark]

23 minutes ago, The_Joe said:

Thank you, I will have to look deeper into seeing how hard it would be to patch this myself.  Im still a super noob, so knowing that Module manager is where to start is really helpful.  Thank you!  

A few pointers to get you started:

• ModuleManager syntax documented here and here.
• You can see my IL config for tinkering with the Science Jr. here.
• You'll want to look at whatever config Seti Probe Parts has for the Science Jr.  Comparing that config to mine should give an idea where the problem likely lies.
• Your fix will likely need some combination of "AFTER" syntax from ModuleManager (see the docs), e.g. to make sure your config is applied after IndicatorLights and after Seti Probe Parts.
• My guess is that you'll need to tinker with the model (for the part itself, and for the indicator meshes that need to be added for this to work).

If you get stuck or have questions, the IndicatorLights Community Extensions thread is probably the best place to continue this conversation. 

Good luck!  (And sorry I don't have the bandwidth to do this myself, but feel free to ask questions in the ILCE thread, I'm happy to advise.)

Oh, and by the way:  the really simple workaround, if coming up with config to fix it seems like too much of a hassle:  you can just go into your IndicatorLights installation, find the config file for the Science Jr. therein (it's in the "Parts/science" folder within IndicatorLights), and delete that file.  That will cause the Science Jr. not to have any indicator lights, but at least the rest of IL will work just fine, and the part won't be broken.

[DrLicor]

@The_Joe,
I was about to publish the same problem. I've had this problem with a KSP 1.2.2. install with RSS/RO/RP-0 etc. Where I had this problem:

You can clearly see that instead of one dockingport, there are 3 of them. With, ofcourse, only the inner one working.
After breaking down my install, splitting mods in half over and over again. I managed to find out it is indeed IndicatorLights who causes this and your post confirms this pretty much. 
I don't exacly know if this happens to more mods how it's happening here, but this is quite easy to detect since docking ports are quite essential. 

I have some knowledge in MM-patching, made and maintaining a RO-patch for cormorant Aeronology, but I have no idea how to get a workaround for this. 
@Snark, any suggestions from your side? 
I don't use the indicator light that much, it's more that I really like to use the feature of 'indicatorLightSmall'-part. Since the dockingports of RO aren't compatible with IndicatorLight, I can imaginen deleting the ...\IndicatorLights\Parts\dockingPorts won't do any bad?

 

UPDATE: deleting the folder solved the problem for me. 

Edited August 17, 2017 by DrLicor

[Snark]

1 hour ago, DrLicor said:

@Snark, any suggestions from your side? 

Would be happy to offer advice-- would need more information, though.

1 hour ago, DrLicor said:

You can clearly see that instead of one dockingport, there are 3 of them.

Actually, I can't "clearly see" anything.    Have no idea what on earth I'm looking at, there.  Have never seen anything that looks even vaguely like that, before.  Is that one part, from some mod?  Multiple parts, clipped together somehow?  What is that?

And how is it implemented?  Got a link to the .cfg file that defines it?

1 hour ago, DrLicor said:

With, ofcourse, only the inner one working.

"Of course" how?  And do you mean that usually all three of them work, and with IL installed only the inner one works?

This doesn't look like the stock docking ports to me... but if that's the case, I would expect that IL shouldn't affect it at all, because IL specifically affects only the three stock docking ports (small, medium, and large).  So without additional info, I have no idea what's going on.

1 hour ago, DrLicor said:

I can imaginen deleting the ...\IndicatorLights\Parts\dockingPorts won't do any bad?

Correct (as you have discovered).  IL has been designed to be very modular, with respect to the way it patches the stock parts.  Every stock part affected by IL has its own dedicated config file.  Deleting the file doesn't cause any harm at all, by design:  it just makes IL ignore that part and leave it untouched.  So if, for example, you only ever use the BL-01 Indicator Light and don't need any of the stock parts patched, you can delete all of the folders except for the indicatorLightSmall, and it won't hurt anything.

[DrLicor]

@Snark, I'm sorry, don't get me wrong. 
The dockingport in the attached image is a model you get when you install RO. 
This is how it's supposed to look:

Notice this model has only one. 
If we look back at this:

You can see 3 models, cliping inside. while only using two parts (the cockpit and the dockingport)
With 'Ofcourse' I didn't meant any offence, I meant that the inner port, (green one), is the size it is supposed to be. The 2 outer ports, are the resized models. The inner port is the one the parameters of the config go to, so when you want to dock, it only docks with the inner port.

I deleted the folder of the dockingports and somehow it solved the problems, so I can live on.   
I think I'll adress this to the RO-community so they can look what causes this 'bug', since it didn't appear on the 1.1.3 version. 

Anyway, thanks for responding and for making this mod.  

 

(upper image comes from a youtuber called Cosmonaut Crash, this video)

Edited August 17, 2017 by DrLicor

[Snark]

2 hours ago, DrLicor said:

The dockingport in the attached image is a model you get when you install RO. 
This is how it's supposed to look:

Ah, okay.  So, if I understand correctly, that's a case of a mod that's keeping the stock part, but replaces the model for it, correct?

In that case, you might as well delete the IndicatorLights config for it.  Even if it weren't breaking anything, it wouldn't help.  Why?  Because that config adds indicator-light meshes that are carefully sized and placed based on the original stock model of the part.  Swapping out a different model would, at a minimum, make the indicator lights misplaced-- either floating incongruously in space near the part, or else buried invisibly inside it.

2 hours ago, DrLicor said:

You can see 3 models, cliping inside. while only using two parts (the cockpit and the dockingport)

Yes, and here's what I'm confused by.  What is that thing with the three docking-port rings on it?  Is that some RO part?  If so, what part is it?

[DrLicor]

52 minutes ago, Snark said:

Ah, okay.  So, if I understand correctly, that's a case of a mod that's keeping the stock part, but replaces the model for it, correct?

Yep, exactly. RO has a patch that replaces the stock model with a new one, that looks more like the real deal.
 

 

54 minutes ago, Snark said:

Yes, and here's what I'm confused by.  What is that thing with the three docking-port rings on it?  Is that some RO part?  If so, what part is it?

Yep, me too. That thing is just the 'nasa docking port' that comes with RO. With IL dockingport folder installed, it is showed with those 3 rings. Than is has like three models in it. A small one (that's the one you want) and 2 bigger versions overlapping it, all in one part. 
There's a option with the part which says 'extend bumper', that the ring of the inner port will extend. The other 2 will just be fixed there. 

This is the config it think:
...\RealismOverhaul\RO_SuggestedMods\Squad\RO_Squad_DockingPorts. However, you can't see anything changing the model of it. 
It could be another mod, like SXT...

[Snark]

20 minutes ago, DrLicor said:

With IL dockingport folder installed, it is showed with those 3 rings. Than is has like three models in it. A small one (that's the one you want) and 2 bigger versions overlapping it, all in one part.

Okay.  There, that's the nugget of information that I was missing.  Until this moment, I was assuming that the three-ring thing was some specialized multi-mode docking port part from some other mod, and nothing made any sense.

It has to do with a collision of the model specifiers for the two.  It's fixable via MM, but you'd also need to update the positions of the indicators to adjust for the changed model, so perhaps more of a work item than you'd care to take on.  Just deleting the IL file for the corresponding docking port will take care of the problem, as you see. 

[Chaumas]

I love this mod, thank you @Snark. 

[SchwinnTropius]

So I have a thought on a possible feature to add: I would like to be able to adjust the Emissive Alpha (how much the mesh glows) either in the VAB/SPH or in a .cfg/.xml file. I have an idea for a parts mod that would allow the user to choose any color for the part but without an emissive glow in the dark, kinda like the old KerbPaint. How difficult would it be to add that functionality?

[Snark]

20 hours ago, SchwinnTropius said:

I would like to be able to adjust the Emissive Alpha (how much the mesh glows) either in the VAB/SPH or in a .cfg/.xml file.

Not totally clear to me exactly what you want, but if all you want is "adjust the brightness", that functionality's already there.  Look at the BL-01 indicator light-- it has UI sliders that let you pick the color (including the brightness).  Is that not what you need?

20 hours ago, SchwinnTropius said:

I have an idea for a parts mod that would allow the user to choose any color for the part but without an emissive glow in the dark, kinda like the old KerbPaint. How difficult would it be to add that functionality?

That sounds to me like a completely unrelated, separate question from the first one, above.  In other words, if I'm understanding correctly, you have two reasonable-but-completely-unrelated requests:

1. For glowing things, be able to control how brightly they glow.
2. For non-glowing things, be able to control what color they are.

Yes?

Assuming that my understanding is correct, then:  as I mention above, you basically already have #1.  #2 isn't present currently, but I suspect it probably wouldn't be too hard to add-- but it's unclear whether it would actually help you, depending on what you want.  Here's the deal:

What you want, if I'm understanding correctly, is to be able to change the diffuse color of an  object, as opposed to its emissive color.  For example, be able to change a red object so it looks blue instead, that kind of thing.

In Unity, this is controlled by a shader.  When I originally wrote IndicatorLights, it only worked with one kind of shader-- emissive-- so that it could do glowing.  However, about a year ago, @Enceos asked if it could support tint shaders as well, so that he could integrate IndicatorLights support into his mod.

So I did.

Anyway, now that I've already done the IndicatorLights work to support more than one shader (even though it's currently just two), I'm guessing that adding support for a third would be practically trivial.  Basically, what you're asking for is (I think) "add support for diffuse shaders", which would probably just be a couple of lines of code at this point.

The only real question would be how useful to you would it actually be if I did that.  For example, most parts in KSP aren't showing any naked materials-- they have textures, i.e. bitmaps that are painted across the surface of the part.  I could add support for diffuse shaders pretty easily, but that would (I think-- I'm not an expert at this) only affect the color of materials.  If you have a particular part you want to tinker with, and it has a texture on it, I wouldn't be surprised if tinkering with the color of the diffuse shader wouldn't help you much.  It would totally depend on the way the part is implemented, and on the interactions between its material and its texture in determining the final appearance of the surface.

Put another way:  Think of KSP parts as being carved out of wood, which is then painted over.  I can easily change the color of the wood.  But unless you have a part that's unpainted (or has unpainted sections), that won't matter, because someone looking at the part only sees the color of the paint, not the color of the wood it's made out of.  And I can't affect the paint at all.  So it totally depends on the part.

Can you clarify your use case?  Do you have a specific example of a part with a specific effect that you want to achieve?

[SchwinnTropius]

2 hours ago, Snark said:

What you want, if I'm understanding correctly, is to be able to change the diffuse color of an  object, as opposed to its emissive color.  For example, be able to change a red object so it looks blue instead, that kind of thing.

This is precisely what I was attempting to get at. I was asking about the emissive bits because I wasn't sure how much different the diffuse shaders were from emissives. I noticed you added support for the tint shaders and I had planned on trying that, but the only shaders with tint that I could find were particle shaders that had undesired side effects.

The use case would be for new parts that I intend to make, with textures that allow the material color to show through effectively. Specifically, I intend on making rover bodies in the shapes of vintage cars (anything up to about 1970ish) and I would like to be able to choose the body color, and the texture would only be for windows and details like for the car doors. Understandably this wouldn't work so well for existing parts for the reasons you describe, but this would be intended just for new parts.

[Snark]

21 minutes ago, SchwinnTropius said:

The use case would be for new parts that I intend to make, with textures that allow the material color to show through effectively. Specifically, I intend on making rover bodies in the shapes of vintage cars (anything up to about 1970ish) and I would like to be able to choose the body color, and the texture would only be for windows and details like for the car doors. Understandably this wouldn't work so well for existing parts for the reasons you describe, but this would be intended just for new parts.

Ah, okay, that makes sense.

...Aaaand, here's my "derp" moment for the day.  Now that I go back and actually look at my own darn code, I see that actually I did add support for diffuse shaders, just a few months after I added support for tint shaders.  The keyword is "main" (as opposed to "emissive" or "tint").

Try using that and see how it goes?  Instructions here.

[SchwinnTropius]

Ooh, I missed those details when I was last browsing the IL wiki. I'll tinker with it during this week and I'll report back. Thank you again for this epic mod. :)

[SchwinnTropius]

So after playing around with stuff, I got something good to work. Once I can figure out how to make this look less toy-like, I'll really be in business.

 

EDIT: A little more tinkering and the colors seem to be working perfectly. Now I'm off to teach myself how to make IVAs.

Edited November 2, 2017 by SchwinnTropius

[Snark]

12 hours ago, SchwinnTropius said:

So after playing around with stuff, I got something good to work.

lol, that's great!  Now all you need to do is make it so that the car starts out green and gradually turns yellow and then red as the gas tank empties...

 

[Trann]

I really love this mod @Snark so thanks for that up front.

 

On 4/22/2016 at 7:36 PM, Snark said:

Update to v1.2.11 (add indicators to SENTINEL Infrared Telescope)

I had a SENTINEL without any hits for 6 years game-time (I forgot about it) so I went to check it out: the unit itself was "invisible" but the indicator lights were still present:

I went back to the VAB and the unit looks fine there but once it moves to the pad, it disappears (probably because the indicator light has an affect there?).

    

Possibly related? The mod was added to my save after this vessel initially launched.  Removing the file Parts/science/telescope.cfg brought the part back so that's how I'll run it for now.

 

Let me know if I can help sort this out.

Edited February 21, 2018 by Trann
Photo*ucket

[Wcmille]

What do you think about making the passenger lights blink if a crew report is possible, consistent with other blinking science modules?

[Snark]

12 hours ago, Trann said:

I went back to the VAB and the unit looks fine there but once it moves to the pad, it disappears (probably because the indicator light has an affect there?).

Well, that's not good. 

Hmm.  That's seriously weird.  All I can say is, first, it worked fine for me when I wrote it (have never run into this myself), and, second, I added this functionality quite a few months ago-- if it had been doing this all along, I'm sure someone would have pointed it out before now.  (IndicatorLights has a lot of users these days.)

So, whatever's going on here, I assume it must be something that got broken relatively recently.  I'm not at a KSP computer right now, so I can't check things first-hand, but I can only think of two possibilities that seem reasonably likely to me:

• One possibility would be that something changed in the stock game (for example, when 1.3.1 came out)-- e.g. if they did something to the definition of the Sentinel part, such that the IndicatorLights config no longer works with it.
• The other would be, perhaps something with ModuleManager?  I know that MM recently shipped a major version upgrade, and I know it broke some backwards-compatibility stuff-- see the discussion over at the IndicatorLights Community Extensions mod.  So... I could imagine that, conceivably, there could be something about the telescope.cfg file in IndicatorLights that worked fine in the old version of ModuleManager, but is broken with the new version.  Out of curiosity:  what version of ModuleManager are you running?

I won't be able to verify anything myself until I get to a KSP computer and can test this first-hand, but for now, the "which MM version are you running?" would be useful to know.

9 hours ago, Wcmille said:

What do you think about making the passenger lights blink if a crew report is possible, consistent with other blinking science modules?

Heyyyyyyy, now there is a nifty idea.  That's frickin' brilliant.

[Insert sound of palm smacking forehead, "whydidn'tIthinkofthat" muttered softly under one's breath]

I've long thought "gee, there should be something for crew reports" ... except I was always thinking in terms of "I'd need to add another indicator to the crewed parts, and they already have the crew indicators so that would be too cluttery".

Use the crew indicators themselves... now there's a neat idea.  After all... they're already there, no additional modeling work needed, no additional clutter.  And if there's nobody occupying the crew slot, there's no possibility for that slot to take a crew report, so "off" can just be "off".

It would actually be rather different functionality than the other science instruments, since those use color coding to indicate full/partial/minimal value of the science, and they also use "solidly lit" to mean "contains science".  But since crew reports are an all-or-nothing thing anyway, seems to me it would make sense to just have the state look like this:

• Slot occupied, no crew report available:  solidly lit, colored by profession (same as now)
• Slot occupied, crew report already on board:  solidly lit, colored by profession (same as now, for crew indicator; different from science instruments, since color isn't being determined from science value)
• Slot occupied, crew report available to acquire:  blinking, colored by profession (new behavior, different both from existing crew indicators and existing science instruments)
• Slot unoccupied:  off, regardless of crew report availability or status (same as now for crew indicator; different from science instruments, since they'd be blinking if there's science availability and lit if the science was contained there)

I think there ought to be enough flexibility in the config wiring to allow setting that up without needing any code changes-- the IL config language is pretty darn flexible, if you'll pardon my tooting my own horn a little. 

Won't be able to say for sure until I've had a chance to get to a KSP computer and spend a little time mulling this over.  But my initial knee-jerk reaction is that this ought to be pretty straightforward to do, just a minor change to how stuff is wired up in the config.  (And if it's not possible... well, it oughta be, and hopefully I could change the code to enable it.  But I'm guessing I won't have to.)

Okay, campers, now it sounds like I've got three good reasons to consider an IndicatorLights update in the near future:

1. Sort out whatever weird bug it is with the telescope, as reported by @Trann.
2. Flashing the crew indicators if a crew report is available, as suggested by @Wcmille.
3. Update to the latest version of ModuleManager.

So I guess that's enough for me to get off my duff and go make something happen.    No promises on an exact delivery date, as I'm pretty busy IRL at the moment, but now I'm motivated so hopefully it will be Soon™.

[Trann]

7 hours ago, Snark said:

• what version of ModuleManager are you running?

 

Looks like I had both 2.8.1 and 2.8.0 there so I tossed the older and restored the telescope.cfg file: no go.

 

I then went and checked for ModuleManager's latest and that's at 3.0.1 so I grabbed that version and tried again: the problem persists.

 

Real Life matters more so take your time; I'm okay with tossing the telescope.cfg for now.

[Snark]

2 hours ago, Trann said:

Looks like I had both 2.8.1 and 2.8.0 there so I tossed the older and restored the telescope.cfg file: no go.

I then went and checked for ModuleManager's latest and that's at 3.0.1 so I grabbed that version and tried again: the problem persists.

So, you're saying you're consistently seeing the problem, regardless of which ModuleManager version you have?  The problem is there with MM 2.8.1, and is also there with MM 3.0.1?

In that case ... sorry, I have no idea what the issue could be.  I've never seen this myself.  I've been able to go and check on my KSP computer, and I'm still not seeing it, even now.  This is running KSP 1.3.1 with ModuleManager 2.8.1 and IndicatorLights 1.2.11.  I start up KSP, go to the VAB, create a simple spaceship which is the Sentinel sitting on top of a HECS2, and launch it.  Result:

...it looks just fine, exactly how I would expect it to look.

So, no clue what your issue might be.  Perhaps some interaction with some other mod you've got running somewhere?  Any interesting error messages from ModuleManager sitting in your log file?

Unless you can find a clue on your end, or unless someone else observes the same problem and can come up with some repro steps, I'm afraid I can't help, since it works just fine for me.

[DStaal]

@Trann - Do you see the issue with a newly designed and launched craft?  (Not just newly launched - one you've put the telescope on after you installed the mod.)

[Rocket In My Pocket]

31 minutes ago, Snark said:

So, you're saying you're consistently seeing the problem, regardless of which ModuleManager version you have?  The problem is there with MM 2.8.1, and is also there with MM 3.0.1?

In that case ... sorry, I have no idea what the issue could be.  I've never seen this myself.  I've been able to go and check on my KSP computer, and I'm still not seeing it, even now.  This is running KSP 1.3.1 with ModuleManager 2.8.1 and IndicatorLights 1.2.11.  I start up KSP, go to the VAB, create a simple spaceship which is the Sentinel sitting on top of a HECS2, and launch it.  Result:

...it looks just fine, exactly how I would expect it to look.

So, no clue what your issue might be.  Perhaps some interaction with some other mod you've got running somewhere?  Any interesting error messages from ModuleManager sitting in your log file?

Unless you can find a clue on your end, or unless someone else observes the same problem and can come up with some repro steps, I'm afraid I can't help, since it works just fine for me.

I just got Indicator Lights re-installed on my new computer, I'm using MM 3.0.1 the newest version; I'll go check out the Sentinel and see if I can confirm.

Yeah, it looks fine on my end. Must be a mod conflict or something particular to his setup.

Sorry I couldn't help.

Edited December 16, 2017 by Rocket In My Pocket