Need some basic parts help

[vossiewulf]

Sigh. Well it fixed the first one, the rest continue to do the same thing. Which makes zero sense considering I triple-checked every Box0XX number to make sure the config of each part had the right value. But now the first fin throws no errors and works correctly, moving and controlling flight. All the rest are still throwing that same error even though all their configs have been updated in the same way as the first one. I'm poking at it but completely confused... again.

[Mecripp]

15 minutes ago, vossiewulf said:

Sigh. Well it fixed the first one, the rest continue to do the same thing. Which makes zero sense considering I triple-checked every Box0XX number to make sure the config of each part had the right value. But now the first fin throws no errors and works correctly, moving and controlling flight. All the rest are still throwing that same error even though all their configs have been updated in the same way as the first one. I'm poking at it but completely confused... again.

where they throwing them to start with also ?

 

[vossiewulf]

As far as I know they were throwing them before, but am not 100% sure. See below, the one with Box008 works, the one with Box005 doesn't. Even though I've confirmed that's the correct mesh name in MAX, Substance Painter, and Unity. It makes no sense.

MODULE
	{
		name = ModuleControlSurface
		useInternalDragModel = True
		dragCoeff = 0.4
		deflectionLiftCoeff = 0.75		// 2.18m^2
		ctrlSurfaceRange = 25
		ctrlSurfaceArea = 1.5
		actuatorSpeed = 25
		transformName = Box008
	}

MODULE
	{
		name = ModuleControlSurface
		useInternalDragModel = True
		dragCoeff = 0.4
		deflectionLiftCoeff = 0.75		// 2.18m^2
		ctrlSurfaceRange = 25
		ctrlSurfaceArea = 1.5
		actuatorSpeed = 25
		transformName = Box005
	}

 

[Mecripp]

9 minutes ago, vossiewulf said:

As far as I know they were throwing them before, but am not 100% sure. See below, the one with Box008 works, the one with Box005 doesn't. Even though I've confirmed that's the correct mesh name in MAX, Substance Painter, and Unity. It makes no sense.

MODULE
	{
		name = ModuleControlSurface
		useInternalDragModel = True
		dragCoeff = 0.4
		deflectionLiftCoeff = 0.75		// 2.18m^2
		ctrlSurfaceRange = 25
		ctrlSurfaceArea = 1.5
		actuatorSpeed = 25
		transformName = Box008
	}

MODULE
	{
		name = ModuleControlSurface
		useInternalDragModel = True
		dragCoeff = 0.4
		deflectionLiftCoeff = 0.75		// 2.18m^2
		ctrlSurfaceRange = 25
		ctrlSurfaceArea = 1.5
		actuatorSpeed = 25
		transformName = Box005
	}

 

Looking at anther mod some have that the cfg just has this 

	MODULE
	{
		name = ModuleLiftingSurface
		useInternalDragModel = True
		deflectionLiftCoeff = 0.05
		dragAtMaxAoA = 0.12
		dragAtMinAoA = 0.0
	}

EDIT- and the only thing there changing is 

deflectionLiftCoeff = 0.25

	MODULE
	{
		name = ModuleControlSurface
		useInternalDragModel = True
		dragCoeff = 0.33
		deflectionLiftCoeff = 0.35
		ctrlSurfaceRange = 20
		ctrlSurfaceArea = 1.0
		actuatorSpeed = 30
		transformName = ctrlSrf  ( more then likely thats what they named it )
	}

 

Edited September 24, 2018 by Mecripp

[vossiewulf]

That's a little different though as that's a wing and not a control surface  But good idea for me to go look at more configs.

Yeah, whatever is making the first one work isn't that field. This is the section from the Squad Delta Deluxe Winglet:

MODULE
	{
		name = ModuleControlSurface
		useInternalDragModel = True
		dragCoeff = 0.6
		deflectionLiftCoeff = 0.65
		ctrlSurfaceRange = 25
		ctrlSurfaceArea = 0.2
		actuatorSpeed = 25
	}

