[1.12.x] MissingHistory v1.9.3: Handy parts to complement Making History.

[Snark]

56 minutes ago, Burning Kan said:

now please say , iam not the only one who has NO

emmensiv.glowing nozzles from porkjets overhault engines.but i can see the texture in the folder

i tryed 100th times but still not working !

Yep.  Based on my (admittedly sketchy and inexpert) observations, my impression is that Porkjet simply didn't get around to implementing the glowing-nozzles part of those engines.

Technobabble details in spoiler section below, for the curious, but it boils down to this:

• Yes, that's right, there's no nozzle glow for these parts.
• No, it's not fixable.  (At least not by me.)

Spoiler

KSP engines implement the emissive glowing nozzles via a PartModule called FXModuleAnimateThrottle.  If we look at the Swivel, for example, we find that its stock config includes this:

MODULE
{
    name = FXModuleAnimateThrottle
    animationName = HeatEmissiveAnimation
    responseSpeed = 0.001
    dependOnEngineState = True
    dependOnThrottle = True
}

^ that.  That right there is why the Swivel gets that nice orange glow on its nozzle in the stock game.

Note that for this to work, two things have to be there:

• First, and most importantly (because this is where all the hard work and artistic talent come in):  the model itself needs to have a "glow" animation and texture built into it.
• Second (and this is the easy part):  the part's config needs an FXModuleAnimateThrottle set up, to point at the relevant animation in the model.

The stock Swivel works because its model has all the necessary stuff hooked, up, and it also has the config shown above.

Now, with that in mind, let's take a look at Porkjet's reskinned Swivel, shall we?

The original config that comes from Porkjet, interestingly, contains a section that looks like this:

// MODULE
// {
//     name = FXModuleAnimateThrottle
//     animationName = HeatEmissiveAnimation
//     responseSpeed = 0.001
//     dependOnEngineState = True
//     dependOnThrottle = True
// }

Those // characters mean that the section is commented out.  In other words:  when he was working on these parts, Porkjet took the trouble to copy the FXModuleAnimateThrottle section from the stock Swivel... and then deliberately removed it from his config.

Which is an odd thing to do... especially since, if I look at the texture files he included, he actually has a JebsJunkyard_Emissive.dds texture file sitting in there, which tells me that he meant to hook this up.

I also note that the way that I set up the reskinned Swivel in MissingHistory... I've kept the original FXModuleAnimateThrottle config from the stock Swivel.  Which means, this ought to work, if the model has the animation built into it.  But it's clearly not working.

So, what's going on here?

I'm not Porkjet, of course, so I have no way of knowing exactly what he was thinking or what was going on at the time he made this stuff.  But putting all the observable pieces together (including the rather abrupt way that these parts were released in the first place), here's my theory.  To be clear, this is only a theory, I'm just guessing since I have no inside information on the subject:

I think that he clearly meant to put an emissive nozzle glow on these parts, and that he had actually started the work to do so (that's why there's an emissive texture file sitting there in the folder).  However, I think that some unexpected, sudden circumstances intervened that required him to stop what he was doing and just release what he had.  And I also think that when he had to do that, he hadn't yet gotten around to hooking up the emissive texture with an animation in the model.  So he just quickly commented out the FXModuleAnimateThrottle and shipped what he had before heading out the door.

What this means, if I'm correct, is that there's basically no way of fixing this without actually going into the part model itself and doing the work that Porkjet didn't have time to do, and hooking up an animation (named HeatEmissiveAnimation) to the emissive texture that he produced.

I'm guessing that that's technically possible... but it would require modeling skills that I don't have at the moment, and would take more time than I currently have for me to go and acquire them.

Therefore:  until/unless someone (who does have the modeling skills) wants to volunteer to come in and hook all this up... I'm not going to be able to fix this myself.

 

 

24 minutes ago, mostlydave said:

Would it be possible to add a matching color variant to the engines, The white engine fairings in the middle of the orange rocket looks out of place.

Yeah, I've noticed that myself.  You're right, it's kind of jarring.

I'm guessing it's technically possible, but would be somewhat low on my priority list, for a couple of reasons.

