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

[Snark]

2 hours ago, Jarin said:

My intent here is to copy as much as humanly (kerbally?) possible from the existing models, trying to just get my hands on the current texture image files, edit the color/texture, and put it straight back, hopefully dodging any alignment and mapping issues by not actually changing anything that would affect it. More than that may be beyond me.

The texture files themselves are nicely accessible, since they're stored as a separate .dds file sitting right next to the model file for the part.  So all you need is an image editor (such as GIMP) that's capable of opening the file and then you can edit it.

So, with a workflow that involves nothing more than "open an image file, do artwork, save it as a separate image file", you can pretty up the textures.  I expect you'll manage that nicely, assuming that unlike me you have art talent. 

The problem is... simply producing the new texture file isn't enough.  You also have to jigger a .mu file that is referencing the new image file, and that's where you have to do the "re-export through Unity to generate a new .mu file" thing, even if you're not actually touching any of the tank's geometry, since the .mu file itself has a reference to the texture file by name.

[Jarin]

I'm fairly confident in my ability to at least do the image editing part; especially since I can (if I understand you correctly) just blatantly steal the base color and texturing from the existing orange/black .dds texture files on the new parts. The one thing I'm worried about is a mention I saw of the 1.41 part tools not being released yet. Might have to wait on that?

Edited March 15, 2018 by Jarin

[Snark]

1 hour ago, Jarin said:

The one thing I'm worried about is a mention I saw of the 1.41 part tools not being released yet. Might have to wait on that?

Yeah, will definitely need that.

[benjee10]

You can use the new part variant module to reference a texture not referenced in the .mu if that's helpful. Not sure if the TEXTURE{} variable works outside of modulePartVariant though. 

[Snark]

2 hours ago, benjee10 said:

You can use the new part variant module to reference a texture not referenced in the .mu if that's helpful. Not sure if the TEXTURE{} variable works outside of modulePartVariant though. 

Whoa, really?  Now that would make things much, much simpler.

Is there any example or documentation or something you could point me at?

@Jarin, if this is the case, your job would become much easier:  basically, just generate a new .dds file with the new textures.  You can use the existing .dds as your guide to UV-mapping it.  With a new texture in hand, I could then tinker with the config to make that work with the ModulePartVariants, and then we'd be in business.

[benjee10]

Don't think there's any documentation yet, but this is from one of my reDIRECT parts: 

	MODULE
	{
		name = ModulePartVariants
		baseVariant = Orange
		VARIANT
		{
			name = Orange
			displayName = Foam
			themeName = Orange
			primaryColor = #f49841
			secondaryColor = #4c4f47
			TEXTURE
			{
				materialName = shuttle_tank
				mainTextureURL = reDIRECT/Phase1/Parts/5m_Tanks/shuttleTank_main
				_BumpMap = reDIRECT/Phase1/Parts/5m_Tanks/shuttleTank_normals
			}
			TEXTURE
			{
				materialName = jupiter
				mainTextureURL = reDIRECT/Phase1/Parts/5m_Tanks/jupiter_elements
				_BumpMap = reDIRECT/Phase1/Parts/5m_Tanks/jupiter_elements_NRM
			}

		}
		VARIANT
		{
			name = White
			displayName = Painted
			themeName = White
			primaryColor = #ffffff
			secondaryColor = #ffffff
			TEXTURE
			{
				materialName = shuttle_tank
				mainTextureURL = reDIRECT/Phase1/Parts/5m_Tanks/shuttleTank_main_alt
				_BumpMap = reDIRECT/Phase1/Parts/5m_Tanks/shuttleTank_normals
			}
			TEXTURE
			{
				materialName = jupiter
				mainTextureURL = reDIRECT/Phase1/Parts/5m_Tanks/jupiter_elements
				_BumpMap = reDIRECT/Phase1/Parts/5m_Tanks/jupiter_elements_NRM
			}
		}
	}

So as you can see each variant has a TEXTURE{} field where you can define an arbitrary texture location. I've got a material field too because that part uses multiple textures, so you have to define which material each texture will be applied too. The isn't necessary with a part with only one texture however. 

The only problem is that by including this module you're going to get the little icon indicating that variants are available popping up in the VAB. I'm not sure if TEXTURE {} works outside of this module but it might be worth testing. 

[Snark]

5 hours ago, benjee10 said:

So as you can see each variant has a TEXTURE{} field where you can define an arbitrary texture location. I've got a material field too because that part uses multiple textures, so you have to define which material each texture will be applied too. The isn't necessary with a part with only one texture however.

Excellent, thanks!  So, my reading of this:

• There's a "materialName" field.  It's optional, not needed if the part has only one material/texture.  If present, I assume it needs to match some specific named object in the .mu.
• There's a "mainTextureUrl" field.  I assume this points at the .dds file with the texture?  I note that the example values you give don't end with ".dds".  So... what exactly goes here?  I'm guessing it's the GameData-relative path to the DDS file, including the DDS filename, but not including the ".dds" extension.  Is that correct?
• There's a "_BumpMap" field.  I assume that this is the same deal with mainTextureUrl, i.e. a path to a DDS file but not including the ".dds" extension.  Correct?  And, am I also correct in assuming I don't need to specify this unless I actually want to override the bump map for the part?

