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

[Sharpy]

Would you mind making the attachable LED Tweakscale-friendly?

[Snark]

2 hours ago, Sharpy said:

Would you mind making the attachable LED Tweakscale-friendly?

Sorry, I have no idea what that means, technically speaking (i.e. what would have to change about it).  I thought Tweakscale was a mod that allows people to make any random part be whatever size they want?  Is there something special and different about the BL-01 that makes it not work?

(FWIW, I do have a plan to add additional sizes and shapes of standalone lights.  Not quite the same thing as being able to scale arbitrarily, but depending on why you need Tweakscale, might or might not address your problem.)

[Sharpy]

1 minute ago, Snark said:

Sorry, I have no idea what that means, technically speaking (i.e. what would have to change about it). 

Tweakscale is much more "intelligent" about the way it changes parts: some parts, like docking ports, are not editable at all. Other change in a clever manner: smaller probe cores are more expensive, for example. It tries to retain a balance, so that e.g, an upscaled Terrier is about the same quality and price as Poodle.

That means, it provides scaling data related to every stock part which can be scaled. And as result, it doesn't touch parts it has no clue about - you can't scale mod parts unless either the author of the mod, or author of Tweakscale included them.

All you need to do, is include:

	MODULE {
		name = TweakScale
		type = free
	}

in IndicatorLightSmall.cfg

and the part becomes freely scalable, following the default algorithm of scaling mass and price, if Tweakscale is installed.

If you'd like to add restrictions or provide different scaling scheme, this post lists the configuration options - but I think for the simple light 'type = free' is optimal.

[Snark]

8 minutes ago, Sharpy said:

Tweakscale is much more "intelligent" about the way it changes parts: some parts, like docking ports, are not editable at all. Other change in a clever manner: smaller probe cores are more expensive, for example. It tries to retain a balance, so that e.g, an upscaled Terrier is about the same quality and price as Poodle.

That means, it provides scaling data related to every stock part which can be scaled. And as result, it doesn't touch parts it has no clue about - you can't scale mod parts unless either the author of the mod, or author of Tweakscale included them.

All you need to do, is include:

	MODULE {
		name = TweakScale
		type = free
	}

in IndicatorLightSmall.cfg

and the part becomes freely scalable, following the default algorithm of scaling mass and price, if Tweakscale is installed.

If you'd like to add restrictions or provide different scaling scheme, this post lists the configuration options - but I think for the simple light 'type = free' is optimal.

Thanks, useful to know-- I'll bear that in mind.  I'd probably do that as a ModuleManager patch rather than in the .cfg of the part itself, with a NEEDS[TweakScale] on it, but that's a helpful thing to know.  Sounds like a reasonable patch to add.

[Fwiffo]

Hi, I have a part I'm creating which combines a lander can and several science experiments (materials bay, mystery goo, temperature, accelerometer, etc).  So the CFG has multiple ModuleScienceExperiment's.  The specific  experimentID's are: crewReport, mobileMaterialsLab, mysteryGoo, barometerScan, seismicScan, gravityScan, temperatureScan and atmosphereAnalysis.  In case it's relevant, note the part also has a ModuleCommand (minimumCrew = 0) and ModuleScienceContainer.

I have a ModuleScienceDataIndicator, but it only seems to trigger when crew reports are stored.  When I do other science (like "Observe Materials Bay") the controller does not activate its associated ModuleControllableEmissive.

I'm assuming it's because the crewReport experiment module is the first one in my CFG. (EDIT: I think it boils down to the line sourceModule = FindFirst<T>(); in  ModuleSourceIndicator.cs)

Is there a way to target my ModuleScienceDataIndicator to a specific experimentId, or to have it trigger when any of ModuleScienceExperiment's in the part have data available?

If not, can I make that a feature request?

Thanks!

ps. Please quote or tag me in reply.

Edited September 12, 2016 by Fwiffo

[Snark]

3 hours ago, Fwiffo said:

I'm assuming it's because the crewReport experiment module is the first one in my CFG. (EDIT: I think it boils down to the line sourceModule = FindFirst<T>(); in  ModuleSourceIndicator.cs)

Having looked at the code:  yes, I believe you're right.  Thank you for tracking this down.

3 hours ago, Fwiffo said:

Is there a way to target my ModuleScienceDataIndicator to a specific experimentId, or to have it trigger when any of ModuleScienceExperiment's in the part have data available?

If not, can I make that a feature request?

No, there's not, but you're right-- there absolutely should be.  Great idea, thanks!  What you're bumping up against is my failure to think ahead when designing it-- it didn't occur to me that there may be more than one ModuleScienceExperiment on the same part.