First, I'd love to get the boat-tail variant thing working (i.e. hook up the "boat tail" variant of these engines that Porkjet provided).  If I'm going to spend "tinkering time" trying to get variants to work for the engines, I'd probably want to get that working first.

Second, even if it does work and all the necessary work can be done for it... that still doesn't solve the problem of all the other engines in the game (including the new Making History variant-mesh engines), as well as all the engine plates, which all have single-color-only shrouds.  In other words, solving this problem for the Porkjet 1.25m engines would only be solving about 20% of the problem in the game.  And making this work for the variant-mesh engines and engine plates would be... really hard (because ModulePartVariants only allows modifying one aspect of a thing, not two; it only has one degree of freedom).

In short:  you bring up a legitimate, vexing problem that occurs throughout the game, and I'm dubious of the merit of spending a bunch of time and effort to solve only a small part of the problem.  Seems to me that if KSP really wants to solve this, they need to figure out a good way to solve the "variable shrouds" problem in general, which they haven't done yet.

Short answer:  probably no fix for this coming any time soon.  It's a great suggestion, turns out to be hard to do.

[Burning Kan]

Thank you for your clarifying answer

 

[mostlydave]

28 minutes ago, Snark said:

Yep.  Based on my (admittedly sketchy and inexpert) observations, my impression is that Porkjet simply didn't get around to implementing the glowing-nozzles part of those engines.

Technobabble details in spoiler section below, for the curious, but it boils down to this:

• Yes, that's right, there's no nozzle glow for these parts.
• No, it's not fixable.  (At least not by me.)

  Reveal hidden contents

KSP engines implement the emissive glowing nozzles via a PartModule called FXModuleAnimateThrottle.  If we look at the Swivel, for example, we find that its stock config includes this:

MODULE
{
    name = FXModuleAnimateThrottle
    animationName = HeatEmissiveAnimation
    responseSpeed = 0.001
    dependOnEngineState = True
    dependOnThrottle = True
}

^ that.  That right there is why the Swivel gets that nice orange glow on its nozzle in the stock game.

Note that for this to work, two things have to be there:

• First, and most importantly (because this is where all the hard work and artistic talent come in):  the model itself needs to have a "glow" animation and texture built into it.
• Second (and this is the easy part):  the part's config needs an FXModuleAnimateThrottle set up, to point at the relevant animation in the model.

The stock Swivel works because its model has all the necessary stuff hooked, up, and it also has the config shown above.

Now, with that in mind, let's take a look at Porkjet's reskinned Swivel, shall we?

The original config that comes from Porkjet, interestingly, contains a section that looks like this:

// MODULE
// {
//     name = FXModuleAnimateThrottle
//     animationName = HeatEmissiveAnimation
//     responseSpeed = 0.001
//     dependOnEngineState = True
//     dependOnThrottle = True
// }

Those // characters mean that the section is commented out.  In other words:  when he was working on these parts, Porkjet took the trouble to copy the FXModuleAnimateThrottle section from the stock Swivel... and then deliberately removed it from his config.

Which is an odd thing to do... especially since, if I look at the texture files he included, he actually has a JebsJunkyard_Emissive.dds texture file sitting in there, which tells me that he meant to hook this up.

I also note that the way that I set up the reskinned Swivel in MissingHistory... I've kept the original FXModuleAnimateThrottle config from the stock Swivel.  Which means, this ought to work, if the model has the animation built into it.  But it's clearly not working.

So, what's going on here?

I'm not Porkjet, of course, so I have no way of knowing exactly what he was thinking or what was going on at the time he made this stuff.  But putting all the observable pieces together (including the rather abrupt way that these parts were released in the first place), here's my theory.  To be clear, this is only a theory, I'm just guessing since I have no inside information on the subject:

I think that he clearly meant to put an emissive nozzle glow on these parts, and that he had actually started the work to do so (that's why there's an emissive texture file sitting there in the folder).  However, I think that some unexpected, sudden circumstances intervened that required him to stop what he was doing and just release what he had.  And I also think that when he had to do that, he hadn't yet gotten around to hooking up the emissive texture with an animation in the model.  So he just quickly commented out the FXModuleAnimateThrottle and shipped what he had before heading out the door.

