[1.12.x] IndicatorLights Community Extensions v1.6.2: Compatibility patches for IndicatorLights

[Snark]

2 minutes ago, Aelfhe1m said:

if IndicatorLights was aware of this value

...which it isn't, currently; thus the problem.

Given that it's a property on the stock ModuleDockingNode, though, it shouldn't be too hard to put a hook somewhere in IndicatorLights to make that work.  Hmmm....

[DStaal]

Question becomes how much work do you want to put into supporting this one mod, given that I don't know of any other docking ports that allow you to *change* their snap status.

On the other hand, it's a dependency of MKS, and available on it's own, so there's probably a fairly large userbase...

[DStaal]

Anyway: PR created.  I've done minimal testing - I know the lights show up in the correct places.

I created a 'USI' folder as part of the PR - hopefully more people will be willing to write USI patches.  (And also it makes it so the configs are closer to the stock configs that they're copies of - in case there needs to be cross-updates at some point in the future.)

[Snark]

6 hours ago, DStaal said:

Anyway: PR created.  I've done minimal testing - I know the lights show up in the correct places.

Woot!

Quick question:  Just suppose, hypothetically speaking (hint hint, wink wink) that I were just about to release an IndicatorLights update that will provide a new syntax that would allow you to address the angle-snap question.

In such a hypothetical situation, would you want to spend some more time to come up with a new version of your PR that incorporates some sort of visual indication of angle-snap status?  Or would you want to stick with the current PR, even if such functionality were available?

I only ask, y'know, hypothetically. 

 

[DStaal]

I’d probably want to spend some time to get the angle-snap status - honestly, the rest of the statuses don't matter that much to me, but that one it would be really nice to be able to quickly double check, especially on the *other* ship.

[Snark]

32 minutes ago, DStaal said:

especially on the *other* ship.

If what you want is an indicator that's in state A when angle snap is turned on and in state B when it's off, then that'll be covered by the update I'm working on.

However, if what you want is something that's based on the interaction of the pair of them, it's not going to have that.  So, for example, if you wanted to have some special flashing animation or other visual state that shows up when "we could dock, except we've got incompatible snap settings", then no.

[DStaal]

1 hour ago, Snark said:

If what you want is an indicator that's in state A when angle snap is turned on and in state B when it's off, then that'll be covered by the update I'm working on.

However, if what you want is something that's based on the interaction of the pair of them, it's not going to have that.  So, for example, if you wanted to have some special flashing animation or other visual state that shows up when "we could dock, except we've got incompatible snap settings", then no.

Mostly I'm just looking for a way to quickly check the state of the other ship.  You can always pull up the right-click menu on a part on the ship you're flying, but it's not always safe or easy to switch ships and pull it up on your target.  Being able to look over and say 'yep, it's in angle snap/not in angle snap' is enough that you can then check your settings and know if something needs to be changed.

Short version: I hadn't even been thinking about the latter.     Former is fine.

[Snark]

Ta dah!  Announcing the release of IndicatorLights v1.2.10, now with the field@module syntax added. 

Thus, for example, @DStaal, you could access the is-angle-snap-on-or-not functionality of the ports by using snapRotation@ModuleDockingNode as a toggle input in the appropriate place.

Or, alternately, perhaps portSnap@ModuleWeldablePort.

On 6/2/2017 at 1:47 PM, DStaal said:

Question becomes how much work do you want to put into supporting this one mod, given that I don't know of any other docking ports that allow you to *change* their snap status.

Point very well taken!  So what I did was to add a general-purpose feature that will work for any arbitrary field of any arbitrary module.  That way it's not just a one-off for USI ports, and it'll be useful to make other mods interoperate with IndicatorLights, even if they're using their own custom PartModules.

[DStaal]

Nice!  Now I just need to get my hands on KSP 1.3 and some elbow grease...

(Hmm.  I wonder how well this works with ModuleSwappableConverter...  I'm guessing that's going to be more complicated than this can handle, as it involves seeing what other modules are present in the cfg files...)

[Snark]

34 minutes ago, DStaal said:

I wonder how well this works with ModuleSwappableConverter

No idea, never heard of it-- what mod is it from, what does it do, and how does it work?

[DStaal]

10 minutes ago, Snark said:

No idea, never heard of it-- what mod is it from, what does it do, and how does it work?

It's from MKS - and it's fairly complicated to describe.  Let me post a fairly minimal example from a config:  (I could probably make it clearer - but this is close enough, I think.)

@PART[KKAOSS_LS_container_greenhouse]:NEEDS[USILifeSupport]:NEEDS[KolonyTools]
{
    MODULE
	{
		name = ModuleSwappableConverter
		bayName = Tank
		typeName = Bay
		ResourceCosts = SpecializedParts,5,MaterialKits,1,ElectricCharge,3
	}

    @MODULE[ModuleKPBSConverter]
    {
        @name = ModuleResourceConverter_USI
        UseSpecialistBonus = false      // This is an automated part.
    }

	MODULE
	{
		name = ModuleEfficiencyPart
		ConverterName = [Greenhouse]
		eTag = Greenhouse
		StartActionName = Start [Greenhouse]
		StopActionName = Stop [Greenhouse]
		UseBonus = false
		Efficiency = 1
		eMultiplier = 0.5

// Snip
	}

The above adds a ModuleSwappableConverter to the container greenhouse from KPBS.  The converter has one 'bay', which can be switched between the ModuleResourceConverter_USI and the ModuleEfficiencyPart's configurations - Both cannot be active at the same time, you have to choose.  (By sending an engineer Kerbal EVA, right-clicking on the part, and paying the ResourceCosts to do the switch.)

More options to switch to can be configured by adding more ModuleResourceConverter_USI, ModuleResourceHarvester_USI, or ModuleEfficiencyPart modules to the part in the config.  More bays can be added by adding more ModuleSwappableConverters to the part in the config.  Each bay is independent of the rest, and you can switch any bay to any mode that the part has.  You can have more bays than modes (though probably zero modes would be an issue...), or more modes than bays.  (Potentially a lot more.  The USI drills for instance have around a dozen different modes - with one to three bays.)

This means you can have the same part be doing quite different things, depending on how it's configured.  A quick example is an ISRU that could be configured to produce LFO or Monopropellant - but not both at the same time.  (Or switched to just produce LF - without also being able to produce LFO.)  A slightly larger ISRU could be configured to produce both - or to produce just one at double the rate.

Anyway: It would be nice to be able to tell which set of modes a particular part was in - but I'm not sure that Indicator Lights is the right way to do that, anyway.  But I suspect that it would take more work to support, as which bay you're talking about, how many bays you have, what options there are per-bay, etc. can all be changed in the cfg file (or, as above be altered by MM).  So I'm not sure a particular order or numeric filter will ever be sure to catch a specific configuration.  An option might be to have a light panel with different lights for each bay/module configuration option - but that could in theory get complicated.  (Though in practice most wouldn't be more than 3x4 or so.)

Just daydreaming here mostly.    I know WildBlueIndustries has a similar system for switching modules via config files as well - although *they* swap textures when they do it, so you can see at a glance which mode each part is in.  (Their switch is more extensive as well - You can turn a fuel tank into crew quarters, or a science lab, for example.)

[Aelfhe1m]

38 minutes ago, DStaal said:

Anyway: It would be nice to be able to tell which set of modes a particular part was in - but I'm not sure that Indicator Lights is the right way to do that, anyway.  But I suspect that it would take more work to support, as which bay you're talking about, how many bays you have, what options there are per-bay, etc. can all be changed in the cfg file (or, as above be altered by MM).  So I'm not sure a particular order or numeric filter will ever be sure to catch a specific configuration.  An option might be to have a light panel with different lights for each bay/module configuration option - but that could in theory get complicated.  (Though in practice most wouldn't be more than 3x4 or so.)

