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

[Snark]

22 hours ago, Frostiken said:

is there any chance of Kerbalism integration with regards to antenna light data transmission?

Well, I don't actually use Kerbalism myself (and am probably unlikely to do so in the future-- it sounds like a cool mod, but isn't my cup of tea), so I won't be doing any sort of patch like that, myself; don't have the bandwidth for that sort of thing.

That said, though, it might (or might not) be possible for someone else to enable such a patch with just a bit of config.  The relevant question is, does Kerbalism expose a boolean field that indicates whether an antenna is currently transmitting?  Or not?

If it does, then IndicatorLights' built-in config language is flexible enough to accommodate it; see IndicatorLights wiki documentation and sample config for how to use the feature.  Again, this isn't something I'd be likely to take on myself, but the good news is that anyone with knowledge of ModuleManager syntax could do it, without any need for actual code, and no changes needed to IndicatorLights itself.  And I have another mod, IndicatorLights Community Extensions, where I'm happy to take community-supplied config with patches like that one, and incorporate it. 

If Kerbalism doesn't expose such a field, then there's likely not any way to make this work, unless the Kerbalism author would be willing to expose such a field.

[piggermortis]

Can we get a RO fix? Resizes the avionics and makes a sounding rocket impossible.

[Jacke]

10 hours ago, piggermortis said:

Can we get a RO fix? Resizes the avionics and makes a sounding rocket impossible.

There's not much to go on to figure out what you mean.  Can you provide a step-by-step process to produce the bug, along with complete logs (upload to to a file site and share the link) and perhaps screenshots to explain this in enough detail so that it can be properly investigated?

[Brigadier]

23 hours ago, piggermortis said:

Can we get a RO fix? Resizes the avionics and makes a sounding rocket impossible.

12 hours ago, Jacke said:

There's not much to go on to figure out what you mean.  Can you provide a step-by-step process to produce the bug, along with complete logs (upload to to a file site and share the link) and perhaps screenshots to explain this in enough detail so that it can be properly investigated?

I agree with @Jacke.  Also, this might be an issue for RO to resolve.  I'd check there because there are, I believe, community contributions to IL.

[piggermortis]

13 hours ago, Jacke said:

There's not much to go on to figure out what you mean.  Can you provide a step-by-step process to produce the bug, along with complete logs (upload to to a file site and share the link) and perhaps screenshots to explain this in enough detail so that it can be properly investigated?

Sorry but I guess I'm not gonna be of any help. Already uninstalled and the issue is gone. Maybe it was B9PS or RSS but I already started a new career and won't be adding it back in. Thanks for your quick response

[MinchinWeb]

It seems at some point, the original HG-5 part was replaced by a new in-game part with the same name/title. Could you re-add this antenna?

If it's helpful, the new part name is HighGainAntenna5_v2.

P.S. Thanks for this awesome mod, and thanks for keeping it up to date!

(I also created an issue on GitHub, but hope this might be seen sooner.)

[zer0Kerbal]

1 hour ago, MinchinWeb said:

It seems at some point, the original HG-5 part was replaced by a new in-game part with the same name/title. Could you re-add this antenna?

If it's helpful, the new part name is HighGainAntenna5_v2.

P.S. Thanks for this awesome mod, and thanks for keeping it up to date!

(I also created an issue on GitHub, but hope this might be seen sooner.)

https://github.com/KSPSnark/IndicatorLights/pull/18

@PART[HighGainAntenna5,HighGainAntenna5_v2]:FOR[IndicatorLights]

+1  to both @MinchinWeb for doing the issue, and +1  to @Snarkfor this awesome mod! Hope you don't mind I did what I did.

Edited January 19, 2022 by zer0Kerbal

[Snark]

Hi all,

Just a note that I've released IndicatorLights v1.8.2.  No new features, just a fix for the HG-5 antenna.

Thanks to @MinchinWeb for spotting the problem, and to @zer0Kerbal for supplying a fix!

(Minor note to zer0Kerbal:  thank you for the suggested update, but it didn't work for me-- looks like the devs rotated the model, or something.  I've included a fix that repositions the indicator so that it ends up on the same spot of the new model as the old one did.)

Enjoy!

[N3N]

Hey,

I'm getting this repeating log spam, when I'm in space with a craft that has a "Survey Scanner":

  Hide contents

