totm sep 2021 [1.12] Stockalike Station Parts Redux (August 14, 2024)

[SlavaYaitsam]

23 minutes ago, Tyko said:

Cool ship. Not sure, but you may want to ask on the RemoteTech forum since this sounds like it's about how that mod works.

Thx:) Yep, think next step will be RT forum. I just wanted to be sure that I understood the possibilities of 'Pier' correctly.

[Shalfar]

On 10/1/2018 at 10:52 AM, Space_Coyote said:

I'm trying to solve a problem when it comes to the inlatable hab units when it comes to inlating them..

 

Now here's the  problem..

 

I have a spacecraft that is connected to the inflatable part and inside sai space craft are  in fact 4 Engineer Kerbals  (And I know that the max you need for any inflatable part is 3 (and that includes the Centrifuges..)

 

So I'm testing this  out on the laungch pad, the space craft connected to the inflatable part, and considering I have 4 enginner kerbals the part should inflate.. 

 

I click on inflate, and ... nothing happens, No inflation animation, nothing. I try to trasfer them into inflatable unit and they won't go..

 

(Also I am using ship Mani est to transfer crew..)

 

It would be kind o nice to explain how you inflate the habitation  unites/Centrifuges  in some hrt detailed method.)

otherwise I'm sticking to the Non Inflatable stuff. )

SO i someone can give me an idea on how to do this, that would be most appreciated..

 

Space_Coyote

I've got the same issue.  I have Ship Manifest and MKS installed.  I verified I have enough Material Kits but it still doesn't work.  I'm going to try without Ship Manifest and see if that fixes it. 

(edit)

Minor correction, I get a message saying I need 1800.00 material kits to expand the Eclair.  I have exactly 1800 material kits on the vessel but it doesn't work.  Also adding the update that Ship Manifest is not the issue.

(Found it)

My problem wound up being a rounding issue.  I had a container capable of carrying 2000 material kits but I only loaded it with 1800.  In the save file it showed to have 1799.9999523162842. I updated the value to something just slightly over 1800 and it works fine.

Sorry for the stream of consciousness post.

Edited October 8, 2018 by Shalfar
Update

[akasha2000]

This is not a serious problem

The flag of the Mobile Processing Lab MPL-LG-2 is Flag overlaps hatch　I want you to fix it if possible　

This is a machine translated text.  I am sorry if English was wrong.　I appreciate this wonderful mod

[Nertea]

On 10/7/2018 at 5:24 PM, Shalfar said:

I've got the same issue.  I have Ship Manifest and MKS installed.  I verified I have enough Material Kits but it still doesn't work.  I'm going to try without Ship Manifest and see if that fixes it. 

(edit)

Minor correction, I get a message saying I need 1800.00 material kits to expand the Eclair.  I have exactly 1800 material kits on the vessel but it doesn't work.  Also adding the update that Ship Manifest is not the issue.

(Found it)

My problem wound up being a rounding issue.  I had a container capable of carrying 2000 material kits but I only loaded it with 1800.  In the save file it showed to have 1799.9999523162842. I updated the value to something just slightly over 1800 and it works fine.

Sorry for the stream of consciousness post.

Well, I made an issue for it https://github.com/ChrisAdderley/StationPartsExpansionRedux/issues/161

7 hours ago, akasha2000 said:

This is not a serious problem

The flag of the Mobile Processing Lab MPL-LG-2 is Flag overlaps hatch　I want you to fix it if possible　

This is a machine translated text.  I am sorry if English was wrong.　I appreciate this wonderful mod

Noted: https://github.com/ChrisAdderley/StationPartsExpansionRedux/issues/162

 

[Cyrious]

Question: Are there any known mod conflicts that would cause the base frame legs to malfunction (specifically, not respond to settings set in the context menu)? Spawning the legs fresh from the VAB partially extended then hitting autolevel just makes them completely retract.

Edited October 11, 2018 by Cyrious

[Someone2018]

For the largest rotating habitat, the mercury, it seems to be about 11 meters in diameter. How do you launch that in any sane way? Even the proposed BFR is 9 meters in diameter, and you still have to fit inside.

[Nertea]

16 minutes ago, Someone2018 said:

For the largest rotating habitat, the mercury, it seems to be about 11 meters in diameter. How do you launch that in any sane way? Even the proposed BFR is 9 meters in diameter, and you still have to fit inside.

Well, it folds up to 10mish, so it fits in a 7.5m expanded fairing. Couldn't make it any smaller, sahry.

45 minutes ago, Cyrious said:

