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

[Trann]

On 12/15/2017 at 8:59 PM, Snark said:

So, you're saying you're consistently seeing the problem, regardless of which ModuleManager version you have?  The problem is there with MM 2.8.1, and is also there with MM 3.0.1?

Yup but I'm now certain it's a mod conflict: I yanked all but Indicator Lights and the Squad folder and was able to put a HECS2 and telescope on the pad like you.  Given that, I expect it's not worth the effort of passing you log files (though I did do some collecting and grepping  ).  I'll try to find some time to play the mod elimination game.

Thanks a lot for your quick response on this (and to DStaal and Rocket, too).

UPDATE: Ok, I'm watching some hockey here and figured, "What the heck: let's start debugging this."  Two mods later:

It appears to be Asteroid Day for Kerbal Space Program 1.2.  That mod had to have been in conflict with AsteroidDay.  Having just Asteroid...1.2 and Indicator Lights, I saw the problem; having just AsteroidDay and Indicator Lights, there was no problem; having all 30 mods except Asteroid...1.2, there was no problem.  Oddly, both README files state they are 1.2 but the working one has a few more lines about installation instructions.

I think this one is solved.  Thanks for your patience!

Edited February 21, 2018 by Trann
Photo*ucket

[Snark]

Hi everyone,

I'm pleased to announce the release of IndicatorLights version 1.2.12, a.k.a. "The @Wcmille Edition". 

New feature is that crew indicators flash when a crew report is available.  I added the feature to all the crew-report-capable parts currently instrumented with crew indictors, except for the Mk3 crew cabin.  (Skipped that one because it has 16 indicators on it, and with the extra number of modules required here, I had some concern about potential performance hit.)  Thanks to Wcmille for the excellent suggestion!

• An empty crew slot will stay dark, regardless of whether a crew report's available or not.
• A filled crew slot will flash if there's an available crew report that's worth new science, and the part doesn't already have its "crew report" slot full with another report.

Other than this new feature, I've also taken the opportunity to update the bundled ModuleManager to the latest version, 3.0.1.

