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

[Snark]

3 minutes ago, Dafni said:

May I ask how Indicator Lights plays along with the Restock parts?

It doesn't, currently.  They use different models, which requires completely overhauling how all the little bitty indicators are precisely positioned, which is a huge and daunting task.  It's been asked about before, you're not the only interested party. 

While I'm sure it would be great to have for a lot of folks, it's not especially high on my priority list, mainly because, 1. it's a huge, time-consuming, tedious, finicky job, and 2. I don't actually happen to run ReStock myself so there's no benefit to my own gameplay.

[VoidSquid]

I assume 1.5 is compatible with KSP 1.7.0?

Sigh... I wish there's be a IL-config for the old K2 pod, but I guess nobody would be willing to make that efforts.

Edited May 31, 2019 by VoidSquid

[Snark]

5 hours ago, VoidSquid said:

I assume 1.5 is compatible with KSP 1.7.0?

No, it isn't. That's why the title of the thread says "1.7.1+".

KSP 1.7.1 introduces a new feature, axis groups. IndicatorLights 1.5 has code in it that uses that new feature, which obviously won't work on an older KSP version where that feature doesn't exist.

So if you're still running KSP 1.7.0, the highest version of IndicatorLights that you'll ever be able to use is 1.4.2.

5 hours ago, VoidSquid said:

Sigh... I wish there's be a IL-config for the old K2 pod, but I guess nobody would be willing to make that efforts.

No idea what is this "K2 pod" you speak of, but you could always go ask about it in the IndicatorLights Community Extensions thread.

[VoidSquid]

28 minutes ago, Snark said:

So if you're still running KSP 1.7.0, the highest version of IndicatorLights that you'll ever be able to use is 1.4.2.

Almost suspected this, been wondering why CKAN offers me 1.5

34 minutes ago, Snark said:

No idea what is this "K2 pod" you speak of, but you could always go ask about it in the IndicatorLights Community Extensions thread.

This one 

Old 1.25m 2-Kerbals pod, but with the respektive MH pod, I doubt that anyone would still like to do the necessary work.

Anyway, thanks for your answers, appreciated  

[Gordon Dry]

@Snark big bad issue.

The fact that IndicatorLight adds models creates issues with RO / RP-1.

Because cloned parts are to be rescaled, and the patches simply want to rescale the model.

But now the first model in the PART is not the part's model itself but the first of x indicator lights models.

Here an excerpt from Discord:

Spoiler

Quote

Gordon Dryheute um 05:12 Uhr

Hmm. The Aerobee Sounding Rocket Telemetry Unit is - huge. And it does not snap to the node.

Hmm:

model = ReStock/Assets/Control/restock-reactionwheel-25-1

and

        scale = 1.0
        rescaleFactor = 1.0

doesn't seem to be right.

So ReStock is bugged.

Or configs for it from RO / RP-1 are.

Should ReStock used with TweakScale?

This config seems right: GameData\RealismOverhaul\Parts\Avionics\Sounding0-3m.cfg but with ReStock something is borked.

I guess I got it - it's IndicatorLights and this:

+PART[RP0probeSounding0-3m]:AFTER[RealismOverhaul]
{
    @name = RP0aerobeeSounding

    @MODEL
    {
        %scale = 0.15, 0.252632, 0.15
    }
 

because there are more than one models, and IndicatorLights come first.

Look:

        MODEL
        {
            model = IndicatorLights/Meshes/squareLamp
            position = -0.884, 0, 0.884
            rotation = 0, -45, 0
            scale = 0.15, 0.252632, 0.15
        }
        MODEL
        {
            model = IndicatorLights/Meshes/squareLamp
            scale = 0.8, 0.8, 1
            position = 0.884, 0, -0.884
            rotation = 0, 135, 0
        }
        MODEL
        {
            model = IndicatorLights/Meshes/squareLamp
            scale = 0.8, 0.8, 1
            position = 0.884, 0, 0.884
            rotation = 0, 45, 0
        }
        MODEL
        {
            model = IndicatorLights/Meshes/squareLamp
            scale = 0.8, 0.8, 1
            position = -0.884, 0, -0.884
            rotation = 0, 225, 0
        }
        MODULE
        {
            name = ModuleControllableEmissive
            target = IndicatorLights/Meshes/squareLamp
            emissiveName = indicator
        }
        MODULE
        {
            name = ModuleReactionWheelIndicator
            emissiveName = indicator
        }
        MODEL
        {
            model = ReStock/Assets/Control/restock-reactionwheel-25-1
        }
    

The scale is in the wrong model node.

---

Papheute um 05:30 Uhr

What are indicator lights?

---

Gordon Dryheute um 05:32 Uhr

A mod. You don't know?

The odyssey starts here: GameData\IndicatorLights\Parts\reactionWheels\largeReactionWheel.cfg

@PART[asasmodule1-2] {
    @description ^= :(.)$:$0 Indicator lights show the reaction wheel's status.:
    
    // We have to re-specify the model for the stock part, because this is
    // an older part that uses the "mesh =" syntax in its .cfg file instead
    // of the newer "MODEL" syntax. The "mesh =" syntax doesn't allow having
    // multiple models as part of the same part, which would prevent this mod
    // from adding meshes for the indicator lights.
    MODEL
    {
        model = Squad/Parts/Command/advancedSasModuleLarge/model
    }
    

    //-------------------------------------------------------------------------
    // INDICATOR MESHES
    //-------------------------------------------------------------------------

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.8, 0.8, 1
        position = -0.884, 0, 0.884
        rotation = 0, -45, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.8, 0.8, 1
        position = 0.884, 0, -0.884
        rotation = 0, 135, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.8, 0.8, 1
        position = 0.884, 0, 0.884
        rotation = 0, 45, 0
    }

    MODEL
    {
        model = IndicatorLights/Meshes/squareLamp
        scale = 0.8, 0.8, 1
        position = -0.884, 0, -0.884
        rotation = 0, 225, 0
    }

---

Papheute um 05:33 Uhr

I don't know a lot of mods that are not RO configged or related

---

Gordon Dryheute um 05:33 Uhr

This is then cloned to

+PART[asasmodule1-2]:BEFORE[RealismOverhaul]
{
  @name = RP0probeSounding0-3m
} 

Problem is, IndicatorLight adds its own models first.

And it adds models.

Not modules.

---

Papheute um 05:34 Uhr

That is an issue that is not on our end, has to be fixed from the Indicator Lights side

 

This is bad.

[Snark]

Sorry to hear that you're having difficulty getting various mods to play nice together.  ¯\_(ツ)_/¯

With all the thousands of mods out there, there are literally millions of potential combinations of different mods conflicting with each other, so obviously there's no way that any one modder can possibly keep track of them all and make sure there aren't any conflicts.  It wouldn't even be physically possible, even if the modder were inclined to try.  And of course modders are doing this in their spare time as an unpaid hobby just for fun, so obviously no modder has any obligation or responsibility even to try.  It's just up to what people feel like doing.

In my own case, obviously I don't run R0 / RP-1 myself, or I would have run into this problem on my own and would have sunk however much time into it is necessary to figure out a fix.  But I never run that mod myself and never will, which means I'll never put any of my own time into trying to figure out how to solve it.  I simply don't care enough to try; I have other, more pressing things to do with my time.

Similarly, from the Discord channel that you quote, it sounds as though the exact same situation pertains from the other side as well-- i.e. the RP0 / RP-1 folks don't run IndicatorLights themselves, so they're not interested in spending any of their own time to figure out how to make them play nice together-- nor would I expect them to.

This kind of situation pops up all the time; it's unavoidable.  So, how it gets resolved comes down to one of two possibilities:

• Someone else (e.g. a mod user who wants to use the two mods together) cares enough to put in the time to figure out a fix for the issue, and then either publishes it themselves somewhere or else persuades one of the modders involved to incorporate the fix.
• Nobody cares enough to fix it themselves, so it doesn't get fixed and those mods simply don't work together.

Also, bear in mind that no modder has any obligation to anyone-- i.e. no obligation to fix an issue, and no obligation to accept a "fix" if someone else does the work.  But the thing that modders care the most about is their own time, followed by the quality of their mods, so I'd say that you'd have the best chance of persuading someone to make a fix to their mod if you present them with a gift-wrapped solution that works well and doesn't have any "warts" on it. 

9 hours ago, Gordon Dry said:

This is bad.

Well, it's bad for you, because you happen to be trying to use those two particular mods together and they're not playing nice together.  It's not bad for me at all, because I don't run R0 / RP-1 and so it doesn't affect me.  And it's also not bad for the R0 / RP-1 authors at all either, since clearly they've never heard of IndicatorLights so there's no reason they should care.  It's also not bad at all for the 99%+ of IndicatorLights users who happen not to use R0 / RP-1, or this issue would have popped up before now. 

So basically you have one of three choices:

1. Don't use IndicatorLights.
2. Don't use R0 / RP-1.
3. Figure out a solution yourself.  Once you've done it, let me (and the R0 / RP-1) authors know about it, and we might be inclined to incorporate the compatibility patch.  No guarantees, though-- I can't speak for the R0 / RP-1 authors, of course, and I myself would have to look at any prospective "fix" before deciding whether to incorporate it.

I will say that I do care about my users, and I sympathize.  I would love to incorporate a fix, if there's one that's both available and "palatable".  It's just that my time is scarce and needed for other things, so I won't be putting any of my own time into figuring out a fix.

9 hours ago, Gordon Dry said:

But now the first model in the PART is not the part's model itself but the first of x indicator lights models.

Shrug.  No idea what R0 / RP-1 is doing, but there's nothing I can do about that.

• "Don't add models."  ... Sorry, not possible.  IndicatorLights has to add models, it's how it works.  It's the entire point.
• "Don't make the models be the first ones."  No idea what you're talking about, and please don't try to explain it to me unless it comes with a proposed solution, because frankly I don't care.  My config patches that set these things up generally specify the part's own native model first, and then add the indicator meshes after that, so that sounds like the exact opposite of what you're saying.  Obviously something is going off the rails somewhere, but I have no idea what that may be and have no time to try.

 

Anyway, best of luck with your efforts to figure out a fix! 

[Tonka Crash]

@Gordon Dry It also looks like you use Restock and this is your problem. I'm not impressed with how they do their model substitution. IL isn't completely compatible with Restock yet anyway. I dealt with it locally, but not is a way suitable for widespread use. I don't use the complete Restock either. I skip some due to the indicator lights needing to be in drastically different places (science, antennas, command pods) and others due to a preference for stock (fuel tanks, revamped engines). Mostly I have some engines, control parts and electrical parts.

Mostly what you have is a sequencing problem between Restock and Indicator Lights. Several older Squad parts specify the model with a mesh = model syntax. Both IL and Restock replace these with a complete MODEL node entry. IL runs first and will add in the stock model creating a new model node before adding it's own light models. Up to this point the model node you want to rescale is the first model node. Then Restock runs replacing models. Restock's patches delete the mesh = model line and the first model node before it adds it's own model entry. Since IL has added models prior to this, the Restock model definition that you want to rescale ends up at the end of the list.

I edit every Restock .cfg to add the :FIRST directive to each part. I think this should have been done by the Restock team. This will take care of the IL patch ordering issue, but you still need to fix some of the IL patches to add :NEEDS[!Restock] where it adds back in the stock MODEL since this isn't necessary with Restock and can give you a weird flickering part with both the old and new models z-fighting. A side benefit of forcing Restock first is any parts created by copying stock parts with +PART[] will automatically have the Restock models without needing to be aware of Restock, i.e. Missing History.

 

Edited June 2, 2019 by Tonka Crash

[Gordon Dry]

@Tonka Crash when you do massive edits I suggest you open a PR on Github with a proper explanation like ^that one.

@Snark yep. I wanted to reply, but ^reply is enough

[Tonka Crash]

1 hour ago, Gordon Dry said:

@Tonka Crash when you do massive edits I suggest you open a PR on Github with a proper explanation like ^that one.

@Snark yep. I wanted to reply, but ^reply is enough

@Gordon Dry  I do a lot of patch writing to get mods to play nice and to customize the game for me. When I find something that I think is useful to the general user I'll submit a PR or post a cfg on the forum. Some authors are receptive, some aren't. I've got PRs for bug fixes on a couple mods that have been sitting on github for months.

This falls into the area of getting several incompatible mods to play nice on my computer. It's a fundamental change to Restock I don't consider appropriate for the general user. Just like mod authors avoiding using :FINAL I don't think a mod should be published using :FIRST. What happens if a user wants to run something before Restock in that case?  It works for me in my configuration, but may not for everybody. However, based on what it's doing Restock probably has the best argument for running with :FIRST in a mod that I've seen.

I use CKAN for mod installs, so I hate editing .cfgs directly since an update could wipe my changes. Most I tweak through patches. What I change in Restock is so extensive its one of the few mods I can't avoid editing directly. I did a scan a couple weeks ago and my personal patches directory is up over 10,000 lines in the various .cfg files.

Edited June 2, 2019 by Tonka Crash

[Electrocutor]

I think restock is used commonly enough that it may warrant a NEEDS[!ReStock] for the parts that are replaced. In the future, IL may even get a PR someday to place some lights on restock models, which would then have two patches: one for !ReStock and one for ReStock.

[Nereid]

On 5/30/2019 at 8:59 PM, Snark said:

For example, in the above video clip, I've bound the two lights you see to the "Wheel Steer" axis group.  Result:  functioning turn signals!

LOL. This mod is completely underestimated. I didn't liked it at first, because the included indicator lights are a bit to big for my taste. But the indicator lights on all stock parts especially for science modules are awesome.

[Beetlecat]

On 6/2/2019 at 8:35 AM, Electrocutor said:

I think restock is used commonly enough that it may warrant a NEEDS[!ReStock] for the parts that are replaced. In the future, IL may even get a PR someday to place some lights on restock models, which would then have two patches: one for !ReStock and one for ReStock.

We'll have to migrate this over to the IL Community Extensions thread --   I've been meaning (for almost literal years now) to figure out how to position lights on things like the Kerbonov cockpits -- but don't have my work environment setup to figure out how to do it properly yet.

[Snark]

On 6/2/2019 at 5:35 PM, Electrocutor said:

In the future, IL may even get a PR someday to place some lights on restock models, which would then have two patches: one for !ReStock and one for ReStock.

Wish... granted! 

23 hours ago, Beetlecat said:

We'll have to migrate this over to the IL Community Extensions thread

You're too late.

Because it already has.

In the best possible way-- meaning that @UnanimousCoward has already been and gone and done it. 

I haven't had a chance to integrate it into a new IndicatorLights Community Extensions release, due to IRL issues that will occupy me for another couple of weeks.  But at the earliest possible opportunity I will do so.  (And if anyone is impatient enough that they just can't wait, I believe he's submitted a pull request on github so you could pull it down and try it yourself.  Or you could just wait a couple of weeks until I have a chance to fully integrate it in a new ILCE release.)

[Geschosskopf]

Always adding more lights to more stuff!  Thanks, @Snark

[Twinki]

Are crew lights supposed to be blinking like this?

Spoiler

Edited September 7, 2019 by Twinki

[VoidSquid]

Science instruments are blinking when new science is available, I'd assume if the pod's lights are blinking, this means a crew report as science experiment is available?

@Snark Can you confirm this, or is there another reason for the pod's lights blinking?

[Snark]

15 hours ago, Twinki said:

Are crew lights supposed to be blinking like this?

Yes. As @VoidSquid points out, it's a science indicator, same as with the science instruments. It means there's a crew report available to collect from the current location.

[VoidSquid]

45 minutes ago, Snark said:

science indicator

Talking of, as many science experiments do not give 100% of the available science when done, i.e. do get all science, they need to performed a couple of times, is there a threshold configurable for the blinking? Like one can set a threshold to say 50% or 90% in the Science Alert mod?

[Snark]

2 hours ago, VoidSquid said:

Talking of, as many science experiments do not give 100% of the available science when done, i.e. do get all science, they need to performed a couple of times, is there a threshold configurable for the blinking? Like one can set a threshold to say 50% or 90% in the Science Alert mod?

Yep. 

The relevant PartModule is ModuleScienceAvailabilityIndicator (note that this is distinct from ModuleScienceDataIndicator, which controls the lit-up display when the instrument already contains science).  That module has two configurable fields that are relevant to your question:

• lowScienceThreshold:  Defaults to 0.15.  Below this, no blinking.  Above this (but below highScienceThreshold), slow yellow blink.
• highScienceThreshold:  Defaults to 0.7.  Above this, rapidly flash bright green.  Below this (but above lowScienceThreshold), slow yellow blink.

Additional details in spoiler, for the curious.

Spoiler

The idea is that when there's "fresh" science available, its value is above highScienceThreshold and you get the bright green flashing.  If you've transmitted-but-not-retrieved the science, then you get the slow yellow blink.  If you've retrieved the science (or transmitted something that's 100% value for that, like a crew report), so that there's no (or negligible) science left, then it doesn't blink at all, it's just off.

