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

[Snark]

19 hours ago, Fwiffo said:

I'm thinking bake master "On/Off switch" functionality into a new part [module] intended to occur only once on your ship.

Not going to happen, for various design reasons:

• Any condition that's "intended to", won't be, due to the free-design nature of KSP.  Players are free to do whatever they want, so it would need to handle the multiple-instances case gracefully, which is a lot of work.
• I don't like the idea of putting whole-ship functionality on a part.  Parts are parts.  Parts are not ships.  Functionality that pertains to the whole ship belongs in the flight UI, not as a part.  And I don't do flight UI, it's not my thing.  So... given that I'm not going to implement a feature in the wrong place (because wrong place = wrong), and given that I'm also not going to implement it in the right place (because I don't do UI), then this isn't going to happen.
• For various reasons, I tend to put "add additional parts" lower in my priority queue than adding programmatic features.

That said, I do rather like the idea of giving modders access to some sort of search-the-whole-ship functionality.  In other words, I don't want to implement a part such as you've just described, but I would love it if I had enough basic building blocks in IndicatorLights that some other modder could accomplish that if they were so inclined.

However, search-the-whole-ship functionality is a very non-trivial design feature, so it's not going to happen all that soon.

19 hours ago, Fwiffo said:

I put [module] in brackets because I'm not sure if there's an efficient way to check for a module across the entire ship, and/or whether that problem becomes simpler if the mod knows it would always occur on only a specific type of part (and reading your post a little further, I see you get into that question too).  I guess there's no way to store / retrieve state information at the "ship" level?

It's doable.  It's even doable efficiently, from a performance standpoint.  But it's not simply doable.  Implementing it "right", so that it's not only robust but also performant, will take a sizeable chunk of code.  The reason it's complex:

• It's expensive to scan the whole ship because you have to look at every single part, which is an O(N) operation that there is absolutely no way to short-circuit.  You have to iterate through every single module of every single part on the ship, and there could be thousands of parts.  You can't limit it to only one kind of part because it's PartModules, not Parts, that determine behavior, and any part could have any PartModule.  There is simply no way around this.  It's expensive.
• Ships aren't static.  They can add and remove parts.  So the super-expensive scan has to be made at strategic moments, and cached somewhere intelligent.

Yes, it's doable, but it's a complicated time-consuming feature to implement, so it's not at the top of my priority queue right now.

19 hours ago, Fwiffo said:

All they have to do is stick the new "Master Switch" part somewhere onto their ship and it just works.

At the cost of putting special-case code into every single part everywhere, which I am loath to do.  It smells of building a solution, and IndicatorLights isn't about building solutions, it's about building Lego bricks that enable solutions.

19 hours ago, Fwiffo said:

Could there be a way for a toggle button somewhere on your ship to feed that "global mod variable"?  That would avoid breaking immersion from the need to drop into the debug console.  Yes, a side-effect would be the button would be game-wide rather than just for the active ship - personally I'm ok with that compromise.

Certainly it would be trivially easy to add some sort of functionality on a part menu to toggle the global variable.  But I'm not going to do it, for two reasons:

• I loathe UI clutter.  The part menus are already (IMHO) messily, irritatingly cluttered with excessive noise that doesn't belong there.  Buttons on part menus are suppost to be about the part.  This kind of button is about the ship, not about the part, so I'm not going to become part of the problem.
• There's that issue you mention about it toggling everything everywhere instead of just the ship.  I'm not okay with that.

19 hours ago, Fwiffo said:

Sorry if it offended you.

Oh, not at all-- no offense taken, and I hope I didn't give that impression.  You were being completely reasonable, you were following typical github etiquette, and I'm the one who's being persnickety here.  It's not your fault if I happen to be a selfish, cantankerous curmudgeon. 

 

[Snark]

Hi gang,

I've released v1.2.1 of IndicatorLights, a.k.a. "The Fwiffo Edition".  Not a lot of player-facing changes, other than a small bug fix; most of the changes are for moddability.  Thanks to @Fwiffo for numerous helpful suggestions.

New with this release:

• ModuleReactionWheelIndicator now supports IToggle and IScalar.
• Fixed ModuleReactionWheelIndicator bug that caused it to always flash on launch. (Thanks to Fwiffo for catching.)
• Added new toggle syntax.  Allows saying things like "and(toggle1, !toggle2)" for color sources.
• Breaking change to ModuleBooleanIndicator to use the new toggle syntax.
• Added new "if()" color source syntax. (Thanks to Fwiffo for suggesting.)
• ModuleCustomBlink now has a field that can choose where to show its UI (editor, flight, both, neither). (Thanks to Fwiffo for suggesting.)
• Modified BL-01 light's config so that its "blink enabled/disabled?" UI is only shown in the editor.
• ModuleScienceAvailabilityIndicator can now specify experiment ID and "low science" color. (Thanks to Fwiffo for suggesting.)
• Add new ModuleEmissiveArrayController, with sample config. (Experimental module, subject to breaking change without warning in future updates. You've been warned.)
• Add a global "master switch" to the mod, accessible from the debug console, that allows turning everything on and off all at once; useful for debugging purposes (or if you just want to grab a screenshot without lights everywhere).  /il enabled on or /il enabled off.  (Thanks to Fwiffo for the suggestion, though this isn't exactly what he asked for...)

So, unless you're a modder, not much to write home about, here. 

The ModuleEmissiveArrayController is, as I've said, an "experimental" module:  it's not currently in use by any part, and I reserve the right to make breaking changes to it without warning at any time.  I'm including it as a sort of "sneak peak" so folks can get a feel for some of the possibilities coming down the pike.  (To help ensure that modders don't get caught unaware, I've labeled the module with an "ExperimentalController" attribute that causes it to log a warning message at run time if it gets used.)

To give you an idea of some of the kinds of things that are possible with ModuleEmissiveArrayController, I've included some sample config, EmissiveArrays.cfg, in the github repository.  Here's what the sample config looks like in action (don't worry, I don't have plans to actually mod the HECS2 this way!):

Each of the two "arrays" is controlled by a single ModuleEmissiveArrayController, with all the animated behavior defined in color-source syntax.

Caveat:  I haven't documented any of the new stuff on the wiki... really building up a backlog, there.  Thank you for your patience, I'll try to update the docs soon.

Anyway, enjoy!

[EDIT]  Argh.    My "fix" for the reaction wheels fixed one problem (always flash at launch), and replaced it with another, which is arguably worse (always flash when in time warp).  Sigh.  That'll teach me to skimp on testing.  Oh well, expect a fix for that soon.

[Fwiffo]

I wanted to make the on/off transition of the default blinking lights on my science equipment a little less harsh, so I added some slight easing.  Also made them blue (for science!).  He's a quick, ad-hoc tutorial on compositing color source functions if anyone's interested.

1. Start out with a simple pulsate() color source.  I picked a period of 400ms, equal to the cycle of the default blink() the mod applies to stock science parts:
   
   pulsate($HighScience, 400, 0)
    
2. Feed that into a square wave blink() pattern, which will be used to gate the signal.  For the moment, it gives us a periodically flashing light which comes on instantly then appears to "drain" more slowly (great for a "red-alert" type effect):
   
   blink(pulsate($HighScience, 400, 0), 200, $Off, 200)
    
3. Shift the blink pattern to uncover the pulsate portions we're actually interested in.  Here we center the orange "on" portions at the blue peaks.  Note a positive phase moves the signal left, and negative moves it right.  We want to shift by 100ms, which works out to 0.25 of the total cycle.  Note we also push up the minimums of the pulsate() waveform to 0.5, which starts the flashes at a higher brightness and reduces the ramping effect (I want the dimming to be subtle):
   
   blink(pulsate($HighScience, 400, 0.5), 200, $Off, 200, 0.25)  // p = (1/2) * on / (on + off)
    
4. Finally, we add some emphasis by widening the "on" segments (by 25%, or an eighth on each side) and shifting the blink slightly to the right (reducing the phase shift by 25ms), so the lights illuminate more quickly than they go out.  This was entirely to tweak things to personal taste:
   
   blink(pulsate($HighScience, 400, 0.5), 250, $Off, 150, 0.25)  // p = (2/5) * on / (on + off)

Here's what it looks like in the end.  The top LED is mine, the lower one is the default (from version 1.2 of the mod).  In my own game I also slowed mine down slightly more than seen here, which made the effect more prominent.

It's completely a matter of taste - I just found the softer blink more appealing when there are lots of these things going off at once all over your ship :-).

Some friendly suggestions to @Snark after going through this exercise:

• Next wiki update, add some documentation to pulsate() clarifying which end is which (i.e. in 3-parameter form it starts at 1, and ends at the value you give it).
• Consider adding a phase parameter to pulsate() to give modders a bit more flexibility.
• Clarify docs as to which direction positive and negative numbers shift the phase.

EDIT: Open the spoiler to see a couple slower variants suitable for the mediumValueColor source (to indicate availability of lesser science).

Spoiler

blink(pulsate($MediumScience, 600, 0), 400, $Off, 800, 0.0833)  // p = (1/4) * on / (on + off)

blink(pulsate($MediumScience, 600, 0), 400, $Off, 800, 0.22)  // p = (2/3) * on / (on + off)

 

I settled on the second one, which emphasizes the ramp-up time and further distinguishes it from the highValueColor animation above.

Edited October 29, 2016 by Fwiffo

[Fwiffo]

On 10/27/2016 at 3:00 PM, Snark said:

a.k.a. "The Fwiffo Edition"

Awe, gee, well, shucks.

On 10/27/2016 at 3:00 PM, Snark said:

To give you an idea of some of the kinds of things that are possible with ModuleEmissiveArrayController

How cool would that be on a thermometer!  If you sized these just right you could make the mercury (or hot/cold squares) actually look like it's rising with temperature.

Edited October 29, 2016 by Fwiffo

[Vorg]

I had a thought a few days ago about indicators for science. The way it is now, if the science has been collected and is back at KSC, the lights stay off. What about an option to have the lights come on, maybe a different color If you have it back at KSC, but not on the local craft. This would be handy when re-collecting new samples to be stuffed in a lab.

[Fwiffo]

The wiki entry for ModuleCrewIndicator says:

• toggleName: Optional. A string that references a toggle module (e.g.ModuleCrewIndicatorToggle) to control whether the crew indicator is on or off. If omitted, the indicator is always on.

Are you sure having a ModuleCrewIndicatorToggle is optional?  I had a craft without one, and had trouble getting it to show the crew status.

Then I tried a simpler test by commenting out the following lines on your mk1can.cfg patch:

//  MODULE {
//      name = ModuleCrewIndicatorToggle
//      toggleName = indicatorToggle
//  }
    
    MODULE {
        name = ModuleCrewIndicator
        emissiveName = indicator
//      toggleName = indicatorToggle
    }

The game slowed down to a crawl in the Editor and I get a ton of these messages in the log (with verbose = 1):

Spoiler

    IndicatorLights.ModuleCrewIndicator.get_ToggleStatus ()
    IndicatorLights.ModuleCrewIndicator.get_ToggleStatus ()
    IndicatorLights.ModuleCrewIndicator.get_ToggleStatus ()
    IndicatorLights.ModuleCrewIndicator.get_ToggleStatus ()
    IndicatorLights.ModuleCrewIndicator.get_ToggleStatus ()
    IndicatorLights.ModuleCrewIndicator.get_ToggleStatus ()
    IndicatorLights.ModuleCrewIndicator.get_ToggleStatus ()
    IndicatorLights.ModuleCrewIndicator.get_ToggleStatus ()
    IndicatorLights.ModuleCrewIndicator.get_ToggleStatus ()
    IndicatorLights.ModuleCrewIndicator.get_ToggleStatus ()
                                      etc. until....
[EXC 22:29:36.803] StackOverflowException: The requested operation caused a stack overflow.

Maybe I did something wrong...

Also any reason ModuleCrewIndicatorToggle has a toggleName property instead of referencing it by its controllerName?  (Is it because controllerName's are optional and act as color sources, but toggleName should not?)

Finally, you might consider making the ModuleCrewIndicatorToggle button only visible in the Editor (or giving us an attribute to do so), not Flight UI.

Edited October 29, 2016 by Fwiffo

[Fwiffo]

On 10/27/2016 at 3:00 PM, Snark said:

ModuleCustomBlink now has a field that can choose where to show its UI (editor, flight, both, neither).

How do you use this in a CFG?  I figured out the field name is uiToggle but couldn't figure out the precise values it's expecting to parse.

EDIT: Nevermind.  I was subtly misled by the values listed above and in the changelog, but when I used Editor (capital E) it worked as expected.

Edited October 29, 2016 by Fwiffo

[Snark]

7 hours ago, Fwiffo said:

How do you use this in a CFG?

Yep, this is in the long list of stuff that I've fallen way behind on... really need to update the documentation.

[Snark]

On 10/28/2016 at 0:24 AM, Vorg said:

I had a thought a few days ago about indicators for science. The way it is now, if the science has been collected and is back at KSC, the lights stay off. What about an option to have the lights come on, maybe a different color If you have it back at KSC, but not on the local craft. This would be handy when re-collecting new samples to be stuffed in a lab.

Hm, interesting case.  I'll bear it in mind, but it's not super high on the list right now.  The issue is that it's hard to figure out a way to"multiplex" that behavior into the existing functionality without muddling things and making it too confusing.  (One of my design goals for IndicatorLights is to try to keep the lights' meaning really simple and intuitive for the user; a corollary of that is a general principle of "don't try to cram too much information into one indicator.")  The science instruments present an interesting design challenge:  there is a lot of information around them, and there are many relevant variables potentially to consider:

• Can the instrument actually take a reading in the current situation?
• If so, what's the fractional science value available?
• Does this science already exist somewhere on the ship?
• If it's a non-rerunnable experiment, has it already run?
• Is the vessel commandable or not?
• Does the vessel have a science lab?  If so, has the science lab previously processed this experiment or not?

...with all that richness of information, it took quite some head-scratching to try to find a way to boil the behavior down to something that's informative but intuitive.  I only managed it by basically just throwing the science lab under the bus and pretending like there's no such thing, and that all the user cares about is returning science for points.  With that convention, the simple "flashing = wants science, solid = has science, off = never mind" convention, with a color code according to value, seemed to hit the sweet spot.

I may come back and revisit this in the future-- either as an actual feature (if I can figure out a good way to fit it in), or as some form of additional moddability "knobs" on the ModuleScienceAvailability indicator, so that if someone wanted behavior such as you describe, they could do it by tweaking the .cfg files to make it act how they want.  (Right now there's no way to do it with just .cfg.)

[Vorg]

It currently does an AND/OR check for science on the craft and KSC right? So an option to remove the KSC check at the module ether for that module or shipwide and just leave the color as is. Then it only checks the craft for the science and lights up if not regardless of what is sent back to KSC. The only reason for the color change is a reminder that you don't need that one back at KSC.

Edited October 31, 2016 by Vorg

[Snark]

4 hours ago, Vorg said:

It currently does an AND/OR check for science on the craft and KSC right? So an option to remove the KSC check at the module ether for that module or shipwide and just leave the color as is. Then it only checks the craft for the science and lights up if not regardless of what is sent back to KSC. The only reason for the color change is a reminder that you don't need that one back at KSC.

It's a bit more complex than that, but yes, something along those general lines would work.  However, it's a question of how to fit it into the existing behavior in a way that avoids undesired side effects:  either putting too much special-case code into a general-purpose module, or not actually addressing all the desired behavior, or making future enhancements to the module awkward, etc.

Like I said, am not saying "no", just that I need to think about it, and it's not high on the priority list right now.

[Snark]

Hi all,

I've released v1.2.2 of IndicatorLights.  No new player-facing features (other than one bug fix); this one's all about moddability.

• Fixed the ModuleReactionWheelIndicator bug I introduced in 1.2.1 which made it flash in time warp.  (I "fixed" this by removing the flash-when-no-electricity feature completely, since I came to the conclusion that there's no reasonable way to make it work correctly.)
• Breaking change to ModuleScalarIndicator to use new scalar syntax.
• Update pulsate color source to allow a "phase" parameter. Switched the order of the two multipliers.
• Updated "/il part" command to allow dynamically (and non-persistently) setting ColorSource fields on the fly, for debugging.
• Add new "lerp" color source type.  Syntax: lerp(scalarID, colorSource1, scalarValue1, colorSource2, scalarValue2)
• Add new parseable scalar syntax. Includes function types: scale, offset, range, lt, gt, max, min, average, scalar
• Add more parseable toggle function types: gt, lt, ge, le, eq, between

And no, I don't have the docs up to date for this yet.  That's my next thing.  Unless someone reports some horrible gut-wrenching bug that I've managed to introduce and which needs fixing right away, I'm not gonna write another line of IndicatorLights code until I've gotten the documentation updated.  I've let that slide for too many releases now.  I'll post an update here once the docs are up to snuff.

Aside from adding various new types of color source syntax, the feature in this release that I'm happiest with is the "override" ability in the debug console.  This lets you tinker with the color source syntax of a ship (either in the editor, or while in flight):  type a string, and you can instantly see it take effect on the ship.  Can be really handy if you're hacking around in the color source language and don't want to have to go through umpteen cycles of "try it out, no that's not quite right, restart KSP and try again".  I'll have full instructions on how to use this feature once I've got the docs updated, but it tries to be self-explanatory-- just type "/il help" in the debug console and take it from there.  Note that this feature does not allow permanently editing anything-- it's a temporary override only, not saved anywhere, will be wiped out the next time the ship is loaded.

To non-modders:  Enjoy the, um, well, basically nothing new!

To modders:  Enjoy the new features!  After I document them so that they're actually comprehensible.

[EDIT]  argh, I did it again.  I've managed to break the antennas, can't believe I did that.  The indicators still work, but they just show the red-green-blue-pause, red-green-blue-pause "error" animation, rather than the random-flicker animation based on data speed.  Sigh.  Oh well, expect 1.2.3 real soon.  My apologies.

[steedcrugeon]

3 hours ago, Snark said:

Can be really handy if you're hacking around in the color source language and don't want to have to go through umpteen cycles of "try it out, no that's not quite right, restart KSP and try again".  I'll have full instructions on how to use this feature once I've got the docs updated, but it tries to be self-explanatory-- just type "/il help" in the debug console and take it from there. 

This little tweak alone makes this a very important update. restarting KSP for each config tweak gets me down.

[Snark]

7 hours ago, steedcrugeon said:

This little tweak alone makes this a very important update. restarting KSP for each config tweak gets me down.

Heh, thought you might find it handy.    Actually, you and Fwiffo are kind of the reason I got off my duff and added the feature-- I'd been thinking about it for quite some time, and just never got around to it.  Realizing that someone's actually writing a mod that significantly uses IndicatorLights, along with seeing the kind of fine-grained color patterns that Fwiffo has been tinkering with for science indicators, got me thinking "wow, fine-tuning the light behavior must be excruciating" and prodded me into finally implementing it.

(For the record, REKT's not the first mod to add IndicatorLights support; SpaceY has done so nearly from the beginning of IndicatorLights.  But the SpaceY usage is more straightforward than REKT's, and I don't think NecroBones had to do a lot of tinkering in color-source syntax (he added support before that was even a thing).  Thus REKT was the spur, here.)

Incidentally, FWIW, I recently learned of another tool that I've really come to love while working on IndicatorLights.  (Would link to it, except now I can't remember which thread someone mentioned this in.  Thought it was this thread here, but I haven't been able to find it.)  Turns out that ModuleManager has a debug UI you can get by pressing Alt+F11 while in the space center view.  It pops up a little dialog with a button you can press that causes it to reload the parts database.  Thus, for example, when I'm fine-tuning the position of meshes I add to a stock part, I can try it in the VAB, note the problem, go edit the .cfg file, then just exit to KSC view and ALT+F11 to reload.  It still takes a while to re-load, but is way faster than completely restarting KSP.

That functionality is a godsend to anyone doing ModuleManager hackery with .cfg files.  If what you're doing is directly modeling a part, rather than applying a patch via MM, I don't know whether this will help you or not-- specifically, I don't know whether MM is reloading everything, or just the MM patches.

[Fwiffo]

5 hours ago, Snark said:

If what you're doing is directly modeling a part, rather than applying a patch via MM, I don't know whether this will help you or not-- specifically, I don't know whether MM is reloading everything, or just the MM patches.

If it doesn't, I'm pretty sure KSP's stock "Reload database" button would (at least I assume the one in the stock menus is not put there by MM).

While we're talking debugging tools, AssemblyReloader by @xEvilReeperx is also pretty sweet (even though it doesn't get a lot of attention).  It doesn't reload assets, but does let you swap in a new version of your mod's DLL without restarting the game (I think it can even detect when the DLL is overwritten with a new one and load it automatically).  Technical details are in a PDF he used to distribute with the mod.  A long time ago I was doing a bunch of mod debugging, and between it and the mono debugger for VS2015, I had a pretty tight "Edit-Compile-Continue" cycle going.

[LeLeon]

On 28.10.2016 at 8:01 AM, Fwiffo said:

 

 

  Hide contents

blink(pulsate($MediumScience, 600, 0), 400, $Off, 800, 0.0833)  // p = (1/4) * on / (on + off)

blink(pulsate($MediumScience, 600, 0), 400, $Off, 800, 0.22)  // p = (2/3) * on / (on + off)

 

I settled on the second one, which emphasizes the ramp-up time and further distinguishes it from the highValueColor animation above.

i really like the blue lights for science and the slow interval.

Edited November 2, 2016 by LeLeon

[Snark]

Hi all,

I've released v1.2.3 of IndicatorLights.  This fixes a stupid careless bug that I introduced with 1.2.2 that broke the data display for antennas.  Cannot believe that I did that.    Anyway, here's a fix, by way of apology.

Sorry 'bout that.

Interestingly, the way I caught this was from doing documentation. I was spending some time today, gradually bringing the wiki up to date.  Documenting something thoroughly and methodically forces one to take a very close, detailed look at the thing being documented... and that turned up my "oops".

So, one lesson I hope to take from this:  it's a good idea not to let the documentation lag too far behind ongoing work.  Not that lack of docs actually caused the problem here-- but certainly if I'd been more diligent about it, I might have caught the problem sooner.  Ah well, time will tell how well I'm capable of learning from experience.

On 10/28/2016 at 10:44 PM, Fwiffo said:

The wiki entry for ModuleCrewIndicator says:

• toggleName: Optional. A string that references a toggle module (e.g.ModuleCrewIndicatorToggle) to control whether the crew indicator is on or off. If omitted, the indicator is always on.

Are you sure having a ModuleCrewIndicatorToggle is optional?  I had a craft without one, and had trouble getting it to show the crew status.

...Oh hey, sorry, just now saw this one.  Lotta messages flew past in a relatively brief time-- I managed to lose this one in the shuffle.  The wiki documents the intended behavior, but if it's not actually doing that, I should take a look.  Thanks for the heads-up.

On 10/28/2016 at 10:44 PM, Fwiffo said:

Also any reason ModuleCrewIndicatorToggle has a toggleName property instead of referencing it by its controllerName?

Actually, yes.  If you look at  ModuleCrewIndicator.cs, you'll note that it's actually not a controller.  That is, it doesn't derive from ModuleEmissiveController-- it has no output color, it's not capable of directly driving any emissives.  It's purely an abstract toggle.

It does need to have some form of identifier, so that other controllers can reference it.  I happened to settle on toggleName rather than controllerName, simply because it's a different beastie and I didn't want to cause confusion with actual controllers.

On 10/28/2016 at 10:44 PM, Fwiffo said:

Finally, you might consider making the ModuleCrewIndicatorToggle button only visible in the Editor (or giving us an attribute to do so), not Flight UI.

Not a bad idea-- I can give it the same treatment that I gave ModuleCustomBlink, so that it's possible to choose UI visibility of none, editor-only, flight-only, or both.  I'll probably leave the default as "both", but at least this way it's possible to configure it not to have a UI.

 

[Fwiffo]

On 10/31/2016 at 8:41 PM, Snark said:

Switched the order of the two multipliers.

Could you elaborate on that please?

e.g. Do I need to switch the order of my parameters to that function in my parts to maintain old behavior?  If I used the 3-parameter format should I change it to pulsate(blah, blah, 1, old_third_parameter)?

Thanks!

Edited November 3, 2016 by Fwiffo

[Fwiffo]

Any idea what's causing this log noise when I launch a craft?

Spoiler

[EXC 07:57:05.491] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleReactionWheelIndicator.get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.492] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleResourceEnabledIndicator.get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.494] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.495] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleCustomBlink.get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.497] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleDataTransmitterIndicator.get_OutputColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.498] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.499] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.501] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.502] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.504] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.505] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.506] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.508] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.509] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleCustomBlink.get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.511] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleConverterIndicator.get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.517] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleBiomeScannerIndicator.get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.519] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleConverterIndicator.get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.520] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleConverterIndicator.get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.522] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleConverterIndicator.get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()
[EXC 07:57:05.523] NullReferenceException: Object reference not set to an instance of an object
	IndicatorLights.ModuleConverterIndicator.get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()

 

 