What this means, if I'm correct, is that there's basically no way of fixing this without actually going into the part model itself and doing the work that Porkjet didn't have time to do, and hooking up an animation (named HeatEmissiveAnimation) to the emissive texture that he produced.

I'm guessing that that's technically possible... but it would require modeling skills that I don't have at the moment, and would take more time than I currently have for me to go and acquire them.

Therefore:  until/unless someone (who does have the modeling skills) wants to volunteer to come in and hook all this up... I'm not going to be able to fix this myself.

 

 

Yeah, I've noticed that myself.  You're right, it's kind of jarring.

I'm guessing it's technically possible, but would be somewhat low on my priority list, for a couple of reasons.

First, I'd love to get the boat-tail variant thing working (i.e. hook up the "boat tail" variant of these engines that Porkjet provided).  If I'm going to spend "tinkering time" trying to get variants to work for the engines, I'd probably want to get that working first.

Second, even if it does work and all the necessary work can be done for it... that still doesn't solve the problem of all the other engines in the game (including the new Making History variant-mesh engines), as well as all the engine plates, which all have single-color-only shrouds.  In other words, solving this problem for the Porkjet 1.25m engines would only be solving about 20% of the problem in the game.  And making this work for the variant-mesh engines and engine plates would be... really hard (because ModulePartVariants only allows modifying one aspect of a thing, not two; it only has one degree of freedom).

In short:  you bring up a legitimate, vexing problem that occurs throughout the game, and I'm dubious of the merit of spending a bunch of time and effort to solve only a small part of the problem.  Seems to me that if KSP really wants to solve this, they need to figure out a good way to solve the "variable shrouds" problem in general, which they haven't done yet.

Short answer:  probably no fix for this coming any time soon.  It's a great suggestion, turns out to be hard to do.

Thanks, I didn't realize it was that hard to modify the shrouds, let's hope Squad does something about it.

[Jarin]

Okay, filing that under "to-do once I think I can actually create original textures" I guess.

[Capt. Hunt]

3 hours ago, Snark said:

Well, not quite.  His original config models the engines as entirely separate parts, whereas what I'm doing is to modify the original parts with a different mesh.  What I did was to do a careful surgery that blended aspects of both the stock config and the Porkjet config to splice in his models.

If you want the upgrade options, what you'd need to do is to take his original config, find just the bits involving upgrades, then go into my config with a text editor and do brain surgery on it to splice the upgrade stuff in there "just so" to make it work.  You'd also need to add various ModuleManager config to override values that I don't touch at all (like the stock engines' Isp, thrust, etc.), because Porkjet's config modifies that and mine doesn't, and his upgrades are designed with the assumption that the base engine has different properties.

In short:  No, you can't just "delete A, copy B in its place".  You'd basically be re-implementing that part of the mod from scratch, and doing all the same kinds of things that I needed to do to produce MissingHistory in the first place, except do it differently than I did.

To summarize the summary:  It's hard.  Sorry.

Ok, I know you fully intend to implement them in your mod eventually as part variants.  Ultimately that would be ideal, but for the time being I just want them to keep working as originally designed, even if they don't have all the extra paint swapping functionality and balance tweaks.

Edit: looks like just installing both mods side by side does basically what I wanted.  It's duplicating the parts that were changed by your mod, but since that's only a handful of parts, it's no big deal, they don't appear to interfere with one another.

Edited March 19, 2018 by Capt. Hunt

[Papa_Joe]

Have you considered supporting Connected Living Space?  I'm working on config files for the expansion, so there will be examples in the Mod when complete.  Let me know.  I'd prefer that you do it, but if not, I will try to add support for these parts.

[Delbrutis]

On 3/13/2018 at 10:30 PM, Snark said:

What it does

Adds (or updates) various parts that I wish MakingHistory had included, but didn't.

Download from SpaceDock

•  

---

---

 