If you look at the IndicatorLights config files for most of the science parts, you won't see either of these fields mentioned, because those parts just use the default values of 0.15 and 0.7 for the two thresholds.

However, you can see these fields in the Mystery Goo config and Science Jr. config, because I needed to override for those parts; they set the low threshold to 0.25 and the high threshold to 0.8.  That's because those parts have a lower science-return value for initial retrieval-- with the default values, they "acted funny".     They would show up as blinking yellow instead of flashing green, even when you haven't retrieved them yet... and then after retrieving them, they would still show as blinking yellow instead of just being off.

Anyway, those are the fields-- if you want to tweak the thresholds, that's the place to go.

 

[VoidSquid]

Wow... I didn't know, just been wondering, and you had this feature already implemented, nice!

Thanks, @Snark  

Edited September 8, 2019 by VoidSquid

[Snark]

Hi gang,

Just a note that I've released IndicatorLights v1.6.  No new features, just a compatibility update for KSP 1.8.

[Problemless Mods Wanter]

Hello,

I am lovingly using this wonderful mod, but unfortunately the RA-100 Relay Antenna's second small light is not compatible with the @Nertea's ReStock mod.

On 4/23/2016 at 3:36 AM, Snark said:

I know It's been asked about before, and @Tonka Crash and @Avera9eJoe were talking about it here, but I couldn't see any solutions or workarounds in conclusion.