It's a good feature request.  Basically, I should add a field on ModuleSourceIndicator that allows indicating which thing is being indicated (and make the default be "everything" not "the first thing").  Should be pretty simple to add.

I'll almost certainly have to come out with a new version of IndicatorLights to maintain compatibility when KSP 1.2 arrives, so I'll aim to work it in there.  (I probably won't be coming out with any further versions of indicator lights before 1.2 arrives.)

[Fwiffo]

@Snark Great, can't wait!  Thanks for the quick reply.

[Fwiffo]

I'm creating an indicator light for an LFO tank.  Is it possible to wire up two ModuleResourceLevelIndicator's such that one emissive will show the "lowest" of either resource?  Or do I need to stick with separate indicators for LiquidFuel and Oxidizer?

[Fwiffo]

Also, I think your indicators on the stock Small ISRU are slightly off:

The set on the side that says "R4-03", and the set on the side with the yellow "Processor is not <blurred> for preparing food"* warning label, are all floating a little bit above the surface.  The third set on the side with no markings seems fine (perfectly flush).

* What does that blurred word say, anyway?

[Snark]

3 hours ago, Fwiffo said:

I'm creating an indicator light for an LFO tank.  Is it possible to wire up two ModuleResourceLevelIndicator's such that one emissive will show the "lowest" of either resource?  Or do I need to stick with separate indicators for LiquidFuel and Oxidizer?

Not currently possible-- a ModuleResourceLevelIndicator tracks exactly one resource.

I could see how it could be useful to track the lowest-of-N-resources, though.  Seems like a reasonable thing to do, might be a nice feature add.  Let me think about it. 

2 hours ago, Fwiffo said:

Also, I think your indicators on the stock Small ISRU are slightly off

Thanks for the heads-up!  I never, ever use the mini-ISRU myself (I find it, and the mini-drill, to be essentially useless, at least in my own games), so I didn't look too closely at it and just naively assumed that the part was trilaterally symmetric.  I'll look into it.

 

By the way, @Fwiffo, thanks for the bug reports and feature requests-- keep 'em coming!  I very much would love modders to use IndicatorLights to enhance their own parts, and have tried as much as I can to make IndicatorLights friendly to modders.  But I'm not much of a part author myself, and as far as I can tell, you're the first parts modder to really get into IndicatorLights for stuff other than what I've already done, which means you're the perfect guinea pig to tell me what I've missed.    (NecroBones has already hooked some stuff up in SpaceY for charge-level and SAS indicators on his probe cores and reaction wheels, which needless to say I'm over the Mun about... but he's using those indicators in pretty much exactly the same way I've used them on the stock parts, so I don't find out design limitations there.)

I especially love suggestions such as the ones you've made thus far, where I can get a lot of bang for the buck by making an existing module significantly more useful/flexible with just a little bit of extra effort.

[Fwiffo]

 

1 hour ago, Snark said:

I find it, and the mini-drill, to be essentially useless, at least in my own games

It works well with the big drill but saves a bit of weight.  On the craft I'm working on, I don't need a lot of conversion throughput, but I do need to be able to get ore from low yield geography (hence the big drill).

BTW, you might also want to check on the Barometer while you're at it, I think the indicator nubbin for that isn't in the correct spot either.

Also while we're talking about indicators for stock parts, here's what I did with the Mystery Goo - there's a nice oval indent to the right of the word "JETTISON" which fits a nubbin well without covering up that text on the texture (although there's nothing wrong with how your normal indicator looks on that part):

Spoiler

 

1 hour ago, Snark said:

I very much would love modders to use IndicatorLights to enhance their own parts, and have tried as much as I can to make IndicatorLights friendly to modders.

IndicatorLights is easliy one of the most well-thought-out, and certainly most well-documented Kerbal mods I've come across.  Props to you!

Edited September 13, 2016 by Fwiffo
More goodness

[Snark]

32 minutes ago, Fwiffo said:

BTW, you might also want to check on the Barometer while you're at it, I think the indicator nubbin for that isn't in the correct spot either.

Barometer was a bit tricky, since it didn't really have a naturally obvious place to put the indicator, and it's concave.  I basically settled for something that looked reasonably OK to me and seemed to "fit" with the part.

33 minutes ago, Fwiffo said:

Also while we're talking about indicators for stock parts, here's what I did with the Mystery Goo - there's a nice oval indent to the right of the word "JETTISON" which fits a nubbin well without covering up that text on the texture (although there's nothing wrong with how your normal indicator looks on that part):

Yeah, I waffled a bit with the Goo, and actually considered a circular indicator more or less like the one you've shown, but ended up deciding that I just liked the look of the rectangular indicator more.  I covered up "Jettison" with a clear conscience because you can't actually jettison the damn thing and that label has always kinda bugged me. 