Really like this  release nice parts that we needed in stock. I have been using the Porkjet's  pack with the part switching working for a long time now. works fine in 1.4.1.  You have to drop the switchers.dll "that I believe came out originally with the pack?" In the plugins folder or have module manager Installed to load it . I'm sorry to say the link's seem dead? And I don't remember Who the original author was? But you need the Merged.mu file for it to work. The merged file might work with the new system no switcher.dll  needed? Maybe the original person who got it working will see this or someone else remembers where to get the file? Sorry I'm not much help but the part switching is really nice. And has always worked fine and bug free for me with the file's I have. Thank god I have almost a one and a half TIB backup drive full of Kerbal stuff going back to version .22 I think LOL . It would be cool to get the new system working. You would get that cool icon and preview in the parts menu. Good job with the pack color tanks look great.I hope someone can find whoever merged the .mu files? hell it could have been Porkjet I think the original release came with a bunch of documentation he wrote and might have had the source file's. Can you even combine a .mu  file without the original Unity build?  If so I have a copy of a old VEN Mainsail file and would love to combine it with his new boat tail version.  Thanks for all the hard work.  

Yeah and I would love to see the Heat Emmisive's working to + + + "You don't Know how many hours I waisted when I first got these trying to make that emmisive work "

 

Edited March 21, 2018 by Delbrutis
Holding DEL em-mmmmmmmmmmm OK fixed Sorry

[DatBoi]

Guys, please only use the relevant parts of the post in a quote, you are just clogging the thread.

[CobaltWolf]

On 3/16/2018 at 11:57 PM, Jarin said:

 

On 3/18/2018 at 6:18 PM, Snark said:

One thing I've noticed, that concerns me a little. In the screenshot @Jarin posted above, the tank appears to have kept most of its detail. However, below in @Snark's screenshot, it appears to be missing much of the diffuse and specular detail. Note the missing horizontal (well, vertical with the tanks sideways) paint strokes, and moreover, the shading around the corrugated parts (most noticeable at the left hand side of Snark's screenshot) - it appears the normals are still present, but there is no complementary shading in the diffuse to help sell the effect. Again, it seems that they were present in the screenshot Jarin shared above. Is there a reason for that? Ignoring the complications presented by the black stripes on the original textures, I believe with some slight adjustments the the original textures can be overlaid using the 'multiply' blend more to add at least the dark shading back?

In any case, @Jarin your retextures are very cool! The two longest tanks in particular are nice. I think the stripe in the small corrugated tank looks a bit out of place however, and the shortest tank I feel would look best fully green. Are the green/orange tanks using custom specular maps as well?

[Jarin]

57 minutes ago, CobaltWolf said:

Note the missing horizontal (well, vertical with the tanks sideways) paint strokes, and moreover, the shading around the corrugated parts (most noticeable at the left hand side of Snark's screenshot) - it appears the normals are still present, but there is no complementary shading in the diffuse to help sell the effect.

This was actually an intentional change, but was undermined by my borking the normal map hard. I had intended to remove the normal ridges on the far left of the largest tank, and only have ridges on the orange section of the second-smallest (FL-T200). But since the map borked, @Snark had to stick with the original porkjet normal map, so you have ghost ridges that only exist in the bump mapping and not the texture file. The stripe on the 400 was also removed because the coloration went weird with the orange skinning.

Fixing that is on the to-do list, but I can really only scrounge modding time on Saturdays right now, so it's going to have to wait for the weekend.

Edited March 20, 2018 by Jarin

[Delbrutis]

5 hours ago, DatBoi said:

Guys, please only use the relevant parts of the post in a quote, you are just clogging the thread.

My bad I did not intend to do that fixed. Sorry no more post and run

[StevieC]

Would it be outside the scope of this parts-pack to include a Kerbalized equivalent to this engine that powered the Saturn 1 booster?

[DatBoi]

@StevieC I love your Sig

[Snark]

11 hours ago, StevieC said:

Would it be outside the scope of this parts-pack to include a Kerbalized equivalent to this engine that powered the Saturn 1 booster?

Don't currently have any plans for it.

First of all, I'm really not a modeler.  I'm a good coder, and I have fun with creative stuff, but I'm not artistic and I'm simply not equipped to build models or textures myself.  That's why this mod currently doesn't have any original "artistic" content at all, other than the gray/orange texture for the 1.25m engines which @Jarin kindly supplied since I'm not wired for that myself.    So, there wouldn't be any way of adding a brand-new engine without having someone stepping up and doing all the modeling/texturing work for it, which is a pretty big job requiring good modeling skills.

Also... bear in mind that this mod is focused mostly on gameplay.  I like flying rockets, I like my rockets to look "rockety", I enjoy the gameplay and the creativity and the engineering challenges-- but I have no interest at all at trying to recreate specific historical things.  For example, I love the Making History expansion, but not because it lets me build historical replicas-- it's because it provides new gameplay options that allows for a wider variety of rocket designs.

So, for example, I was glad to add Porkjet's "Valiant" and "Pug" engines here, even though they're not particularly modeled after any specific historical engine that I know of, because I felt that they filled some useful gaps in the 1.25m engine lineup.  Having a lightweight sustainer engine for small ships (the Valiant), and a lightweight 1.25m orbital engine for small ships (the Pug), is something I've wanted for a long time, so they filled a hole.

So... unless someone has a proposed set of stats that I haven't thought of, I just don't see the utility of adding additional engines to the lineup.  We now have a pretty good menagerie of engines at the 1.25m, 1.875m, and 2.5m sizes-- each one of them has a heavy lifter, a decent mid-range sustainer, and a high-Isp vacuum engine for orbital work.

One of the things I like about KSP is the way it gives such a huge amount of creative freedom without needing to have thousands of different parts in it.  I like that, by and large, most parts serve valuable and fairly unique gameplay functions that can be used in a variety of cases.  Which means I'm a big fan of parsimony on the parts tab-- I don't like adding parts willy-nilly, and I especially don't like adding them for "cosmetic" reasons (e.g. to look like one thing or another).  In general, I only like to add a part if it solves a specific gameplay problem that's currently unaddressed.

So, that makes "add a new engine" a kind of hard sell, for me.    Not impossible, just that my default position is to be skeptical, and to be convinced I'd need to see a proposed set of stats that would fill what I see as being a "gameplay gap".

What did you have in mind for this engine?  How is it different from the Mastodon or Skiff or Wolfhound or Cheetah?

[klesh]

Any chance of getting the White variant added to the S2-S3 Adapter Tank?  Pretty please?

[Jarin]

16 minutes ago, klesh said:

Any chance of getting the White variant added to the S2-S3 Adapter Tank?  Pretty please?

Falls into the same category of work as the reskinned 3.75m tanks. I.e. "when I can do original art for it" because the current texture isn't licensed for me to edit the way I did the porkjet parts. Basically, I'd love to, but it's probably going to be a while before I get to that point.

If someone with skills for original texture work (rather than just editing like I did) feels like volunteering, that might be different. Otherwise we get to wait on my slow-ass learning curve.

Edited March 21, 2018 by Jarin

[klesh]

6 minutes ago, Jarin said:

Falls into the same category of work as the reskinned 3.75m tanks. I.e. "when I can do original art for it" because the current texture isn't licensed for me to edit the way I did the porkjet parts.

 

It currently uses the Black and White, and Gray and Orange variants.  I figured they were just the textures from MH used on the rescaled part, no?  I guess you do good work, because they look fab!

Edited March 21, 2018 by klesh
spelling

[Jarin]

8 minutes ago, klesh said:

It currently uses the Black and White, and Gray and Orange variants.  I figured they were just the textures from MH used on the rescaled part, no?  I guess you do good work, because they look fab!

I'm glad people like them!

You really have to understand the level of cheating I did here, though. I just created a flat square texture on a scratch file of the gray and the orange, then copied that in a square onto a new layer on top of the existing image, <ctrl-t>ransformed the box into whatever shape needed the new color, and set the layer to "multiply". It's the digital equivalent of putting colored shrink-wrap over something. They look good largely because I could retain 90% of the detail of Porkjet's work.

The most actual "artistic" work I did was erasing the black stripes and making that area flat white on the base skin before applying the overlay.

Edited March 21, 2018 by Jarin

[OhioBob]

@Snark, I know this is off topic, but you seem to know quite a bit about part variants, so I thought I'd ask.  Do you know if it's possible to have a variant that changes a part's stats?  For instance, could a variant change a part's maxThrust and atmosphereCurve?  This could be used to simulate a low expansion ratio (sea level) and a high expansion ratio (vacuum) version of the same part.

Edited March 21, 2018 by OhioBob

[Snark]

2 hours ago, OhioBob said:

Do you know if it's possible to have a variant that changes a part's stats?

Yes, I believe I do.  And the answer is no, it can't.  Variants only change models and/or textures (and nodes), that's it.

[OhioBob]

48 minutes ago, Snark said:

Yes, I believe I do.  And the answer is no, it can't.  Variants only change models and/or textures (and nodes), that's it.

That's what I thought the answer was going to be.  Thanks.

[Snark]

On 3/21/2018 at 8:13 AM, klesh said:

Any chance of getting the White variant added to the S2-S3 Adapter Tank?  Pretty please?

Huh?!  It should already be there!  <scurries off and looks>... Well, I'll be gosh-darned.  You're right!  It's missing.

It's not a question of adding it-- it was supposed to be there in the first place, and the fact that it's not, is a bug.  Thanks for calling my attention to it!

This part is a rescaled clone of the FL-A151L adapter, so it ought to have all the same textures as the original.  Looks like when I added my config snippet to change the default texture from "White" to "Black and White" (since I thought that fits better with the 3.75m paint scheme), there was an unintentional side effect of hiding the "White" variant from view.  Well, fortunately this is easily fixed, just a bit of config to adjust-- no new artwork required.

Ahem.  Well... this sounds like a job for... Missing History version 1.1.1, a.k.a. "The Klesh Edition" 

Update posted.  Aside from the new texture on this tank (thanks, @klesh!), I've also fixed the attachment nodes on the 1.875m reaction wheel and battery (they were size 1, are supposed to be size 2 in keeping with the standard for 1.875m stacks).

Enjoy!

On 3/19/2018 at 10:26 PM, Papa_Joe said:

Have you considered supporting Connected Living Space?  I'm working on config files for the expansion, so there will be examples in the Mod when complete.  Let me know.  I'd prefer that you do it, but if not, I will try to add support for these parts.

Hadn't considered it, mainly because I've never used that mod and know nothing whatsoever about it other than a vague idea of what it does.  I gather that it's just a ModuleManager patch?

If you're making a compatibility patch for this stuff, perhaps just slip one in there for MissingHistory as well.  Sounds like anyone who has MissingHistory and Connected Living Space both installed would want such a compatibility patch... but then, they'd want it for Making History parts too, which means they'd need your patch, which means your patch seems like a fairly reasonable place to put the config.

[Papa_Joe]

57 minutes ago, Snark said:

...

Hadn't considered it, mainly because I've never used that mod and know nothing whatsoever about it other than a vague idea of what it does.  I gather that it's just a ModuleManager patch?

If you're making a compatibility patch for this stuff, perhaps just slip one in there for MissingHistory as well.  Sounds like anyone who has MissingHistory and Connected Living Space both installed would want such a compatibility patch... but then, they'd want it for Making History parts too, which means they'd need your patch, which means your patch seems like a fairly reasonable place to put the config.

Yes, it is a simple Module Manager patch.  Ok.  I'll add a config file for them.  As a side note, I could simply add a PR to your repo and you could add it to your mod.  Then, if you later decide to add other parts, the templates will be there.  your choice.

 

Ok, I've taken a look at the parts listed in your mod, and I don't see any that would be good candidates for crew movement.  I briefly considered the service bay, but that is not pressurized (doors can be jettisoned), so I'm not including it in the Making History configs. 

So, at this time Disregard the need for CLS compatibility.

Edited March 23, 2018 by Papa_Joe

[Muetdhiver]

This mod is a god send, especially the retextured 1.25m tanks in gray/orange, finally been able to build a rocket not looking to jaring ^^

In that line, how hard would it be to add the orange/gray textures for 2.5 / 3.75 / 5m parts ? I find it quite sad that there is no way to use the gray/orange color in an harmonious way past 1.85m rockets. I have no experience in modding ksp so maybe what I'm asking about is quite hard ?

Oh, and big thy for the missing fuel connector

[Kwebib]

Great mod. Thanks for putting this together. Do you think the Swivel and Valiant should be swapped in the tech tree, though?

// Switch "Valiant" and "Swivel"
@PART[liquidEngine2]
{
	@TechRequired = generalRocketry
}
@PART[liquidEngineT15]:NEEDS[MissingHistory]:AFTER[MissingHistory]
{
	@TechRequired = basicRocketry
}