Need a tiny bit of help getting started

[Stone Blue]

re-read my post, as you ninja'd my edit

Try loading a different .fbx file from Blender... make sure its a very simple model...like a small fuel tank or something... No windows, no lights, no animations, no AIRLOCKS or LADDERS, like the part in your screen shot...

Edited August 4, 2016 by Stone Blue

[Tokamak]

2 hours ago, Stone Blue said:

re-read my post, as you ninja'd my edit

Try loading a different .fbx file from Blender... make sure its a very simple model...like a small fuel tank or something... No windows, no lights, no animations, no AIRLOCKS or LADDERS, like the part in your screen shot...

I apologize for being thick, but I'm missing something, I think. I'm not sure how that helps me with the problem that the KSP part tools just plain aren't working in Unity for me, even before I get to the point of trying to import a part. The tool window itself is empty, and throwing exceptions like crazy. 

[Randazzo]

4 hours ago, Tokamak said:

I apologize for being thick, but I'm missing something, I think. I'm not sure how that helps me with the problem that the KSP part tools just plain aren't working in Unity for me, even before I get to the point of trying to import a part. The tool window itself is empty, and throwing exceptions like crazy. 

I made this with Unity 5 this morning, perhaps it will help clarify things. Sorry about the audio quality, I only had time to record it once.

 

[Stone Blue]

5 hours ago, Tokamak said:

I apologize for being thick, but I'm missing something, I think. I'm not sure how that helps me with the problem that the KSP part tools just plain aren't working in Unity for me, even before I get to the point of trying to import a part. The tool window itself is empty, and throwing exceptions like crazy. 

Ahhh... OK... I thought you were getting exceptions AFTER loading parts in Unity... I guess wht I was saying, is that when you DO start loading parts, load up something VERY basic at first, to help determine whether its just something with the part itself, or Part Tools...

 

Edited August 4, 2016 by Stone Blue

[Stone Blue]

@Randazzo AWESOME video... Wish that was around a few months ago...

Thats the best, shortest, clearest, actually up-to-date instructions for this I've seen...

Any chance you could throw it up on its own thread, similar to the stickied thread ? Then I could pester the forum mods to use it to REPLACE the stickied thread...

Edited August 4, 2016 by Stone Blue

[Randazzo]

15 minutes ago, Stone Blue said:

@Randazzo AWESOME video... Wish that was around a few months ago...

Thats the best, shortest, clearest, actually up-to-date instructions for this I've seen...

Any chance you could throw it up on its own thread, similar to the stickied thread ? Then I could pester the forum mods to use it to REPLACE the stickied thread...

Done. Might be easier just to link to it in that thread though.

[Tokamak]

6 hours ago, Randazzo said:

I made this with Unity 5 this morning, perhaps it will help clarify things. Sorry about the audio quality, I only had time to record it once.

 

Dingdingding! Thank you so very much! I see what I was doing wrong. Somehow I missed the idea that I had to apply the part tools to a game object. I think I was thinking of them more in terms of being like a Photoshop plugin, than as being a thing applies to the specific project.

 

When I started this thread, I was hoping for a few pointers. I didn't expect people to type out long instructions on their phones, or make videos. @.@ Learning to do this stuff is an uphill battle through bad or incomplete documentation... but you guys are amazingly helpful

Woooo! It worked!

 

Well, I say "worked"... once the part is in KSP, it is invisible, and the nodes are messed up, but I can poke around and figure out what I messed up. It is a thing that exists in KSP and doesn't crash the game, which is a breakthrough

[NecroBones]

On 8/3/2016 at 3:48 PM, Randazzo said:

Unity 5 is really only an absolute requirement if you're creating parts that need the asset bundles (KSPedia and who knows what else), or wheels or landing legs. For Engines it's more convenient for me to use 4.2.2 for emissives and such.

 

 