With the way that bays are configured in USI using multiple instances of ModuleSwappableConverter, I think you'd need some way of specifying an index in the IndicatorLight config in order to set up separate lights for each bay (perhaps something like value@module[ i ] ?). 

Some way of indexing a module instance could be useful for other parts where there are multiple copies of the same module configured to slightly different behaviours.

Edited June 5, 2017 by Aelfhe1m

[Snark]

43 minutes ago, Aelfhe1m said:

With the way that bays are configured in USI using multiple instances of ModuleSwappableConverter, I think you'd need some way of specifying an index in the IndicatorLight config in order to set up separate lights for each bay (perhaps something like value@module[ i ] ?).

Yah, the thought had occurred to me as well.  If I did do it, I'd probably follow the syntax convention I already use for indexing meshes-with-the-same-name, i.e. with a colon, like value@module:N where N is the index.  It wouldn't be all that hard to write.

1 hour ago, DStaal said:

It's from MKS - and it's fairly complicated to describe.

<complicated description>

....Yeah, that does sound kinda tricky.  Depending how "dynamic" the config is (e.g. how much the player can change on the fly, as opposed to how much is baked into the .cfg files), it could range anywhere on the spectrum:

• best case, "currently doable, but incredibly tedious to author the patch"
• pretty good case, "same as above, but would only need some fairly minor tweak by Snark to enable"
• worse case, "would be doable, but only with massive new functionality in IL that would be huge, complicated, and time-consuming for Snark to try to build" ( = "not going to happen")
• worst case, "it can't be done in generic fashion by IL, even with lots of work-- needs to be addressed by custom code dependent on MKS"  ( = "not going to happen by Snark, ever; would need a dedicated modder who can write code")

 