NullReferenceException: Object reference not set to an instance of an object
  at IndicatorLights.ModuleOrbitalSurveyorIndicator.get_CurrentSource () [0x00038] in <004a2a6dcba8485db15aa4ae0951041e>:0
  at IndicatorLights.ModuleOrbitalSurveyorIndicator.get_HasColor () [0x00000] in <004a2a6dcba8485db15aa4ae0951041e>:0
  at IndicatorLights.ModuleEmissiveController.SetColors () [0x00000] in <004a2a6dcba8485db15aa4ae0951041e>:0
  at IndicatorLights.ModuleEmissiveControllerBase.Update () [0x0001f] in <004a2a6dcba8485db15aa4ae0951041e>:0
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
 
(Filename: <004a2a6dcba8485db15aa4ae0951041e> Line: 0)

It seems because of this file: "GameData\IndicatorLights\Parts\scanners\surveyScanner.cfg".

(The model seems not to be right, because the Indicator Light "floats a little above" the part.)

Here are the logs: https://tancredi.nl/logs.zip

Can somebody please help me?

[Snark]

On 5/4/2022 at 9:25 AM, N3N said:

Here are the logs: https://tancredi.nl/logs.zip

Can somebody please help me?

Thanks, the log is helpful!

It is clear to me what is happening-- what's not clear is why.

More specifically, it's not clear what's triggering it in your particular case, since I don't get this problem myself in my own gameplay.  If I had to guess, it would be that there's something about one of your other mods you're running that's causing IndicatorLights to have indigestion.  Without going into too many technobabble details, IndicatorLights relies on registering certain information when a part is being loaded, and I notice the following from your log:

• IndicatorLights is logging a "hey, I can't find the module that I need" warning, and
• there are a whole bunch of other mod-related log messages going on at that same time (in particular from FAR and something called S.A.V.E.)

I don't know that one of those is the culprit, and maybe the log lines I'm seeing are red herrings and not directly related to the problem, but that's about the only guess I have, at the moment.

Certainly, the fact that IndicatorLights is giving you log spam in this case is a miss on my part.    I can see exactly where in my code the problem is-- I've got some code there that's making an assumption that it shouldn't.  It would be straightforward for me to add a simple check at the appropriate spot in the code, so that if the necessary info isn't present, then the indicator light simply doesn't light up rather than spamming log messages.

Such a "fix" would result in the indicator light on the M700 part not working, in your particular case... but at least it wouldn't be hosing you with log spam.

Are you only seeing this with that one part, or are you getting this on other IndicatorLight-equipped stock parts as well?

If it's just that one part, then you can eliminate this problem by just deleting the GameData\IndicatorLights\Parts\scanners\surveyScanner.cfg file from your IndicatorLights installation.  That will cause the M700 scanner not to have an indicator light on it, but at least it would eliminate your spam.

[N3N]

3 hours ago, Snark said:

Thanks, the log is helpful!

It is clear to me what is happening-- what's not clear is why.

More specifically, it's not clear what's triggering it in your particular case, since I don't get this problem myself in my own gameplay.  If I had to guess, it would be that there's something about one of your other mods you're running that's causing IndicatorLights to have indigestion.  Without going into too many technobabble details, IndicatorLights relies on registering certain information when a part is being loaded, and I notice the following from your log:

• IndicatorLights is logging a "hey, I can't find the module that I need" warning, and

Hey @Snark,

Thank you for your fast and understandable answer and help!

 

3 hours ago, Snark said:

there are a whole bunch of other mod-related log messages going on at that same time (in particular from FAR and something called S.A.V.E.)

The "FAR messages" seems to be maybe because of this:

And S.A.V.E. is this mod:

3 hours ago, Snark said:

Certainly, the fact that IndicatorLights is giving you log spam in this case is a miss on my part.    I can see exactly where in my code the problem is-- I've got some code there that's making an assumption that it shouldn't.  It would be straightforward for me to add a simple check at the appropriate spot in the code, so that if the necessary info isn't present, then the indicator light simply doesn't light up rather than spamming log messages.

Such a "fix" would result in the indicator light on the M700 part not working, in your particular case... but at least it wouldn't be hosing you with log spam.

Are you only seeing this with that one part, or are you getting this on other IndicatorLight-equipped stock parts as well?

If it's just that one part, then you can eliminate this problem by just deleting the GameData\IndicatorLights\Parts\scanners\surveyScanner.cfg file from your IndicatorLights installation.  That will cause the M700 scanner not to have an indicator light on it, but at least it would eliminate your spam.

Thank you,

removing the "GameData\IndicatorLights\Parts\scanners\surveyScanner.cfg" helped removing the log spam.

And no, no other "IndicatorLight-equipped (stock) part" have this behavior.

[DougS2K]