Correction: Landing legs made in 4.2.2 work just fine (probably wheels too, but I haven't tried them). However Unity 5 is needed if you want to import the newer "internal" assets for making IVAs or make use of the new IVA shaders.

 

[Stone Blue]

55 minutes ago, Tokamak said:

Well, I say "worked"... once the part is in KSP, it is invisible, and the nodes are messed up, but I can poke around and figure out what I messed up. It is a thing that exists in KSP and doesn't crash the game, which is a breakthrough

Try to zoom in on the center of where the part would be... If you have to, try to launch it in the flight screen... You can zoom in closer in the flight screen, than in the VAB/SPH...

My 1st guess would be a scale discrepancy in Unity... I still dont understand it fully, but most of the time, when I export .fbx from Blender, into Unity, the scale is off on the top object by 100x... Scale being 100, instead of 1... Hence, your part (just the model), is 100 times smaller than the size its supposed to be, in KSP....(the nodes will show, as they are defined in the .cfg, separate from the model)... So its THERE, its just so small you cant see it...

Dont touch the scale... just create an empty Game Object, then use that to parent your model's hierarchy...

Edited August 4, 2016 by Stone Blue

[Tokamak]

1 hour ago, Stone Blue said:

Try to zoom in on the center of where the part would be... If you have to, try to launch it in the flight screen... You can zoom in closer in the flight screen, than in the VAB/SPH...

My 1st guess would be a scale discrepancy in Unity... I still dont understand it fully, but most of the time, when I export .fbx from Blender, into Unity, the scale is off on the top object by 100x... Scale being 100, instead of 1... Hence, your part (just the model), is 100 times smaller than the size its supposed to be, in KSP....(the nodes will show, as they are defined in the .cfg, separate from the model)... So its THERE, its just so small you cant see it...

Dont touch the scale... just create an empty Game Object, then use that to parent your model's hierarchy...

Noted for future. In this case I didn't even troubleshoot it, because it was a garbage model anyway. I tried again with a better model that I grabbed from somewhere, and it worked like a charm. The collider mesh is borked. The part can't be selected once it's placed, and falls through the ground. I'll poke at that before I ask for help. It's probably something goofy I did when rushing through. Still... I can take a thing from blender, through unity, and into KSP and have it exist in the game and not crash the game. That is HUGE. Everything else is just details.

 

Excite excite excite!

 

Edit: Collider issue resolved. I was trying to just use a copy of the part mesh as my collision mesh (performance be damned, I'm testing) but it was very much not convex. Herpb derp.

Edited August 4, 2016 by Tokamak

[Van Disaster]

On 03/08/2016 at 9:49 PM, Tokamak said:

I notice that in every working part I import into blender to look at, there is a very specific scene structure, with "GameObject" at the root, and other elements nested with standard seeming names. Is this:

A) Just good practice, not required by KSP

B) An organizational structure required by KSP for it to use the part

C) Something that parttools will take care of for me so I should not worry about it

 

You should read the Unity manual entries on GameObjects. TBH you should probably read the Unity manual entries on all the basics, it doesn't take that long to digest.

Yes, that is the right version of the manual despite it declaring itself outdated.

[TiktaalikDreaming]

On 8/1/2016 at 11:08 PM, NecroBones said:

The "@PART[partname]" is for modifying an existing part, but this is all about a new part. I've never tried using MM "NEEDS" conditions on a straight add like that, but it should work. Also doable, is to copy an existing part, like:

+PART[oldPartName]:NEEDS[something]
{
    name = newPartName
    // and whatever other changes are needed can follow here
}
 

I know you've moved on, as I read through the remainder of the topic, but...

Actually, before the but, this is a thread that will remind most modders of how they started out.  Which makes it a useful thread for any starting modder.  And several people have volunteered some really good info.

Back to the but.

The MM config @PART... (as @NecroBones rightly says) is clearly for editing a part.  Just for the record, if you're going to make a copy of a part, the easiest way to start is by copying everything and just changing the part name in the regular, non-MM cfg file.  Then you should have a duplicate part.  And then you can start messing with it from there.  No need to mess with MM directives like @ and ! etc.  If you want to delete a module, just delete it.  By making the part's cfg file MM based, it's now dependent on the old part existing.

[Tokamak]

8 hours ago, TiktaalikDreaming said:

I know you've moved on, as I read through the remainder of the topic, but...

Actually, before the but, this is a thread that will remind most modders of how they started out.  Which makes it a useful thread for any starting modder.  And several people have volunteered some really good info.

Back to the but.

The MM config @PART... (as @NecroBones rightly says) is clearly for editing a part.  Just for the record, if you're going to make a copy of a part, the easiest way to start is by copying everything and just changing the part name in the regular, non-MM cfg file.  Then you should have a duplicate part.  And then you can start messing with it from there.  No need to mess with MM directives like @ and ! etc.  If you want to delete a module, just delete it.  By making the part's cfg file MM based, it's now dependent on the old part existing.