[DStaal]

It's not hugely dynamic - All the player can change is which converter/harvester is active in which bay.  Number of bays and types of converter/harvesters are baked into the cfg files.  It's actually very simple to see in action: In the right-click menu, for each bay, you can select 'previous' or 'next' configuration, cycle through until you pick the one you want and then click 'reconfigure'.  (Which pays the reconfig cost - so you don't have to pay it while you're cycling through.)

But even if I could do it, I'm not entirely sure how I'd want to present it via lights.

[Snark]

7 hours ago, DStaal said:

But even if I could do it, I'm not entirely sure how I'd want to present it via lights.

Yeah, that's a tricky one.  About all I could think of would be to have one light per bay, and color code them:  off = empty bay, on dim = full-but-inactive bay, on bright = active converter.  Color would indicate which converter it is.  You'd have to pick a distinct color for each converter type.

I believe it's technically doable, but the UX may be... suboptimal.  Honestly, it feels like it would probably just be visual noise for the player, particularly if they have lots of parts.  This is one of those cases where I suspect that less is more, and maybe just better off letting the player interact via the right-click menu.

Maybe put just a single light on there that lights up if any of the converters are active, or something?  Basically, the strategy is to distill it down to the bare essential of "what is the single important bit of information that the player wants to know at a glance?" and go with that.

[DStaal]

46 minutes ago, Snark said:

Yeah, that's a tricky one.  About all I could think of would be to have one light per bay, and color code them:  off = empty bay, on dim = full-but-inactive bay, on bright = active converter.  Color would indicate which converter it is.  You'd have to pick a distinct color for each converter type.

I believe it's technically doable, but the UX may be... suboptimal.  Honestly, it feels like it would probably just be visual noise for the player, particularly if they have lots of parts.  This is one of those cases where I suspect that less is more, and maybe just better off letting the player interact via the right-click menu.

Maybe put just a single light on there that lights up if any of the converters are active, or something?  Basically, the strategy is to distill it down to the bare essential of "what is the single important bit of information that the player wants to know at a glance?" and go with that.