Is there any way that I can edit some files to disable or move that second small light, only in that particular part?

I believe the related file is called "largeRelayDish.cfg" in "GameData\IndicatorLights\Parts\antennas" and I'm guessing that the mentioned light is defined by these values;

Quote

    MODEL
    {
        model = IndicatorLights/Meshes/nubbinLamp
        position = 0, 2.252, -0.07
        scale = 1.65, 1.65, 2
        rotation = -90, 0, 0
    }

Would it be OK if I removed all of the above part? Would I have to edit anything else?

Also, would it still work if I moved the "largeRelayDish.cfg" file into my "Personal Tweaks" folder, so I wouldn't have to redo or lose it in case of an update?

I would much appreciate any help or guidance about this issue and thanks in advance...

EDIT:

Using this guide here https://github.com/PorktoberRevolution/ReStocked/wiki/Restoring-Stock-Parts

I decided to make both versions available, but I won't delete this post in case anybody else is interested.

Edited December 7, 2019 by Problemless Mods Wanter
update

[Snark]

On 12/7/2019 at 8:09 AM, Problemless Mods Wanter said:

Is there any way that I can edit some files to disable or move that second small light, only in that particular part?

Yes, it's straightforward to remove an indicator mesh via ModuleManager.  Basically, would just need some config with an AFTER[IndicatorLights] directive, that deletes the Nth MODEL node, where N would depend on which mesh you're removing.

Out of curiosity, though... have you tried installing IndicatorLights Community Extensions?  That already contains a patch that's supposed to make IndicatorLights work with ReStock.  Does that not solve your problem?

[Problemless Mods Wanter]

On 12/11/2019 at 5:06 PM, Snark said:

Yes, it's straightforward to remove an indicator mesh via ModuleManager.  Basically, would just need some config with an AFTER[IndicatorLights] directive, that deletes the Nth MODEL node, where N would depend on which mesh you're removing.

Out of curiosity, though... have you tried installing IndicatorLights Community Extensions?  That already contains a patch that's supposed to make IndicatorLights work with ReStock.  Does that not solve your problem?

It is installed yes... Version 1.6... Wasn't aware it was installed, but it is...

And it seems, it's not working.

[Vagrant203]

I've been trying to find a good mod for science collection, and then I find the experiment lights here. That's a great solution rather than trying to find a toolbar that may or may not have hit 1.8.1 yet. Beautiful in its simplicity.