Yeah. My original thought had been to use that to create an alternate version of a part, with just some features changed. Regardless of whether or not that was a good idea, it's useful to call out to people finding this thread in the future that you can't do that

[Tokamak]

17 hours ago, Van Disaster said:

You should read the Unity manual entries on GameObjects. TBH you should probably read the Unity manual entries on all the basics, it doesn't take that long to digest.

Yes, that is the right version of the manual despite it declaring itself outdated.

That is a good wisdom. I apparently had some basic misapprehensions about how things were structured that that cleared up.

[Tokamak]

Dumb question... I've gotten the hang of UV unwrapping. However, say I have a part with a texture that is kind of meh, but good enough to use as a base, but the UV map is not sane. Perhaps because it re-uses sections it shouldn't, so AO baking won't work properly, or just because my part was part of a larger model, with a big texture.

Is there a way I can... not sure how to put this (which is why google hasn't been helpful) "re-wrap" it? In other words, can I have Blender take the mesh I am using, redo the UV map to something sane, AND give me a new texture file such that the model will look the same as it did before the process? 

If that is confusingly phrased, I can make a diagram.

Unrelated question: What is a reasonably poly count for a part? For an IVA? I've been looking at existing ones, and different modders seem to have... different ideas about that XD

[Randazzo]

@Tokamak 99.8% sure Blender does not have that functionality. You can certainly unwrap your part again in a different way, but I don't know of any software that can disassemble and put a texture back together after the UV map changes.

 

If such a thing exists, I sure wish I had found it a year ago.

[Tokamak]

4 minutes ago, Randazzo said:

@Tokamak 99.8% sure Blender does not have that functionality. You can certainly unwrap your part again in a different way, but I don't know of any software that can disassemble and put a texture back together after the UV map changes.

 

If such a thing exists, I sure wish I had found it a year ago.

Didn't think so, but I thought it was worth asking.

I'm also playing with IVAs, now that I've opened the pandora's box of blender and unity. It'd probably be best to start with editing existing IVAs and change them, so I have a working base. Obviously I can just edit any old one, but if it doesn't have a permissive license, then if I DO end up making something that I like, releasing it would be problematic. I've found some that have appropriate licenses and/or I've gotten permission, but if anyone has any good suggestions, I'm open

[TiktaalikDreaming]

1 hour ago, Tokamak said:

Unrelated question: What is a reasonably poly count for a part? For an IVA? I've been looking at existing ones, and different modders seem to have... different ideas about that XD

Acceptable poly counts for parts depends on how much work you want people's GPUs to be doing, and that's not normally a big issue for KSP.  So you can actually scale up poly counts quite a bit from stock parts with no noticeable difference in performance.  BUT, this is dependent on the type of PC running KSP.  If you end up with large poly counts, then laptop users and people running on integrated graphics will tend to have things slow down.  I've got parts with 40,000+ polygons (a V-2 engine, it's got nightmarish plumbing) that don't seem to slow anything down.

Now, the second "but".  Collision meshes.  KSP's physics mostly works on the collision meshes.  Make those as simple as you can.  Adding complexity to the collision meshes can make huge differences in game performance.  Where possible use the sphere, capsule, and box colliders built into Unity as well.  The same thing goes for "Part Triggers" type colliders, airlocks, ladders and so on.

Keep the physics simple, and you can go nuts on the poly count without really affecting game performance.  Up to a point.  I've found high detail Blender models on the Internet that pretty much make Unity crash, or think so long I wish it'd just crash.  Those were all in the multiple million poly size.

[Tokamak]

20 minutes ago, TiktaalikDreaming said:

Acceptable poly counts for parts depends on how much work you want people's GPUs to be doing, and that's not normally a big issue for KSP.  So you can actually scale up poly counts quite a bit from stock parts with no noticeable difference in performance.  BUT, this is dependent on the type of PC running KSP.  If you end up with large poly counts, then laptop users and people running on integrated graphics will tend to have things slow down.  I've got parts with 40,000+ polygons (a V-2 engine, it's got nightmarish plumbing) that don't seem to slow anything down.

