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

[Beetlecat]

That is a wildly sophisticated implementation. I love it!!!

[Snark]

Hi all,

I'm proud to announce the release of IndicatorLights v1.1, a.k.a. "The Community Edition" (in honor of the many users who have contributed helpful suggestions, bug diagnoses, etc.)

Thanks to @Fwiffo, @Sharpy, @Beetlecat, @Kerbas_ad_astra, and @Jiraiyah for the many helpful suggestions that went into this revision!

New in this release:

• Changed to CC-BY-NC-SA license (was previously MIT).  (I don't expect this to impact users. The most substantive change is that "you can't make money from it" and "if you include it in anything, you need to have a compatible license.")
• KSP 1.2 compatibility. 
• Repackaged with ModuleManager v2.7.1 (for KSP 1.2).
• Add /il console debugging command. Try /il help for details!
• ModuleToggleLED parts (e.g. BL-01 light, docking ports) are in Light action group by default, without requiring DefaultActionGroups.
• ModuleControllableEmissive implementation reworked for stability & performance.
• Fix a bug in which multiple parts would change indicator color when one part changes status.
• Add new ModuleScienceContainerIndicator.
• Add indicators to the new KSP 1.2 "science box" part.
• Add new IScalar interface; many existing modules now implement.
• Add new ModuleScalarIndicator.
• Add new ModuleBooleanIndicator (replaces old ModuleIndirectToggleIndicator)
• Add new "examples" folder in github.
• Add an example showing how to have one indicator that tracks multiple resources. (Thanks to Fwiffo for suggesting.)
• Fix indicator positioning on mini ISRU. (Thanks to Fwiffo for pointing out!)
• ModuleScienceDataIndicator on multi-experiment parts can now specify which one. (Thanks to Fwiffo for suggesting.)
• Modify the dim() syntax to allow brightening. (Thanks to Fwiffo for suggesting).
• Fix incompatibility with Texture Replacer. (Thanks to Fwiffo for tracking this down.)
• Add compatibility with TweakScale. (Thanks to Sharpy for requesting, and explaining how.)
• Add random() color source type, along with an example. (Thanks to Beetlecat for suggesting.)
• Not included here, but: A shout-out to Kerbas_ad_astra and Jiraiyah for supplying mod-compatibility patches, which were spun out to their own mod, IndicatorLights Community Extensions.

Thanks also to Kerbas_ad_astra for a helpful discussion about software licenses.  I've been moving all my mods from their original MIT license to a more restrictive CC-BY-NC-ND.  Discussion with Kerbas, plus talking with an enterprising user who wants to incorporate IndicatorLights functionality in the new mod he's working on, convinced me to pick a more permissive license for IndicatorLights.  I settled on CC-BY-NC-SA.

Note that I haven't yet updated the modder's documentation for the new features in 1.1; that will be coming soon™, please be patient.

Anyway, enjoy! 

[DStaal]

On the licensing thing: Creative Commons recommends you not use their licenses for software.  They aren't designed for it - they are designed for more traditional literary works.

[Snark]

31 minutes ago, DStaal said:

On the licensing thing: Creative Commons recommends you not use their licenses for software.  They aren't designed for it - they are designed for more traditional literary works.

Yup, @Kerbas_ad_astra pointed that out, too.  I may reconsider in the future, if appropriate.  For now I'm fine with CC and preferred not to go with GPL for various reasons.  Licenses are an important topic, but I really don't feel like debating about them right now.  I do appreciate the concern, though, thanks for pointing out.

[Starbuckminsterfullerton]

On 10/10/2016 at 3:21 PM, Snark said:

A lot of the antennas don't exactly have a lot of open, "flat" places where it would be easy to slap on an indicator.  Where the dickens do you put an indicator on a Communotron-16, anyway? There's practically nothing there; heck, I have trouble just targeting the darn thing with my mouse.

How about some kind of ring around part of the base? For the umbrella (88-88) you could put it in the center so you can see it when it's open. For the new ones maybe a light on the end of the antenna/dish focus for the ones that don't move and on the base for those that do. 

Random blinking like you say might be a cool way to indicate active transmission, then you can use color for signal status.

Also, the science container could use a simple does/does not contain data light... if you think it's worth the effort.

Edited October 13, 2016 by Starbuckminsterfullerton

[Snark]

56 minutes ago, Starbuckminsterfullerton said:

How about some kind of ring around part of the base?

Well, if you read just a few messages above,

On 10/11/2016 at 0:44 AM, hab136 said:

Could you put a light at the base of the antenna, centered at the middle of the antenna, but thick enough that it extends out?  The effect would wind up being that most of the light is hidden by the mast of the antenna, but a "donut" surrounds the base.

 

On 10/11/2016 at 1:30 PM, Snark said:

Yah, that's pretty much what I was thinking.

 

And,

1 hour ago, Starbuckminsterfullerton said:

Also, the science container could use a simple does/does not contain data light... if you think it's worth the effort.

Actually, I did, which is why:

4 hours ago, Snark said:

• Add indicators to the new KSP 1.2 "science box" part.

...The implementation on the science container is pretty similar to the science instruments:  green for high-value science, yellow for medium, dim red for low, off for none.  If it contains multiple science results, it will show a color based on the highest-value result.

Enabling this functionality on the science container involved implementing a new ModuleScienceContainerIndicator.  Right now the only part that actually uses it is the science container, but (for example) if someone wanted to have such indicators on other science-container parts (e.g. a crew capsule, or one of the larger probe cores), it would be possible to add them with some ModuleManager config.

 

[Starbuckminsterfullerton]

6 minutes ago, Snark said:

Well, if you read just a few messages above

Argh I thought I was on the last page!

Edited October 13, 2016 by Starbuckminsterfullerton

[KerbMav]

This is so ... squeeek!!

[Snark]

Hi all,

I've released v1.2 of IndicatorLights, a.k.a. "The Antenna Edition".  Three guesses what's in this one. 

All antennas now have an indicator that lights up while science data is being transmitted.  The light has a random "flicker", like old-style modem lights.  The speed of the flicker is tied to the transmission speed of the particular antenna:  faster antenna = faster flicker.  (Thanks to @Beetlecat for suggesting the feature.)

Note that the screenshot above is for illustrative purposes only, and isn't typical of what you'd see in-game.  Normally you'd never see that many antennas lit up at once, unless you happen to have scads of science data and everything's actually transmitting simultaneously.  Here's what it looks like in action:

Besides the antennas, other changes in this version include:

• Fixed a bug that caused IndicatorLights-enabled meshes to break the thermal overlay display.  (The Science Jr. was especially bad, since it affected the whole part.  Most parts, it's just the actual indicator meshes themselves.)
• Added some new "scalar" parsing syntax for more flexible configurability of color sources.  (This is of interest mainly to modders; the idea is to enable certain modules to declare "scalar fields" that can be referenced in ColorSource syntax.  It's how I get the antenna lights' flicker speed to be automatically tied to the antenna's data rate.  I've fallen way behind on updating the "modder's guide" documentation... this feature will make a lot more sense once I've had a chance to update the docs.  Thank you for your patience.)

Enjoy!

[Fwiffo]

Neat!  And in time for Christmas; I won't need a tree ;-)

[Fwiffo]

Hey @Snark I'm updating some of my parts to your latest IndicatorLights.  I noticed you have an MM patch for the Mk 1 Lander Can which makes use of excludedRenderer.  Where did you learn of this magical directive and what does the "(Clone)" syntax mean?

For a part that has several different emissives meshes can I do something like:

excludedRenderer = IndicatorLights/Meshes/squareLamp(Clone)
excludedRenderer = IndicatorLights/Parts/indicatorLightSmall/model(Clone)
excludedRenderer = IndicatorLights/Meshes/nubbinLamp(Clone)
excludedRenderer = IndicatorLights/Meshes/squareLamp2(Clone)

Also really interested whether the treasure chest you found it in has something that might give me a better way to deal with #3 and #4 here (e.g. a way to more fully-qualify animationName when multiple meshes on a part have animations with the same name, and tie them to specific ModuleScienceExperiment's).

ps. I noticed (with some help from GitHub's searchbox)  ;-).

Edited October 22, 2016 by Fwiffo

[Fwiffo]

On 10/12/2016 at 4:16 PM, Snark said:

Modify the dim() syntax to allow brightening

Did you end up implementing a complementary brighten() verb?

I see there is indeed.  Any reason you went with "brightness" instead of "brighten"?  Not a big deal, just wondering :-).

Edited October 22, 2016 by Fwiffo

[Fwiffo]

On 10/12/2016 at 4:16 PM, Snark said:

ModuleScienceDataIndicator on multi-experiment parts can now specify which one.

Why doesn't ModuleScienceAvailabilityIndicator also have an experimentId field?

How does it currently pick which experiment to indicate?  (Or does it activate whenever any science is available?)

Edited October 22, 2016 by Fwiffo

[katateochi]

@Snark this is a really nice mod! adds nice functionality and some pretty! Thanks for making this.

[Snark]

6 hours ago, Fwiffo said:

 I noticed you have an MM patch for the Mk 1 Lander Can which makes use of excludedRenderer.  Where did you learn of this magical directive

From chatting privately with one of the devs.  In KSP 1.2, ModuleColorChanger was added to the "old-school" crewed parts (like the Mk1 command pod), which gave us cabin lights... but happened to completely break IndicatorLights on those parts.  Was asking a dev about it.  It turns out that there's a feature includedRenderer and excludedRenderer on that module that gives the part to specify specific meshes not to be controlled by ModuleColorChanger.  So I added excludedRenderer for my meshes, to prevent my module from arm-wrestling with Squad's.

 

6 hours ago, Fwiffo said:

what does the "(Clone)" syntax mean?

It's a ModuleManager wart.  Whenever you add a mesh to a part via ModuleManager (like this), it turns out that ModuleManager actually appends the word "(Clone)" to the end of the name of the mesh in the part.  I have no idea why it does this, it just does.

In most of the IndicatorLights config, you never see this, because I've specifically added IndicatorLights code to deal with the "(Clone)" thing.  By doing this, I can hide that detail from the user, so you can just say things like this without having to insert a silly "(Clone)" all over the place.

However, in the config line that you noticed, I can't hide the "(Clone)", because I'm giving a directive to a stock Squad module and I need to tell it the actual, literal name of the mesh on the part.

6 hours ago, Fwiffo said:

Also really interested whether the treasure chest you found it in has something that might give me a better way to deal with #3 and #4 here (e.g. a way to more fully-qualify animationName when multiple meshes on a part have animations with the same name, and tie them to specific ModuleScienceExperiment's)

Alas, no.  It's only a specific thing to ModuleScienceExperiment. I wouldn't have a clue about the ModuleAnimateGeneric issues you're running into.

3 hours ago, Fwiffo said:

Any reason you went with "brightness" instead of "brighten"?

Mainly that "brighten" felt weird to me when it could be actually dimming.  "brightness" struck me as more neutral.

2 hours ago, Fwiffo said:

Why doesn't ModuleScienceAvailabilityIndicator also have an experimentId field?

Because it didn't occur to me and nobody mentioned it until now.  See, not all answers have to be complicated.    (Yeah, I should add that.)

2 hours ago, Fwiffo said:

How does it currently pick which experiment to indicate?

It just iterates modules on the part and picks the first ModuleScienceExperiment it comes across-- the same way that ModuleScienceDataIndicator used to do, before I added the feature to allow specifying experimentId.  I just need to add that feature to ModuleScienceAvailabilityIndicator too.

 

[Fwiffo]

8 minutes ago, Snark said:

3 hours ago, Fwiffo said:

Why doesn't ModuleScienceAvailabilityIndicator also have an experimentId field?

Because it didn't occur to me and nobody mentioned it until now.  See, not all answers have to be complicated.

I'd be happy to beta test it.  My multi-science-module part has experimentId lines ready and waiting to be uncommented ;-)

[Fwiffo]

I'm having trouble getting the new experimentId stuff to work properly.  I have a craft that includes two ModuleScienceExperiment's with different experimentId's (mysteryGoo and temperatureScan), but both are behaving as if they're hooked up to the mysteryGoo.

Here's my part:

Spoiler

PART
{
	name = MultiScienceIndicatorTest
	module = Part
	author = Fwiffo
	rescaleFactor = 1
	PhysicsSignificance = -1
	node_stack_bottomfuelTankSmall0 = 0.062, -0.817, 0.089, 0, -1, 0, 1
	node_stack_topprobeCoreHex3 = 0.062, 0.669, 0.089, 0, 1, 0, 0
	node_attach = 0.626, 0, 0, 0.125, 0, 0, 1
	CrewCapacity = 0
	TechRequired = generalRocketry
	entryCost = 10700
	cost = 2705
	category = Pods
	subcategory = 0
	title = MultiScienceIndicatorTest
	manufacturer = Fwiffo Industries
	description = Demonstrates IndicatorLight problem with multiple experiments on board.
	attachRules = 1,1,1,1,0,0,0
	mass = 0.285
	vesselType = Probe
	dragModelType = default
	maximum_drag = 0.188
	minimum_drag = 0.178
	angularDrag = 1.1880
	crashTolerance = 9.228
	breakingForce = 34.281
	breakingTorque = 34.281
	maxTemp = 1200
	fuelCrossFeed = True
	explosionPotential = 0.5
	thermalMassModifier = 1
	heatConductivity = 0.12
	emissiveConstant = 0.4
	radiatorHeadroom = 0.25
	bulkheadProfiles = srf
	MODEL
	{
		model = Squad/Parts/FuelTank/fuelTankT200/model
		position = 0.062, -0.262, 0.089
		scale = 1.25, 1.25, 1.25
	}
	MODEL
	{
		model = Squad/Parts/Science/GooExperiment/GooExperiment
		position = -0.278, -0.282, -0.251
		scale = 0.6, 0.6, 0.6
		rotation = 0, 45, 0
	}
	MODEL // IndicatorLight for goo (squareLamp index 0)
	{
		model = IndicatorLights/Meshes/squareLamp
		position = -0.407, -0.282, -0.466
		scale = 0.3, 1.02, 0.3
		rotation = 0, 315, 0
	}
	MODEL // IndicatorLight for goo (squareLamp index 1)
	{
		model = IndicatorLights/Meshes/squareLamp
		position = -0.149, -0.282, -0.466
		scale = 0.3, 1.02, 0.3
		rotation = 0, 135, 0
	}
	MODEL
	{
		model = Squad/Parts/Science/sensorThermometer/model
		position = -0.132, -0.267, -0.444
		scale = 1, 1, 1
		rotation = 0, 20, 0
	}
	MODEL // IndicatorLight for thermometer (squareLamp index 2)
	{
		model = IndicatorLights/Meshes/squareLamp
		position = -0.132, -0.151, -0.495
		scale = 0.6, 0.3, 0.5
		rotation = 0, 200, 0
	}
	MODEL
	{
		model = Squad/Parts/Command/probeCoreHex/model
		position = 0.062, 0.481, 0.089
		scale = 1, 1, 1
	}
	MODEL
	{
		model = Squad/Parts/Electrical/z-100Battery/model
		position = -0.109, 0.483, -0.207
		scale = 1, 1, 1
		rotation = 0, 30, 0
	}
	MODEL // IndicatorLight for battery (z100lamp index 0)
	{
		model = IndicatorLights/Meshes/z100lamp
		position = -0.067, 0.691, -0.29
		scale = 1.02, 1, 1.02
		rotation = 0, 30, 0
	}
	RESOURCE
	{
		name = LiquidFuel
		amount = 0
		maxAmount = 90
	}
	RESOURCE
	{
		name = Oxidizer
		amount = 0
		maxAmount = 110
	}
	RESOURCE
	{
		name = ElectricCharge
		amount = 110
		maxAmount = 110
	}
	MODULE
	{
		name = ModuleAnimateGeneric
		animationName = Deploy
		startEventGUIName = Deploy
		endEventGUIName = Close
		actionGUIName = Toggle Cover
		evaDistance = 1.5
	}
	MODULE
	{
		name = ModuleScienceExperiment
		experimentID = mysteryGoo
		experimentActionName = Observe Mystery Goo
		resetActionName = Reset Goo Canister
		useStaging = False
		useActionGroups = True
		hideUIwhenUnavailable = True
		xmitDataScalar = 0.3
		FxModules = 0
		dataIsCollectable = True
		collectActionName = Collect Data
		interactionRange = 1.5
		usageReqMaskInternal = 1
		usageReqMaskExternal = 8
	}
	MODULE
	{
		name = ModuleScienceExperiment
		experimentID = temperatureScan
		experimentActionName = Log Temperature
		resetActionName = Delete Data
		useStaging = False
		useActionGroups = True
		hideUIwhenUnavailable = False
		xmitDataScalar = 0.5
		dataIsCollectable = True
		collectActionName = Take Data
		interactionRange = 1.5
		rerunnable = True
		usageReqMaskInternal = 1
		usageReqMaskExternal = 8
	}
	MODULE
	{
		name = ModuleEnviroSensor
		sensorType = TEMP
	}
	MODULE
	{
		name = ModuleCommand
		minimumCrew = 0
		hasHibernation = True
		RESOURCE
		{
			name = ElectricCharge
			rate = 0.025
		}
	}
	MODULE
	{
		name = ModuleReactionWheel
		PitchTorque = 0.5
		YawTorque = 0.5
		RollTorque = 0.5
		RESOURCE
		{
			name = ElectricCharge
			rate = 0.05
		}
	}
	MODULE
	{
		name = ModuleSAS
		SASServiceLevel = 1
	}
	MODULE
	{
		name = ModuleKerbNetAccess
		MinimumFoV = 17
		MaximumFoV = 63
		AnomalyDetection = 0.12
		DISPLAY_MODES
		{
			Mode = Terrain
		}
	}
	MODULE
	{
		name = ModuleDataTransmitter
		antennaType = INTERNAL
		packetInterval = 1.0
		packetSize = 2
		packetResourceCost = 12.0
		requiredResource = ElectricCharge
		antennaPower = 5000
		optimumRange = 2500
		packetFloor = .1
		packetCeiling = 5
	}
	MODULE
	{
		name = ModuleControllableEmissive
		target = IndicatorLights/Meshes/squareLamp:0,1
		emissiveName = gooIndicator
	}
	MODULE
	{
		name = ModuleControllableEmissive
		target = IndicatorLights/Meshes/squareLamp:2
		emissiveName = thermometerIndicator
	}
	MODULE
	{
		name = ModuleControllableEmissive
		target = IndicatorLights/Meshes/z100lamp:0
		emissiveName = batteryIndicator
	}
	MODULE
	{
		name = ModuleScienceDataIndicator
		experimentId = mysteryGoo
		emissiveName = gooIndicator
		dataColor = $HighScience
		partialDataColor = $MediumScience
		lowDataColor = $LowScience
		emptyColor = $Off
		lowScienceThreshold = 0.25
		highScienceThreshold = 0.8
	}
	MODULE {
		name = ModuleScienceDataIndicator
		experimentId = temperatureScan
		emissiveName = thermometerIndicator
		dataColor = $HighScience
		partialDataColor = $MediumScience
		lowDataColor = $LowScience
		emptyColor = $Off
		lowScienceThreshold = 0.25
		highScienceThreshold = 0.8
	}
	MODULE
	{
		name = ModuleResourceLevelIndicator
		resourceName = ElectricCharge
	}
	MODULE
	{
		name = ModuleResourceEnabledIndicator
		resourceName = ElectricCharge
		enabledColor = ModuleResourceLevelIndicator
		disabledColor = blink(ModuleResourceLevelIndicator, 900, $Off, 300)
		emissiveName = batteryIndicator
	}
}

 

Did I do something wrong, or is this a bug?

[Snark]

25 minutes ago, Fwiffo said:

Did I do something wrong, or is this a bug?

I'm not at a KSP computer right now, but just eyeballing your config, it generally looks pretty good.  However, I note that where you set up the ModuleScienceDataIndicator modules, you're trying to set a field named "experimentId".

However, the field is actually named experimentID, not experimentId.  "ID", not "Id".  I don't know exactly how ModuleManager maps text values from .cfg files to actual member fields on C# classes, but I'm guessing it's case-sensitive.  If that's the case, then what you're doing is setting a nonexistent field "experimentId" (which I assume MM just ignores), and leaving experimentID at its default null value, which causes the module to follow its default behavior of "just pick the first one you see."

[Fwiffo]

Good catch; thanks!

Renamed experimentId to experimentID across the board and it's working now.

[Fwiffo]

Possible bug: Reaction wheels blink when your craft is first launched from the VAB, even when they aren't deprived.  Toggling SAS on/off fixes it.

Edit: More details in spoiler

Spoiler

I did a bit of debugging and believe this is caused because resource.available in your isDeprived function is sometimes returning stale data.

The wheels don't flash if SAS is off when you run out of electric charge.  Here is some debug output from a ship that just ran out of electric charge:

[LOG 02:41:30.407] [IndicatorLights] Reaction wheel ElectricCharge available.  Amount: 0, currentAmount: 8.37878638311208E-06, currentRequest: 8.37878638311208E-06, isDeprived: False

And they keep flashing if SAS is off when you get power back again.  Here is output from a ship that has some electric charge:

[LOG 03:02:12.136] [IndicatorLights] Reaction wheel ElectricCharge unavailable.  Amount: 0, currentAmount: 0, currentRequest: 2.7491379002069E-06, isDeprived: False

Quick & dirty code that was used in isDeprived to capture the above:

Logging.Log("Reaction wheel " + resource.name + (resource.available ? " available" : " unavailable")
    + ".  Amount: " + resource.amount + ", currentAmount: " + resource.currentAmount
    + ", currentRequest: " + resource.currentRequest + ", isDeprived: " + resource.isDeprived);

I fixed by making OutputColor only trigger the blink when isDeprived && IsAutopilotActive.  Besides, I figure if SAS is inactive, there's no need to nag the user about it being starved (and they'll already have warning lights going off on the batteries anyway).

Suggestion: ModuleScienceAvailabilityIndicator needs an "unavailableColor" and/or "lowValueColor" field so you can chain other controllers onto it.  e.g. I want to make my lander cans blink when crewReport science is available, and the rest of the time show the profession color of the kerbal inside.  Don't think I can do that with the existing building blocks.

Edit: I didn't want to wait, so went ahead and implemented those, along with the ability requested further up to constrain ModuleScienceAvailabilityIndicator to a particular experimentID.  I'm going to send you a pull request with my fixes / enhancements.  I'm still pretty new to GitHub so go easy on me.

Edited October 24, 2016 by Fwiffo

[Fwiffo]

Is there a simple way to wire all my emissives or controllers (which have different color sources) to be toggled by a single master ModuleToggleLED button?  I want an "off" switch to let me turn off all the IndicatorLights under some circumstances.

Also would like a field that can disable the ModuleCustomBlink GUI button during Flight (one less button on my list).

Edit: My approach to this is going to be defining several ModuleBooleanIndicators (one for each emissive) and gating them all by the master toggle.  I suggest you add a "ternary" ColorSource function that takes a toggle and two color sources as its inputs; it would make it possible to do this sort of thing with a lot less verbosity and less modules.

Edit: I went ahead and implemented a toggle() parameterized ColorSource, which I think might be convenient in some cases.  Tried to add it to my open PR or make a new one, but GitHub is foobared at the moment ("Oops something went wrong" responses).  Might try again later, in the meantime the changes are in ColorSource.cs in my Fwiffo2 branch.

In retrospect, it doesn't quite completely solve what I wanted to achieve.  I think what I'm really after is a master "lightswitch" part that turns off all the indicator lights on your whole ship (not just in the one part).  I love Indicator Lights, but it would be handy for those times you want to take a screenshot without the "Christmas Tree" effect (did I mention I appreciate the restraint you've exercised in that regard?).

Edited October 25, 2016 by Fwiffo
Another new feature

[steedcrugeon]

23 hours ago, Fwiffo said:

Possible bug: Reaction wheels blink when your craft is first launched from the VAB, even when they aren't deprived.  Toggling SAS on/off fixes it.

I have observed this happening as well during my parts testing. It is most peculiar but as stated a quick toggle of SAS and everything is normal

[Fwiffo]

15 hours ago, steedcrugeon said:

I have observed this happening as well during my parts testing. It is most peculiar but as stated a quick toggle of SAS and everything is normal

Thanks for confirming.  I fixed this in my personal version and sent a copy of the source code to @Snark in a pull request.  Here's a copy of my bootleged DLL if you want to test (link removed at the very understandable and kindly-made request of Snark), and here's its unofficial changelog.

It did entail removing the flashing "starvation" indicator when SAS is disabled.  But I argue the warning should be disabled in any case when SAS is disabled.  My reasoning is, if SAS is disabled, then presumably the reaction wheels are dormant (correct me if I'm wrong) so they aren't really "staved".  (And in most cases where this is likely to occur you have other indicators that will be going off anyway, e.g. batteries).  When SAS is enabled the starvation warning works just like it does today.

Snark might feel differently and rework / exclude that fix.

Edited October 25, 2016 by Fwiffo
Remove DLL link

[Snark]

On 10/23/2016 at 11:21 PM, Fwiffo said:

Possible bug: Reaction wheels blink when your craft is first launched from the VAB, even when they aren't deprived.  Toggling SAS on/off fixes it.

Yup, I've recently noticed that myself.  Coulda sworn it didn't do that in the past-- perhaps something changed in the way resource flow is handled in 1.2?  Anyway, I've spent some time digging into this, and have reluctantly come to the conclusion that what I want ("flash if you don't have the resources needed to do your job") isn't physically possible.  Resource consumers have a "deprived" flag that gets set when they ask for resources and don't get it, and which gets turned off when they ask for resources and do get it.  There's no way to clear that flag without actually demanding a resource.  (It's the moral equivalent of having a queue where the only way to tell if it's empty is to try to pop something out of it-- there's no non-destructive way to check.)  Perhaps, if I really really wanted to, I could come up with some hacky byzantine workaround that involves extensive reverse engineering of Squad's internal algorithm in order to try to accomplish this... but I don't know if that's actually possible, and even if it were, I seriously don't want to go there.

So I'll be walking this feature back, and making it so that it only flashes in the case "autopilot = on" and "operational = false".  That's a pity, because I would have liked to have it when autopilot is off, too-- that's a useful feature.  (Player:  "Hey, I'm trying to rotate my ship and nothing's happening!  What's going on?  <flash flash flash>  Oh, okay, my reaction wheels are out of power."  Nope, can't have that.  Oh well.)

On 10/23/2016 at 11:21 PM, Fwiffo said:

Suggestion: ModuleScienceAvailabilityIndicator needs an "unavailableColor" and/or "lowValueColor" field so you can chain other controllers onto it.  e.g. I want to make my lander cans blink when crewReport science is available, and the rest of the time show the profession color of the kerbal inside.  Don't think I can do that with the existing building blocks.

Agreed, good point.  Going back and looking at the code, in retrospect I have no idea why I didn't do it that way in the first place, instead of hard-coding it to "off" as I did.  (IndicatorLights has grown enough now that it can be hard for me to remember the rationale for specific design decisions, sometimes... maybe I was just tired or distracted on that day.) 

On 10/23/2016 at 11:21 PM, Fwiffo said:

I'm going to send you a pull request with my fixes / enhancements.  I'm still pretty new to GitHub so go easy on me.

Thanks, and that's very thoughtful of you.   Actually, however, all I need is a feature request and/or specific description of the problem, and I'll take care of the coding end myself.  I don't actually take pull requests; I prefer all lines of code to come directly from me.

It's not that I don't trust you... it's just that my mental ability to keep track of what's happening everywhere is largely predicated on the fact that it's all me, and I'm relentlessly consistent about what I do (usually), and so if I see something odd happen, I know huge swaths of possibility space that I don't have to investigate because I know what I didn't do.

For me, taking a pull request-- from anyone who isn't me-- would be kind of like if some competent, organized, and well-meaning family member of mine were to come in and "tidy up" my office for me when I'm not there.  It might be a great job, and it might "organize" things nicely... but I would be hopelessly lost the moment I stepped into my office, because nothing would be placed where I put it, even if the new placement is somehow objectively "better" than what I did.

10 hours ago, Fwiffo said:

Is there a simple way to wire all my emissives or controllers (which have different color sources) to be toggled by a single master ModuleToggleLED button?  I want an "off" switch to let me turn off all the IndicatorLights under some circumstances.

Possibly, but it depends what you mean by,

1. "all"
2. "simple"

First, regarding "all":  If you mean "everything all over the ship":  No, there really isn't.  IndicatorLights modules generally work only in the context of the part that they're on.  You can toggle the state of one controller on a part by using the output of another controller on that same part, but not from somewhere else on the ship.

To make it happen all over the ship, basically what you'd need to do is to set up the "wiring diagram" of every light's controller so that it feeds to something with an action-group toggle, and then assign them all to the same action group.  (If you were to use ModuleToggleLED for this, it's automatically in the Light action group, so you wouldn't have to manually tinker with the action group assignments for every individual part.)

As for "simple":  what you'd need to do is to wire the functionality into each individual emissive's controller diagram, by setting up an appropriate toggle controller for each one.  There's currently no "master switch."

Do you only want this for debugging/screenshot purposes (you mention "screenshots")?  Or is it something needed for actual gameplay?  The former would be easier for me to slip in than the latter-- lower bar for usability, e.g. could be something involving the debugging console, like /il on and /il off or some such.

 

10 hours ago, Fwiffo said:

Also would like a field that can disable the ModuleCustomBlink GUI button during Flight (one less button on my list).

Hm, not a bad idea-- actually, more as a general principle of allowing folks to decide for anything with a UI "do you want this in editor, flight, or both".  Let me muse on this.

10 hours ago, Fwiffo said:

My approach to this is going to be defining several ModuleBooleanIndicators (one for each emissive) and gating them all by the master toggle.  I suggest you add a "ternary" ColorSource function that takes a toggle and two color sources as its inputs; it would make it possible to do this sort of thing with a lot less verbosity and less modules.

Hm, interesting idea.  You mean add a logical-combining ColorSource syntax that would allow doing in a string what is currently done via an explicit ModuleBooleanIndicator.

Again, not a bad idea-- let me think on it.

However, it's worth bearing in mind that even having that wouldn't, on its own, solve your current problem of wanting a global switch, since all ColorSource parsing is done in the context of the current part only.

Adding some sort of functionality to allow specifying "search the whole ship" instead of "search the current part" may be possible, but it's nontrivial (requires wiring in lots of event-handling, since parts can move around as ships dock, undock, stage, etc., and scanning a whole ship can get computationally expensive since ships can be very big).  I'll think about it, because I like the idea-- if architected correctly, it could open the door to all kinds of interestingly flexible design options.  It will take some time, however, and no promises-- it's not something I can just "slip in".

In any case, if a simple "global mod enable/disable" switch accessible via the debug console would solve your use case, that would be a lot easier to add.

9 hours ago, Fwiffo said:

Here's a copy of my bootlegged DLL if you want to test

A side note:  I appreciate your desire to be helpful, but please be careful about licensing requirements.  Your current download link violates the license, and I'd appreciate it if you could either delete the link or fix it so that it legally complies.

Details in spoiler section.

Spoiler

IndicatorLights is currently distributed under CC-BY-NC-SA.  That license does legally allow redistributing modified versions of the mod... but your current download link violates the "BY" and "SA" clauses of the license:

• "BY" (attribution):
  • From the license:  "You must give appropriate credit, provide a link to the license, and indicate if changes were made."
  • Your download zip file just contains the naked DLL.  There's no reference to where it came from, or that I wrote it, or that it's been modified by you (or how), or that it has a license, or what that license might be.
• "SA" (share-alike):
  • From the license:  "If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original."
  • Your download zip file just contains the naked DLL, without any specification of license.

True, you try to remedy both of the above by your post here in the thread... but any mitigation needs to be packaged with the distributed file, because right now, someone could take your modified version, post it anywhere on the Internet, host it on SpaceDock or CurseForge, and it could get copied everywhere, and then I could be receiving bug reports from people who are running some modified copy and neither I nor they realize it.

You can mitigate the "BY" problem thus:  include a README file in your zip, which explains the necessary information:

• that this is an unofficial and unsupported variant of IndicatorLights
• that the original is by Snark (with a link to this thread and the IndicatorLights github repository)
• that this version has been modified by you, as follows, with a changelog
• that it's licensed under CC-BY-NC-SA, please see the LICENSE file

You can mitigate the "SA" problem by including a LICENSE file in your zip, similar to what I have done.

One more comment regarding all of this, just on a purely personal note so you understand where I'm coming from:

Due to a recent horror story that badly rattled me, I moved most of my mods to a very restrictive CC-BY-NC-ND license, which prevents anyone from distributing any "derived work" (including modified versions of the mod).

I hated to do it, 'coz it kinda sucks for users, but I was forced there by the aforementioned horror story.  The idea of an unknown number of modified versions of my mods potentially running amok on the internet, completely out of my control, complicating and randomizing my relationship with my users and generating random noise in support requests, is a particular phobia of mine.  The very idea of it gives me the slithering creeps.  It's enough to make me want to stop modding and run screaming from the room.  So basically, I (reluctantly, unhappily) locked down the licenses as the lesser of two evils.  Yes, it sucks for the users... but the alternative would be for me to have a hissy fit and stop modding altogether, which I like to flatter myself by thinking would be even worse for the users.

The sole exception to the CC-BY-NC-ND parade is IndicatorLights, which I left somewhat more open with the more-permissive CC-BY-NC-SA.  I did that because IndicatorLights, more than my other mods, is intended to be very modder-friendly; I want people to be able to build mods on top of it, and I want them to feel comfortable doing so, and I really didn't want to chill that by locking it down too hard.

So sure, it's permissible to distribute "tweaked" versions, such as what you're doing... but not because that's what I especially wanted.  What I wanted to allow was for people to be able to build stuff on top of it, and it just happens to be an unfortunate (from my perspective) side effect that that also allows distributing modified copies.  So I don't have any right to tell you "don't do that", and no hard feelings.  You're entirely within your rights.

However... on a purely personal note, given that I think I have a pretty good track record of adding features promptly and not leaving IndicatorLights languishing and neglected... I'd appreciate it if folks could be a bit patient and just wait for my version to come out, unless it's some sort of extreme situation (e.g. I've been hit by a bus and haven't shown up on the forum in months and nobody knows what's going on with the mod and it needs continuing).

So if you do have the urge to distribute a modified version of the DLL... perhaps take a moment to think "is it actually necessary, or is it likely that Snark will have a fixed version up pretty soon anyway?"  And if you do decide that it's necessary, please bear in mind that files have a life of their own once they're released into the wilds of the Internet, and therefore be conscientious in following the license, so that its provenance and provisos will be blatantly clear to anybody who happens to get it, from anybody anywhere.

Anyway, my two cents.  Thank you for your understanding.

 

[Fwiffo]

5 hours ago, Snark said:

Player:  "Hey, I'm trying to rotate my ship and nothing's happening!  What's going on?  <flash flash flash>  Oh, okay, my reaction wheels are out of power."

That's a good point.  So, you could narrow the focus a little from what I did and disable the deprived warning only when SAS is off and the user is not trying to turn the ship.  I did a quick test and hitting a rotation key (causing a request for electricity to be made) also clears the aberrant flashing.

5 hours ago, Snark said:

Do you only want this for debugging/screenshot purposes (you mention "screenshots")?  Or is it something needed for actual gameplay?  The former would be easier for me to slip in than the latter-- lower bar for usability, e.g. could be something involving the debugging console, like /il on and /il off or some such.

Both equally (screenshots and gameplay).  I follow what you mean about the "wiring diagram" approach and it's basically what I did within the part.  But after implementing it (and even using the toggle() feature to somewhat reduce the amount of cfg clutter) I'm of the opinion this is a case where it might be better to introduce a feature specifically for this, rather than trying to accomplish it through the existing "nesting" methodology of the mod.

i.e. I'm thinking bake master "On/Off switch" functionality into a new part [module] intended to occur only once on your ship.  All the emissive controllers would be smart enough to check if that part [module] exists, and if so, turn off their output when the switch is turned off.  From a programming perspective, the only thing this new module would really do is provide a ship-wide boolean state variable.  It would be wired up to an existing toggle to provide the actual button (or maybe come in the form of a ModuleMasterSwitchController which would be a cut-down ModuleToggleLED or different flavour of ModuleBooleanIndicator).

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?  (I know some mods stuff things into savegame files, for better or worse...)

An advantage of the approach is the user doesn't have to do a thing to their cfg's to make this work.  All they have to do is stick the new "Master Switch" part somewhere onto their ship and it just works.

I'd be curious if anyone else would appreciate having a master switch to toggle all the IndicatorLights functionality off at once.  It would feel akin to using the main breaker switch on your fusebox.

5 hours ago, Snark said:

In any case, if a simple "global mod enable/disable" switch accessible via the debug console would solve your use case, that would be a lot easier to add.

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.

5 hours ago, Snark said:

Hm, interesting idea.  You mean add a logical-combining ColorSource syntax that would allow doing in a string what is currently done via an explicit ModuleBooleanIndicator.

Yes.  In my implementation I copped out on the "logical-combining" part - it's just a SPDT switch.  It was intended for simple one-liner cases where you want to avoid creating whole new ModuleBooleanIndicator.  I figured for complex cases the user can just revert to that.

I did do one small thing which turned out to be helpful when using it; that was to make the offSource optional (so it knows to just use $Off if not specified).

Incidentally (and purely for academic interest) the resulting toggle() could have been combined internally with a theoretical generic new "timer()" parameter (essentially a squarewave generator) to implement existing patterns like blink().  e.g. blink() === toggle(squarewave(200ms), onSource).  Where squarewave() is some class that inherits from a generic timer().  But I digress :-P.

5 hours ago, Snark said:

For me, taking a pull request-- from anyone who isn't me-- would be kind of like if some competent, organized, and well-meaning family member of mine were to come in and "tidy up" my office for me when I'm not there.

Hah, great analogy!  Incidentally the only reason I went to the trouble of creating a pull request was because I thought it would be convenient for you.  Personally I find GitHub a little less intuitive to use than I feel it ought to be.

Anyway I respect your desire not to have other people dabbling in your code.  I just wanted to move on with my CFG files, and needed some of the missing functionality to proceed.  It looked (and was) very trivial to implement and I figured I was doing you a favor.  I was careful to preserve the coding patterns you used (and had hoped to learn something if you took a look at it and said "no, that over there isn't quite right, here's how it should be done").  Sorry if it offended you.

I removed the link as requested.

Edited October 25, 2016 by Fwiffo