Sign in to follow this  
DrunkenKerbalnaut

Custom part not inheriting texture from surrogate.

Recommended Posts

I copied and modified the Stratus-V Monopropellant tank (leaving the original intact) to make a LF/OX radial tank. Everything works as intended, except the tank doesn't inherit the texture from the original part. The cfg file references "mesh" and so I've left it alone where it resolves as "model".  I assumed this just looks to whatever model shares the same folder as said cfg file. Except it isn't doing that, and the tanks just have a standard grey scale texture, in-game. 

Something tells me I'm missing something obvious. 

 

5SLW3ua.jpg

Edited by DrunkenKerbalnaut
add screen cap

Share this post


Link to post
Share on other sites

1) every texture and model is loaded on startup.

2) cfg files are loaded. If the file has a MODEL{} entry, it will assign itself to that specific model. If it has mesh= entry, it will completely ignore whatever filename mesh= contains and pick the first available model from the .cfg's directory (even with complete disregard of the MODEL entry if present in the same .cfg, so use either of those, not both.)

3) Model contains texture file names and types but not paths. It picks the texture files from... I believe the same directory it's in, but I'm not entirely sure if not from the .cfg directory. If it fails to find the texture, it remains black. If the texture is wrong format, it won't load at all.

4) If the MODEL entry contains a texture replacement entry, the texture on the model is replaced with the one pointed to. Assuming the model had some texture. If it failed to load the initial texture for one reason or another, this won't work.

So, your easiest option is to keep the tank model, cfg and texture file in one separate folder. If you want to save memory, reference the model by its path in MODEL cfg entry, keep a 2x2px texture of the same format as the model uses, and use texture replace entry to restore the texture from the stock folder.

Edited by Sharpy

Share this post


Link to post
Share on other sites
25 minutes ago, Sharpy said:

-snip-

First of all, thanks for trying to help.

1)I've been closing KSP to make any changes, so shouldn't be an issue. 

2-4) I'll just answer by showing you what I've got. Prob should have done that to begin with :) . Check OP for image of file paths and .cfg in question. 

 

Share this post


Link to post
Share on other sites

@DrunkenKerbalnaut: I was just listing points what happens, not your problems.

Anyway, the answer to your problem is in "Model contains texture file names and types but not paths".

model.mu looks for ksp_r_rcsCylTank_diff.dds in the current directory (/Squad/Parts/FuelTank/fuelTankStratusX/) and doesn't find it. There's nothing that would suggest it should load ksp_r_fuelTankStratusX.dds instead, or look for the texture in a different directory.

Share this post


Link to post
Share on other sites
2 hours ago, Sharpy said:

-snip-

Ah. I think I see what your saying. What program are you using to access the .dds and .mu files?

 

EDIT: Yup. Works great now. For posterity: I'm a doofus :) . Thanks again, kind stranger. 

Edited by DrunkenKerbalnaut

Share this post


Link to post
Share on other sites
6 hours ago, DrunkenKerbalnaut said:

Ah. I think I see what your saying. What program are you using to access the .dds and .mu files?

 

EDIT: Yup. Works great now. For posterity: I'm a doofus :) . Thanks again, kind stranger. 

.mu - no simple way to edit them. Import into Blender using MU import plugin, save as .blend or one of supported programs, import into Unity.

.dds - GIMP with DDS plugin; alternatively IrfanView to convert to .png, edit and save as .png with Gimp, edit .mu (through Blender->Unity) to use .png instead of .dds

 

Share this post


Link to post
Share on other sites
49 minutes ago, Sharpy said:

-snip-

Gotcha. Actually found said plugin for the ol' GIMP. Having export issues, but that's another thing entirely. 

 

So .mu is the actual polygon mesh? Is this also where nodes are defined?

Edited by DrunkenKerbalnaut

Share this post


Link to post
Share on other sites

@DrunkenKerbalnaut: .mu is much more than that. It's all the meshes of the part, their animations, hierarchy and shaders/materials minus the very texture image. It's special objects and meshes - colliders, raycasts/transforms (wheel/ground contact area; engine thrust point; lamps with specific light cones), particle emitters/exhaust/smoke (again with everything except the particle texture/picture; but all behaviors of the emitter defined), controls for dynamic animation (like wheel suspension).

They are contain everything that Unity can contribute to KSP - .cfg contains stuff that is KSP-specific, not providable by Unity. Minus texture images - although .mu still specifies 'base' colors that show through partially transparent textures, colors the parts take due to shadows, emissive colors (engine glow; LED lights), particle color (alpha-blended with whatever the particle image provides; make particle pic white and you can color it arbitrarily in Unity), and so on, and so forth. They also specify filenames for textures, normal maps and emissive maps, and their layout (UV maps) although not content of these files (emissive map defines what locations of part glow, but color information is ignored, taken from .mu instead.)

Everything about a part that is not defined in .cfg is defined in .mu; .cfg also binds KSP's modules (thrust, FX emission, special functions like toggleable animations) to their respective objects in .mu (through MODULE entries.) .cfg can also apply a few tweaks - rescale the model; replace the texture (though original must still be present even if as token dummy 2x2px), reposition the model relative to game logic's 'middle', and several more such tweaks/modifications, so that you can reuse the same model for several parts.

Interestingly, NODES, are one of few things not defined in .mu - although they could have been (like transforms) - they are fully defined in .cfg through node_stack_..., and node_attach_... controls.

Share this post


Link to post
Share on other sites

Wow. I just got educated! Thanks for taking the time to explain. You've only triggered more questions, but I think I'll just download blender again and make a mess first. :)  I have a need for a few niche structural parts anyways. Modular roll cage tubes and bends. Man, just when this game starts feeling old hat, it presents a new discipline to explore. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this