Can you confirm that my above assumptions are correct?

5 hours ago, benjee10 said:

The only problem is that by including this module you're going to get the little icon indicating that variants are available popping up in the VAB.

Actually, in this particular case, it's not a "problem", it's desired behavior.  Because what we're doing is:  we have a part that currently has only one texture available, and we want to make it switchable, so that little icon is exactly what we want. 

[benjee10]

5 minutes ago, Snark said:

Excellent, thanks!  So, my reading of this:

• There's a "materialName" field.  It's optional, not needed if the part has only one material/texture.  If present, I assume it needs to match some specific named object in the .mu.
• There's a "mainTextureUrl" field.  I assume this points at the .dds file with the texture?  I note that the example values you give don't end with ".dds".  So... what exactly goes here?  I'm guessing it's the GameData-relative path to the DDS file, including the DDS filename, but not including the ".dds" extension.  Is that correct?
• There's a "_BumpMap" field.  I assume that this is the same deal with mainTextureUrl, i.e. a path to a DDS file but not including the ".dds" extension.  Correct?  And, am I also correct in assuming I don't need to specify this unless I actually want to override the bump map for the part?

Can you confirm that my above assumptions are correct?

Actually, in this particular case, it's not a "problem", it's desired behavior.  Because what we're doing is:  we have a part that currently has only one texture available, and we want to make it switchable, so that little icon is exactly what we want. 

Yup, you're absolutely correct on those. You only need to specify things you want to change. 

Materials are indeed defined in the .mu. 

[Snark]

1 minute ago, benjee10 said:

Yup, you're absolutely correct on those.

Excellent, that's all I needed to hear!    Am not at a KSP computer at the moment, but look forward to trying this out.

[Jarin]

15 hours ago, benjee10 said:

You can use the new part variant module to reference a texture not referenced in the .mu if that's helpful. Not sure if the TEXTURE{} variable works outside of modulePartVariant though. 

Best possible news to see first thing in the morning. Thanks!

[OhioBob]

@Snark, @Jarin, et al.  If you guys do make switchable textures for the 1.25 m tanks, I'd like to make a suggestion.  The 1.25 m tanks really need to also have a drab green gray Vostok/Voskhod texture like those available on the 1.875 m tanks.  I don't know if you've ever noticed before, but the center core of the first stage of all the R-7 derived launchers has a smaller diameter than the max diameter of the upper stages and the strap-ons.  Here's a picture showing it:

 

 

To make a proper Vostok/Voskhod replica, that section of the rocket really needs to be made using 1.25 m tanks.  The RK-7 Kodiak engine is even made with a selectable 1.25 m shroud specifically for connecting to that size tank.  All the parts are available for a realistic Vostok/Voskhod replica, but without the ability to change the texture on the 1.25 m tanks, it looks like dog poo.  The option to change that texture to the green gray should have been made part of the DLC, but it wasn't.  If you guys can make that happen, it would be fantastic.

BTW, thanks much for this mod.  It is exactly what I wanted and needed.
 

Edited March 17, 2018 by OhioBob

[Jarin]

I'll be starting with the black/orange, but assuming that I can make those look not-horrible (far from a given at this point), I'll certainly look at doing the same for all color schemes. Long-term I'd love to be able to have multiple matching color schemes for most tank and structural parts.

Edited March 16, 2018 by Jarin

[OhioBob]

