Change PART{} from "mesh = " to MODEL{} form?

[JumpsterG]

Hi everybody. This problem seemed simple at first, but it has me pulling my hair out at the moment.

As part of a bigger project, I'm trying to create an automated procedure to change all parts in GameData to using URL references to their resources.

Basically, converting from:

mesh = model.mu
scale = 0.01

to this form:

MODEL
{
model = Squad/Parts/FuelTank/MK1Fuselage/model
position = 0.0, 0.0, 0.0
scale = 1.0, 1.0, 1.0
rotation = 0, 0, 0
}

Simply commenting out the "mesh = " line and adding in the MODEL{} node as above works to some extent, but some sizes seem off and some parts are missing visible attachment nodes and/or attach strangely in the VAB/SPH. This is using the model node exactly as above with what I understand are basic settings.

Obviously, I'm failing to set scale, rescaleFactor, the MODEL{} variables (pos, scale, rot), and/or the attachment node properties to reflect the changeover to the MODEL format. Can anyone help me understand what are equivalent sets of values between a minimally-defined PART{} and one that explicitly defines MODEL{}?

[Greys]

MODEL
{
  model = Squad/Parts/FuelTank/MK1Fuselage/model
  position = 0.0, 0.0, 0.0
  scale = 1.0, 1.0, 1.0
  rotation = 0.0, 0.0, 0.0
}
scale = 0.01
rescaleFactor=1

scale doesn't do what you think and rescaleFactor's default value is not 1, so they must be set explicitly or the result will not be the same; there are also some conflicts between scale, rescaleFactor, and MODEL{scale} that you'll have to experience and account for.

scale directly impacts the coordinate space that attachment nodes are defined in; if it was supposed to be 0.01 and you leave it out, the default value is either 1 or a value near 1, and your nodes will be 100 times farther away from the part origin than intended.

[JumpsterG]

Thanks, Greys. I think I just needed some more eyes on this, since I have no experience making models or adjusting part sizes and such. I assumed there would be just a 1-to-1 conversion between implementations, but this seems not to be the case.

I understand that scale needs to stay the same, regardless of whether MODEL{} is being used. Does it's behavior change in any way though?

If rescaleFactor was not present in the original "mesh = " implementation, I assume this meant it was using KSP's default for that value. (1.25 I think is what I read elsewhere). I wouldn't think that switching to MODEL{} would require rescaleFactor to be adjusted or explicitly set, but I'll play with a couple of settings and see if something works.

My fear is that even if I experiment and figure out good values for one part (say, the MK1Fuselage I was experimenting with), that I might not be able to find a recognizable pattern that can be automated for performing the same transformation on arbitrary parts.

Does anyone know of a reference describing the class KSP loads these values into? I guess I should probably bite the bullet and dig into the .dlls myself...

[NathanKell]

Except there's a bug whereby a model using MODEL node is scaled by rescaleFactor * rescaleFactor. So you will need to set, in model node, scale = 1/rF, 1/rF, 1/rF (for any rF), where rF = 1.25 if not present in cfg.

[JumpsterG]

Except there's a bug whereby a model using MODEL node is scaled by rescaleFactor * rescaleFactor. So you will need to set, in model node, scale = 1/rF, 1/rF, 1/rF (for any rF), where rF = 1.25 if not present in cfg.

I get it now! I had read about this elsewhere, but it didn't click in my head as the issue I was dealing with until you wrote it out this way. The way I saw it, I was already scaling 1-to-1, but now it's obvious that I need to be compensating. Some testing now with stock parts switched to MODEL{} confirms that adjusting scale as you suggested results in those stock parts appearing as expected in the VAB/SPH. Funny that I'm excited about seeing the exact same parts I started with!

I'm writing out the following in case it helps someone else as dense as I am who winds up reading this thread:

This works as a simple 1-to-1 conversion for parts without a rescaleFactor:

Replace just this line

mesh = model.mu

with

MODEL
{
model = Squad/Parts/FuelTank/MK1Fuselage/model
scale = 0.8, 0.8, 0.8
}

The MODEL{scale} values will need to be set differently for PART{}'s with a rescaleFactor set to any value other than 1.25, but that is simple math (1 divided by rescaleFactor). Allowing Position and Rotation defaults seems to work fine, but I'm going to play with some test cases to find out if there are situations these need to be set to ensure 1-to-1 conversion.

Thank you both for helping out here in the addon development subforums! I'm sure I'm not the only one flailing around in the pool.

[MisterFister]

I'm not sure if you're trying to accomplish your project a certain way in terms of folder structure, but what about keeping the endemic "mesh =" format and just renaming the mesh files so they're unique and able to be consolidated in the same folder with no conflicts? I still don't think I'll quite understand why almost all parts, even tock squad parts, ALL use the part.cfg / model.mu filenaming scheme, except to artificially necessitate subfolders. I understand that having subfolders has some advantages, and that artifically necessitating the use of repetitive subfolders is one way to realize such advantages; I just can't imagine that the advantages are so monumental, or so impossible by alternate means. (I recognize that modding is made easier by grouping modpaks into their own folders, I speak only of the enforced need to nest folders and subfolders within each modpak on pretty much a per-part basis.

[JumpsterG]

The idea is that I want to leave all resources where they are in whatever folder structure was designed by the mod maker. This way, if a plugin or a welded part or something refers to that location, the file and folder structure will be there. I also suspect it would be an additional headache to track those renamed resources in addition to the part data I'm already moving around.

Mod makers have options now, but still tend toward putting each part and its resources into its own folder, which is a neat and tidy way of doing things. Otherwise, everything needs to be named uniquely, which I bet can actually get annoying. Standards are also nice, as everyone can more easily recognize what is going on with a group of files. Consider the filename: "starmaker.cfg". It's not clear what's in there. It could be a single part, it could contain multiple PART{} nodes, it could contain resource definitions, or it could be a .cfg used by a plugin and not by KSP. Naming it "part.cfg" is surprisingly LESS ambiguous than uniquely naming it. Model files might be a different story, but I think the same applies.

I'm happy to say, I'm passed the hurdle of this thread. Parts are now working while placed in the unique sorting folder structure, separate from their resources. I'm coding the management side of things now, and hope to have something usable posted before Christmas.