[Fwiffo]

1 hour ago, Snark said:

Barometer was a bit tricky, since it didn't really have a naturally obvious place to put the indicator, and it's concave.  I basically settled for something that looked reasonably OK to me and seemed to "fit" with the part.

Right but I think it's hidden *inside* the part right now.  Unless I have some other mod impacting my stock barometer.

1 hour ago, Snark said:

I covered up "Jettison" with a clear conscience because you can't actually jettison the damn thing and that label has always kinda bugged me.

LOL fair enough!

[Snark]

1 minute ago, Fwiffo said:

Right but I think it's hidden *inside* the part right now.  Unless I have some other mod impacting my stock barometer.

Screenshot?  Looks perfectly fine to me.

[Fwiffo]

1 hour ago, Snark said:

Screenshot?  Looks perfectly fine to me.

Nevermind, my bad.  Sorry, didn't realize it's actually inside the barometer, but still visible.

I'm actually making corrections by hand to post-welded parts created by UbioZur Welding.  For some reason it's not putting the IndicatorLights meshes in the right spot in the welded part.  They're close, but not quite right.  Haven't investigated in depth, although might have something to do with rescale factors which are known to trip up that mod.  The manual tweaking is a real pain in the butt.  Have you welded parts with IndicatorLights and run into such a problem?

Edited September 13, 2016 by Fwiffo

[Fwiffo]

Sorry for all the noise here.  Have what might be a "dumb" question.  Does IndicatorLights deal ok with parts that have modules dynamically added / removed dynamically during gameplay, or cases where the mod corresponding to some modules on the part has been removed?

I've seen "PartModule indexing mismatch" errors in my log before under certain conditions.  From what I gather they're caused when mods are removed (or a part is manually edited to add/remove a module), and it screws up the (KSP) indices assigned to part modules within a craft file.  i.e. The part at index 3 is no longer a ModuleIExpected, it's now a ModuleSomethingElse.

I'm not sure what KSP does when this occurs, but infer from log traces that it just grabs the first module with "name" matching what it expects, and maps to that.

I'm wondering since IndicatorLights modules share common names by design (e.g. ModuleControllableEmissive) if that can cause problems.

Maybe (hopefully) I just don't understand the mechanics properly and it's a non-issue!

 

[Fwiffo]

One more:  Is there a trick to getting the Fuel Cell indicators to come on?  Mine just stays dark, even after I activate the fuel cell:

Picture above is a stock IndicatorLights-patched fuel cell.  But I even tried making my own ModuleConverterIndicator with an explicit activeColor... no dice.

EDIT: After some investigating, it seems the ModuleConverterIndicator is working fine, and there's something up with rectangularIndicatorModel.  It all works fine when I change the mesh for the fuel cell indicator to a standard squareLamp, except that the "Off" color is too bright for taste and isn't impacted even if I set inactiveColor = #000000:

So rectangularIndicatorModel doesn't show any colors through at all, and squareLamp seems to have a light greyish background that I can't make darker.

EDIT: Turns out I'm having some problems with the plain old BL-01, too:

and changes to my config.xml don't seem to be having an impact.  Ahk, not sure what's going on.  (Maybe something to do with my graphics settings??)

EDIT: Also, on a different topic, there's a small bug in your documentation for ModuleConverterIndicator (should say inactive instead of active):

• inactiveColor: Optional. A ColorSource string specifying the color to display when the converter is active. If omitted, defaults to $Off.

Edited September 13, 2016 by Fwiffo

[Snark]

8 hours ago, Fwiffo said:

Have you welded parts with IndicatorLights and run into such a problem?

Nope, I've never welded anything to anything with anything.  I just use parts.

8 hours ago, Fwiffo said:

might have something to do with rescale factors which are known to trip up that mod

Yeah, in the process of decorating the various stock parts with indicator lights, I ran into all sorts of interesting quirks in the underlying stock models, including several which use rescale factors on their models, doubtless for historical reasons.

9 hours ago, Fwiffo said:

Does IndicatorLights deal ok with parts that have modules dynamically added / removed dynamically during gameplay

No.  The design assumption is that part module lists are static.  Most of my modules which display content based on the state of another module (e.g. resource level, or whatever) are based on the ModuleSourceIndicator class, whose behavior is to go and find the "target module" at OnStart time (i.e. when the part is loaded, either in flight or in the editor) and cache that reference.  So if the target module is missing at start time, then it'll never get picked up; and if it's removed after start time, it'll still be referenced.