Edited November 3, 2016 by Fwiffo

[Fwiffo]

Feature suggestion (once you're done with getting the wiki up to date): It would be nice if one could define more complex, global, constant color sources in the settings file.  e.g. $HighScience = blink(pulsate(blahblahblah)).  Even better if we could define our own, new names.

That would allow you to get rid of all the duplicated parameters across the various parts files, give users a single place to make updates to shared patterns, and (if implemented cleverly) reduce the number of object instances required (and garbage collection impact) when running your mod (many parts could all share a reference to a single squarewave/pulsate/etc. generator).  I know it's easier said than done, but figured I'd suggest it.

Edited November 4, 2016 by Fwiffo

[Snark]

15 hours ago, Fwiffo said:

Could you elaborate on that please?

e.g. Do I need to switch the order of my parameters to that function in my parts to maintain old behavior?  If I used the 3-parameter format should I change it to pulsate(blah, blah, 1, old_third_parameter)?

Yes, exactly.  (Here's the file that changed.)

12 hours ago, Fwiffo said:

Any idea what's causing this log noise when I launch a craft?

No idea, I'll have to take a look.  Clearly it's a bug.  In the process of enabling the debug console feature that allows "live tinkering" with color sources, I had to switch around the order of initialization for some stuff, and perhaps I left a hole open.

Just to confirm, it's 1.2.3 where you're seeing this, yes?

 

3 hours ago, Fwiffo said:

Feature suggestion (once you're done with getting the wiki up to date): It would be nice if one could define more complex, global, constant color sources in the settings file.  e.g. $HighScience = blink(pulsate(blahblahblah)).  Even better if we could define our own, new names.

That would allow you to get rid of all the duplicated parameters across the various parts files, give users a single place to make updates to shared patterns, and (if implemented cleverly) reduce the number of object instances required (and garbage collection impact) when running your mod (many parts could all share a reference to a single squarewave/pulsate/etc. generator).  I know it's easier said than done, but figured I'd suggest it.

Not a bad idea, but there's an interesting grey area of design, there.  There's "what color is it", versus "what animated pattern is it", and what kind of information each one conveys.  My knee-jerk reaction is that I don't like the idea and prefer to keep them as simple colors, but I'm hard-pressed to articulate at the moment exactly why I feel that way-- it just "feels wrong" to me.  I've never really thought about it in detail.  I'll mull it over.

Even if I change my mind about the desirability, though, it's probably not super high on my list of priorities, mainly for demographic reasons.  As I see it, there are basically three categories of people who might use IndicatorLights:

1. "Regular" users:  the large numbers of folks who just download the mod and use it as-is.
2. Modders.
3. "Power" users:  folks with the skills and inclination to delve deep into the config language and use it to fine-tune their personal gameplaying experience.

Basically, I'm trying to cater to #1 and #2, not so much #3.  It's not that I don't care about power users, just that I believe they represent by far the smallest "return on investment" for the effort I put into the mod.

• "Regular users" are huge, simply because there are so many of them.
• Modders, of course, are a far tinier number than regular users... but they have an impact far out of proportion to their numbers.  If I produce a nifty feature that a single modder uses... but then a thousand people use his mod... then in effect, I've just produced a feature for a thousand people.  So I view making IndicatorLights modder-friendly to be just as important to making it great for casual users.  Perhaps even more so, depending on how well it catches on.
• Power users, though... it just seems like by far the smallest "footprint" of the three groups.  In terms of population size, they're probably a lot closer to modders than to regular users; but they're just hacking IndicatorLights for their personal use rather than publishing mods, so they don't get that multiplier effect.

Given that I only have just so many hours available to spend on IndicatorLights, and there's never enough time to do everything I want to do, I really want to maximize the effectiveness of the time I spend on the mod.  That means that features specifically of interest only to power users are likely to have to take a back seat; they're simply a victim of math.

Doesn't necessarily mean it'll never happen, just that there's a whole lot of other stuff that would be higher priority than that.

3 hours ago, Fwiffo said:

reduce the number of object instances required (and garbage collection impact) when running your mod (many parts could all share a reference to a single squarewave/pulsate/etc. generator)

This, I don't think would be much of an issue.  It may reduce the number of object instances, but not all that much.  Object instances don't take up all that much memory.  What's a real killer for KSP is garbage collection... but I've taken pains to make IndicatorLights as "garbage neutral" as possible.  Every single IndicatorLights mesh has its color adjusted on every single update cycle.  That's a lot.  The GC for doing that needs to be zero, because hundreds of lights times dozens of updates per second would hammer the computer into submission in no time.  I believe I've done a pretty good job in that regard; I don't think moving to a model like that would actually save anything significant in terms of game performance.

[Fwiffo]

2 minutes ago, Snark said:

Just to confirm, it's 1.2.3 where you're seeing this, yes?

I believe so (DLL modified date 11/3/2016 4:57AM PST).  And KSP 1.2.1.

[Fwiffo]

Noticed a minor bug while troubleshooting.  The wiki indicates the toggle attribute of ModuleCrewIndicator is optional.  However it generates log warnings (like No toggle "" found for ModuleCrewIndicator on Hopper-Mk4-LeftPylon) when that parameter is missing, due to the ParseIDs function in ModuleCrewIndicator.cs not checking for null before calling FindToggle (which in turn throws an ArgumentException).

ps. Not sure why the href part of that link isn't working.

Edited November 4, 2016 by Fwiffo

[Snark]

Hi all,

I've released v1.2.4 of IndicatorLights.  No new player-facing features; this is just a very minor update with some bug fixes and moddability improvements.  Thanks again to @Fwiffo for bug-catching and helpful suggestions.

In this release:

• Fix some recently-introduced bugs that caused log error spam.
• Fix a bug in which the supposedly optional toggleName field for ModuleCrewIndicator wasn't actually optional.
• Add a uiToggle field to ModuleCrewIndicatorToggle, allowing config to specify where the UI is available.
• Add static field specifiers to various controller fields (allows using them as static-value references in IndicatorLights syntax).
• Update to ModuleManager 2.7.3.

In addition, I'm pleased to announce that I have (finally!) gotten around to updating the IndicatorLights documentation wiki to bring it fully up-to-date.  This should be helpful to modders, who will no longer need to scratch their heads wondering how some of the newer stuff works (or, worse, have documentation that's flat-out wrong due to being out of date).

Notable additions/improvements to the documentation:

• Brought the controller reference fully up to date, including all the recently added controllers.
• Added an overview page for IndicatorLights syntax.
• Added pages for the new scalar syntax, static syntax, and toggle syntax.
• Added a page for the new IndicatorLights debug console.

Enjoy!

[Fwiffo]

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