I'd say the S2000 was working before and I didn't notice, but that doesn't make much sense either as I just tested it yesterday, but that's only thing that fits the facts.

 

[vossiewulf]

Diffing the config files shows only difference being things that shouldn't make a difference. 

It's complaining about the COM (Center of Mass in this case). Is that relative to the transform center set for the object in the modeler? I ask because I set all of them right on the edge of the parts so the attachment points would be exactly where I want them. But I'm wondering if the game is using that and is seeing some of them as outside the shape, and maybe I need to move those back to be sure the game reads those points as being within the object and not outside. Will try that next.

[Mecripp]

35 minutes ago, vossiewulf said:

Diffing the config files shows only difference being things that shouldn't make a difference. 

It's complaining about the COM (Center of Mass in this case). Is that relative to the transform center set for the object in the modeler? I ask because I set all of them right on the edge of the parts so the attachment points would be exactly where I want them. But I'm wondering if the game is using that and is seeing some of them as outside the shape, and maybe I need to move those back to be sure the game reads those points as being within the object and not outside. Will try that next.

sounds like you might be on to something there well there is one way to see 

[Mecripp]

On ‎9‎/‎23‎/‎2018 at 9:39 PM, vossiewulf said:

As far as I know they were throwing them before, but am not 100% sure. See below, the one with Box008 works, the one with Box005 doesn't. Even though I've confirmed that's the correct mesh name in MAX, Substance Painter, and Unity. It makes no sense.

MODULE
	{
		name = ModuleControlSurface
		useInternalDragModel = True
		dragCoeff = 0.4
		deflectionLiftCoeff = 0.75		// 2.18m^2
		ctrlSurfaceRange = 25
		ctrlSurfaceArea = 1.5
		actuatorSpeed = 25
		transformName = Box008
	}

MODULE
	{
		name = ModuleControlSurface
		useInternalDragModel = True
		dragCoeff = 0.4
		deflectionLiftCoeff = 0.75		// 2.18m^2
		ctrlSurfaceRange = 25
		ctrlSurfaceArea = 1.5
		actuatorSpeed = 25
		transformName = Box005
	}

 

Maybe @blackheart612 can help and know what to do ?

[vossiewulf]

My guess on the transform center and the CoM didn't pan out. I'm still clueless as to how one can be throwing errors and the other not with basically identical configs and models built the same way and passed down the same workflow to get to a game part.

[vossiewulf]

More news: it doesn't have anything to do with the config (!?!). I just copied the config of the one that doesn't throw errors verbatim into the config of one of the parts throwing errors, and it still threw the same cacophony of noise in the logs. So now the question would be what can be wrong with part tools output that would cause a control surface to throw these errors?

    [EXC 23:56:33.532] NullReferenceException: Object reference not set to an instance of an object
    ModuleControlSurface.CtrlSurfaceEditorUpdate (Vector3 CoM)
    ModuleControlSurface.LateUpdate ()

Edited September 25, 2018 by vossiewulf

[blackheart612]

I couldn't understand what's going on despite reading back, but NREs usually are because of wrong naming if I remember right.

Few points, first, make sure you actually exported properly - see if the .mu is modified to your latest export. Gets me everytime.