This was done for performance reasons.  The code in IndicatorLights which sets the color of emissives does so on every update cycle, which gets called a lot, so it's important for that code path to be performant.  I didn't want each of these modules to have to hunt again on every single update cycle to find its target module, and (at least in my experience) modules tend to be fairly static, so it seemed like a safe design assumption to make.

Do you have a particular use case of a mod that dynamically adds/removes modules during flight?

 

9 hours ago, Fwiffo said:

or cases where the mod corresponding to some modules on the part has been removed?

...Hmm.  I haven't actually tested it, but I suspect it would end up working out more or less okay.  I think that what KSP does at load time, if it sees a part module that it doesn't actually have any code for, is to just ignore it and load anyway.  What my modules do when they're loading is to find the other modules on the part and pick the ones they care about.  Which is based on the list of modules that are actually loaded, so I think that any missing-modules-due-to-mod-having-been-uninstalled would be fine.

So I suspect that this case would work just fine... but I can't swear to it, since (as I said) I haven't actually tested the scenario.

 

9 hours ago, Fwiffo said:

I've seen "PartModule indexing mismatch" errors in my log before under certain conditions.  From what I gather they're caused when mods are removed (or a part is manually edited to add/remove a module), and it screws up the (KSP) indices assigned to part modules within a craft file.  i.e. The part at index 3 is no longer a ModuleIExpected, it's now a ModuleSomethingElse.

Hmm, you could be right.  I haven't really tested this at all.  I've always treated uninstalling part-affecting mods as an intrusive gamebreaker, regardless of whether it actually is or not, so in my own gameplay, I always make a point of deciding at game creation time "which mods will I use this time around?" and install those, and then never uninstall anything during the game.  I simply don't trust all mods to play nice with all other mods if something gets uninstalled.  For me it's an assume-guilty-until-proven-innocent thing, I simply have no tolerance to spend time debugging that kind of issue when all I want to do is to play my game.  So I just set things up so it can never happen.

 

7 hours ago, Fwiffo said:

One more:  <stuff about the fuel cell indicator>

Works fine for me (always has, in fact this was the very first indicator I implemented).  I suspect that this may be an interaction with some other mod you have, especially after reading this:

 

7 hours ago, Fwiffo said:

EDIT: Turns out I'm having some problems with the plain old BL-01, too:

and changes to my config.xml don't seem to be having an impact.  Ahk, not sure what's going on.  (Maybe something to do with my graphics settings??)

