Prop config files

[nli2work]

is there a way to specify mesh for a prop in the prop config? like the way part config file works?

I tried "mesh =" line in the prop config, but that doesn't do anything. all different prop configs pull the same mesh.

Edited June 20, 2014 by nli2work

[Mihara]

Yes. The same way as you are supposed to do it in part configs these days, with model nodes:

	MODEL
	{
		model = Squad/Props/IndicatorPanel/model
		texture = model000,JSI/RasterPropMonitor/Library/Props/IndicatorPanelReplacement/model000
		texture = model001,JSI/RasterPropMonitor/Library/Props/IndicatorPanelReplacement/model001
	}

where 'model' is the full path to the model file, no extension, 'texture' is <texture name embedded in the model>,<full path to the texture to substitute'>. There's also position, scale and rotation, but you are unlikely to want those with props -- they most likely work there too. The only required variable is the 'model' as far as I can tell -- i.e. if the model is kept in the same directory with it's textures like it usually is, when you reference the model, it will pull the textures in.

Search the forum for 'model nodes' and 'part welding', which is one practical application of same. Everything said about model nodes in relation to part welding will also apply to props.

[nli2work]

Thanks! This is exactly what I was looking for.

oops. spoke too soon.

The model code seems to be pointing to the folders... each individual prop still requires their own model, texture, and config files. I was hoping to share 1 texture between multiple prop models by atlasing the prop textures onto a big sheet. Creating individual folders for config and model file, and pointing texture path to a common location doesn't seem to work.

no biggie though. things to know about the pipeline for future references.

Edited June 20, 2014 by nli2work

[nli2work]

hm... it appears MODEL{} node requires dummy textures.

[Mihara]

hm... it appears MODEL{} node requires dummy textures.

Not the model node, but rather, the model itself. I.e. a model file will not load at all and will not appear in GameDatabase to be referenced by a MODEL node if the textures it links to (the actual names of the files can be seen amongst the binary data further towards the end) are not present in the same directory as that model file. Once the model file actually gets into memory and is listed by pathname in GameDatabase, you can override any texture.

The smallest size of texture KSP appears to correctly handle is 32x32 by the way.

[nli2work]

yeah, took a bit of experimenting, but it's working out now. good to know.

Odd way it works... dummy textures won't load into the database, but must be there for model to be able to pick up redirected texture. a 2nd set of real textures with same exact name will get loaded a 2nd time, even though the model is presumably using the 1st set from a different folder.

Edited July 6, 2014 by nli2work