Second, on surfaces? I think it's what you're trying to build?
ModuleControlSurface transformName is case sensitive and needs the correct name, I assume you know this already, just to point out. You could alternatively just not use transformName = and just use obj_ctrlSrf. If I actually capitalized it correctly. (I don't use transformName on AirplanePlus most of the time, if not ever.)

Third, outside of config, the orientation and naming of the Control Surface in Unity is of course important, though unknowingly, the parent of the mesh usually messes things up too. If your hierarchy is Exporter > Holder > Mesh, you could try making it directly under the exporter (Exporter > Mesh). This actually causes the it's basically the same but it's not working issue, the parent isn't usually mentioned as an essential.

If you could simplify your problem for my small mind to understand, I'll try to help. Your unity hierarchy and orientations posted here will probably help too. I just got back from a lengthy slumber from the forums so I don't know if I can help properly.

[vossiewulf]

13 hours ago, blackheart612 said:

I couldn't understand what's going on despite reading back, but NREs usually are because of wrong naming if I remember right.

Few points, first, make sure you actually exported properly - see if the .mu is modified to your latest export. Gets me everytime.

Second, on surfaces? I think it's what you're trying to build?
ModuleControlSurface transformName is case sensitive and needs the correct name, I assume you know this already, just to point out. You could alternatively just not use transformName = and just use obj_ctrlSrf. If I actually capitalized it correctly. (I don't use transformName on AirplanePlus most of the time, if not ever.)

Third, outside of config, the orientation and naming of the Control Surface in Unity is of course important, though unknowingly, the parent of the mesh usually messes things up too. If your hierarchy is Exporter > Holder > Mesh, you could try making it directly under the exporter (Exporter > Mesh). This actually causes the it's basically the same but it's not working issue, the parent isn't usually mentioned as an essential.

If you could simplify your problem for my small mind to understand, I'll try to help. Your unity hierarchy and orientations posted here will probably help too. I just got back from a lengthy slumber from the forums so I don't know if I can help properly.

Blackheart, see below, Shadowmage figured the problem out. My request below has been overtaken by events, good ones. Thanks for stopping in and offering to help, it's much appreciated.

Thanks for looking into this, I am walking clueless through a valley filled with mines and half of them don't make a sound when they go off.

I have 18 fins I made to provide players more options. Of the 18, the first one works fine and throws no errors. Although I haven't checked every one of the remaining 17, every one that I have checked is spamming the NRE in the KSP.log:

  [EXC 23:56:33.532] NullReferenceException: Object reference not set to an instance of an object
    ModuleControlSurface.CtrlSurfaceEditorUpdate (Vector3 CoM)
    ModuleControlSurface.LateUpdate ()

I've added the line transformName = <meshname> to all of them at @Mecripp's suggestion, that probably was what made the first one now work properly. However, the rest are still spamming errors despite having that NVP present with correct case-sensitive values:

E.G., transformName = Box005

Experimenting with one of them, I triple confirmed the mesh name in MAX, Substance Painter, and Unity as that's the workflow order I'm using. I've copied the name straight from what Unity said the mesh name was but I am still getting the same errors on all parts but the first one. Just to be certain, I copied the config of the one that's working verbatim into the config of a part that's not working, and then only changed the transformName to the correct value so that when I run a diff that's the only difference, and yet I still get the CoM error spam.

I'll try some of your suggestions later, but that's as clear as I can be about the problem I'm seeing. Thanks very much for looking into it, it is greatly appreciated!

Edited September 25, 2018 by vossiewulf

[vossiewulf]

@Shadowmage figured it out. @Mecripp you were very close to being a genius  You had the right thing to add, but the value was wrong, what needs to be there is the model name from Unity, not the mesh object name. So for like the second fin, it's FT_Fin_02. Adding this line stops the error spam so now I can fix all  the configs, thanks everyone for the help!

[Mecripp]

2 hours ago, vossiewulf said:

@Shadowmage figured it out. @Mecripp you were very close to being a genius  You had the right thing to add, but the value was wrong, what needs to be there is the model name from Unity, not the mesh object name. So for like the second fin, it's FT_Fin_02. Adding this line stops the error spam so now I can fix all  the configs, thanks everyone for the help!

Well sometimes a kerbal falls just short

[vossiewulf]

No errors, went through and set correct masses and control surface areas based on relative sizes (calculated, not pulling out of air) and have the TU config working. Sweet jesus I think I'm reaching the far side of the quagmire

 

Look MA, normal maps working! Adding panel lines and ports and things!

 

Edited September 26, 2018 by vossiewulf

[Mecripp]

38 minutes ago, vossiewulf said:

 

 

 

 

These look like air show 

[vossiewulf]

On 9/25/2018 at 7:47 PM, Mecripp said:

These look like air show 

You want airshow, we got airshow  In 9 different color combos! You should also be able to see that TU is working now, with reflections helping show off the normal map details of panel lines and ports.

[Mecripp]

5 hours ago, vossiewulf said:

You want airshow, we got airshow  In 9 different color combos! You should also be able to see that TU is working now, with reflections helping show off the normal map details of panel lines and ports.

How did you fix the normal map ? I have seen it come up some where  but couldn't found it again.

[vossiewulf]

Textures Unlimited makes the normal map work. The normal map channel is disabled by default in KSP, for reasons only they understand they use the Unity engine but they disable almost all of the features,  including normal maps and physics-based rendering (PBR). TU turns those features back on, so you can use PBR rendering with albedo, metal/smoothness, and normal map channels. You need something that will output those maps for you, I'm using Substance Painter for the texturing and to output correct Unity PBR maps.

[vossiewulf]

@Mecripp or @blackheart612, do you know what controls the axis of rotation for the control surface? I have fins moving in the wrong axis, but if I change the axes in Unity, all that happens is the fin tries to surface attach in the wrong orientation. So I'm wondering if there's a config that tells the control surface module which axis is active rotation.

[blackheart612]

Control surfaces turn on x axis, I think the forward is the arrow head in unity, so left and right is going to be based off that. It shouldn't affect attachment, I don't know why it would? There's no config regarding it as it's set to follow on the x axis in the classes or whatever makes ksp. Edit - x axis on unity.

Edited September 28, 2018 by blackheart612

[vossiewulf]

41 minutes ago, blackheart612 said:

Control surfaces turn on x axis, I think the forward is the arrow head in unity, so left and right is going to be based off that. It shouldn't affect attachment, I don't know why it would? There's no config regarding it as it's set to follow on the x axis in the classes or whatever makes ksp. Edit - x axis on unity.

Thanks. When I change the rotation in Unity, let's say 90 degrees in the Y axis, when I try to surface attach those parts they lay flat against the rocket. The only orientation I've found in Unity that makes them surface attach correctly is aligning them with the Z axis.

Also I have a new problem... there always seems to be a new problem.

Unity is breaking the normal maps, killing the blue channel and outputting a pink normal map if I click on the button that says something like this map needs to be marked as a normal map, with a button that says Fix Now. If I click on that, I get a semi-functional normal map that is pink. If I don't click on Fix Now, it outputs a normal map with the correct blue color space, but it has no data - it's totally flat.

What do I do to stop Unity from turning the maps pink and screwing them up?

Edited September 28, 2018 by vossiewulf

[sumghai]

[MOD - Moved to Add-on Development subforums, as that is the place to post mod development progress and ask modding questions.]

[wasml]

On 9/28/2018 at 12:50 AM, vossiewulf said:

when I try to surface attach those parts they lay flat against the rocket

The node_attach = XPos, YPos, Zpos, XDir, YDir, ZDir line in the config controls how surface attach works. Typically the one of XDir, YDir or ZDir is 1.0 and the others 0.0 - depending on which axis you want to attach on.

[vossiewulf]

7 hours ago, wasml said:

The node_attach = XPos, YPos, Zpos, XDir, YDir, ZDir line in the config controls how surface attach works. Typically the one of XDir, YDir or ZDir is 1.0 and the others 0.0 - depending on which axis you want to attach on.

Thanks, any and all explanations welcome at this point.

@Shadowmage helped me by getting one set up correctly so I could see and then I just had to repeat that 17 times. Sigh what idiot thought up this mod? Regardless, the good news is that I now have 17 fully functional fins and  just have to finalize the TU configs and decide whether I'm going to mess with the normal map problem anymore- Unity is outputting pink normal maps that aren't playing nice with TU, and I may just dump them unfortunately. 

Edited October 1, 2018 by vossiewulf