Question: Are there any known mod conflicts that would cause the base frame legs to malfunction (specifically, not respond to settings set in the context menu)? Spawning the legs fresh from the VAB partially extended then hitting autolevel just makes them completely retract.

That seems expected behaviour. The ground is flat, the algorithm will pick the lower deployment possible that makes the slope flat.

[Cyrious]

24 minutes ago, Nertea said:

That seems expected behaviour. The ground is flat, the algorithm will pick the lower deployment possible that makes the slope flat.

Yeah, I'm seeing that when I move the ship to the launchpad ramp; it'll bottom out the legs closest to the pad but keep the legs further away longer. Question now is why it doesnt accept leg extension commands either before or after hitting the autolevel while on a slope. I cant do something like put one base frame in the middle then use smaller frames on outriggers, then hit level to get all legs at the appropriate angle, then use the height adjustment slider to get all legs into contact with the surface.

Edited October 12, 2018 by Cyrious

[Nertea]

16 hours ago, Cyrious said:

Yeah, I'm seeing that when I move the ship to the launchpad ramp; it'll bottom out the legs closest to the pad but keep the legs further away longer. Question now is why it doesnt accept leg extension commands either before or after hitting the autolevel while on a slope. I cant do something like put one base frame in the middle then use smaller frames on outriggers, then hit level to get all legs at the appropriate angle, then use the height adjustment slider to get all legs into contact with the surface.

I don't know if I fully understand your problem. Some screenshots might help.

[Jesusthebird]

Hi there. Ive been looking through the source code..but Im not super great at reading code. I see in one of your patches that was made by @JadeOfMaar; these lines:

Spoiler

@PART:HAS[@MODULE[ModuleDeployableCentrifuge]]:NEEDS[MKS,!Kerbalism]
{
    DeployedMass = #$mass$
    @mass *= 0.4
    
    @MODULE[ModuleDeployableCentrifuge]
    {
        DeployResource = MaterialKits
        DeployResourceAmount = #$../DeployedMass$
        @DeployResourceAmount *= 600
        %DeployedMassModifier = #$../DeployedMass$
        @DeployedMassModifier *= 0.6
    }
}

Im looking to apply a patch in stock for the moment, that instead of requiring MaterialKits, it will require EC instead. I also would like it to use EC at a specified rate like reaction wheels for example. This is the modified version, However it doesnt seem to have any effect on the parts, advise? Or perhaps Im doing something not allowed by the module?

Spoiler

@PART:HAS[@MODULE[ModuleDeployableCentrifuge]]
{    
    @MODULE[ModuleDeployableCentrifuge]
    {
        DeployResource = ElectricCharge
        DeployResourceAmount = #$../DeployedMass$
        @DeployResourceAmount *= 600
        RotationResource = ElectricCharge
        RotationResourceRate = 3
    }
}

if (DeployResource != "")

if (Rotating)

Both strings above are located inside ModuleDeployableCentrifuge.cs, So I was thinking that might be OK..but alas...

Thanks!!

[Nertea]

1 minute ago, Jesusthebird said:

Hi there. Ive been looking through the source code..but Im not super great at reading code. I see in one of your patches that was made by @JadeOfMaar; these lines:

  Hide contents

@PART:HAS[@MODULE[ModuleDeployableCentrifuge]]:NEEDS[MKS,!Kerbalism]
{
    DeployedMass = #$mass$
    @mass *= 0.4
    
    @MODULE[ModuleDeployableCentrifuge]
    {
        DeployResource = MaterialKits
        DeployResourceAmount = #$../DeployedMass$
        @DeployResourceAmount *= 600
        %DeployedMassModifier = #$../DeployedMass$
        @DeployedMassModifier *= 0.6
    }
}

Im looking to apply a patch in stock for the moment, that instead of requiring MaterialKits, it will require EC instead. I also would like it to use EC at a specified rate like reaction wheels for example. This is the modified version, However it doesnt seem to have any effect on the parts, advise? Or perhaps Im doing something not allowed by the module?

  Hide contents

@PART:HAS[@MODULE[ModuleDeployableCentrifuge]]
{    
    @MODULE[ModuleDeployableCentrifuge]
    {
        DeployResource = ElectricCharge
        DeployResourceAmount = #$../DeployedMass$
        @DeployResourceAmount *= 600
        RotationResource = ElectricCharge
        RotationResourceRate = 3
    }
}

if (DeployResource != "")

if (Rotating)

Both strings above are located inside ModuleDeployableCentrifuge.cs, So I was thinking that might be OK..but alas...

Thanks!!