Well, the most common problem in MKS is figuring out where you're resource-starved.  If I was going to distill it down like that, I'd probably want one light per bay, with two colors: Green for 'on and processing without issue', Red for 'On and has issue' and then off is for off.  I can't think of any MKS parts with more than 3 bays off the top of my head (and my KPBStoMKS pack maxes out at 6).  (Note by the way that there's no such thing as an 'empty' bay - every bay is always in *some* configuration, you can just switch which it is.)

The player would then be able to right-click on that part in particular to see how it was configured, and what it was running out of.

Other option would be to tie to efficiency - probably brighter is higher efficiency, as long as it's on.  That might be able to cover 'has issues' as well - I'm not sure if 'out of resources' counts as 0% efficiency or if the two mechanics are unrelated.  If they are related, then the dimmest lights would always be your limiter, and you could work out how to handle that.  Main issue there is that efficiency has no upper bound that I know of in MKS...  (It increases over time as your Kerbals colonize a planet/moon.)

Anyway, this is all me just thinking out loud here.    First I need to get my hands on a copy of KSP 1.3, finish the patch for the construction ports, and finish my KPBStoMKS patches.  Then I can start thinking of more complicated things like this.

[DStaal]

BTW: I have working patches for angle-snap, I'm just debating on light placement - particularly on the 'normal' sized construction port.  I don't want to change any of the lights they carry over from the normal docking ports, but I'm not sure where a good additional light placement would be.  If anyone has ideas (even just a description) I'm open.  I'm debating whether 'inside' the docking port is a good idea: you don't really care about this once they're docked, but you do want to be able to spot it easily while docking.  (Additionally, if the snap-light could give some idea of which side is 'up' that would also be useful.)

[Snark]

1 hour ago, DStaal said:

I'm debating whether 'inside' the docking port is a good idea: you don't really care about this once they're docked, but you do want to be able to spot it easily while docking.

^ This seems pretty reasonable to me.

1 hour ago, DStaal said:

(Additionally, if the snap-light could give some idea of which side is 'up' that would also be useful.)

^ Also a really excellent idea.

Perhaps a light that's dead-center in the middle of the docking port?  If you want to re-use the indicator meshes that come with IndicatorLights and don't want to try to roll your own using Blender, perhaps the snap-light could consist of two meshes:  say, a circular one that's dead-center on the port, and then a skinny horizontal line immediately below it, like an underscore, to demonstrate which way is up?

Or maybe someone else has a better idea.  Goodness knows I'm not much of a graphic designer or an artist. 

[DStaal]

Ok, I stumbled upon a decent placement for the middle-sized docking port.  (I put the snap indicators for the mid-sized on the docking ring itself...  Three, top, right, and left.)  PR updated.

[Snark]

Hi gang,

I'm pleased to announce the release of IndicatorLights Community Extensions v1.3.  This update adds support to MKS construction ports, courtesy of @DStaal.

Aside from adding the same indicators that stock docking ports have (since these do function as docking ports), they've also got "angle snap" indicators, which is an MKS thing.  The indicators not only show whether angle snap is turned on or not, but also their placement indicates which way is "up" (useful when aligning things).

A round of applause, please, to @DStaal for stepping up to the plate! 

[Critter79606]

Snark,

I've been getting an error loading GameData\IndicatorLightsCommunityExtensions\patches\IndicatorLights_PorkjetPartOverhauls.cfg, even with the new ModuleManager release.

I tracked down to this line.

@PART[mk1podNew]:AFTER[PartOverhauls]:AFTER[IndicatorLights]:NEEDS[IndicatorLights]:NEEDS[PartOverhauls]
According to https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering

You can control how module manager applies patches through these five directives, that are applied at the top-level node. Only ONE of these directives can be applied to a specific top-level patch.

• :FIRST
• :BEFORE[modname]
• :FOR[modname]
• :AFTER[modname]
• :FINAL