...This looks familiar.  By any chance are you running Texture Replacer?  It's a known issue; Texture Replacer and IndicatorLights don't play nice together.  The symptom is exactly this.  (If you read back through this thread, you'll see a few people reporting the same problem.)

7 hours ago, Fwiffo said:

EDIT: Also, on a different topic, there's a small bug in your documentation for ModuleConverterIndicator 

Not any more, there isn't.    Also, when fixing that, I noticed that I've gotten lax and didn't keep the docs up to date-- there were several emissive controller types that I've added recently to IndicatorLights but hadn't added to the docs.  That oversight has been rectified.

[Fwiffo]

@Snark Ah!  Yes, I have Texture Replacer.  Now that 64-bit (>4GB) support is official and better texture management is baked in (alleviating the need for things like Active Texture Management), I think the only thing I'm using it for is an enhanced skybox (and possibly also clouds & CityLights - assuming the EVE bundled in StockVisualEnhancements uses it... which it might not).

I'd like to troubleshoot this a little.  Did anyone make headway on figuring out why this mod and Texture Replacer are stepping on each others toes, or progress on a workaround?  Off the top of my head I tried disabling reflections in TextureReplacer; that didn't do the trick.  I saw some discussion about "whitelisting" this mod, but I think that was a red herring relevant to ATM not TR.

What are the main differences in your mu file between the squareLamp (which works fine with TR) and rectangularIndicatorModel (which doesn't)?  Or between squareLamp and the mesh(es) / texture(s) used by the BL-01?

BTW, to confirm, removing TextureReplacer solves the "black BL-01" problem, and makes your out-of-box fuel cell work (although the "off" indicators are still a bit lighter than I'd like them to be, and attempts to darken via inactiveColor = #282828 are still ineffective).  Also my attempts to tailor IndicatorLights/PluginData/IndicatorLights/config.xml (and doing a complete close & restart of KSP) don't seem to be doing anything either (which just feels really strange).

I wouldn't mind some more general info on how meshes/textures and coloring works.  A "revealing" example occurred on a weldment I made with a materials bay.  I wired up a pair of ModuleCustomColoredEmissive's to it's Glass (inner top panel with an array of blue slots) and DoorAssembly (the tiling along the interior back sides and the small round bulb on the upper right side) and played around with them:

Note the first three green sliders have nothing to do with this and can be ignored (they're for a stock Illuminator mounted lower down on the part).

Of particular interest, look what happens when Glass is made 100% red.  Only a thin red outline appears around the edges of the blue panel lights.  It almost seems like there's a mask on the mesh which is only letting some of the color through.  Is that normal / expected?  I'm wondering if the reason I can't darken your meshes to be more "black" than the normal inactive color is due to something similar (e.g. a static white background or something in the mesh).

Incidentally, the effect above can be leveraged to create a very nice "blinkenlight" pattern on the tiling (cosmetic tweak idea for your mod?).

I guess I'll have to create a stripped-down KSP for troubleshooting all this, without all the mods.  Might be some time before I get around to that (will take some surgery to the part files, savegames, etc. which I'm using).

 

19 hours ago, Snark said:

Do you have a particular use case of a mod that dynamically adds/removes modules during flight?

Sarbian mentioned here that FAR does (or used to?).  I'm hoping its dynamic ones always get appended to the end of the list and wouldn't break indices of the "static" modules.

Edited September 14, 2016 by Fwiffo

[Fwiffo]

Ok, so I solved your TextureReplacer incompatibility.  One of TextureReplacer's features is to generate mipmaps for PNG and JPEG files.  This is what's breaking your mod.

There are a few ways to work around, any of which is effective:

1. Make users disable the feature globally by setting isMipmapGenEnabled = never in TextureReplacer's @Default.cfg file (sledghammer approach).
    
2. Adjust the paths where TextureReplacer will search for missing mipmaps.  This line in its out-of-the-box @Default.cfg tells it to include any GameData subfolder whose name includes the substring "Parts" (which is why only your fuelCells and indicatorLightSmall are affected):
   
   generateMipmaps = /FX/ /Parts/ /Props/ /Spaces/
   
   Removing /Parts/ from this line eliminates the issue (another sledgehammer).
    
3. While TR makes it easy for mods to add paths to the search scope above, unfortunately as far as I can tell it doesn't provide any exclude syntax.  I've got a question / potential feature request out to them on this.
    
4. Rename your Parts folder to something else, like "CustomParts", so it's ignored by TextureReplacer.  I tested this and it works.
    
5. Resize your 2x2 pixel PNG's to 1x1 pixel.  TextureReplacer skips mipmap generation for 1x1 pixel textures.  I tested this and it works.

#5 seems like the best solution in my opinion.  Is there a reason your textures are 2x2?  Here are some 1x1 versions of the five problematic ones.

Note TR also includes some logic to defer texture optimization to Active Texture Management if the latter is installed, so that could change the behavior in that case.

Finally, while you're looking at textures you might consider converting the larger PNG's in your mod like Blinkenlights.png and Blinkenlights-Flag.png to DDS files.  It's a little more efficient and memory friendly, and I've noticed other mods going that route.  Mind you, those images are pretty darn small to start with so it's not a big deal.

[Fwiffo]

1) Suggestion: It would be nice if the fuel cell indicator blinked a warning color when the fuel cell is active but has no LiquidFuel to operate, i.e. this scenario:

2) Also another documentation tweak / question:  ModuleCustomColoredEmissive is lacking documentation for the isUiEnabled property showcased in indicatorLightSmall.cfg.  Further in this vein, is it possible to wire up ModuleCustomColoredEmissives so that they show/hide in the Editor GUI according to when a ModuleCustomBlink is enabled/disabled?

EDIT: Although I'd still love some more info on this, I've since switched to a cleaner approach using just one color swatch and dim().  It'd be great if dim() supported negative multipliers to make it brighten.

e.g. I have a part with a red navigation light which I'd like to strobe brighter for 100ms every 2 seconds.  I want the user to be able to turn it on/off, pick the "on" color and "strobe" color, and enable/disable/configure blinking.  I can wire this up and it all works, but I need some help tweaking the Editor GUI to hide the strobe color picker swatches when blinking is disabled.  i.e. The Editor GUI logic should be something like:

Blink button visible  = (ToggleLED on)                  // Works
Color swatch visible  = (ToggleLED on)                  // Works
Strobe swatch visible = (ToggleLED on && Blink enabled) // How?

Below are my controllers.  Note I don't care about providing a color selector for when ToggleLED is off.

Spoiler

    // IndicatorLights Controllers for port side nav indicator
    MODULE // Flight and Editor UI to toggle indicator on/off
    {
        name = ModuleToggleLED
        status = true // initial status
        emissiveName = navIndicator
        activeColor = ModuleCustomBlink
        inactiveColor = $Off
    }
    MODULE // Editor UI to set "on" color
    {
        name = ModuleCustomColoredEmissive
        controllerName = navColorSource
        label = Nav
        color = #660000
        isUiEnabled = true // since LED toggle initially turned on
    }
    MODULE // Editor UI to set strobe color
    {
        name = ModuleCustomColoredEmissive
        controllerName = navStrobeSource
        label = Nav Strobe
        color = #CC0000
        isUiEnabled = true // since LED toggle and blink initially turned on
    }
    MODULE // Editor UI to tailor blink, and Flight/Editor UI to disable blink
    {
        name = ModuleCustomBlink
        onColor = navStrobeSource
        offColor = navColorSource
        blinkEnabled = True
        onMillis = 100
        offMillis = 2000
        phase = 0
    }

 

3) And another question or two: I've got a weldment which includes:

    MODEL // Port side nav indicator
    {
        model = IndicatorLights/Parts/indicatorLightSmall/model
        position = -0.76, 0.164, 0.286
        scale = 1, 1, 1
        rotation = 90, 270, 0
    }

