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

[Beetlecat]

Yup -- it's that same case of -- leave the game long enough, forget all the bugfixes people post a few pages back in the forums...

[aceman67]

First off, love The main mod, and this extension, but I have a question.

I use Restock/Restock+, but I also use the SDHI Service Module System which required me to white list the Stock 1-3 Command Pod and duplicate the Restock variant (the parts in that mod don't fit the Restock Variant of the pod), and what I found is that the Indicator lights on the Stock Pod are there and work, but there's three white lights that float just above those lights, which i assume is where they would be on the Restock Variant.

You can kinda see it in this image: https://imgur.com/UeifHz5  (I'm at work, so I can't get a better image).

Is there a way I can modify the MM Patch so that it plays nice with both Restock and Stock variants of the pod?

[TicTac]

On 2/14/2020 at 4:18 PM, gunt3rgam3r said:

I don't have tweakscale installed in my save.

Found a fix:

  Reveal hidden contents

// Small radial battery
@PART[batteryPack]:AFTER[ReStock]:NEEDS[IndicatorLights]
{
    -MODEL,* {}
    MODEL
    {
        model = ReStock/Assets/Electrical/restock-battery-radial-small-1
        position = 0.0, 0.0, 0.0
        scale = 1,1,1
        rotation = 0, 0, 0
    }

If you reset the scale to 1,1,1 in the ReStock.cfg file for the community patches the battery size is now correct. 

Yup, I submitted a pull request for this on Github but it seems like it hasn't been patched yet.  You'll also want to double the position and scale values for the z1001amp indicator light in the same cfg file to get it to show up correctly on the full size model. 

[Krzeszny]

Another bug: When ReStock is installed, Indicator Lights remove 99% of the Experiment Storage Unit's mesh. Basically, only 4 lines are visible. Don't use these mods together before an update.

[Moofrog]

20 hours ago, Krzeszny said:

Another bug: When ReStock is installed, Indicator Lights remove 99% of the Experiment Storage Unit's mesh. Basically, only 4 lines are visible. Don't use these mods together before an update.

I looked into the Patch Configs and its a typo in the IndicatorLights_ReStock.cfg file. On line 857 the "-1" part is missing from the model mesh path. I added the "-1" to the line and it fixed it  

model = ReStock/Assets/Science/restock-sciencebox-radial-1

[linuxgurugamer]

35 minutes ago, Moofrog said:

I looked into the Patch Configs and its a typo in the IndicatorLights_ReStock.cfg file. On line 857 the "-1" part is missing from the model mesh path. I added the "-1" to the line and it fixed it  

model = ReStock/Assets/Science/restock-sciencebox-radial-1

Pinging @Snark

[Tonka Crash]

I got around to updating my install to use Restock and had a look at the IL Restock patch. This should fix the relay antennas that change the position of feed horn in Restock.  The trick is to use one light that works in both variants. This is a compromise solution where the light is above the feed horn in one variant and below in the other.  One is usually better looking than the other to me, but it's at least functional and doesn't have weird floating meshes detached from the parts.

Edit to add: PR Submitted on github

Spoiler

// RA-2, RA-15 and RA-100 Relay Antennas have model variants that change
// the position of the feed horn.  The IL position is a compromise that
// is designed to be visible in both positions.

// RA-2 Relay Antenna
@PART[RelayAntenna5]:AFTER[ReStock]:NEEDS[IndicatorLights]
{
	!MODEL:HAS[#model[IndicatorLights/Meshes/nubbinLamp]],* { }
	MODEL
	{
		model = IndicatorLights/Meshes/nubbinLamp
		position = 0, .38, 0
		scale = 2.0, 2.0, 1
		rotation = -90, 0, 0
	}
}

// RA-15 Relay Antenna
@PART[RelayAntenna50]:AFTER[ReStock]:NEEDS[IndicatorLights]
{
	!MODEL:HAS[#model[IndicatorLights/Meshes/nubbinLamp]],* { }
	MODEL
	{
		model = IndicatorLights/Meshes/nubbinLamp
		position = 0, 1.125, 0
		scale = 2, 2, 2.5
		rotation = -90, 0, 0
	}
}

// RA-100 Relay Antenna
@PART[RelayAntenna100]:AFTER[ReStock]:NEEDS[IndicatorLights]
{
	!MODEL:HAS[#model[IndicatorLights/Meshes/nubbinLamp]],* { }
	MODEL
	{
		model = IndicatorLights/Meshes/nubbinLamp
		position = 0, 1.18, 0
		scale = 1.5, 1.5, 5
		rotation = -90, 0, 0
	}

}

 

Edited May 3, 2020 by Tonka Crash

[Snark]

Hello all,

Apologies for the very long delay, but I've finally released IndicatorLights Community Extensions v1.6.1.  This incorporates several fixes from the community (mainly around ReStock+) that have been languishing for a long time.

Thanks to the following folks for their contributions:

• @Poodmund, for addressing the science box
• @Tonka Crash for addressing antennas and docking ports
• @linuxgurugamer for pulling together the above, and testing it out

Enjoy!

[Iodyne]

Hi, using latest version (1.6.1). Is there nothing that prevents Indicator Lights (not Community Ext.) from still creating lights for stock parts even if Community Ext. and Restock are installed? Had extra (floating) lights on Lander Can Mk2 V2 which I fixed by commenting out the Model lines in IndicatorLights/Parts/Crewable/mk2can_v2.cfg. Or is it supposed to prevent it but my DL is messed up for some reason? I can provide more info if needed (screenshots, GameData, log).

Edited July 21, 2020 by Iodyne

[Snark]

9 hours ago, Iodyne said:

Hi, using latest version (1.6.1). Is there nothing that prevents Indicator Lights (not Community Ext.) from still creating lights for stock parts even if Community Ext. and Restock are installed? Had extra (floating) lights on Lander Can Mk2 V2 which I fixed by commenting out the Model lines in IndicatorLights/Parts/Crewable/mk2can_v2.cfg. Or is it supposed to prevent it but my DL is messed up for some reason? I can provide more info if needed (screenshots, GameData, log).

Sounds like there's a bug in handling ReStock.

What's supposed to happen is, if you're running IndicatorLights plus ReStock plus IndicatorLights Community Extensions... the latter has a patch that's supposed to make IL play nice with ReStock.  If it's not doing that, then looks like there's an issue with the ReStock patch in ILCE.

I don't actually author or test any of the content in ILCE (don't have the bandwidth, and don't use the mods it patches for)-- I'm basically just a curator.  So thanks for raising it, will need to wait for someone to step up with a fix they can submit.

Thank you for calling it out!

[DStaal]

Skimming the patch, it looks like in some cases the patch correctly removes the IndicatorLights patch first, and in some cases it just adds it's own lights.

[Tonka Crash]

I've been round and round with IL, ILCE, Missing History and Restock. The last several updates were stuff I did, but I didn't see issues with the Mk2 Lander Can V2.  I need to check to see if the current releases matches what I'm running.  @Iodyne could you upload a copy of the KSP.log and your ModuleManager.ConfigCache?  Maybe post a photo of what you are seeing, because I'm not seeing a problem with the Mk2 lander can. I used a vessel with it Sunday.

@DStaal The problem is the indicator lights (core) patches often explicitly load the model when a "mesh=" definition was originally used.  Restock does the same thing when it reskins these parts, so when you combine the two you sometimes have multiple models being defined.  The order of patches can also affect how things end up looking.  The last go around I had with the Restock patch I was looking at what ended up in the ConfigCache and adjusted the Restock ILCE patch to deal with what I was seeing. Sometimes this meant deleting "extra" model nodes. When @Snark added :FOR clauses to IL on his last update this changed the sequencing again, so I had to make adjustments and may have missed something. 

[DStaal]

Probably a better solution is to add :NEEDS[!Restock] to the core IL patches.  Then this whole ordering thing can be sidestepped - and the lights aren't in the correct places on the Restock models anyway.

[Tonka Crash]

6 minutes ago, DStaal said:

Probably a better solution is to add :NEEDS[!Restock] to the core IL patches.  Then this whole ordering thing can be sidestepped - and the lights aren't in the correct places on the Restock models anyway.

Even that isn't a great solution.  A good number of the IL patches work fine with ReStock.  If core IL shuts off if ReStock is present, then everything has to move to ILCE instead of just workarounds. It's doable, but it's a lot of patches that would need to be copied to ILCE.  When I was first fixing this locally only I did go through and set :NEEDS[!Restock] :NEEDS[Restock] all through IL to get it to work, but was updates were a pain.  I found it simpler to let IL behave with no knowledge of ReStock and just fix it later.  

[Iodyne]

7 hours ago, Snark said:

What's supposed to happen is, if you're running IndicatorLights plus ReStock plus IndicatorLights Community Extensions... the latter has a patch that's supposed to make IL play nice with ReStock.  If it's not doing that, then looks like there's an issue with the ReStock patch in ILCE.

...

Thank you for calling it out!

Figured. No problem!

 

3 hours ago, Tonka Crash said:

I've been round and round with IL, ILCE, Missing History and Restock. The last several updates were stuff I did, but I didn't see issues with the Mk2 Lander Can V2.  I need to check to see if the current releases matches what I'm running.  @Iodyne could you upload a copy of the KSP.log and your ModuleManager.ConfigCache?  Maybe post a photo of what you are seeing, because I'm not seeing a problem with the Mk2 lander can. I used a vessel with it Sunday.

Yeah sure; just have to comment it back in... Here's log/configcache/photos.

 

3 hours ago, Tonka Crash said:

When @Snark added :FOR clauses to IL on his last update this changed the sequencing again, so I had to make adjustments and may have missed something. 

Yeah doesn't FOR force other mods to think the targeted mod loaded and so should mainly only be used within the mod's own files. NEEDS is what is intended, right? Wonder if there's some of those floating around...

3 hours ago, DStaal said:

Probably a better solution is to add :NEEDS[!Restock] to the core IL patches.  Then this whole ordering thing can be sidestepped - and the lights aren't in the correct places on the Restock models anyway.

Yeah I was thinking this too, seeing as it fixed it easily for me by just commenting it out. Although perhaps there's a decent portion of ReStock models that don't need new light locations? I guess they could be selectively defined though...

3 hours ago, Tonka Crash said:

If core IL shuts off if ReStock is present, then everything has to move to ILCE instead of just workarounds. It's doable, but it's a lot of patches that would need to be copied to ILCE.

...or force ILCE to do models for every part. 

Edited July 21, 2020 by Iodyne

[Tonka Crash]

On 7/21/2020 at 1:52 PM, Iodyne said:

Yeah doesn't FOR force other mods to think the targeted mod loaded and so should mainly only be used within the mod's own files. NEEDS is what is intended, right? Wonder if there's some of those floating around...

FOR does announce a mod to MM, but the primary effect is to allow other patches to use :BEFORE and :AFTER in reference to the mod.  If you write a patch using :BEFORE/:AFTER directed at a mod that did NOT use :FOR the patch gets deleted and your left scratching your head about what went wrong.  If you are interested read the MM wik  As you can see from the wiki, it also has the side effect of changing when the patches with :FOR will run.  What happened when Snark added :FOR to IL it changed IL from executing before ReStock to after ReStock which affected which model nodes are actually present in each part by the time ILCE runs.

On 7/21/2020 at 1:52 PM, Iodyne said:

...or force ILCE to do models for every part. 

It's not just models, but IL controllers and all the other stuff that goes into implementing an IL patch for a part.  BTW, when I looked in my game I had an older version of IL patches in my main save, so wasn't seeing the same problems.  I looked at it in a clean test environment and your problems were apparent.  I just hadn't noticed them when I did my last set of updates since I'd concentrated on parts that I knew weren't working right like the antennas and Sentinel.

I have provided a PR to ILCE to fix the Mk2 Lander Can (floaters), Hitchhicker (no lights) and the Sentinel (old light positions). I'd swear I'd submitted a Sentinel fix before since it was already in my fork. There were probably some others that got fixed by cleaning out old meshes that were usually buried inside ReStock models and some leftover models that throw errors in the log with the published version (again I thought I had resolved all these).  I also changed lights on parts that use the common exterior hatch model in ReStock to be more consistent across parts.

Until @Snark gets around to releasing an update you can get my version of the file at my fork.  

[Iodyne]

Gotcha @Tonka Crash; makes enough sense.

3 hours ago, Tonka Crash said:

Until @Snark gets around to releasing an update you can get my version of the file at my fork.  

Thanks; although I noticed you forgot to rotate the lights on the top of the Mk2 Lander Can V2. Should be:

//Mk2 lander can (V2)
@PART[mk2LanderCabin_v2]:AFTER[ReStock]:NEEDS[IndicatorLights]
{
	!MODEL:HAS[#model[IndicatorLights/Meshes/squareLamp]],* { }
	MODEL
	{
		model = IndicatorLights/Meshes/squareLamp
	        scale = 1, 0.25, 0.5
		position = 0.0, 0.365, -1.378
		rotation = 0, 180, 0
	}
	MODEL
	{
		model = IndicatorLights/Meshes/squareLamp
		scale = 0.25, 1, 0.5
		position = -0.245, 0.745, 0
	        rotation = -90,0,0 //0, 180, 0
	}
	MODEL
	{
		model = IndicatorLights/Meshes/squareLamp
	        scale = 1, 0.25, 0.5
		position = 0.0, -0.065, -1.378
		rotation = 0, 180, 0
	}
	MODEL
	{
		model = IndicatorLights/Meshes/squareLamp
		scale = 0.25, 1, 0.5
		position = 0.245, 0.745, 0
	        rotation = -90,0,0 //0, 180, 0
	}
}

 

[Tonka Crash]

1 hour ago, Iodyne said:

Gotcha @Tonka Crash; makes enough sense.

Thanks; although I noticed you forgot to rotate the lights on the top of the Mk2 Lander Can V2. Should be:

Thanks, I've updated my fork on GitHub.

[Snark]

Hi gang,

I've released v1.6.2 of IndicatorLights Community Extensions.  Thanks to @Tonka Crash for supplying all the additions to this version, namely:

• which-way-is-up indicators for docking ports
• various ReStock fixes

(Screenshot provided by Tonka Crash)

Enjoy!

[SkiRich]

@Snark @Tonka Crash Thank you for the direction indicators.  Very handy.

Where it would be better served is if you can add them to the MKS construction docking ports which use directionalality extensively for welding two ports together.

While I havent seen this in action yet (just updated the mod) from the picture on the RegDocking port and the Sr Docking port above I'm guessing up or zero is the single green light while down or 180 is the three green lights.

On the MKS ports that would be opposite.  You may want to adjust that so there is consistency in all the ports.

Edited July 26, 2020 by SkiRich

[Tonka Crash]

36 minutes ago, SkiRich said:

@Snark @Tonka Crash Thank you for the direction indicators.  Very handy.

Where it would be better served is if you can add them to the MKS construction docking ports which use directionalality extensively for welding two ports together.

While I havent seen this in action yet (just updated the mod) from the picture on the RegDocking port and the Sr Docking port above I'm guessing up or zero is the single green light while down or 180 is the three green lights.

On the MKS ports that would be opposite.  You may want to adjust that so there is consistency in all the ports.

The patch should have everything you need to show you how to modify YOUR game how YOU want. I don't want direction indicators on Konstruction ports, so didn't include them. (Does MKS have a different set of ports).  As long as I dock at a cardinal angle, it's good enough. I also prefer that the light pattern on Konstruction ports look different at range from a standard port.

[SkiRich]

10 minutes ago, Tonka Crash said:

The patch should have everything you need to show you how to modify YOUR game how YOU want. I don't want direction indicators on Konstruction ports, so didn't include them. (Does MKS have a different set of ports).  As long as I dock at a cardinal angle, it's good enough. I also prefer that the light pattern on Konstruction ports look different at range from a standard port.

@Tonka Crash That was plan B. I figured it would be easier for you to do then for me to figure out the mechanics and make a MM patch, but if you dont plan on adding this then I'll customize my version.

While MKS uses the exact same textures as stock, their modules are named differently, so technically yeah they are different and at the moment do not have any directional lights.  Just plain lights.

You got the Jr port right, but the regular and Sr versions are upside down.  Those dark rectangles in the middle of the parts are windows and signify up.

Edited July 26, 2020 by SkiRich

[Tonka Crash]

28 minutes ago, SkiRich said:

@Tonka Crash That was plan B. I figured it would be easier for you to do then for me to figure out the mechanics and make a MM patch, but if you dont plan on adding this then I'll customize my version.

While MKS uses the exact same textures as stock, their modules are named differently, so technically yeah they are different and at the moment do not have any directional lights.  Just plain lights.

You got the Jr port right, but the regular and Sr versions are upside down.  Those dark rectangles in the middle of the parts are windows and signify up.

Have you tried it in game, yet? 

The junior is upside down in that picture, too, but you can't tell which is precisely why I created this patch. That was my first pass to show the concept and I fixed it after flying it in game. But I didn't bother creating a new photo and in over a  month since then you are the only one to complain about the photo.

[SkiRich]

1 hour ago, Tonka Crash said:

Have you tried it in game, yet? 

The junior is upside down in that picture, too, but you can't tell which is precisely why I created this patch. That was my first pass to show the concept and I fixed it after flying it in game. But I didn't bother creating a new photo and in over a  month since then you are the only one to complain about the photo.

@Tonka Crash Digging a bit deeper I found that the original mod, Indicator lights, includes indicator lights for the SNAP functions of the Konstruction ports, so making indicator lights for MKS ports would be redundant.

I did notice the orientation for the patch is correct once I did get in game, but also noticed it broke the lights for dockingport2.

I do have one issue, the dockingport2 (regular clampotron) has no indicator lights at all.  Just for testing I remmed out your patch to move the two bulbs but that wasnt it.

A bit more testing and surfing the log and I found Station Parts Expansion Redux changes the model so dockingport2 can have multiple variants.
I suspect the model is deeper and the indicator lights are just buried in the model and cant be seen.  In any case the patch you use targets a model in the cfg by its index and not the name (which isnt set), so there was a bit of conflict there.
I suggest putting in another MM qualifyer for dockingport2 :NEEDS[!Restock&!StationPartsExpansionRedux] to prevent the conflict or coordinate with Snark to add a name to the model module and then specifically target the modules.

I'm going to try and decrease the depth of the original indicator lights to see if I can make that compatible with Station Parts Expansion.

Just trying to be helpful, no complaints at all.

Edited July 26, 2020 by SkiRich
Fixed syntax for NEEDS statement

[Tonka Crash]

2 minutes ago, SkiRich said:

@Tonka Crash Digging a bit deeper I found that the original mod, Indicator lights, includes indicator lights for the SNAP functions of the Konstruction ports, so making indicator lights for MKS ports would be redundant.

I did notice the orientation for the patch is correct once I did get in game, but also noticed it broke the lights for dockingport2.

I do have one issue, the dockingport2 (regular clampotron) has no indicator lights at all.  Just for testing I remmed out your patch to move the two bulbs but that wasnt it.

A bit more testing and surfing the log and I found Station Parts Expansion Redux changes the model so dockingport2 can have multiple variants.
I suspect the model is deeper and the indicator lights are just buried in the model and cant be seen.  In any case the patch you use targets a model in the cfg by its index and not the name (which isnt set), so there was a bit of conflict there.
I suggest putting in another MM qualifyer for dockingport2 :NEEDS[!Restock,!StationPartsExpansionRedux] to prevent the conflict or coordinate with Snark to add a name to the model module and then specifically target the modules.

I'm going to try and decrease the depth of the original indicator lights to see if I can make that compatible with Station Parts Expansion.

Just trying to be helpful, no complaints at all.

 

Welcome to the mod conflict party.  The docking port direction patch assumes nothing but ReStock is messing around with the model definitions because stock and stock+ReStock are the only configurations I deal with. I don't have an all encompassing knowledge of every conceivable mod that might modify models in the stock parts. You have multiple mods changing the part definition that are mostly unaware of what the others are trying to do. 

The picture you show looks like the ReStock docking port, so I'd look at using it's patch as a model for how to address the SSPR docking port. A simpler approach would be to ask how important is the SSPR docking port to you?  Is it just simpler to remove the SSPR patch than messing with an IL patch for the docking port?

To be a bit rude I don't really care what you do. You have a configuration I don't run, so I'm not motivated to try to fix it, just like @Snark wasn't motivated to write a patch for ReStock.  ILCE is a community driven mod, so I'd suggest you figure out what works with the configuration you have that tries to avoid trashing 1) IL+stock game and 2) IL+stock+ReStock.  Sign up on GitHub and submit a PR to fix it.

SSPR has 20+ crewed parts that need lights, and I've never been motivated to add that, so I don't use SSPR. Just patching one part is kind of lame. If you've never tried writing an IL patch for a part it's tedious and very time consuming to get the light placement figured out and then there's testing the logic for what you want the part to do. It's easy to spend hours per part.  I figure some one that actually uses SSPR and wanted IL functionality will eventually take care of it. That person is not me.

I had the same issue with ReStock. I wasn't going to figure out the new locations for all the models ReStock replaced, so initially only used ReStock for things without IL like tanks and engines. Then I started using parts with minimal changes like reaction wheels and batteries. Someone else did a pass and addressed enough part that I started using most of ReStock/ReStock+ and started fixing parts that still had issues.  I'm still not satisfied with some of the parts, but I haven't been motivated to fix them yet. 

I originally wrote the docking port direction patch as a change to the core IL patch which was much simpler since it was in the core mod.  @Snark wanted it in ILCE instead, so the patch is the adjusting the minimum necessary based on which model nodes should contain the lights that are moving based on where IL puts them in the stock part definition.  A more robust fix would be to write it more like ReStock patches. First delete all IL model nodes and then add them back in.