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

[Skalou]

1 hour ago, Snark said:

 

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

Thanks!

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]".

I tried, and it works too:
the part apply with the required mods are there,
with IndicatorLights removed from GameData, the patch seems to don't apply, at least the mk1 crew cabin part seems OK, with the MK1 hatch in the right place.
but i have no idea if one is worst than the other and will call the craken in 2018.

@SchwinnTropius, great but mine seems more robust to me, it won't try to move not intended model nodes if there is a fail somewhere.
(i wanted to use @MODEL:HAS[#model[IndicatorLights*]],0 but the ,0 doesn't work with the :HAS)

Edited December 10, 2017 by Skalou

[SchwinnTropius]

@Skalou the only time there would be some kind of fail is if these patches were installed without the base Indicator Lights mod (like you did for testing), when the patch would then try to move non-existent stuff. As long as these patches are installed with the base IL mod they'll work (no Kraken summoning ).

Edited December 10, 2017 by SchwinnTropius
clarity

[Skalou]

29 minutes ago, SchwinnTropius said:

@Skalou the only time there would be some kind of fail is if these patches were installed without the base Indicator Lights mod (like you did for testing), when the patch would then try to move non-existent stuff. As long as these patches are installed with the base IL mod they'll work (no Kraken summoning ).

Who knows, it can also be possible that an other mod adds an other model node before IndicatorLights and will mess your patch, etc...
mine is not perfect too, but it will less likely mess things.

[SchwinnTropius]

@Skalou well, I'll say it works for now, and I can work with anyone that wants to make patches that will influence mine. I do want your hatch mod to continue looking awesome.

[Critter79606]

2 hours ago, SchwinnTropius said:

 

  Reveal hidden contents

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)?

@SchwinnTropius I tried the above without the parts overhaul, and had no errors.  I went and installed the porkjet project and had no error, but had indicator light on the new capsule.

[SchwinnTropius]

1 hour ago, Critter79606 said:

@SchwinnTropius I tried the above without the parts overhaul, and had no errors.  I went and installed the porkjet project and had no error, but had indicator light on the new capsule.

So it works then?

[Snark]

Hi all,

I've released v1.3.1 of IndicatorLights Community Extensions.  This includes some tweaks to fix a compatibility issue with ModuleManager 3.0 and above.

Thanks to @Critter79606, @Murdabenne, @Skalou, and @SchwinnTropius for spotting the bug, providing fixes, and testing!

[Critter79606]

11 minutes ago, SchwinnTropius said:

So it works then?

@SchwinnTropius I use Ven's rework, so I removed it on my test build, installed the pork project and I couldn't get the light to show up on either the change I made, or the one you made.

https://drive.google.com/file/d/11zfS20LwRHHwdduL9w9SbTUR8YqITyMu/view?usp=sharing

The top is the pork part, the bottom is the original part.  

It works fine with Ven's rework.

 

[SchwinnTropius]

We may have to get @Ven here for some input on this, since your issue involves his mod.

[Critter79606]

3 minutes ago, SchwinnTropius said:

We may have to get @Ven here for some input on this, since your issue involves his mod.

 

@SchwinnTropius I'm not having an issue with Ven's mod.  I said above that the light shows up fine on his capsule. 

The original issue was that who ever wrote

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

wasn't following the Module Manager instructions, and put 2 :AFTER entries in the first line of a patch.  I didn't test that PartOverhauls worked after I suggested a correction as I don't use it, just that the line didn't throw anymore errors.

The error was keeping my Module Manager from creating a cache, and it tried to rebuild every time I loaded KSP.

The only reason the mk1podNew was picked up in the first place was because Kerbal Stats creates a seat task with that name, so it is checking the :NEEDS and found the :AFTER error.

After removing the :AFTER error, it correctly skips this line, as it is not part of PartOverhauls.

[SchwinnTropius]

@Critter79606 My apologies for misunderstanding initially. I'm glad you found a solution. I need to study on the new syntax for future patches.

[Snark]

Continuing a discussion from over in the main IndicatorLights thread:

10 hours ago, Tyko said:

Hi @Snark! I was hoping to get your help please...

I've come across a conflict between Indicator Lights and Ven's Stock Revamp being maintained by @Kerbas_ad_astra on 1.4.2.

When both mods are installed the bumpers on Docking Port and Docking Port Jr are broken. There's an extra copy of the bumper that's stuck in the "extended" position. Clicking the extend/retract bumper option causes a second copy of the bumper to animate as it's supposed to, but that extra bumper will still be extended.

This is new in 1.4.2 and didn't occur with 1.3.1

I don't use Ven's Stock Revamp myself and never have, so I don't directly have any idea what that mod has done that would break IndicatorLights.  However, the text I've highlighted above is pretty much the smoking gun, and I can infer what's going on:

I'm guessing that Ven has recently rejiggered the docking ports so they're animated and can extend/retract.

That's a problem.

An animated part is a completely different beast from a static part, and needs to be handled completely differently.  The Ven's Stock Revamp patch here in IndicatorLights Community Extensions, as produced by @Kerbas_ad_astra, was produced against an older version of Ven's Stock Revamp from quite some time ago.  If Ven has recently rejiggered his docking ports, so that they're now using a different model than before, it means that the patch needs to be updated, too.  If you're running an out-of-date version of the patch against a current version of Ven's, it's not going to work and it'll be fugly.

Bear in mind that there are some pretty hard limitations about how IndicatorLights can work with animated parts.  Specifically, unless the part-mod author deliberately integrates IndicatorLights meshes in the model itself, it's impossible to put a mobile mesh on with an IL patch that will move with the model.  Therefore, for example, if Ven has animated extendable docking ports and someone wants to patch them to add indicator lights, they'll need to make sure that those indicator lights are placed on a "stationary" part of the model that never animates.

So, to summarize:

• It appears that Ven has recently changed the model of the docking ports.
• Therefore the Ven's patch here in IndicatorLights Community Extensions will need updating in order to work correctly.
• So this is an ILCE problem, not an IL problem.

 

10 hours ago, Tyko said:

it's occurring even if the Community Extensions aren't installed

Just to be clear, this isn't a thing.  If you're running both Ven's Stock Revamp and IndicatorLights, then you must install IndicatorLights Community Extensions or various things will be munged.  (This is how it has always been.)  That's because the two mods will be arm-wrestling over the same parts and trying to dink around with their models in different ways, and hilarity will ensue.  That's why the patch is a thing. 

 

So, just to be clear, here:

• You can't now (and never have been able to) run Ven's and IL without having the Community Extensions installed.
• You can't now (and never have been able to) run Ven's and IL with the Community Extensions, if the Community Extensions are out of date.
• The Community Extensions are now out of date (because of a recent change to Ven's).
• Therefore you're screwed.
• Q.E.D.

There are two solutions available to you.

The simple and easy thing, which you can do for yourself, is to just go in to IndicatorLights and delete the .cfg files for the docking ports, i.e. "un-mod" them so that IndicatorLights simply doesn't instrument the docking ports.  Unfortunately, this "solution" isn't ideal, because of course this means you don't get any indicators on the ports... but at least the ports themselves won't be borked and you can use them.

The other solution is for some public-spirited individual to go in and update the IndicatorLights Community Extensions patch for Ven's Stock Revamp so that it works with the new-and-improved docking ports from Ven's.  Then, having done that and verified that the fix works, send the fix to me so that I can publish an updated version of ILCE with the fix in it.  Then, everybody wins! 

(Yet a third solution, which I hesitate to mention because of reasons given below, would be if Ven Himself wanted to add IL compatibility to his mod, so that he'd be maintaining it and would make needed updates if he changes stuff around.  But that would be a very large chunk of work for him, and I don't know that he'd even have any real reason to do that because he may not even be an IndicatorLights user.  Therefore, asking him to do that feels like it would be an unreasonably large thing to ask, which is why I'm not proposing it here.  Please don't go and pester him about it, I'm sure he has enough on his plate as it is.)

So, that's the lay of the land.

[Beetlecat]

Note to self: Try adding crew indicator lights to the Kerbonov and MK-1 Open Cockpit this weekend as practice. [posting here as added pressure to avoid the shame of not doing it... ]

[Tyko]

5 minutes ago, Snark said:

Continuing a discussion from over in the main IndicatorLights thread:

I don't use Ven's Stock Revamp myself and never have, so I don't directly have any idea what that mod has done that would break IndicatorLights.  However, the text I've highlighted above is pretty much the smoking gun, and I can infer what's going on:

I'm guessing that Ven has recently rejiggered the docking ports so they're animated and can extend/retract.

That's a problem.

An animated part is a completely different beast from a static part, and needs to be handled completely differently.  The Ven's Stock Revamp patch here in IndicatorLights Community Extensions, as produced by @Kerbas_ad_astra, was produced against an older version of Ven's Stock Revamp from quite some time ago.  If Ven has recently rejiggered his docking ports, so that they're now using a different model than before, it means that the patch needs to be updated, too.  If you're running an out-of-date version of the patch against a current version of Ven's, it's not going to work and it'll be fugly.

Bear in mind that there are some pretty hard limitations about how IndicatorLights can work with animated parts.  Specifically, unless the part-mod author deliberately integrates IndicatorLights meshes in the model itself, it's impossible to put a mobile mesh on with an IL patch that will move with the model.  Therefore, for example, if Ven has animated extendable docking ports and someone wants to patch them to add indicator lights, they'll need to make sure that those indicator lights are placed on a "stationary" part of the model that never animates.

So, to summarize:

• It appears that Ven has recently changed the model of the docking ports.
• Therefore the Ven's patch here in IndicatorLights Community Extensions will need updating in order to work correctly.
• So this is an ILCE problem, not an IL problem.

 

Just to be clear, this isn't a thing.  If you're running both Ven's Stock Revamp and IndicatorLights, then you must install IndicatorLights Community Extensions or various things will be munged.  (This is how it has always been.)  That's because the two mods will be arm-wrestling over the same parts and trying to dink around with their models in different ways, and hilarity will ensue.  That's why the patch is a thing. 

 

So, just to be clear, here:

• You can't now (and never have been able to) run Ven's and IL without having the Community Extensions installed.
• You can't now (and never have been able to) run Ven's and IL with the Community Extensions, if the Community Extensions are out of date.
• The Community Extensions are now out of date (because of a recent change to Ven's).
• Therefore you're screwed.
• Q.E.D.

There are two solutions available to you.

The simple and easy thing, which you can do for yourself, is to just go in to IndicatorLights and delete the .cfg files for the docking ports, i.e. "un-mod" them so that IndicatorLights simply doesn't instrument the docking ports.  Unfortunately, this "solution" isn't ideal, because of course this means you don't get any indicators on the ports... but at least the ports themselves won't be borked and you can use them.

The other solution is for some public-spirited individual to go in and update the IndicatorLights Community Extensions patch for Ven's Stock Revamp so that it works with the new-and-improved docking ports from Ven's.  Then, having done that and verified that the fix works, send the fix to me so that I can publish an updated version of ILCE with the fix in it.  Then, everybody wins! 

(Yet a third solution, which I hesitate to mention because of reasons given below, would be if Ven Himself wanted to add IL compatibility to his mod, so that he'd be maintaining it and would make needed updates if he changes stuff around.  But that would be a very large chunk of work for him, and I don't know that he'd even have any real reason to do that because he may not even be an IndicatorLights user.  Therefore, asking him to do that feels like it would be an unreasonably large thing to ask, which is why I'm not proposing it here.  Please don't go and pester him about it, I'm sure he has enough on his plate as it is.)

So, that's the lay of the land.

VSR hasn't been updated since February of 2017. The things that changed are IL, ILCE and KSP. That's why I reached out to this community first.

I appreciate you taking the time to respond. Since a change to VSR isnt' the problem and you're saying it's not even possible that it's IL's fault I guess it's what it is...

[Snark]

7 minutes ago, Tyko said:

VSR hasn't been updated since February of 2017. The things that changed are IL, ILCE and KSP. That's why I reached out to this community first.

I appreciate you taking the time to respond. Since a change to VSR isnt' the problem and you're saying it's not even possible that it's IL's fault I guess it's what it is...

Ah.  Well, if VSR hasn't updated, that makes it a more interesting problem. 

No idea what it might be.  Maybe some subtle behavior about how KSP works with models has changed, or maybe a newer version of ModuleManager performs its operations in a different order than before, or something.

Regardless of what the problem is, though, I'm 99% sure that the correct place to address it is in IndicatorLights Community Extensions.  The assumption is that with the right bit of MM-fu in ILCE, then the forces of the universe can be brought into harmony again and it'll all work as desired.

So, what this means is that for this to get fixed, somebody is going to have to spend time futzing with it, doing various trial-and-error surgery on the part of ILCE config that deals with Ven's docking ports, to figure out how to address the problem.

Unfortunately, that person would not be me, since I don't have the bandwidth for it-- I've got my hands full with other stuff, and don't happen to run Ven's myself so I'm not well placed to experience the issue.  So, basically this won't get fixed  until some public-spirited, generous person is willing to step up and run this problem to ground.

I'm sorry about that-- would love to be able to give you a fix myself.  But I simply don't have time to do 3rd party compatibility patches for IL-- it's why I spun up ILCE as a separate mod (with the "C" being the operative term!), with me simply as curator rather than producer.

[Tyko]

2 minutes ago, Snark said:

Ah.  Well, if VSR hasn't updated, that makes it a more interesting problem. 

No idea what it might be.  Maybe some subtle behavior about how KSP works with models has changed, or maybe a newer version of ModuleManager performs its operations in a different order than before, or something.

Regardless of what the problem is, though, I'm 99% sure that the correct place to address it is in IndicatorLights Community Extensions.  The assumption is that with the right bit of MM-fu in ILCE, then the forces of the universe can be brought into harmony again and it'll all work as desired.

So, what this means is that for this to get fixed, somebody is going to have to spend time futzing with it, doing various trial-and-error surgery on the part of ILCE config that deals with Ven's docking ports, to figure out how to address the problem.

Unfortunately, that person would not be me, since I don't have the bandwidth for it-- I've got my hands full with other stuff, and don't happen to run Ven's myself so I'm not well placed to experience the issue.  So, basically this won't get fixed  until some public-spirited, generous person is willing to step up and run this problem to ground.

I'm sorry about that-- would love to be able to give you a fix myself.  But I simply don't have time to do 3rd party compatibility patches for IL-- it's why I spun up ILCE as a separate mod (with the "C" being the operative term!), with me simply as curator rather than producer.

understood..I spent 3 hours last night just figuring out which of my 80 mods was causing the issue...I'll just delete the configs for the ports for now.

[Snark]

2 minutes ago, Tyko said:

understood..I spent 3 hours last night just figuring out which of my 80 mods was causing the issue...I'll just delete the configs for the ports for now.

By the way, in case it wasn't clear:  thank you for taking the time to run it down and post it here.  You've just saved someone else from having the same problem, and now we're all better informed so we know that there's an issue, and (more importantly) where the issue is.  Even without an actual fix yet, that's a major part of the battle right there.

So, thank you for your public service. 

[Beetlecat]

2 minutes ago, Tyko said:

understood..I spent 3 hours last night just figuring out which of my 80 mods was causing the issue...I'll just delete the configs for the ports for now.

I've been a fan of the Ven's parts for a while, but haven't yet tried them in 1.4* -- have you tried them by themselves? Do the bumper animations work fine? I think of things like landing gear and other animated mods that have been broken by the major unity updates lately.

I also don't remember the lights being *on* the bumpers, just surrounding the ring as usual. ILCE worked great to swap out (cover) those lights when I've used both in the 1.3* era.

[Tyko]

1 hour ago, Beetlecat said:

I've been a fan of the Ven's parts for a while, but haven't yet tried them in 1.4* -- have you tried them by themselves? Do the bumper animations work fine? I think of things like landing gear and other animated mods that have been broken by the major unity updates lately.

I also don't remember the lights being *on* the bumpers, just surrounding the ring as usual. ILCE worked great to swap out (cover) those lights when I've used both in the 1.3* era.

the bumpers work fine in 1.4.2 as long as IL isn't installed. Once I install IL I get that second bumper locked permanently in the extended position.

Try it yourself. It would be great to know it's not unique to something in my setup.

1. install 1.4.2 ( I also have MH installed, I haven't tested it without MH)
2. Install MM
3. Install latest production build of VSR = 1.9.6: https://github.com/VenVen/Stock-Revamp/releases
4. Test bumpers
5. Install Indicator Lights + ILCE
6. Test bumpers

 

[JH4C]

Having just installed mk1CabinHatch, I realised the IndicatorLights were in a bad spot and started to move them. Knowing that I could edit the base file but that it's bad form in case of future updates, I started looking for MM patch guidance... and found this instead, which works just as well but saves me doing the tinkering. Yay!

One question: I don't suppose there's any way to have the IndicatorLights in one set of positions when the hatch is visible, and a different (their original?) positions when the hatch is hidden, without simply making it so the cabin with hatch is a separate part?

ETA: Okay, two questions: Has anyone looked at extending this to include SXT?

Edited May 9, 2018 by JH4C
belated thought, didn't want to double-post

[Snark]

22 hours ago, JH4C said:

One question: I don't suppose there's any way to have the IndicatorLights in one set of positions when the hatch is visible, and a different (their original?) positions when the hatch is hidden

Correct, there's no way to do that (at least, not without writing your own custom mod, with C# code, to do that).  Technobabble explanation of why it's not possible in a spoiler.

Spoiler

The indicator meshes are placed by config, which happens once when the game gets loaded to the main menu.  Those meshes' positions aren't dynamic; they're nailed in place, they can't be moved.

They don't have any way of knowing what's happening in the guts of some other mod.  In the case of Mk1CabinHatch, that mod allows turning the hatch on-and-off, in-game, because the model itself has that ability baked into it-- the author of the mod gave it a "show hatch / hide hatch" animation that's part of the model itself, and then provided the config hook so that the player can trigger that animation in-game.

There's no special animation code baked into IndicatorLights; they're just ordinary meshes handled the way that all static meshes are handled in-game.  So there's no way for them to have any awareness of what Mk1CabinHatch is doing.

This limitation is why you'll never find an IndicatorLights-added indicator on a moving portion of a KSP part.  For example, look at the HG-5 antenna, or the HG-55 for that matter:  I would have loved to put the flashing "data transmission" indicator on the receiver horn of those antennas; it would look cool there.  But I couldn't do it, because that's a mobile part of the model, and there was no way to get the indicator mesh to move along with the antenna when the antenna folds and unfolds.  Therefore I had to put the indicators on the stationary "base" part of the antenna.  It doesn't look as cool there, but it's the best I could do.

Note that this limitation doesn't apply if the part's model itself has IndicatorLights support baked in.  For example, if you look at the JX2Antenna mod:  the big JX2 antenna does have indicator lights on a mobile animated component.  But it can do that because it's a custom part, and @steedcrugeon provided an indicator-light mesh to use that's part of the actual part model itself, and not something that gets spackled on after the fact using a ModuleManager patch.

So, in the current compatibility mode-- in which Mk1CabinHatch is a completely separate mod from IndicatorLights, and doesn't have any IL support actually built in, and the indicators get added on with a ModuleManager patch-- then no, there's no way to make that happen.

If the Mk1CabinHatch model had been designed with IndicatorLights support in mind, then something like what you're asking for would have likely been doable.  But it wasn't, so it isn't.

 

22 hours ago, JH4C said:

Has anyone looked at extending this to include SXT?

Was scratching my head trying to figure out what the dickens SXT might be.  Some googling turned up this, I'm guessing it's what you're referring to?  (Protip:  when mentioning something, it's usually good to provide an actual link rather than just assuming that folks know what you're talking about.) 

Anyway, I assume that the answer to your question is that "no, nobody has done that", because if they had, then it would be here already.  From glancing at it, sounds like the sort of mod that would be a good "fit" for a compatibility patch.  So, what we'd need would be some fine, upstanding, community-spirited individual (hint), who happens to be interested in both SXT and IL and would like to see them work together (hint hint), who would be willing to take the time to  put together a patch (hint hint hint) and then pass it along to me so I could include it here, and then everyone wins!    (Hint.)

(I'm always happy to offer advice to anyone who's trying to produce an IndicatorLights compatibility patch-- feel free to drop me a line if you have questions.)

 

[Beetlecat]

50 minutes ago, Snark said:

(I'm always happy to offer advice to anyone who's trying to produce an IndicatorLights compatibility patch-- feel free to drop me a line if you have questions.)

It's been a back-burner thing for me for weeks (months?) to take a stab at this for the KN-2 cockpit(s), Stock Extension would be great as well. Just adding the simple bar, dot, or square indicators for crew would be plenty to attempt at the moment. I'll assume to need blender and/or unity to help with placement?

[DStaal]

30 minutes ago, Beetlecat said:

It's been a back-burner thing for me for weeks (months?) to take a stab at this for the KN-2 cockpit(s), Stock Extension would be great as well. Just adding the simple bar, dot, or square indicators for crew would be plenty to attempt at the moment. I'll assume to need blender and/or unity to help with placement?

Nope.  For just the simple indicators, all you need is KSP and a text editor - they can be configured in a config file.

Oh, and patience.  Because you'll have to reload things. 

[Beetlecat]

3 minutes ago, DStaal said:

Nope.  For just the simple indicators, all you need is KSP and a text editor - they can be configured in a config file.

Oh, and patience.  Because you'll have to reload things. 

Heh. True enough -- though some idea of *what* numbers to put in the coordinates would be nice.

As to the second point, Game Data Switcher has been a godsend. I just swap out to a minimum install for a *much* shorter startup time between loads.

 

[JH4C]

@Snark: yes, that's exactly right. Sorry, still learning the forum codes & things for linking pages.

@Beetlecat: I was just thinking that, for a testing environment, only having the one (or in this case two) mod(s) necessary would make it much faster; shouldn't be surprised there's a program to automate that!

As for what means what, I know that the second of the three co-ordinates are positive going from the centre to the front/top, and negative going from the centre to the rear (worked that out from my own Mk1Cabin patch and the one included in this) so that's Y... I'm gonna assume the first digit is X (left/right) and the third is Z (in/out).

I'm not terribly busy right now, so I'll see what I can come up with for SXT over the next few days - any kind of cheat sheet to explain/confirm what means what, and guidelines for positioning that may exist, gratefully received.