@Snark, I've looked over your mod and I'm amazed by how much your changes exactly mirror my own thoughts.  I was planning to mod the game myself, but now I don't have to.  What you've done is almost exactly what I would have done had I done it myself.  Even adding in those few extra Porkjet engines was on my to do list (the DLC didn't do anything to address some gaps among the small sized engines).  This is, in my opinion, the perfect compliment to the DLC.  Between the DLC and this, I don't think I really need any other part mods.  Thanks for making it.
 

Edited March 16, 2018 by OhioBob

[Bottle Rocketeer 500]

@Snark @Jarin If you would like, I can quickly whip up a few 1.25 tank replacement models in blender with tank domes thingies. I can probably do it all (modeling and UV unwrapping) for 3 tanks and have it ready for texturing somewhere around tomorrow. Would you like me to do so?

[Jarin]

10 minutes ago, Bottle Rocketeer 500 said:

@Snark @Jarin If you would like, I can quickly whip up a few 1.25 tank replacement models in blender with tank domes thingies. I can probably do it all (modeling and UV unwrapping) for 3 tanks and have it ready for texturing somewhere around tomorrow. Would you like me to do so?

It sounds like we're not going to need actual new models, just the image textures. The config should allow the new texture file to be applied to the existing models. If you have experience with turning blender models into parts though, I may have some questions for you soon.

Edited March 16, 2018 by Jarin

[Bottle Rocketeer 500]

@Jarin If you mean configuring models in Unity, then yes. If you mean writing config files, the also yes (that is if balancing them isn't part of it, though I can find the fuel capacity of a tank.) The reason why I wanted to make new models was just because IMO, ones with tank domes might fit in a little bit better with the MH parts. I will start with the FLT-800 tank and post a render here, just so you can decide if you want me to make new models or not. Still, I think you would have to bring the existing parts through Unity anyway. Also, @Snark, maybe change the stock Mk1 command pod to @Porkjet's overhauled version, as that might fit in better with the MH Gemini parts. Then, if you would like, I could maybe model a few extra Gemini parts, mainly for the nose (monoprop tank and docking port/parachute). Also, maybe some Mercury parts.

[Jarin]

I think I'm going to stick to editing existing textures rather than try to create entirely new ones, for now. For the rest, I defer to @Snark

[Bottle Rocketeer 500]

@Jarin OK, understood.

[Jarin]

3 minutes ago, Bottle Rocketeer 500 said:

@Jarin OK, understood.

To clarify, I do appreciate the offer of assistance. But this being my first actual foray into KSP modding, I want to start simple.

[Bottle Rocketeer 500]

@Jarin One I finish my current CST-100 mod, I might actually make a stock overhaul project including some tanks. Still, there is the possibility that @Snark would accept my offer to make Gemini and Mercury parts.

[Snark]

5 hours ago, OhioBob said:

The 1.25 m tanks really need to also have a drab green Vostok/Voskhod texture like those available on the 1.875 m tanks.

Um... what do you mean?  I only see three textures available for the 1.875m tanks.  "White", "Black and White", "Gray and Orange".  Am I missing something?

We're working on providing a variant of the 1.25m tanks that will match the "Gray and Orange" scheme that the 1.875m and 2.5m tanks have.  If that's what you're asking, then yeah, that's coming. 

Or are you asking for a complete drab-green reskinning of all the tanks (1.25m, 1.875m, 2.5m)?  Because that would be undoubtedly super cool, but would also be a really big job (particularly since for 1.875m and 2.5m, one wouldn't be starting with "free" CC-BY-SA textures to crib from).  It sounds like a neat idea, but also sounds like it would be a topic for a different mod, given the size/scope of such a thing.

1 minute ago, Bottle Rocketeer 500 said:

Still, there is the possibility that @Snark would accept my offer to make Gemini and Mercury parts.

Well, there are a lot of reasons for mods. 

To be clear, my motivation is almost entirely around gameplay.  I don't particularly give a wet slap about "make a rocket that looks just like <historical thing>", e.g. building a Vostok or a Saturn V or whatever.  I just like playing KSP, and I made this mod because it kind of itched at me that there was a lack of a lot of practical parts (e.g. 1.875m stack parts), and also that there was a very visually jarring style difference between the 1.25m parts and the rest, and also a lack of new engines for 1.25m stacks.

I'm a lot less motivated to tweak the Mk1 pod, Mk2 pod, etc., because for me they're not "broken", I like their looks already. 

I also have a fair amount of incentive not to touch the meshes of any of the stock crewed parts, mainly because I've very carefully instrumented all of them for my IndicatorLights mod, which takes a super huge amount of very carefully, tediously placing the indicator meshes "just so" on the stock models.  Anything that reskins the parts in a way that affects the shape will hork all of my carefully managed placements (the indicator lights end up either buried invisibly inside the part, or floating out in space).  Which means I'd need to generate a whole new set of patches to fix it, and double the IndicatorLights work.  It's why I don't, for example, run Ven's Stock Revamp, never mind how cool that is. 

That said, there's plenty of room for cooperation and collaboration, as far as I'm concerned.  The details of "what goes where" can be worked out-- perhaps some extra options can be added to this mod, perhaps they might make more sense factored into another mod, etc.

And it's early days yet, this mod's just a couple of days old at this point and I'm still getting used to playing with it.    So ask me again in a week and perhaps my feelings might be different... or maybe not.

In any case, thank you thank you for the public-spirited offer, and I really appreciate it.  Let's keep in touch.

[Bottle Rocketeer 500]

@Snark If you decide otherwise at any point, just PM me. I will now resume work on my CST-100 mod, as 1.4 has some very useful features, such as the service bay module.

Edited March 16, 2018 by Bottle Rocketeer 500
Fixed punctuation (accidentally made a / instead of a .)

[Snark]

2 minutes ago, Bottle Rocketeer 500 said:

@Snark If you decide otherwise at any point, just PM me. I will now resume work on my CST-100 mod, as 1.4 has some very useful features, such as the service bay module.

Could you post an actual link to your mod here?  (or to a development thread, or anything you may have that's publicly visible?)

I know I'd love to look, and I suspect I'm not the only one. 

[Bottle Rocketeer 500]

@Snark Here you go:

 

[klesh]

5 minutes ago, Snark said:

Um... what do you mean?  I only see three textures available for the 1.875m tanks.  "White", "Black and White", "Gray and Orange".  Am I missing something?

 

For the 1.875m parts, the "Grey and Orange" theme is mostly the drab green that OhioBob was talking about.  It also makes me wonder if that one grey band on the second tank shouldn't be orange, and the theme changed to "Green and Orange".