Now, the second "but".  Collision meshes.  KSP's physics mostly works on the collision meshes.  Make those as simple as you can.  Adding complexity to the collision meshes can make huge differences in game performance.  Where possible use the sphere, capsule, and box colliders built into Unity as well.  The same thing goes for "Part Triggers" type colliders, airlocks, ladders and so on.

Keep the physics simple, and you can go nuts on the poly count without really affecting game performance.  Up to a point.  I've found high detail Blender models on the Internet that pretty much make Unity crash, or think so long I wish it'd just crash.  Those were all in the multiple million poly size.

Aaah, that makes sense. I've noticed that some complex parts do make KSP get choppy, but that would be the colliders, since those are the bits that make the CPU chew on physics, whereas just drawing shaded polys is what GPUs are for. Gotcha 

Addendum to my earlier question: I assume that taking a Squad asset, like an IVA, and modifying it for re-release, even as a kerbal mod, is not kosher?

[TiktaalikDreaming]

4 minutes ago, Tokamak said:

Aaah, that makes sense. I've noticed that some complex parts do make KSP get choppy, but that would be the colliders, since those are the bits that make the CPU chew on physics, whereas just drawing shaded polys is what GPUs are for. Gotcha 

The other thing to watch for is the texture load.  Any texture maps get loaded up into RAM, which increases how much RAM KSP uses.  Less of an issue now that 64bit works again.  But still best not to over-do it.  :-)

[Tokamak]

3 minutes ago, TiktaalikDreaming said:

The other thing to watch for is the texture load.  Any texture maps get loaded up into RAM, which increases how much RAM KSP uses.  Less of an issue now that 64bit works again.  But still best not to over-do it.  :-)

Aww, no full-res gigapixel images from NASA?

Edited August 5, 2016 by Tokamak

[TiktaalikDreaming]

1 minute ago, Tokamak said:

Aww, no full-res gigapixel images from NASA?

Only for those users that can load all the gigapixel images into RAM at once while still having the base KSP loaded into RAM.  :-)   I have a dodgy laptop I test things on so I don't get too complacent with my main PC and it's 16G RAM and fancy graphics card.  Still, there's something to be said for releasing 2 versions of mods, one with full rez and one at sane rez.  Unity has a very easy image rescale option in the texture management area.  As does the KSP DDS converter.

[Tokamak]

1 minute ago, TiktaalikDreaming said:

Only for those users that can load all the gigapixel images into RAM at once while still having the base KSP loaded into RAM.  :-)   I have a dodgy laptop I test things on so I don't get too complacent with my main PC and it's 16G RAM and fancy graphics card.  Still, there's something to be said for releasing 2 versions of mods, one with full rez and one at sane rez.  Unity has a very easy image rescale option in the texture management area.  As does the KSP DDS converter.

Makes sense. Though one thing I've noted is that crisp, high-res textures really clash with stock parts. So that works well anyway

[Tokamak]

Once again, information seems to conflict. Some tutorials say that when I set parttools's GameData folder, it should be a new folder where I want to dump things that I export from Unity. But others say I should set it to the actual location of my KSP development install's GameData folder.

If I do the former, and just make my own folder, then PartTools detects no spaces or props, so I can't do much for creating an IVA.

If I do the latter, and point it to the actual GameData folder I am using for development, then PartTools throws exceptions like crazy, and stops functioning.

Examples:

Config in file 'C:\Program Files (x86)\Steam\steamapps\common\Kerbal testbed\GameData\TweakScale\patches\Squad_TweakScale.cfg' contains no data.
UnityEngine.Debug:LogWarning(Object)
UrlConfig:CreateNodeList(UrlDir, UrlFile)
UrlFile:.ctor(UrlDir, FileInfo)
UrlDir:Create(UrlDir, DirectoryInfo)
UrlDir:.ctor(UrlDir, DirectoryInfo)
UrlDir:Create(UrlDir, DirectoryInfo)
UrlDir:.ctor(UrlDir, DirectoryInfo)
UrlDir:Create(UrlDir, DirectoryInfo)
UrlDir:.ctor(UrlDir, ConfigDirectory)
UrlDir:.ctor(ConfigDirectory[], ConfigFileType[])
KSPPartTools.GameDatabase:LoadDataDirectory()
KSPPartTools.GameDatabase:SetDataDirectory(String)
KSPPartTools.GameDatabase:set_GameDataDirectory(String)
KSPPartTools.PartToolsWindow:DrawGameDatabaseSetup()
KSPPartTools.PartToolsWindow:OnGUI()
UnityEditor.DockArea:OnGUI()
 

 