Is there any reason I'm stuck using "native" syntax and the MM-form targets indicated below aren't working?

    MODULE
    {
        name = ModuleControllableEmissive
        // target = IndicatorLights/Parts/indicatorLightSmall/model  // DOESN'T WORK
        // target = IndicatorLights/Parts/indicatorLightSmall        // DOESN'T WORK
        target = light                                               // WORKS
        emissiveName = navIndicator
    }

Note I've only got one indicatorLightSmall in the part, and I can target other meshes using the MM-style syntax just fine.

Is it because the light mesh is "buried deeper" in the model?  If so, is there any sort of "hybrid" syntax to target specific meshes buried in ModuleManager'd parts, e.g. something like:

target = IndicatorLights/Parts/indicatorLightSmall/model/light

In case it helps, here's a full dump of my meshes, obtained by temporarily creating a bogus emissive / controller to prompt IndicatorLights to write "Did you mean...?" messages to my log:

Spoiler

obj_base
flagTransform
(Clone)
Box008
Cylinder001
Box001
Box002
Cylinder002
Box003
Cylinder003
Box004
Cylinder004
Box005
Cylinder005
Box006
Cylinder006
Box007
Cylinder011
Cylinder012
Object001
Object002
Box009
Box010
ChamferBox001
Cylinder009
Cylinder010
Object003
(Clone)
ksp_s_resourceContainer_fbx
ksp_s_resourceContainer_fbx_001
light2
model
bezel
light
octostrut
DoorAssembly
LeftFrontSlat
LeftSlat
LowerSlat
RightFrontSlat
RightSlat
UpperSlat
Glass
Line001
Line002
SampleContainer
WiresPlaneL
WiresPlaneLower
WiresPlaneR
WiresPlaneUpper
(Clone)
(Clone)
Cylinder
Capsule001
Object001
(Clone)
barometer
(Clone)
accelerometer
(Clone)
gravimeter
(Clone)
thermometer
(Clone)
obj_base
(Clone)
rung
rung
rung
rung
rung
rung
cubestrut
cubestrut
cubestrut

Edited September 15, 2016 by Fwiffo
Clarification

[Snark]

On 9/13/2016 at 3:44 PM, Fwiffo said:

(although the "off" indicators are still a bit lighter than I'd like them to be, and attempts to darken via inactiveColor = #282828 are still ineffective)

...

Is that normal / expected?  I'm wondering if the reason I can't darken your meshes to be more "black" than the normal inactive color is due to something similar (e.g. a static white background or something in the mesh).

So, here's how the appearance of the light works:  It has two important colors.

• The "diffuse" color, i.e. the actual "native" color of the object when viewed in reflected ambient light, rather than what it emits.
• The "emissive" color, i.e. the intensity and color of the light it produces itself.

The "diffuse" color is easy to understand.  When you have an actual, real light bulb and you turn it off, it doesn't turn into a black hole in space.    It has some color of its own (generally either white or light gray, to the human eye, for most lightbulbs).  In game terms:  setting this to white means it's a white object, setting it to black means it's a black object.

The "emissive" color works differently; "black" means "emits no light".

In IndicatorLights, the diffuse color is a constant, controlled by the color of the built-in model.  The "emissive" color is what the mod's code tinkers with.

So... the darkest you can ever make an indicator is to set its emissive color to black (meaning "emit no light at all")... but then it will still have the native "built in" color of the light bulb itself, which in my case is determined by the lightbulb.png texture.  I've made that a somewhat-dark gray (in order to make the turned-off lights be visibly off).  Perhaps I should make it a tad darker.  I don't want to make it too dark, because I don't want the turned-off light bulbs to look black.

On 9/14/2016 at 6:31 AM, Fwiffo said:

Ok, so I solved your TextureReplacer incompatibility.  One of TextureReplacer's features is to generate mipmaps for PNG and JPEG files.  This is what's breaking your mod.

Oh frabjous day!  THANK YOU for running this down.  You're a lifesaver.  I regret that I can only give that post one "like".

So, basically, it's just a TR bug.  Generating mipmaps for a 2x2 flat-gray texture should produce mipmaps that are the same flat-gray, not black.  That unambiguously sounds like a TR bug to me.

In the meantime, I like the workaround of using 1x1 textures to avoid the bug.  I'll do that in the next update to IndicatorLights.

Thank you for not only tracking this down, but for the extra diligence above and beyond the call of duty in really nailing down the parameters and the various possible workarounds.

On 9/14/2016 at 6:31 AM, Fwiffo said:

Finally, while you're looking at textures you might consider converting the larger PNG's in your mod like Blinkenlights.png and Blinkenlights-Flag.png to DDS files.  It's a little more efficient and memory friendly, and I've noticed other mods going that route.  Mind you, those images are pretty darn small to start with so it's not a big deal.

Yeah, it's been on my to-do list for a while.  Simple to do, the only reason I haven't gotten around to it is precisely for the reason you mention-- I only have two textures of significant size thus far, and they're pretty little.  I'll get around to it at some point.

16 hours ago, Fwiffo said:

Suggestion: It would be nice if the fuel cell indicator blinked a warning color when the fuel cell is active but has no LiquidFuel to operate

That's not a bad idea.  I know that KSP 1.2 is going to be completely rejiggering how resources flow around-- I'll take a look at what would be involved to implement this in a post-1.2 world.  Hopefully it would be pretty straightforward.

There are various ways one could come at this-- one idea that springs to mind would be to have a ModuleResourceConsumerIndicator that has a color to display when the consumer is missing something vital.  That would allow wiring it in not only to the fuel cells, but to anywhere else that consumes resources (e.g. you could have an engine that blinks a flashing red light when it's out of fuel, or whatever).  Nice and flexible, and sticks to the "make simple Lego pieces" philosophy of IndicatorLights.

I'll have to give it some thought. 

16 hours ago, Fwiffo said:

Also another documentation tweak / question:  ModuleCustomColoredEmissive is lacking documentation for the isUiEnabled property showcased in indicatorLightSmall.cfg.

Ah, good point, I should address that-- thanks.

16 hours ago, Fwiffo said:

Further in this vein, is it possible to wire up ModuleCustomColoredEmissives so that they show/hide in the Editor GUI according to when a ModuleCustomBlink is enabled/disabled?

Hmmm, now there's an interesting question.  Let me get back to you on that-- I'd like to think on it when I have all the code in front of me in my development environment (I'm not at my KSP computer right now).  It may or may not be possible; I'm guessing not, but I've occasionally surprised myself with IndicatorLights turning out to be more flexible than I anticipated.

The really interesting question is, if it's not possible, what would be the elegant/simple solution to make it possible, and that sort of thing is the really fun part of software design, which is why I do this for a living and then do it for free in my spare time for fun.    Again... gonna need to think on this a bit.

16 hours ago, Fwiffo said:

It'd be great if dim() supported negative multipliers to make it brighten.

Actually, it wouldn't be a negative multiplier, it would be a multiplier greater than 1.  In other words, a multiplier of 1.5 would be "make it 50% brighter".

The culprit here is some code I wrote which deliberately clamps the brightness multiplier to the range 0 to 1.  I should go in and tweak it to allow multipliers >1.  Of course, in that case, the name "dim" for this type of color source becomes a bit misleading, really it should be called "brightness" rather than "dim".  I don't want to rename "dim", for backward-compatibility reasons.  Oh well, I could always add "brightness" as a synonym for "dim", so you could have something in your .cfg like "activeColor = brightness(someSource, 1.5)".

I should just add this.  It's a trivial amount of code and would open up new possibilities to folks.

(Note that the increasing-brightness would still have to be clamped so that you can't make any individual R, G, or B component greater than maximum.  If your starting color is #FF0000 bright red, you can't make it any brighter, and trying to do brightness > 1 would have no effect.)

16 hours ago, Fwiffo said:

Is there any reason I'm stuck using "native" syntax and the MM-form targets indicated below aren't working?

That I don't know, off the top of my head.  Will need some time to dig into it once I have my KSP computer in front of me, and debugging that sort of thing can take some time.

16 hours ago, Fwiffo said:

here's a full dump of my meshes, obtained by temporarily creating a bogus emissive / controller to prompt IndicatorLights to write "Did you mean...?" messages to my log

HA! 

...sorry, just glad to see that putting that "Did you mean...?" message in the log actually helped someone the way I intended it to.  Including the use case of deliberately triggering it just to get a dump. 

I should look into the new-and-improved debug console UI with 1.2.  It already supports some user commands (i.e. you can make it do stuff by typing "/someCommand").  I wonder if that's moddable?  i.e. if I could add custom IndicatorLights commands so that you could go into the console and type "/showmeshes" or whatever and it would display interesting stuff?  That would be so cool, if possible.  Could really go to town on it.  Dunno if it's actually possible, but I should go look into that. 

...Anyway, thank you so much for your continued deep dive into IndicatorLights, and your extremely helpful constructive feedback.  Keep it coming!

[Fwiffo]

Thanks for the straightforward explanation on emissive and diffuse!

8 hours ago, Snark said:

Perhaps I should make it a tad darker.  I don't want to make it too dark, because I don't want the turned-off light bulbs to look black.

I think it looks great on everything I've noticed so far, except on the fuel cell it's a bit bright for my taste.  But it really is just a matter of personal preference :-).  I trust your judgement on any tweaks.

8 hours ago, Snark said:

I should go in and tweak it to allow multipliers >1.  Of course, in that case, the name "dim" for this type of color source becomes a bit misleading, really it should be called "brightness" rather than "dim".  I don't want to rename "dim", for backward-compatibility reasons.  Oh well, I could always add "brightness" as a synonym for "dim", so you could have something in your .cfg like "activeColor = brightness(someSource, 1.5)".

Maybe the verb "brighten" would be a better identifier for dim's counterpart.

8 hours ago, Snark said:

I should look into the new-and-improved debug console UI with 1.2.  It already supports some user commands (i.e. you can make it do stuff by typing "/someCommand").  I wonder if that's moddable?  i.e. if I could add custom IndicatorLights commands so that you could go into the console and type "/showmeshes" or whatever and it would display interesting stuff?  That would be so cool, if possible.  Could really go to town on it.

Yep, would be cool.  In the meantime a simple example in the "How to find a mesh" documentation describing how to induce a dump would be great (and probably sufficient), to help people discover that useful ability is there.

Edited September 16, 2016 by Fwiffo

[Snark]

On 9/15/2016 at 5:38 PM, Fwiffo said:

In the meantime a simple example in the "How to find a mesh" documentation describing how to induce a dump would be great (and probably sufficient), to help people discover that useful ability is there.

Yay!  It turns out that the new /command feature of the debug console is moddable!    Oh, man, I'm like a kid with a shiny new toy.

So with my next update (the 1.2 compatibility release), along with a bunch of other stuff (mainly feedback from this thread), I'm including a new console command, /il, which will allow doing various interesting things with IndicatorLights.  It'll be self-explanatory (i.e. displays help if you type /il help, and so forth).

Example usage:

Spoiler

(stuff that the user types is in boldface)

/il help
[IndicatorLights] Commands available via /il:
/il help: Shows this message
/il parts: List all IndicatorLights parts on the current vessel
/il part <index> {meshes|emissives|controllers}: Shows information about the specified part

/il parts
[IndicatorLights] 5 IndicatorLights parts found:
0: Mk1 Lander Can
1: SC-9001 Science Jr.
2: Z-400 Rechargeable Battery
3: Z-400 Rechargeable Battery
4: BL-01 Indicator Light

/il part 4
[IndicatorLights] Part 'BL-01 Indicator Light' has 2 meshes, 1 emissives, 4 controllers.

/il part 4 meshes
[IndicatorLights] Part 'BL-01 Indicator Light' has 2 meshes:
0: bezel
1: light

/il part 0 meshes
[IndicatorLights] Part 'Mk1 Lander Can' has 3 meshes:
0: obj_base
1: flagTransform
2: IndicatorLights/Meshes/squareLamp

And this gives me a nice framework for adding more options into it in the future.  Should really help the mod's debuggability, both for me and for modders who use IndicatorLights. 

 

 

 

 

 

[mikerl]

Wow, looks like the next version might be the "fwiffo edition."  Multiple science experiments in the same part is pretty rare, perhaps Dmagic's Orbital Science can help as it includes parts with 2 identical and parts with 2 different experiments.  This may help in testing that functionality.

I was messing around with changing the color on the BL-01 in the VAB when i realized I was changing the color of it when off.  I noticed that I could then give it two different colors based on on\off.  Not sure if this is intended, but it gave me an idea for a simple fuel indicator that could be green when on. and red when off when the tank is empty.  I'm not sure if the BL-01 can be set up to do this.