So this mod is fantastic but I've noticed some of my crewable parts are not functioning as intended such as cupola, hitchhiker, and science lab. Upon further investigation I see notes about an issue while using restock in the IndicatorLights_ReStock.cfg file that mention about duplicate parts. I assume this is the issue.  The info is a little confusing to me as someone that is not familiar with this process. I have Indicatorlights, Indicatorlightscommunityexstensions, restock, and restock plus installed. Now my question is how exactly do I go about resolving this to have the indicator lights appear on these parts? It talks about deleting redundant model nodes but I'm not sure exactly how to do that.  

Spoiler

// Fix duplicate models where IL added a model based on the original parts
// having a mesh=model syntax.  Restock does this too, so parts end up with
// duplicate models for the basic part.  Sometimes it's not obvious if the
// stock part was not whitelisted. But this will throw an error since the
// model was removed by ReStock. The worst case is the part was whitelisted,
// so both models overlay each other. The simplest fix is to just delete the
// reduncdant model nodes. -Tonka Crash
//---------------------------------------------------------------------------//
@PART[advSasModule]:AFTER[ReStock]:NEEDS[IndicatorLights]    { !MODEL:HAS[#model[Squad/Parts/Command/inlineAdvancedStabilizer/model]] { } }
@PART[asasmodule1-2]:AFTER[ReStock]:NEEDS[IndicatorLights]    { !MODEL:HAS[#model[Squad/Parts/Command/advancedSasModuleLarge/model]] { } }
@PART[cupola]:AFTER[ReStock]:NEEDS[IndicatorLights]        { !MODEL:HAS[#model[Squad/Parts/Command/cupola/model]] { } }
@PART[crewCabin]:AFTER[ReStock]:NEEDS[IndicatorLights]        { !MODEL:HAS[#model[Squad/Parts/Command/hitchhikerStorageContainer/model]] { } }
@PART[landerCabinSmall]:AFTER[ReStock]:NEEDS[IndicatorLights]    { !MODEL:HAS[#model[Squad/Parts/Command/mk1LanderCan/model]] { } }
@PART[ISRU]:AFTER[ReStock]:NEEDS[IndicatorLights]        { !MODEL:HAS[#model[Squad/Parts/Resources/ISRU/ISRU]] { } }
@PART[SurfaceScanner]:AFTER[ReStock]:NEEDS[IndicatorLights]    { !MODEL:HAS[#model[Squad/Parts/Resources/SurfaceScanner/SurfaceScanner]] { } }
@PART[Large_Crewed_Lab]:AFTER[ReStock]:NEEDS[IndicatorLights]    { !MODEL:HAS[#model[Squad/Parts/Science/LargeCrewedLab/large_crewed_lab]] { } 

 

Edited July 6, 2022 by DougS2K

[AmanitaVerna]

The notes there aren't saying that you need to do that, they're explaining what the rest of the stuff you pasted does.

[Snark]

12 hours ago, DougS2K said:

So this mod is fantastic but I've noticed some of my crewable parts are not functioning as intended such as cupola, hitchhiker, and science lab. ... I have Indicatorlights, Indicatorlightscommunityexstensions, restock, and restock plus installed.

If you're running ReStock, then whatever issue you're having is almost certainly a mod interaction there; and it would be IndicatorLights Community Extensions that's the issue in that case, not IndicatorLights itself.  Therefore, this would be a better question to ask over there:

 

12 hours ago, DougS2K said:

Upon further investigation I see notes about an issue while using restock in the IndicatorLights_ReStock.cfg file that mention about duplicate parts. I assume this is the issue.  The info is a little confusing to me as someone that is not familiar with this process. .... Now my question is how exactly do I go about resolving this to have the indicator lights appear on these parts? It talks about deleting redundant model nodes but I'm not sure exactly how to do that.  

As @AmanitaVerna points out, that's not what those comments mean.  They're not saying that you should do anything; they're explaining what this patch is doing.  When it says "Fix duplicate models where...", what it's really saying is "The following lines are where I'm fixing duplicate models where..."

 

So, in summary:

• There are no actions you're supposed to take.  The mod is supposed to "just work".
• It's possible that there's some issue with ReStock and/or this patch (for example, if ReStock got updated in a way that makes this patch obsolete, so it needs updating or something).
• Best place to ask about it is over in the IndicatorLights Community Extensions thread.

[DougS2K]

1 hour ago, Snark said:

If you're running ReStock, then whatever issue you're having is almost certainly a mod interaction there; and it would be IndicatorLights Community Extensions that's the issue in that case, not IndicatorLights itself.  Therefore, this would be a better question to ask over there:

 

As @AmanitaVerna points out, that's not what those comments mean.  They're not saying that you should do anything; they're explaining what this patch is doing.  When it says "Fix duplicate models where...", what it's really saying is "The following lines are where I'm fixing duplicate models where..."

 

So, in summary:

• There are no actions you're supposed to take.  The mod is supposed to "just work".
• It's possible that there's some issue with ReStock and/or this patch (for example, if ReStock got updated in a way that makes this patch obsolete, so it needs updating or something).
• Best place to ask about it is over in the IndicatorLights Community Extensions thread.

My bad for posting in the wrong thread. I actually had both threads open when I was searching for a solution and must have posted in the wrong one. It was late here at the time. 

Thanks for clarifying those lines, I guess I misinterpreted them. I'll try posting in the other thread.

Edit* I think I've figured out the problem. I'm using Stockalike Station Parts Expansion Redux  which has changes to these parts and that's what I believe is causing the issue.

Edited July 6, 2022 by DougS2K

[JadeOfMaar]

@Snark Hi there. Feature discussion if you're interested. I'm interested in the CoreHeat state indicator in your planned features list. Unless you've already figured it out, I propose that you "simply" get the following data: Optimal core temperature, the current core temperature (which is the sum of outputs from multiple running modules on the same part). These are shown in a PAW via ModuleOverheatDisplay{} and probably calculated within ModuleCoreHeat{}. To keep things simple: If the core is cold/sub-optimal, the indiciator color is blue, blinking; if the core is optimal: steady blue; if the core is overheating at all: blinking orange. Possibly, also get the core shutdown event flag and if it's set: steady orange emissive (flat-line).

I know not to assume that programming is super easy so I put "simply" in quotes. I also figure that it might be redundant to check for a core heat shutdown status if the player can simply loook and see that a part is obviously not running when it should be, but this only works for parts that have a running animation. Not all converters or harvesters will have a running animation or that animation might be overly subtle.

This mod came up in a chat on a discord server, and I and a few folks agreed that visual cues of parts' dynamic states are really lacking in KSP, even in the modding scene. So I thought I'd come share this idea and share that I'd like to have some form of support for this mod in parts I make.

[serow]

I have a question, and possibly a feature request.

I started a new sandbox game to try doing a bunch of things that I never got around to doing, like legitimately flying to the OPM planets and round trip to Eve.

I love the indicator lights, but in sandbox they are always blink and don't stop when science is collected. To test, I put acommand module with a Science Jr on the launchpad, took crew report, eva report, surface sample, and materials bay study, then recovered. I then launched the same vessel and all the indicators (cockpit and science jr) are still blinking/blinking again.

Is this intended? Is there a config I can set to make them stop blinking in sandbox mode (other than removing the mod entirely)?

If not, can it be made to not blink the 'science available' lights in sandbox mode, or a configuration option to set the same?

Thanks.

[Snark]

9 hours ago, serow said:

I started a new sandbox game to try doing a bunch of things that I never got around to doing, like legitimately flying to the OPM planets and round trip to Eve.

I love the indicator lights, but in sandbox they are always blink and don't stop when science is collected. To test, I put acommand module with a Science Jr on the launchpad, took crew report, eva report, surface sample, and materials bay study, then recovered. I then launched the same vessel and all the indicators (cockpit and science jr) are still blinking/blinking again.

Is this intended? Is there a config I can set to make them stop blinking in sandbox mode (other than removing the mod entirely)?

If not, can it be made to not blink the 'science available' lights in sandbox mode, or a configuration option to set the same?

Good point, and thanks for reporting!

What I observe in a sandbox game is:

1. science instruments always initially blink
2. The craft remembers what science it actually currently has on board. So, for example,  if I take a reading with my gravioli detector, it stops blinking and shows that it's full of science.  And if I have that particular science on board somewhere (for example, collected to the command pod), it doesn't light up.
3. However, the game doesn't remember that "this science has been previously collected from another mission", so if I recover the craft and then launch another one, the new craft will be blinking again even though I've already recovered that measurement.

#1 and #2 are behaving exactly as designed, and exactly the same as in a career game.  #3 is, I believe, the issue that you're running into?

So, that's not exactly... intentional, per se, but it's also not obvious what the correct design would be.  The issue is that the way this works in a career game (so that a new ship will "remember" that a previous ship recovered a particular science result) is that a career game has a built in "science repository" that remembers all that stuff, and this repository simply doesn't exist in a sandbox game.  The game literally has no memory of what any previous spacecraft might have done.

So, there are basically four options:

• Live with it.  As a workaround, if the science experiment is annoying you with its blinking, just go ahead and take a measurement on that craft in order to shut up the blinking.
• Disable science indicators in sandbox games.  Just disable them entirely, so they don't light up, don't blink, don't do anything.  It would be very easy to program this, and would "solve" your issue with #3 above.  Unfortunately, I don't view this as a reasonable fix, because it would also completely break features  #1 and #2, which is undesirable.
• Implement a custom "science store" in sandbox just for this purpose.  Doable, I suppose... but it's a fair bit of code, would be tedious to debug and make sure all edge cases are handled, and seems to me that the amount of complexity it would introduce is not worth it just to solve what I consider to be an edge case.  (Especially since KSP2 is coming out in a couple of weeks and I'm not motivated to make large changes to my KSP1 mods at this point.)
• Add a custom setting for the mod so that the user can, for example, choose between the current behavior, or the "completely disable science indicators in sandbox" option.  Also doable, but again, complexity, plus it's playing guessing games with what most users are likely to want, which I'd prefer not to do.

Given the above, I'm mainly inclined to go with the "live with it" option at this point. 

(Though I'll certainly keep this issue in mind, if I end up writing an IndicatorLights equivalent mod in KSP2, depending on how that game eventually ends up dealing with science.  Thank you for raising the point!)

 

On 1/10/2023 at 6:07 PM, JadeOfMaar said:

@Snark Hi there. Feature discussion if you're interested. I'm interested in the CoreHeat state indicator in your planned features list. Unless you've already figured it out, I propose that you "simply" get the following data: Optimal core temperature, the current core temperature (which is the sum of outputs from multiple running modules on the same part). These are shown in a PAW via ModuleOverheatDisplay{} and probably calculated within ModuleCoreHeat{}. To keep things simple: If the core is cold/sub-optimal, the indiciator color is blue, blinking; if the core is optimal: steady blue; if the core is overheating at all: blinking orange. Possibly, also get the core shutdown event flag and if it's set: steady orange emissive (flat-line).

I know not to assume that programming is super easy so I put "simply" in quotes. I also figure that it might be redundant to check for a core heat shutdown status if the player can simply loook and see that a part is obviously not running when it should be, but this only works for parts that have a running animation. Not all converters or harvesters will have a running animation or that animation might be overly subtle.

This mod came up in a chat on a discord server, and I and a few folks agreed that visual cues of parts' dynamic states are really lacking in KSP, even in the modding scene. So I thought I'd come share this idea and share that I'd like to have some form of support for this mod in parts I make.

Funny you should ask that!    As it happens, a few months ago I actually thought  of this myself, and started to implement "core heat" indicators for drills and ISRU units.  The code shouldn't be complex.  However, once I got it to a semi-working state, it behaved oddly and after sinking a few hours of time debugging it, I kinda lost interest and wandered away.  I'm not saying I'll never do this, but with KSP2 coming out in just a couple of weeks, my interest in sinking substantial time into my KSP1 mods is a bit low at this point.  Time will tell.  Thank you for the suggestion, though!

[OrbitalManeuvers]

On 2/11/2023 at 1:55 AM, serow said:

I love the indicator lights, but in sandbox they are always blink and don't stop when science is collected.

Welcome to the forums. I used to play sandbox mode exclusively until I realized there was a better way for me, which I call Sciencebox. You just start a science game, then use the cheat menu to unlock all parts and progression. Now you have a sandbox game but more of the game's mechanics are active, like science and comms, etc. Even though you're in sandbox mode, you can still collect and transmit science - which I use as one measure of a mission's success. Anyway, just a thought

[Snark]

Hi all, just a note that I've released IndicatorLights v1.8.3.

New in this release is support for indicating current SAS status (yes, I know this is arguably unnecessary, since the navball shows that status anyway, but I found myself wanting this).  The only part I've instrumented to show this is the avionics nosecone, since that part is all about SAS.

Indicator is on when SAS is active, off when it's not.  When on, the color indicates the mode (color-coded by the corresponding navball icons):

• White for "stability assist"
• Yellow for and
• Cyan for and
• Magenta for , , ,
• Blue for

That's the default behavior, but as with pretty much everything in IndicatorLights, it's highly configurable.  Every individual SAS mode can be separately configured.  Details for modders are in the wiki.

Other changes, besides the above:

• Add this as a valid ColorSource identifier in config syntax (of interest only to modders)
• Add a new statusText field to ModuleToggleLED, to allow using config to specify the UI text for the toggle button.  Thanks to @Geonovast for the feature suggestion!
• Various minor bug-fixing and bullet-proofing.
• Update to ModuleManager 4.2.3.

Enjoy!

[Beetlecat]

What the dickens!

[KKKerman]

Hi Snark!

I love this convenient mod and thought it could be a little more convenient if it supported my native language. So I wrote a MM patch to add localization support without altering your original code. I've opened a PR about this.

Thank you!