and:

NullReferenceException: Object reference not set to an instance of an object
UrlDir+<get_AllConfigs>d__53.MoveNext ()
UrlDir+<GetConfigs>d__55.MoveNext ()
System.Collections.Generic.List`1[UrlDir+UrlConfig].AddEnumerable (IEnumerable`1 enumerable) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:128)
System.Collections.Generic.List`1[UrlDir+UrlConfig]..ctor (IEnumerable`1 collection) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:65)
KSPPartTools.GameDatabase.GetConfigs (System.String typeName)
KSPPartTools.PartToolsWindow.DrawSpaces ()
KSPPartTools.PartToolsWindow.OnGUI ()
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)
 

 

Is the correct answer just to do neither, and make my own GameData folder for Unity, and throw a copy of the Squad folder in there?

 

 

[TiktaalikDreaming]

2 hours ago, Tokamak said:

Once again, information seems to conflict. Some tutorials say that when I set parttools's GameData folder, it should be a new folder where I want to dump things that I export from Unity. But others say I should set it to the actual location of my KSP development install's GameData folder.

If I do the former, and just make my own folder, then PartTools detects no spaces or props, so I can't do much for creating an IVA.

If I do the latter, and point it to the actual GameData folder I am using for development, then PartTools throws exceptions like crazy, and stops functioning.

Examples:

Config in file 'C:\Program Files (x86)\Steam\steamapps\common\Kerbal testbed\GameData\TweakScale\patches\Squad_TweakScale.cfg' contains no data.
UnityEngine.Debug:LogWarning(Object)
UrlConfig:CreateNodeList(UrlDir, UrlFile)
UrlFile:.ctor(UrlDir, FileInfo)
UrlDir:Create(UrlDir, DirectoryInfo)
UrlDir:.ctor(UrlDir, DirectoryInfo)
UrlDir:Create(UrlDir, DirectoryInfo)
UrlDir:.ctor(UrlDir, DirectoryInfo)
UrlDir:Create(UrlDir, DirectoryInfo)
UrlDir:.ctor(UrlDir, ConfigDirectory)
UrlDir:.ctor(ConfigDirectory[], ConfigFileType[])
KSPPartTools.GameDatabase:LoadDataDirectory()
KSPPartTools.GameDatabase:SetDataDirectory(String)
KSPPartTools.GameDatabase:set_GameDataDirectory(String)
KSPPartTools.PartToolsWindow:DrawGameDatabaseSetup()
KSPPartTools.PartToolsWindow:OnGUI()
UnityEditor.DockArea:OnGUI()
 

 

and:

NullReferenceException: Object reference not set to an instance of an object
UrlDir+<get_AllConfigs>d__53.MoveNext ()
UrlDir+<GetConfigs>d__55.MoveNext ()
System.Collections.Generic.List`1[UrlDir+UrlConfig].AddEnumerable (IEnumerable`1 enumerable) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:128)
System.Collections.Generic.List`1[UrlDir+UrlConfig]..ctor (IEnumerable`1 collection) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:65)
KSPPartTools.GameDatabase.GetConfigs (System.String typeName)
KSPPartTools.PartToolsWindow.DrawSpaces ()
KSPPartTools.PartToolsWindow.OnGUI ()
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)
 

 

Is the correct answer just to do neither, and make my own GameData folder for Unity, and throw a copy of the Squad folder in there?

 

 

I normally use a mod-light dev install of KSP.  AKA KSP without much mod.  I actually use my base Steam install, as it forces me to update things fairly quickly.  :-)  If the exceptions aren't stopping anything, then just ignore them.  The first blob looks to be regarding tweak scale, and I'd lay odds that it just won't matter.

So, basically you've highlighted the reasons for pointing PartTools at an active KSP GameData.  It needs that to see assets like the IVA props.  I'd assume it's the same for the packaged UI elements introduced in 1.1 that no-one uses (as in, modders, and mostly, OK I haven't touched them).  Like the KSPedia stuff.

But you *could* create a fresh folder, and maybe just copy in elements you want to use.  But then there's a lot of messing around when you get to testing as well.