Yeah... you'd have to change the module code to do that. The code there does not have any way of understanding what you mean by adding the RotationResource and RotationResourceRate.

[Jesusthebird]

1 hour ago, Nertea said:

Yeah... you'd have to change the module code to do that. The code there does not have any way of understanding what you mean by adding the RotationResource and RotationResourceRate.

Would there be some sort of workaround avaliable? Perhaps "if deployed = true, use X EC/second" or something like that? It was a longshot adding RotationResource to the cfg. But I thought id try it before asking.

Edited October 17, 2018 by Jesusthebird

[Nertea]

2 minutes ago, Jesusthebird said:

Would there be some sort of workaround avaliable? Perhaps "if deployed = true, use X EC/second" or something like that? It was a longshot adding RotationResource to the cfg. But I thought id try it before asking.

Well I wrote the code, so I can change it to do this kind of thing, but it's a bit more complex than appeared initially so I am not really super excited about doing it when I have a lot of other projects on the go.

I suppose I can put it in the backlog.

[Jesusthebird]

27 minutes ago, Nertea said:

Well I wrote the code, so I can change it to do this kind of thing, but it's a bit more complex than appeared initially so I am not really super excited about doing it when I have a lot of other projects on the go.

I suppose I can put it in the backlog.

No worries, Im not looking to pry for it or anything like that. If it ends up happening I welcome it tho. I appreciate the work youre doing and Im enjoying learning all the same, Ive never looked at source code before today when I realized I needed too; only coding xp I have was with rational expressions in high school(long time ago), so it can be hard sometimes for me to figure out what can and cannot be possible with a cfg. Thank you for the replies and clarification, and good luck on your projects!!

[KSPrynk]

@Nertea, I figured I'd ask for this before a 1.5 update comes out:

Can you add an orientation indicator to the re-skinned Clamp-O-Tron Docking Port and the new Telescopic Clamp-O-Tron Docking Port?  As far as I can tell, they're pretty much the same on all sides and the front is symmetric, which provides no way of knowing which way is the 0 deg orientation.  A simple decal or a line/arrow at the 0 deg position on the side or front face would suffice I think.

On a related note, can you restore Indicator Light functionality on the Clamp-O-Tron model?  I'm not sure whether your new skin is covering it or bypassing it, but the LED on/off control shows up as a redundant (and non-functional) control next to your light on/off button.  The IndicatorLights Community Extensions Mod seems amenable to better (less band-aid) solutions for compatibility.

I'll post this as a new Enhancement request on GitHub.

Thanks for the huge effort you've into all the NFT mod packs.

[Nertea]

15 minutes ago, KSPrynk said:

Can you add an orientation indicator to the re-skinned Clamp-O-Tron Docking Port and the new Telescopic Clamp-O-Tron Docking Port?  As far as I can tell, they're pretty much the same on all sides and the front is symmetric, which provides no way of knowing which way is the 0 deg orientation.  A simple decal or a line/arrow at the 0 deg position on the side or front face would suffice I think.

Meh. How does this work with the stock port then, which is very directionally agnostic? It's doable it's just... more work and I don't want to have more work.

15 minutes ago, KSPrynk said:

 On a related note, can you restore Indicator Light functionality on the Clamp-O-Tron model?  I'm not sure whether your new skin is covering it or bypassing it, but the LED on/off control shows up as a redundant (and non-functional) control next to your light on/off button.  The IndicatorLights Community Extensions Mod seems amenable to better (less band-aid) solutions for compatibility.

 

It would be nice to have some idea of what is required for this. Perhaps you could point the dev to this thread so I can understand what the problem is?

[KSPrynk]

9 minutes ago, Nertea said:

Meh. How does this work with the stock port then, which is very directionally agnostic? It's doable it's just... more work and I don't want to have more work.

The front face of the stock docking ports have a horizontal "window" of sorts offset from the center.  It's non-functional, but it's asymmetric.  Having a known orientation helps when using an automated docking system, like MechJeb has.

9 minutes ago, Nertea said:

It would be nice to have some idea of what is required for this. Perhaps you could point the dev to this thread so I can understand what the problem is?

I'll post in the IndicatorLights and/or IndicatorLights Community Extensions Forums and see if I can get a bite....

Edited October 17, 2018 by KSPrynk

[Lord_Potato]

Could you add the USI_ModuleRecycleBin module to the USI patch for the next release? I've noticed that the materialkits from disassembling parts don't go into the this pack's containers be default; I added the module in myself.

[PolecatEZ]

1 hour ago, Lord_Potato said:

Could you add the USI_ModuleRecycleBin module to the USI patch for the next release? I've noticed that the materialkits from disassembling parts don't go into the this pack's containers be default; I added the module in myself.

I got a whole laundry list of MKS things I added to that patch.  Varying degree of colony controls for the command pods and the tether system.  Tomorrow I'm going to take a crack at giving the aquaculture pod some MKS function also...that one might be more complicated.  I'm trying to figure out a way to eliminate using the Tundra and Pioneer modules entirely and just use the parts from this pack, at least for the station parts.

[Snark]

13 hours ago, KSPrynk said:

On a related note, can you restore Indicator Light functionality on the Clamp-O-Tron model?  I'm not sure whether your new skin is covering it or bypassing it, but the LED on/off control shows up as a redundant (and non-functional) control next to your light on/off button.  The IndicatorLights Community Extensions Mod seems amenable to better (less band-aid) solutions for compatibility.

13 hours ago, Nertea said:

It would be nice to have some idea of what is required for this. Perhaps you could point the dev to this thread so I can understand what the problem is?

Hi guys,

I'm the IndicatorLights author-- thanks for looping me in.  I took a look at what's going on with the docking port re-skin (and why it's causing issues for IndicatorLights).  Technical details are in a spoiler, below, but the TL;DR is that what's causing the issue is the addition of ModuleColorChanger to the reskinned docking port.  What's happening here is that ModuleColorChanger is grabbing total control of all emissive textures on the part, and preventing IndicatorLights from doing its thing with the few little indicator meshes that it adds.

ModuleColorChanger is an incredibly convenient, useful tool for doing things like cabin-light animations, which is why everyone (including Squad) uses it a lot.    Unfortunately, Squad has implemented it in a sort of "ham-fisted" way, such that the "path of least resistance" (i.e. the most simple, straightforward, easiest way to use it, which of course is what everyone including Squad therefore does) results in behavior like what we're observing here.

There are a couple of ways to work around this problem.  One of them would involve some work by @Nertea to adjust the way the part is implemented; the other is a workaround that doesn't require any changes to this mod itself.  The verbose specifics are in the technical-details spoiler below, but they boil down to this:

• Option 1:  Nertea does some refactoring to the re-skin model, along with a minor update to the ModuleColorChanger config on the part.  The result is invisible to users of this mod, but makes the part friendlier to third-party tweakers of emissive behavior, such as IndicatorLights or KSP's stock thermal overlay.
• Option 2:  Just leave the part alone, and add an SSPX compatibility patch to the "IndicatorLights Community Extensions" mod to work around the problem.

(I've left unsaid an Option 3, "Nertea actually instruments this mod so that it has full IndicatorLights support right out of the box", because that's just my personal fantasy and it would actually be a pretty big work item for someone to add, given the large number of parts in this mod.  Just mentioning it here on the probably-tiny off chance that someone might be interested.)

Anyway, details in spoiler.  Basically, all that needs to be done is for Nertea to decide whether he feels like tweaking the docking port re-skin as described, or not.

• If "yes", that solves the problem right there.   It would also fix your part so that it works with the stock F11 thermal overlay.
• If "no" (which of course would be a perfectly reasonable answer, since the part's not "bugged" per se, and the refactor would take some of his time), then I'll follow up with @KSPrynk in the IndicatorLights Community Extensions thread about what would be involved to add a workaround for this.  (It's pretty straightforward.)

 

Short summary of what would be needed to address this matter in this mod:

Spoiler

First, refactor the model (.mu) file for the part, so that the specific piece that "lights up" is a separate mesh (with its own distinct name) from the rest of the part.  (If there are multiple pieces that light up, there can be multiple ones.)

Next, tweak the ModuleColorChanger config for the part, so that it specifies which pieces are supposed to light up.  Suppose that the light-up mesh is named "dockingLight".  You'd add the following to the ModuleColorChanger config:

includedRenderer = dockingLight

If there were multiple meshes that light up, you can include the directive once for each mesh, e.g.

includedRenderer = dockingLight1
includedRenderer = dockingLight2
// etc.

Doing this lets ModuleColorChanger know that "please only affect the emissive color of the named meshes, and don't tinker with anything else on the part."

That makes the part "friendlier" because now, any other features implemented elsewhere will be left unmolested.

Not only will doing this make your part more compatible with IndicatorLights, but it will also fix its behavior with the F11 thermal overlay (that's the one that, when toggled on, displays red / orange / yellow / white colors on the ship to show their temperature).  One of the side effects of using ModuleColorChanger without the "includedRenderer" syntax is that it stomps all over the thermal overlay.

In fact, Squad's own parts have this bug!  Try building a ship that has the Mk1 command pod on it, plus various other parts, and then after launching hit F11 to toggle the thermal overlay.  The whole ship lights up in thermal-overlay colors... except the command pod, which is just "black" (completely unlit).  It's a terrible bug, because when I'm using the thermal overlay, the part that I care the most about "will this blow up" is the command pod, and now I can't see the temperature!  This bug has been around for a few KSP versions, and they keep not fixing it. 

If you're interested, here's a manual patch I added to IndicatorLights that fixes the behavior for the Mk1 command pod:

https://github.com/KSPSnark/IndicatorLights/blob/master/files/Parts/obsolete/mk1pod.cfg

...though I use "excludedRenderer" instead of "includedRenderer" to do so, the principle is the same.

(Specifying "includedRenderer" will cause ModuleColorChanger to affect only the specified meshes.  Specifying "excludedRenderer" causes ModuleColorChanger to affect all meshes except the specified ones.  Don't specify both.)

 

So, that's the practical "how to", and if that's all you care about, you can stop reading there.    Here's a longer, much more verbose discussion of the overall care-and-feeding of ModuleColorChanger, which I include simply because it has implications for "standard practice" when modeling stuff, and since I know Nertea's a very prolific modeler, I suspect he may be interested.

Spoiler

So, here's the deal with ModuleColorChanger.  I'll go into the following:

1. What it's doing, in game terms
2. How that typically plays out when someone's designing a part that uses it
3. Why this causes problems
4. How it can be worked around

 

What it's doing, in game terms

What ModuleColorChanger does, by default if you don't tell it otherwise (more on that below), is to grab control of the emissive shader on every single mesh on the part.

Here's an example of what ModuleColorChanger config looks like-- in this case I've taken it from the docking-port reskin in SSPX, but it looks pretty much like this just about everywhere I've seen, including the Squad stock parts:

Github link

	MODULE
	{
		name = ModuleColorChanger
		shaderProperty = _EmissiveColor
		animRate = 0.8
		animState = false
		useRate = true
		toggleInEditor = true
		toggleInFlight = true
		toggleInFlight = true
		unfocusedRange = 5
		toggleName = #autoLOC_502011 //#autoLOC_502011 = Toggle Lights
		eventOnName = #autoLOC_502012 //#autoLOC_502012 = Lights On
		eventOffName = #autoLOC_502013 //#autoLOC_502013 = Lights Off
		toggleAction = True
		defaultActionGroup = Light
		redCurve
		{
			key = 0 0 0 3
			key = 1 1 0 0
		}
		greenCurve
		{
			key = 0 0 0 1
			key = 1 1 1 0
		}
		blueCurve
		{
			key = 0 0 0 0
			key = 1 0.7 1.5 0
		}
		alphaCurve
		{
			key = 0 1
		}
	}

So, it's instructive to note what it does say there, and also what it doesn't.

What it does say there is a bunch of parameters that control the nature of the animation:  i.e. the red / green / blue / alpha curves for how the emissive color changes over the course of the animation, and how fast it happens.

What it doesn't say, though, is absolutely critical:  note that nowhere does it say which component of the part it should apply to.  There's nothing there that indicates "this piece right here is the light bulb, please apply this animation effect to that".

Which seems odd.  If it's going to be tinkering with the light on some areas of the part, don't we need to tell it which areas to apply to?

Well, it turns out that we can (ModuleColorChanger supports doing that-- more on this below).  But we don't actually have to, and most folks don't.  What happens when you don't, is that it just assumes that it controls the emissive color for all of the part.  The reason that it ends up only lighting up the windows (or whatever) instead of the entire surface of the part, is that those lit-up areas are the only ones that have an emissive component (e.g. everywhere else is masked out, or something).

 

How that typically plays out when someone's designing a part that uses it

Let's say I'm designing a crew capsule, and I want it to have windows that light up when the player toggles cabin lights.  Let's say I choose to use ModuleColorChanger to accomplish this (which is the right choice-- that's a very nice, flexible, powerful module).  Here's the simplest thing to do, which is what most folks actually do:

1. Model the part.
2. Make it so that only the window has any emissivity to it.  This could be done by making the window be the only component that actually has any emissive shader on it at all.  Or, the whole part could use the same shader, but you could use an "emissive mask" so that everything except the window is masked out.  Thus, you've designed the part so that only the window is actually "glowable".
3. Add ModuleColorChanger with the window animation.  Don't bother trying to tell it which parts to light up, just let it apply to the whole part.
4. When the player toggles the cabin lights, ModuleColorChanger grabs control of the emissive color for the entire part, and tries to light up the whole thing.  But only the window actually lights up, because that's the only area of the part that's physically "glowable", due to the way the model is designed.

This is what the reskinned docking port in SSPX does.  This is also what most of the stock KSP crew modules do, these days (e.g. the Mk1 command pod, the Mk1-3 pod, the cupola... the list goes on).  There are a few KSP crew modules that are still using the old ModuleAnimateGeneric that is what they used to use for cabin lights-- you can see this on the various airplane cockpits, for example.

 

Why this causes problems

It causes a problem because designing a part that way carries the implicit assumption that "I, the part author, 'own' all the shaders associated with this part, so I can do whatever I want with them and it's nobody else's concern."  Which is true, mostly... but it's the exceptions to that which bite us. 

One example of breakage is the KSP thermal overlay.  This is the thing that puts a red / orange / yellow / white glow over the whole ship to show you the temperature of the various parts-- it toggles via F11 by default.  Turns out that the way it's implemented is that it tinkers with emissive color.  As a result, ModuleColorChanger stomps all over it in hobnailed boots:  the part doesn't receive the thermal highlighting.

^ ...can you spot which parts in the above picture are using ModuleColorChanger "indiscriminately" (i.e. in the default way)? 

This also causes problems for a mod such as IndicatorLights.  What IndicatorLights does is to use ModuleManager to add a few extra meshes to the part (the actual LED "lights" themselves), and then it has code that tweaks their emissive color at run time based on the state of the part.

When ModuleColorChanger is used in the default "indiscriminate" mode, then what happens is that it grabs control not only of the original meshes that the part author put in the model, but everything on the part, including the extra IndicatorLights meshes that we added via ModuleManager.

And so hilarity ensues.  IndicatorLights ends up powerless to affect the appearance of the lights, since ModuleColorChanger ham-fistedly tromps all over everything.  On the other hand, when you turn the cabin lights on and off, the  IndicatorLights meshes also turn on/off, in the same color, as if they were cabin lights.

 

How it can be worked around

My suggestion, to all part modelers (including Squad), is, don't use ModuleColorChanger in the default "indiscriminate" mode.  Make it a habit of keeping the light-up parts as separate meshes, where possible, and then use the includedRenderer directive on ModuleColorChanger so that it only affects those pieces.

Doing that makes the KSP thermal overlay work again, and also makes the part much friendlier to third-party mods that may want to decorate it.

It's not actually necessary, if you don't care that your part doesn't work with the F11 thermal overlay.  Third-party mods like IndicatorLights can work around it.  For example, suppose you left the part completely alone, in its current "indiscriminate" default ModuleColorChanger behavior.  In that case, it would be possible for a third party (e.g. the IndicatorLights Community Extensions mod) to write an SSPX compatibility patch, which would add the indicator meshes and also add excludedRenderer directives for them to prevent ModuleColorChanger from grabbing them.

Taking the latter approach means that the part author (e.g. Nertea, in this case) doesn't need to do anything.  On the other hand, it also means that every single mod that ever wants to work with the part is going to have to re-invent the same wheel, and also it means that the F11 thermal overlay will remain broken for the part.

Thoughts?

[Nertea]

Haha @Snark, I didn't need an essay of that length, just an indication of what IL actually does so I could address it! I do very much know how MCC works. It may be useful to others though. The actual solution is neither option 1 or option 2, perhaps an option 0 just pop in the included renderers and everything should be fine. Lowest amount of work.

23 minutes ago, Snark said:

•  If "yes", that solves the problem right there.   It would also fix your part so that it works with the stock F11 thermal overlay.

I mean IMO that's Squad's problem, not ours. It effectively means that the thermal overlay doesn't work for any section of a part for which MCC is applied, which is fairly unacceptable for a lot of things (goodbye engine throttle overheat glows for example). I don't think there's a point separating out all the glowing bits from every mesh, particularly since glows extend beyond just windows, so in some cases you're separating out chunk of contiguous meshes, leading to potential mesh seams and inconsistent smoothing, and even weirder looks than simply a missing thermal overlay.

10 hours ago, Lord_Potato said:

Could you add the USI_ModuleRecycleBin module to the USI patch for the next release? I've noticed that the materialkits from disassembling parts don't go into the this pack's containers be default; I added the module in myself.

I accept PRs for other mods' functions as I don't consider myself well versed enough in their systems to add them.

8 hours ago, PolecatEZ said:

I got a whole laundry list of MKS things I added to that patch.  Varying degree of colony controls for the command pods and the tether system.  Tomorrow I'm going to take a crack at giving the aquaculture pod some MKS function also...that one might be more complicated.  I'm trying to figure out a way to eliminate using the Tundra and Pioneer modules entirely and just use the parts from this pack, at least for the station parts.

That'd be great if you want to add it. I'd like to work towards a 1.5 release within the next few days, if you want something in that please let me know.

[Snark]

34 minutes ago, Nertea said:

Haha @Snark, I didn't need an essay of that length, just an indication of what IL actually does so I could address it! I do very much know how MCC works. It may be useful to others though.

Heh, yeah, sorry 'bout that.  I figured there was a good chance you already knew that stuff, but in any case it might be handy for other folks.

30 minutes ago, Nertea said:

The actual solution is neither option 1 or option 2, perhaps an option 0 just pop in the included renderers and everything should be fine. Lowest amount of work.

Yes, that sounds pretty reasonable.  If we just relegate the F11 overlay problem to Squad, then if you just put an "includedRenderer" directive for just the specific existing mesh (or meshes) where the lit-up portion of the model is, then that would work nicely-- it would stop the part from tinkering with any add-on meshes that get added by third-party mods such as IndicatorLights.

[Tyko]

14 hours ago, KSPrynk said:

14 hours ago, Nertea said:

Meh. How does this work with the stock port then, which is very directionally agnostic? It's doable it's just... more work and I don't want to have more work.

The front face of the stock docking ports have a horizontal "window" of sorts offset from the center.  It's non-functional, but it's asymmetric.  Having a known orientation helps when using an automated docking system, like MechJeb has.

@Nertea This was the problem we worked on that involved rotating where the shocks met. With that change it's easy to visually tell the top by looking at the point where the shocks meet. I don't think you've added that modified part to SSPRX yet, but you've already completed the work   

[PolecatEZ]

On 10/17/2018 at 11:30 AM, Nertea said:

That'd be great if you want to add it. I'd like to work towards a 1.5 release within the next few days, if you want something in that please let me know.

I'll work on it tonight, I got a little side-tracked trying to turn Kerbin-Gael into a binary planetary system.  It works, but it basically screws up Kerbin's reference points when you actually launch from there, so I think I'll need to dig into Kopernicus a little deeper for a fix.  Shelfing it for now.

Add-ons planned for the MKS patch:

- Tethering added to cradles and command pods.  Just one tether needs to be somewhere in the whole colony, so it doesn't need spammed on everything.

- Pioneering function added to all command pods. (Kolony Rewards check)

- Logistics control function added to larger command pods (Orbital Logistics).

- Empty Machinery/Material Kit resources added where appropriate

- Aquaculture will get advanced function for making organics/fertilizer.

- Switch between Hab and Living Space function on Kerbitat pods.

- I'm balancing based on ball-parking between mass and kerbal crew count.

The above will get Kolonies "mid-level functional".  If I can figure out how to tack on decal transforms, I can patch in variants for the parts that have appropriate external labeling and full functions for other pods - workshop, medical center, etc.  It might require building an entire part file for each though, which is beyond the scope of patching.

------

 

Proceeding with the conversion.

Slapped together 2 parts made from the 3.75 that should replicate the functions of the missing Assembler/Refinery combo.  Was going to make the Eclair into an inflatable workshop using Ranger Inflatable values, and discovered the Ranger Workshop was completely OP compared to anything else...so no production for him!  Mwahaha.

Everything else is done, I'm just doing a balance pass right now and then I'll upload the final version to the Git.  If Nertea wants to do some cool models (we discussed transform labels on existing ones also) instead of my hack jobs, that would be a bonus.

 

Current Patch notes for MKS Compatibility (in testing):

• Aquaculture Unit has Advanced Agroponics Unit functionality - Everything in it requires Farmers (Fish Farmers!)
  • 4 Configurable fish tanks allow it to produce food from Fertilizer and Dirt/Water or Substrate/Water
  • Or produce Organics from Dirt or Substrate
  • Or simply be nice to look at (adds to hab timer)
• Greenhouse Units have a Composter that increases Aquaculture's efficiency.  Requires Biologists.
• Smaller inflatable rings have composting toilets.  Everybody poops better in artificial gravity.
• The Asylum, Pilgrim, and Mercury have MedBay function - Eats colony supplies at a rapid rate to cure "Tourists", Medics very useful there.
• The Hostel and Mercury have long term colony functions - Eats ColonySupplies to push back hab timers over the whole colony.
• Airlocks now let your Engineers or Mechanics perform automatic maintenance if you assign them to it.
• Ground Tethers lock your base solidly in place on the ground.  You only need to click it once for the whole colony.
• Command Modules can now check for Kolony Rewards and participate in Logistics.  Quartermasters helpful.
• Modules contribute to Kolony rewards and efficiency percentages as appropriate.
• Two extra parts fill in the gaps for the production chain (Deluxe Refinery and Assembly Plant), you must use the smelters and refineries for other tasks.  These are fused together hack jobs and hopefully we can get some better models in the far future.
• Smaller inflatables got a workshop efficiency module.  Highly recommend bringing one because default converter values suck.

* You will need to use the MKS processors, drills, and Ranger packs (the side mounts) for some things - fuel, fertilizer, and dirt sifting.

* You should not have any need for Pioneer, Tundra, or Caribou basic parts.

* Please use Near Future Atomic/Nuclear/Solar/Heat stuff for power distribution needs.

From Previous version
* Inflatables and Deployables use MaterialKits and (unlike MKS parts) can be deployed internally by anyone.
* Station cores can distribute power and resources
* Several parts have training academy functionality

Edited October 19, 2018 by PolecatEZ
Update

[linecrafter]

I'm having issues installing this mod, the game wont load and this error shows up

Spoiler

KSP:1.3.1

Mods:

Spoiler

ASET props
AT_Utils
B9 part switch
Bettertimewarp
Burn Together!    
Collision FX (CollisionFX v4.0)
CommunityCategoryKit
Community Tech Tree (CommunityTechTree 1:3.2.1)
Contract Configurator (ContractConfigurator 1.23.3)
Contract Pack: Bases and Stations (ContractConfigurator-KerbinSpaceStation 2:3.7.0.1)
Contract Pack: Field Research (ContractConfigurator-FieldResearch 1.2.1)
Contract Pack: Tourism Plus (ContractConfigurator-Tourism 1.5.2)
Custom Barn Kit (CustomBarnKit 1.1.16.0)
Distant Object Enhancement    
Easy Vessel Switch (EVS)    
Engine Lighting (EngineLighting 1.5.1)
EVE
Extraplanetary Launchpads
Firespitter    BobPalmer
Flight Manager for Reusable Stages [FMRS]
FlexoDocking
Hangar Extender        
HyperEdit    
HeatControl
HideEmptyTechTreeNodes
Hullcamera VDS
Interstellar Fuel Switch Core (InterstellarFuelSwitch-Core 2.10.3)
KS3P    
Kerbal Attachment System    
Kerbal Aircraft Expansion Continued
Kerbal Inventory System
Kerbal Engineer Redux
KerbalHacks
Kerbal-Konstructs (KerbalKonstructs 1.2.0.1)
KerbalReusabilityExpansion
KerbalScienceFoundation
Kerbin Side GAP (KerbinSideGAP 2.3)
Kerbin-Side Complete continued (KerbinSide 3:1.4)
KerbinSide Core (KerbinSideCore 3:1.4)
Kopernicus
Kopernicus Planetary System Modifier    
LoadingScreenManager
Lonsesome Robots Station Parts
MechJeb 2    
ModularFlightIntegrator
Module Manager    
MouseAimFlight
NavBallDockingAlignmentIndicatorCE
Near Future IVA Props (NearFutureProps 1:0.3.0.1)
Near Future Solar
Mun Pocket Edition
PlanetShine
QuickBrake (QuickBrake v1.33)
QuickCursorHider (QuickCursorHider v1.06)
QuickGoTo (QuickGoTo v1.33)
QuickSearch (QuickSearch v3.20)
QuickStart (QuickStart v2.14)
RealPlume
RasterPropMonitor    
RecoveryController
Scatterer
Scifi Visual Enchancements
SETI-Contracts (SETI-Contracts 1.3.0.0)
SETI-Rebalance (SETI-BalanceMod 1.3.0.2)
SimpleConstruction (SimpleConstruction 1:3.4.6)
SmokeScreen - Extended FX Plugin    
SPC
TakeCommandContinued (TakeCommandContinued 1.4.11)
TextureReplacerReplaced
Textures Unlimited    
Throttle Controlled Avionics
Tundrea Exploration
Tundra Techonologies
Toolbar (Toolbar 1.7.16.5)
Transfer Window Planner    
Unmanned before Manned (SETI-UbM) (UnmannedBeforeManned 1.3.0.2)
Vessel Mover    
Waypoint Manager (WaypointManager 2.7.0)
WindowShine

LOG file