lo-fi

Some screen grabs would be really helpful. Those components will have been added, or the model won't get rendered in Unity, but they are applied to each object in the model. The top level object may just be an empty object. Look in the console in Unity to see what gets logged as you export too.

Certainly some nice ideas there. Thanks! The odd looking wheel is probably the swing axle concept I made a while back. Glitchy textures are old dev models I've not bothered to texture. The medium wheel has been abused for a lot of things...

Even better, thank you

Brilliant!! That's a major bug to have ticked off the list. In the course of messing, I've also figured out why the RBI inverting track disappears sometimes. All good stuff! Should just be a config edit, SmashBrown. Change the kind that says advancedMotors to experimentalMotors. (I think that's right)

Got it. I'm sure KSP used to over-write the values set in Unity as I tried this before - they can be set in that component from the inspector - but doesn't seem to now. How strange. Anyway, the values are always ~10x out. We can force them in code if needed as they are setable. I think we might have a solution! EDIT: That's hilarious! Having fun?

The track surface has a component called SkinnedMeshrenderer which handles the dynamic animation of the track surface. The thing the caught my eye was "It is recomputed every time when updateWhenOffscreen is enabled, but in this case it would be exactly the size of the mesh at that frame." Promising... Testing now...

Wait a minute. Think I've got it: http://docs.unity3d.com/ScriptReference/SkinnedMeshRenderer-localBounds.html

I use VS 2012 Express. OK, I think you're onto something. print(_trackSurface.GetRendererBounds()); List<Bounds> bound = new List<Bounds>( part.GetRendererBounds()); for(int i = 0; i < bound.Count(); i++) print(bound[i]); yields this for the medium track (in KFTrackSurface): [LOG 16:26:06.030] Center: (-0.5, -1.3, -1.1), Extents: (3.8, 14.5, 4.6) [LOG 16:26:06.030] Center: (-0.8, 9.4, 0.1), Extents: (0.3, 0.3, 0.3) [LOG 16:26:06.031] Center: (-0.5, 9.4, 0.2), Extents: (0.1, 0.2, 0.2) [LOG 16:26:06.032] Center: (-0.8, 10.0, 0.1), Extents: (0.3, 0.3, 0.3) [LOG 16:26:06.032] Center: (-0.5, 10.0, 0.2), Extents: (0.1, 0.2, 0.2) [LOG 16:26:06.039] Center: (-0.8, 10.6, 0.1), Extents: (0.3, 0.3, 0.3) [LOG 16:26:06.040] Center: (-0.5, 10.6, 0.2), Extents: (0.1, 0.2, 0.2) [LOG 16:26:06.041] Center: (-0.4, 10.0, 0.3), Extents: (0.1, 1.3, 0.2) [LOG 16:26:06.042] Center: (-0.8, 8.9, 0.3), Extents: (0.3, 0.2, 0.2) [LOG 16:26:06.042] Center: (-0.8, 11.1, 0.3), Extents: (0.3, 0.2, 0.2) [LOG 16:26:06.043] Center: (-0.5, -1.3, -1.1), Extents: (3.8, 14.5, 4.6) But can they actually be set? If I'm reading it correctly, PartIconFixer uses calculated bounds to set some calculations up, but it doesn't actually attempt to pass the values back to the GO that got baked.

Actually, I've never tried compiling it! xEvilReeperx is and evil genius, that's why Certain things do work with later versions of .net, but not all. Hit and miss! Which IDE are you using?

Did you find where the actual size values are stored in the part prefab? I couldn't figure that out... Lots of other things, but not that!

OK, I've got a handle on the vessel size thing. See latest commit. Needs testing to make sure it's robust (it's truly game-breaking if we get it wrong as it won't let craft launch), but at least that's something. I know that incorrect values will occur if the tracks are attached, taken off, more parts added, then placed again. Have a look and see what you think, anyway. But at least that's some kind of progress on a nasty bug :/

Thanks *Aqua*. I made a little headway on the reported part sizes. I managed to grab a value for the size of the craft before the tracks are attached in OnAwake(), and was hoping to use this to pass to GetModuleSize(). However, the value gets cleared when the part is attached, presumably because an instance of the part prefab is instantiated when it's actually attached, or some some jiggery. (I was being an idiot) Annoyingly, if you just zero the craft size, two things happen: It won't launch because it says you need the size to be calculated, and the icon for the vessel in the load menu gets huge. This is actually quite good, as it tells me that this is governed by the reported craft size for that icon, rather than anything else. I was thinking of looking into the OnEditorAttach() method to see if I can grab a sensible pre-attach value there. but I've not got round to it yet. The other possibility is to make our own method for determining the craft size and passing that back to GetModuleSize, after zeroing the silly value it gets from the stock method. I don't know how hard this will be, though. I think it's probably about time for a release thread, yes. Granted, it does mean monitoring two threads, but lots of stuff gets buried quite quickly here.. I guess I'll go make one! The other thing that probably needs figuring out is whether to split the parts up into motive, structural and utility. Wheel, tracks, landing gear & legs and repulsors certainly live together as they share commong modules in the plugin. Rover bodies, rollcages, trailer hitches and other shenanigans I've got planned maybe do not. I'm favouring splitting in two, with the motive stuff and util/structural separate.

Some info here that may prove useful: http://forum.kerbalspaceprogram.com/threads/93417-Unity-Layers-and-Tags Would be worth going through again and starring a new thread, thinking about it. That info is a little old, and Spanner has not been seen for some time. I found NoAttach by recursing through a stock cargo bay and dumping the layer and tag info for each GO. If parts are selected carefully, a complete list may be possible

Very nice!

Yeah, it's getting a little out of hand, isn't it! Given the major changes, I'd like to keep the up coming release as beta - there will be bugs to iron out. Once that's settled, let's release at 2.0!

Good call, actually! Reading the thread would be quite a gargantuan task to be fair, and most of it is dev stuff that most won't necessarily be interested in. I'll do a little status update when I have a few minutes

I'm afraid KSP just doesn't support multiple materials on one mesh - sorry to be the bearer of bad news!

No drama, it's just you'll get more of the people who can probably help looking there I may be wrong and there is a BD issue with the part, but that's looking very unlikely.

Oh! Terminator!! Either half skin gone, or just machine. Or both..

How about a Mr T Kerbal? "Shut up, fool!" (At Jeb)

@SnowWhite, you might be best served posting a thread in the modelling sub forum as that's looking like a general part export issue unrelated to BD. The output from the Unity console at the bottom and an output_log from KSP would be really helpful too.

That's pretty much what the apu does controlling the engine and alternator. No idea what maths was with the consumption... Glad you're liking the sound!

Actually, I haven't messed with it. Is it any good?

Oh, I think it's been tweaked down in the latest config? Have to check that..

Yeah, pretty much! Two set of joints would be created and all hell would break loose... The size we're on about is just the reported size, not the actual size. The method used to keep track of it is a little crazy!