I was able to fix it (at least I'm not getting an error) by changing it to

@PART[mk1podNew]:AFTER[PartOverhauls&IndicatorLights]:NEEDS[IndicatorLights]:NEEDS[PartOverhauls]

but I'm new to the syntax and not 100% sure I got it right.

[Snark]

16 hours ago, Critter79606 said:

I've been getting an error loading GameData\IndicatorLightsCommunityExtensions\patches\IndicatorLights_PorkjetPartOverhauls.cfg, even with the new ModuleManager release.

Thanks for spotting!    The various config files in IndicatorLights Community Extensions are just that-- community-supplied-- and I neither author them myself, nor even bother to check whether they're correct (for one thing, they often involve mods that I'm not running myself, so it would be time-consuming for me to test and verify.)

You're correct, NEEDS is redundant in the above cases.  "BEFORE" and "AFTER" imply NEEDS.

When I have a moment, I'll take care of this and post an update.  Shouldn't be too hard to fix, hopefully it'll be pretty soon.

[Skalou]

I suggest a fix for the MK1CabinHatch patch,
you could use instead:

// Thanks to SchwinnTropius on the KSP forums for supplying this patch!
// Mod thread for MK1CabinHatch:
// http://forum.kerbalspaceprogram.com/index.php?/topic/151443-12x-mk1-cabin-hatch-v020-3-november-2016/

@PART[MK1CrewCabin]:NEEDS[MK1CabinHatch]:NEEDS[IndicatorLights]:AFTER[IndicatorLights]
{
	@MODEL:HAS[#position[0,?0.469,?-0.625]]
    {
        @position = 0,-0.35, -0.625
    }
	@MODEL:HAS[#position[0,?-0.469,?-0.625]]
    {
        @position = 0, -0.5375, -0.625
    }
}

tested on KSP 1.3.1
module manager 3.0.1
Mk1-Cabin-Hatch v0.2.0
IndicatorLights v1.2.11
IndicatorLights Community Extensions v1.3 (exept the  MK1CabinHatch patch)

Thank's for you mod

[Snark]

On 12/8/2017 at 8:10 PM, Critter79606 said:

I was able to fix it (at least I'm not getting an error) by changing it to

@PART[mk1podNew]:AFTER[PartOverhauls&IndicatorLights]:NEEDS[IndicatorLights]:NEEDS[PartOverhauls]

but I'm new to the syntax and not 100% sure I got it right.

Could you do me a favor?  Try testing it with this syntax and see whether it works for you?

@PART[mk1podNew]:AFTER[PartOverhauls&IndicatorLights]

Would save me a bunch of testing time.  Specific things to check:

• Does it work as expected (provides indicator light on the mk1 pod) when PartOverhauls is installed?
• Does it work when PartOverhauls is not installed?  (i.e. doesn't cause errors complaining "no such part mk1odNew" or similar)?

Thanks!

2 minutes ago, Skalou said:

you could use instead

Thank you!  One more request:  Could you try it thus to see if it still works?

@PART[MK1CrewCabin]:NEEDS[MK1CabinHatch]:AFTER[IndicatorLights]

Rationale:  I believe that AFTER actually implies NEEDS, so that if it says "AFTER[IndicatorLights]", I believe it doesn't actually need to have "NEEDS[IndicatorLights]".

[SchwinnTropius]

@Skalou, @Critter79606, just did some testing of my patches and I have syntax that works on my system: 

Spoiler

Mk1 Cabin Hatch: @PART[MK1CrewCabin]:AFTER[IndicatorLights]:NEEDS[MK1CabinHatch]

PartOverhauls: @PART[mk1podNew]:NEEDS[IndicatorLights]:AFTER[PartOverhauls]

I tried using :AFTER[IndicatorLights&PartOverhauls] but the patch wouldn't work at all and left no obvious errors. The syntax in the spoiler seems to work as expected for me, but can you try this out and see if it works for you (if you have not already done so by now)?