Please let me know if anyone finds any problems.  (I'm sure you will...)

Enjoy!

[cyberKerb]

Thanks for the update! Still love this mod and thanks for your work on it!
One thing I noticed, would it be possible to add a title to your agent cfg file in the next release? It fixes a minor error on game load where it's expecting a title tag. The frustrating thing is that KSP doesn't give any hint as to which mod causes it, so it's something I check whenever a mod updates.

Example:

AGENT
{
  name = Blinkenlights LLC
  title = Blinkenlights LLC

etc...

 

[Rocket In My Pocket]

Hey @Snark since we are talking about adding more blinking lights anyways.

I can't remember the name of the mod, but it's out dated now for sure, (it did something with lights?), but anyways it had a really nice, sort of novel feature where when you came into physics range when rendezvousing with another craft, it would blink it's lights at you for a bit as a form of "greeting." Making it easier to spot as well.

Do you think a functionality like this would be possible to implement? and/or fit with your over all vision of the mod?

Edited December 19, 2017 by Rocket In My Pocket

[Snark]

5 minutes ago, Rocket In My Pocket said:

I can't remember the name of the mod, but it's out dated now for sure, (it did something with lights?), but anyways it had a really nice, sort of novel feature where when you came into physics range when rendezvousing with another craft, it would blink it's lights at you for a bit as a form of "greeting." Making it easier to spot as well.

Do you think a functionality like this would be possible to implement? and/or fit with your over all vision of the mod?

Interesting idea!  But the short answer is "no." 

The longer answer (and, knowing me, you just knew there would be one, don't deny it) is in a spoiler section.

Spoiler

It would certainly be possible to do something like that... except that I don't think it really "fits" with what the mod is about.

On the purely technical level:  It's a large, complex set of behavior that would need lots of work to define exactly how it should behave.  What range should it be?  What should the blinking look like?  How long should it last?  How does it remember when it started?  Big great ugly mass of code, a lot more complex than you'd think.  That means that, first, it would be a great big honking piece of work for me.

Second-- and still at the technical level-- it would share basically nothing whatsoever in common with all of IndicatorLights code.  Literally, it would have no code in common.  You might think "but it's the same thing! with the lights!  and the blinking!", but you'd be wrong.     Technically, it's a horse of a completely different feather.  Implementing this would be like just implementing a completely separate mod that does a completely different thing and just bunging it in there.  So, even if I wanted to implement this (which I don't, it's not my cup of tea), I'd   never package it with IndicatorLights-- it would be a standalone mod of its own.

Nor would it actually involve any of the IndicatorLights lights.  The lights from IndicatorLights often aren't even on unless they're actively displaying something, and in any case they tend to be too tiny to see from a distance.  Any such code functionality would need to work with the really big, visible lights, like the spotlights and cabin lights and such.  Which, again, means it really has nothing to do with IndicatorLights per se.

Then there's the issue of motivation.  I've got precious little free time, and modding competes with other activities for that time-- such as playing KSP, or spending time with loved ones.  So, my solution to that conundrum is to be a really selfish modder.  I mod primarily for me, i.e. to make the game do things that I like.  The fact that I share it online with several thousand of my closest friends is just a side benefit.    But that carries with it the fact that I'm never going to spend any time whatsoever modding a thing that I, myself, would never use.  And this falls into that category.  It simply doesn't appeal to me.  It sounds neat and all, and there's nothing wrong with it, and I'm sure lots of other people might like it, but in my own gameplay I would have basically zero use for it, which means I don't have any motivation to code it.

And, finally... I think that conceptually it just doesn't really fit all that much with what IndicatorLights is about.  When I imagine "why do people install IndicatorLights", I don't think that's it.  I tend not to care for "kitchen sink" type mods that do too much stuff-- I'm a fan of small, compact, precisely "targeted" mods that do basically just one thing and do it really well, so that anyone can get exactly the KSP experience they want by just picking and choosing from a wide and varied menu of available mods.  So I'd be philosophically opposed to including this in IndicatorLights, anyway.

So, anyway:  neat idea for a mod.  But it doesn't really fit with IndicatorLights, IMHO.

 

[DStaal]

I've got a better reason for you Snark:

The original mod still exists!

 

 

[Snark]

6 hours ago, wile1411 said:

One thing I noticed, would it be possible to add a title to your agent cfg file in the next release? It fixes a minor error on game load where it's expecting a title tag. The frustrating thing is that KSP doesn't give any hint as to which mod causes it, so it's something I check whenever a mod updates.

Huh.  Never saw that before, myself.

I bet I know what happened.  I bet it's a new thing they added with the localization stuff in KSP 1.3.  Technobabble, for the curious, in spoiler section.

Spoiler

I note that in Squad's agency definitions, the "name" and the "title" are identical... but the "title" field is localized, and the "name" field is not.

That makes perfect sense to me.  If you have a collection of named objects that need to be displayed to the user, then as a programmer, you really need two fields:   one immutable, language-independent identifier that's used only internally by the computer program as a unique ID, and one localized identifier suitable for display to the user.  I think what happened here was that the AGENT node got designed in KSP way back in the beginning before anyone thought about localization, so they (unfortunately) used the "name" field both as the unique ID and as the user-displayable string.

So, later on when they went to localize KSP in 1.3, I bet someone facepalmed and thought "well crap, now that's awkward."  They couldn't change the unique IDs to something compact and more computery at that point, since it was already all over the place and goodness knows how many mods or whatever might have references to the old IDs.  So they did basically the only thing they could do, which is to add a new field called "title", localize that, and then update the game code so that it uses title instead of name when it displays stuff to the user in-game.

I wrote IndicatorLights back before KSP 1.3 was a thing, and my AGENT definition was perfectly correct at the time, because the way I wrote it was to just look at Squad's own agent definitions and then just copy the format.    But then KSP 1.3 came along, and they changed the definition of AGENT nodes in KSP, but I didn't get the memo and so now my definition's out of date.

(So, this isn't really just an IndicatorLights thing.  It'll be an issue with any mod that added an agent before KSP 1.3, if they haven't specifically updated to take care of the matter.)

Anyway, quickly and trivially fixable.  Thanks for calling it to my attention!  This one's small enough that I won't release a new IndicatorLights version just to fix this one thing, but I've edited the file locally so the fix will be incorporated the next time I release.  In the meantime, for anyone whom this error bothers, you can just locally edit the file as shown by @wile1411 above.

[Rocket In My Pocket]

2 hours ago, DStaal said:

I've got a better reason for you Snark:

The original mod still exists!

 

 

Nice, good find!

[Beetlecat]

On 12/16/2017 at 5:23 PM, Trann said:

It appears to be Asteroid Day for Kerbal Space Program 1.2.  That mod had to have been in conflict with AsteroidDay.  Having just Asteroid...1.2 and Indicator Lights, I saw the problem; having just AsteroidDay and Indicator Lights, there was no problem; having all 30 mods except Asteroid...1.2, there was no problem.  Oddly, both README files state they are 1.2 but the working one has a few more lines about installation instructions.

I think this one is solved.  Thanks for your patience!

I know this one is solved now -- but wasn't the former asteroid day "mod" folded into stock in a more recent game version? If you're just working with KSP 1.2, then nevermind.

[Snark]

1 hour ago, Beetlecat said:

I know this one is solved now -- but wasn't the former asteroid day "mod" folded into stock in a more recent game version? If you're just working with KSP 1.2, then nevermind.

Given the specific symptom that @Trann ran into, and the discovery of what the actual the problem turned out to be, I can make an educated guess as to what I suspect went wrong.

Technobabble in spoiler section for the curious, but what it boils down to is "I suspect they made <certain syntactic change> when rolling it into stock KSP, and my IL patch is designed for the new config, and would have this side effect on the old config."

Spoiler

Every .cfg for a KSP part needs to specify, among other things, its model:  the actual binary file that defines the shape and texture layout of the part.  The model is a .mu file that typically (but not necessarily) sits in the same folder as the .cfg file.

The KSP config language has evolved over time.  There used to be one kind of syntax for specifying the model, which looked like this (taken from the config for the Mk1 command pod):

mesh = model.mu

...If you look at the various part .cfg files in KSP 1.3.1 today, you'll see that a lot of the older parts (such as the Mk1 command pod example above) use this syntax.

Then, at some later time, they introduced a new type of syntax for specifying the model, which looks like this (taken from the config for the HECS2 probe core):

MODEL
{
    model = Squad/Parts/Misc/AsteroidDay/HECS2
}

If you look at KSP now, you'll see that this is the format you'll generally see on the newer parts (such as HECS2).

Even though they introduced the new syntax, though, the old one still works.  Any config file can use either way to specify their model.  And when Squad introduced the new syntax, they didn't bother going back and updating all the old parts' config; they just left them as is, with the old "mesh" syntax instead of the modern "MODEL" syntax.

Now... that syntax makes absolutely zero difference to players.  The game's gonna load the model just fine either way, without any difference at all to the player.  Which-syntax-does-it-use is completely transparent to the player.

However... it's not transparent to modders who are patching things with ModuleManager.  Without going into technical detail:  the old-style "mesh" syntax won't work with ModuleManager in the way that IndicatorLights needs to in order to add the lights to the model.  For what I do, it only works with the new-style "MODEL" syntax.

And when I say it "doesn't work" with the old-style syntax... guess what happens if I try?

Go on... you'll never guess. 

...yeah, that's right, you guessed it.  If I used IL config to add indicator lights onto a part that has the old "mesh" style syntax... then the whole part model vanishes and you're left looking at some disembodied indicator lights floating in space.  Just like @Trann saw.

"But Snark," I hear you cry.  "That can't be right, because you put an indicator light on the Mk1 command pod, and didn't you just say that it uses the old syntax?"

That's an excellent point, friend.  And it is right.  When I'm writing the MM config for one of these older parts, I just need to add an extra bit of tinkering.  I use MM to remove the old "mesh" model, and then add that same exact model back to the part, using the new syntax.  Then it can add the indicator lights.

So... with all that blather in mind, here's what I suspect is going on.  This is just a guess, but it's an educated one.

1. Long ago, Squad made the "Asteroid Day" mod, with the telescope part in it.
2. In the Asteroid Day mod, the telescope used the old "mesh" syntax.  (this is my guess)
3. Later on, Squad released KSP 1.3, and included the telescope as stock.
4. But when they did that... they went in and tidied up the config file, changing it to use the new "MODEL" syntax instead.
5. Along comes Snark, and says "Oh, I'll add the telescope to IndicatorLights."
6. Snark looks at the telescope's config, and sees that it uses the new "MODEL" syntax.  "Oh goody," says Snark, "that's perfect, I can just add indicator lights without having to add the extra tinkering to handle a mesh-syntax part."  So he does.
7. Along comes Trann, who installs the Asteroid Day mod into KSP.  This means he has the old "mesh" syntax in his config.
8. Trann then installs IndicatorLights.  The telescope.cfg that comes with IndicatorLights is designed to work with the new config, not the old config.
9. Result:  it vanishes the telescope model, exactly as Trann observed.

With that in mind, it wouldn't be too hard to write a snippet of MolduleManager code that would detect if the AsteroidDay mod is there, and, if so, swap out the model with the new syntax.  That would then enable Trann to use the telescope config without the hilarity.

@Trann, I suspect that if you were to paste the following into a new .cfg file, then stick it somewhere in GameData, then it might fix the problem you had with the telescope.

@PART[InfraredTelescope] {
    MODEL
    {
        model = Squad/Parts/Misc/AsteroidDay/CamSat
    }
}

 

[Trann]

I love a good tangent!  Thanks much, Snark  

[Snark]

11 hours ago, Trann said:

I love a good tangent!

I've always been more partial to cosines, myself.

[Trann]

3 hours ago, Snark said:

I've always been more partial to cosines, myself.

Forgive me for being obtuse but what's your angle here?

 

(I'll stop now)

[Wcmille]

What do you think of allowing Engineers to change the properties of a BL-01 indicator light?

[Fireheart318]

It was a little hard to tell because I was testing it in midmorning light but do the standalone lights actually light anything? Can there be an option to make them actually light things? If they could actually light things up I'd never use the stock lights again!

[Snark]

4 hours ago, Fireheart318 said:

It was a little hard to tell because I was testing it in midmorning light but do the standalone lights actually light anything? Can there be an option to make them actually light things? If they could actually light things up I'd never use the stock lights again!

No, they don't light anything-- like everything in IndicatorLights, they just glow.  Nor will that change.  Actual lights which illuminate thing use a completely different sort of code from what IndicatorLights does... and they're also a lot more expensive, graphics-wise.  IndicatorLights is about making little glowy blinky things, not actually adding illumination to anything.

If what you want is to actually light things up... perhaps this other mod might be closer to what you want?

[Fireheart318]

57 minutes ago, Snark said:

No, they don't light anything-- like everything in IndicatorLights, they just glow.  Nor will that change.  Actual lights which illuminate thing use a completely different sort of code from what IndicatorLights does... and they're also a lot more expensive, graphics-wise.  IndicatorLights is about making little glowy blinky things, not actually adding illumination to anything.

If what you want is to actually light things up... perhaps this other mod might be closer to what you want?

Yes it is, but I really like the look of the independent light more so I might try to use both mods.

Thanks!

[coolguy8445]

Hi, 

I'm getting a ton of logspam from this mod that looks exactly like the following (2 separate errors, not necessarily sequential):

[EXC 19:48:31.537] ArgumentNullException: Argument cannot be null.
Parameter name: key
	System.Collections.Generic.Dictionary`2[System.String,IndicatorLights.VesselScienceContents+CacheItem`1[System.Boolean]].TryGetValue (System.String key, IndicatorLights.CacheItem`1& value)
	IndicatorLights.VesselScienceContents.get_Item (System.String subjectId)
	IndicatorLights.ModuleScienceAvailabilityIndicator.AlreadyHasAboard (System.String subjectId)
	IndicatorLights.ModuleScienceAvailabilityIndicator.get_CurrentSource ()
	IndicatorLights.ModuleScienceAvailabilityIndicator.get_HasColor ()
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()



[EXC 19:48:31.489] IndexOutOfRangeException: Array index is out of range.
	CBAttributeMapSO.GetAtt (Double lat, Double lon)
	ScienceUtil.GetExperimentBiome (.CelestialBody body, Double lat, Double lon)
	IndicatorLights.ModuleScienceAvailabilityIndicator.GetBiome (.Vessel vessel)
	IndicatorLights.ModuleScienceAvailabilityIndicator.GetSubjectId (.ScienceExperiment experiment, .Vessel vessel)
	IndicatorLights.ModuleScienceAvailabilityIndicator.get_SituationSubjectId ()
	IndicatorLights.ModuleScienceAvailabilityIndicator.get_CurrentSource ()
	IndicatorLights.ModuleScienceAvailabilityIndicator.get_HasColor ()
	IndicatorLights.ModuleScienceDataIndicatorBase`1[T].get_HasColor ()
	IndicatorLights.ModuleEmissiveController.SetColors ()
	IndicatorLights.ModuleEmissiveControllerBase.Update ()

Log (sorry for the size; trying to track down and clear out mod issues): https://drive.google.com/open?id=1cdx4AVSOvBStcenYbQYOp35wZKMfbRCP

From what I can tell, this doesn't appear to be causing any harm, especially considering it looks to be a cache dictionary that's unhappy.

Edited February 17, 2018 by coolguy8445
add another exception

[Snark]

On 2/17/2018 at 7:57 AM, coolguy8445 said:

I'm getting a ton of logspam from this mod that looks exactly like the following

Thanks for the report!  Will look at this when I have the chance.

Do you have any additional context?  Does this happen all the time for every ship that has science instruments on it, continuously everywhere?  Or only for certain ships?  Or only for certain parts?  Or only for certain locations / situations?  Are you running other mods?  Does it reproduce when just IndicatorLights is installed?

Don't get me wrong, I suspect that I can put some safeguard code in there to prevent it from occurring (the call stack you provided is very helpful)... just would like to know what I missed, since I I haven't been getting these errors myself, and if there's some important test case I've been missing, would be nice to know about it. 

[coolguy8445]

hehehe..."are you running other mods"... Let's just say I'm running more than enough to choke a horse and make the sim a little cranky.

So, I learned after I posted that that the errors in "ScienceUtil.getExperimentBiome" are caused by the latest Kopernicus, which apparently broke at least Minmus' biomes. Not much to be done in your mod for that, I suspect.

As for the caching error, I'm not sure whether it's any particular vessel. It may be just some modded part being cranky, and doesn't seem to affect gameplay, so I'm not terribly worried about it. Here's my (admittedly monstrous) ksp.log from the session those errors came from, though: https://drive.google.com/open?id=1cdx4AVSOvBStcenYbQYOp35wZKMfbRCP

[Snark]

Hi all,

Well, KSP 1.4 has shipped, and with it a nice shiny new Mk1-3 command pod!  Which I'm sure you'd love to have crew indicators on. 

Well, I'm kinda busy right now, so no new IndicatorLights version today.  And with Making History coming out in just a week's time, with its own parts needing indicators, I'd just as soon not make two IndicatorLights releases in quick succession.  So I'm going to hold off on revving IL until Making History has shipped.  Rest assured, I'll have stuff instrumented pretty quick after that.

In the meantime, if you just can't wait to get you some indicators on the Mk1-3, I've checked in a file for that, which you can use to manually update your IndicatorLights installation, if you are so inclined:

https://github.com/KSPSnark/IndicatorLights/blob/master/files/Parts/crewable/mk1-3pod.cfg

...just download that file and copy it into the IndicatorLights/Parts/crewable folder, and you should be good to go.

Anyway, hope you're enjoying 1.4!

[viperwolf]

On 3/7/2018 at 10:24 AM, Snark said:

Hi all,

Well, KSP 1.4 has shipped, and with it a nice shiny new Mk1-3 command pod!  Which I'm sure you'd love to have crew indicators on. 

Well, I'm kinda busy right now, so no new IndicatorLights version today.  And with Making History coming out in just a week's time, with its own parts needing indicators, I'd just as soon not make two IndicatorLights releases in quick succession.  So I'm going to hold off on revving IL until Making History has shipped.  Rest assured, I'll have stuff instrumented pretty quick after that.

In the meantime, if you just can't wait to get you some indicators on the Mk1-3, I've checked in a file for that, which you can use to manually update your IndicatorLights installation, if you are so inclined:

https://github.com/KSPSnark/IndicatorLights/blob/master/files/Parts/crewable/mk1-3pod.cfg

...just download that file and copy it into the IndicatorLights/Parts/crewable folder, and you should be good to go.

Anyway, hope you're enjoying 1.4!

thank you for this, I just found your mod last week.

[Snark]

Hi everyone,

I'm pleased to announce the release of IndicatorLights v1.3, now with full Making History support!

Crew indicators added to everything crewable, including the inflatable airlock.

Enjoy! 

[viperwolf]

Just now, Snark said:

Hi everyone,

I'm pleased to announce the release of IndicatorLights v1.3, now with full Making History support!

Crew indicators added to everything crewable, including the inflatable airlock.

Enjoy! 

Thank you Thank you and Thank you, BTW did i say Thank you!

 

[Turk_WLF]

On ‎3‎/‎14‎/‎2018 at 12:03 AM, Snark said:

Hi everyone,

I'm pleased to announce the release of IndicatorLights v1.3, now with full Making History support!

Crew indicators added to everything crewable, including the inflatable airlock.

Enjoy! 

Thank you!