Tiberion

Part tools is actually designed for 4.2.2 (which is pretty old by this point) and you don't really benefit from newer ones strictly for part-making; it is in fact harder to use because of the changes to Unity's animation package.

First thing to try, exit the VAb to the space center, hit alt+f12 to open debug and go to the Database tab, hit reload; this will reload all assets (models, textures, config files) Then go back in and see if the pod loaded correctly; if it did then you're running into a KSP bug, I'm not sure if anyone ever figured out why certain parts got the no-tex bug. Next, a new screenshot of the part in Unity with the object holding the part tools script, and a fresh copy of your config for debugging. Can also zip up the part and link it and I can see if it loads here.

Alright, time for a test release. I made some adjusrtments to Isp and thrust levels for the launcher stuff, tweaked the wings some more and got a decent balance dialed in I think. You have to be pretty easy on the controls, if you get the nose too far from vertical below 20k or so it will not end well for you, so make your gravity turn s-l-o-w-l-y. Also the jet engines on the Intrepid are still too powerful and can get you a space-side Apoapsis going full burn after cruising at 22k or so, but I'll let you guys fly it a bit and give me some feedback how you think it should work. None of it is finalized by any means but it should all be functional. It's been months since the last update though, so report any bugs. All textures are converted to DDS. I removed the "cloned" decouplers and docking ports that where in the structures folder since they're no longer needed (you can hold down ALT to turn off surface-attaching to put decouplers in the cargobay and use tweakables for the rest. I also removed the tiny nubbin canard part since you don't need them anymore (YAY!) and added it back into the actual wing model as a leading edge. Obviously any old saves or crafts you had are likely broken now. https://dl.dropboxusercontent.com/u/46506740/TiberDyneShuttleFor_1_0_2_Test1.zip Commence the bughunt

never used cryoEngines, is the custom fuel setup to be less dense or something? I'm not sure I'd like the core stages to be 5m, it makes them harder to use as standalone launchers (the current 3.75m to 2.5m adapter wouldn't work. Something to examine anyway though. Right now I'm just working to get it ready to play as-is.

So, good news... Just took Intrepid on a 20 minute flight around KSC and it flew very nicely. The drag and lift conversion seems to have worked out; those engines and intakes are basically turbojet and the ramair intakes, and its enough to get it hypersonic. Definitely will take some engine balancing, but the airframe itself seems pretty nice; it doesn't even have the super-glide trouble since it doesn't use wingspam. So if I can get the cargobay working, I'll have solved all the technical challenges (I think)

I don't think the shuttle tiles were really considered "ablative" anyway, so not sure ablation would make sense in those parts.

As far as I know, there's no transform-lookup, it doesn't really care about the model (its shape will determine is drag cube of course, like all parts) its just "when temperature > X, use resource Y

You didn't accidentally revert to an older exported .mu file from Unity, with the wrong hierarchy? Reversion bugs like that are always sneaky. If your latest export and the correct config doesn't work, repost a screenshot from Unity and the config and we can look at it again.

Yeah if you don't create an anchor part, it'll just come off without leaving debris behind. You can also leave debris behind on stack decouplers if you wanted to.

Some will be both, it may overall be overpowered, but the parts are also larger and have more massive so its a bit subjective. You can always try it out

Hmm, a copy you say? that sounds like you have two parts with the same "name=whatever" in their respective configs; KSP will load them both but it will act weirdly (loading config settings from the wrong config, etc..) So thats the place to start

Ring shapes are very tricky; is it one part? How did you set up the collider for the part? If the collider is hollow/ring shaped too then it won't be a valid shape for PhysX and it'll bug out or just be ignored. Another issue could be where your parts origin point is; if its in the middle of the ring outside of the mesh and any colliders the game will not like that. A screenshot of your model in Unity, so we can see the setup will help us offer more advice. Also the config file as well.

Neither *must* have anything special in the model; for decouplers you can specify an object that stays on the part you decouple from as debris, but its not required. if you want the whole part to just detach like the stack decouplers do, you just need your model exported right The decouple module: MODULE { name = ModuleDecouple ejectionForce = 150 explosiveNodeID = top } explosiveNodeID lets you name which attachment node you decouple from when activates, in this case it's this one: node_stack_top = 0.0, 0.125, 0.0, 0.0, 1.0, 0.0 This is how all the stack decouplers work, the decoupler and everything attached to the bottom of it decoupler from whatever is attached to the top. For radial decouplers: MODULE { name = ModuleAnchoredDecoupler anchorName = anchor ejectionForce = -550 explosiveNodeID = srf } it'll be this: explosiveNodeID = srf Which means it breaks the connection that attached the decoupler part TO its parent part (say a decoupler to a fuel tank) but NOT any other parts surface-attached to it, or attached to any stack nodes if there are any. The anchorName is the name of the object in your model that should stay "attached" as debris when decoupled. For the stock radial decouplers, think of the little frame left on the tank; that's the anchor. Note that the anchor isn't persistent, if you save and load or swap far away, the debris will be despawned. That is the basics of the decouplers. I'll make another reply with some for heatshields. - - - Updated - - - Again there's nothing inside the model for heatshields, their function is all in the code and defined in the config. MODULE { name = ModuleAblator ablativeResource = Ablator lossExp = -9000 lossConst = 20 pyrolysisLossFactor = 10000 reentryConductivity = 0.01 ablationTempThresh = 500 } RESOURCE { name = Ablator amount = 200 maxAmount = 200 } and this line somewhere in the config: thermalMassModifier = 0.001 Someone else can give you better details on the math here, but the short version is: the MassModifer makes it easier for your shield to heat up, otherwise it heats too slowly to heat up thus reach the ablator threshold (500 degrees as set in the config above) - Once it reaches that it begins to use the Ablator resource and also begin dumping heat out of the part rather than to continue to heat up and pass it along up to whatever is being shielded. While the ablation is occurring, the game is using a "shader" to darken the texture on your part to mimic the burn marks, you don't need a special texture or animation for it, though you might be able to tweak it some to get it to look right (for instance, high specularity looks a bit odd when burnt) That should definitely get you started. Others can fill in more details. Edit: Fancy auto-merging of replies, its all one post now

For the FX, I used a third layer of empty objects to act as a spawn point for the FX (I call mine smokePoint) This is possible because you can specify a different transform in the Particle module than engine module. So I start thrustTransform and smokePoint in the same place and orientation (blue arrow pointing in the direction of thrust) and then move smokePoint where it needs to be to make the FX look right, typically just 'down' below the engine nozzle. Then you can leave fxOffset and rotation as 0 in the config, it really doesn't work that well.

Yeah I am working on it; back when the new mk3 parts came out I messed around with the idea of using them to make a new shuttle to go with the launcher parts. Might still do that. I have a lot of the game updates done, I really have the major things to tackle: Bodylift for the old fuselage parts New aero settings for the wingy bits Cargo-bay occlusion such that its an actual cargo bay So, we'll see how that goes.

The whole thing needs the bottom node fix so the parts snap together. The tanks should work otherwise. The engines will need adjusted for 1.0 to be right. As for the shuttle itself, it does indeed need more work. I've got a moderate amount of the updates for it done, but it'll be a while yet

hmm, the problem may be that all of the objects are in the same level of hierarchy with the same name, so their paths are identical gameobject/phoenix/thrustTransform When KSP goes looking for that item, its always going to find the 1st copy and may not ever process the 2nd. You might have the same issue with your RCS thrusters. So, try a simple fix, add 2 more empty gameobjects in unity, and add them as another layer in the hierarchy. like gameobject/phoenix/engine1/thrustTransform and gameobject/phoenix/engine2/thrustTransform where engine1 and engine2 are the new empty gameobjects. So they'd be on the same level as your thrustTransforms currently are, and then the 2 thrustTransforms added as children to them.

I wouldn't spend too much time worrying about fairings, I'm sure they'll get further updates for the next version to solve some of the issues. The stock ones work fine for people who don't want to install pFairings.

I have no idea why you would or would not "trust" an engine, you can test them in sandbox all you want without any need for MJ or KER (both of which you can also "trust" in 1.0) so enough of the crazy talk. As for sepratrons.. I'm going to need screenshots and specifics because they all seem to be allowing surface attachments just fine here.

It was balanced against stock before 1.0; For 1.0.2 I did a high level re-balance because the game is quite different now, so things may still be in need of more tweaking. I'll do that more when we know how Squad may change some things for the next version.

Good lord, man. No way. I ran at full settings when the game came out on my laptop, which has a GTX 525 Mobile GPU in it, with an i3. KSP has certainly gotten more CPU intensive since then, but not really any more graphically. Even now I only run a i5 2500K (not overclocked) and a GTX 575, and I play 1920x1080 with it all turned up, and I've used graphics mods like EVE as well. There are plenty of games this system can't run on high anymore, but KSP isn't one of them

Unity is not a 3d modeling program, and as such there is no need to choose. You will in fact need both a 3d modeling program like 3DS Max and also Unity with the KSP Part tools script installed to properly export a .mu model file that KSP will load properly. Unity is in fact a game engine (like Unreal and others) as well as a game development environment. KSP runs on top of a Unity executable. Modders use Unity in a few ways, part makers specifically use its editor along with the KSP Part tools script (made by KSP Developers) to set up a 3d "scene" containing the models for their part (with textures assigned) as well as animations and vectots that describe certain functions called Transforms. (These can be the direction of thrust, which way a docking port connects, the direction a landing leg points when deployed, and so on.) Once its setup properly they use the script to export the entire constructed scene as one model file and any textures it uses. These files can be loaded by KSP, and with the proper CFG file they'll be recognized as a part and show up in the part menu in the VAB to be used in game. So to make a part you'll need 3 basic things: A 3d Modeling program; You know of 3ds Max. Some other choices are: Blender, Wings3d, Sktechup. There are quite a few more, some may produce models supported by Unity and KSP easier than others. Some are free (like Blender) and some cost a lot of money (like 3ds Max) An image editor to create textures and bumpmaps for your models; Photoshop, Paintshop, gimp (general imagine manipulation program, gimp.org), Paint.net (somewhat like the original Paint for windows but with many more features.) Again, some of these are free (Paint.net, gimp) some cost as much as normal software (Paintshop) and some are again quite expensive (Photoshop) And finally unity with the KSP part tools script. The good news is that the normal Unity package is free to most hobbyist and students. As for what is best; impossible to say. They all excel at different things, they have different interfaces and all of them will take some time to learn. You should probably hit up Youtube and watch some videos of them in action, it might help you decide which one to tackle. I personally use Blender (from blender.org) and Paintshop Pro X14

Blender.org for Blender - 3d modeling and animation software, open source, definitely works on Linux gimp.org for gimp, general image manipulation program - a Photo-shop-like program, again open source and definitely for Linux. Your main issue is Unity, even though projects made in Unity are portable to Linux, the editor itself does not run natively (only windows and Mac OSX) - it will work through Wine though, and the limited ways you use it for KSP part making that shouldn't be a problem.

Once you have a normal map image created (the NVIDIA script takes your regular texture, called the diffuse texture and turns it into a normal map) you save it in the Unity asset folder next to your diffuse and your model. Then find it in the Unity assets list, click on it and in its info panel change the texture type to Normal Map, then uncheck Create from Greyscale if its checked, the other defaults are normally okay to begin with. Hit Apply. Once that is done you need to click on the Material for your model and make sure the shader is set to KSP/Bumped or Bumped Specular, this adds the 2nd texture slot for the normal map, select it and you should see the added detail on your model in the scene right away, and now when you export it will put both texture files in there. You might want to adopt a naming convention for your normal maps, the standard one for KSP mods is using the same name as your diffuse texture and then added _NRM; so like engineTex.dds and engineTex_NRM.dds (Note: if you use KSP/Bumped Specular you might want to add a specular map to your diffuse texture to tell it where it should be shiny/reflective and where it should be matte/dull. You can also change the settings on the material to change exactly how shiny the part is overall. That's a bit more advanced, so get the basics down first.

The exported model files have texture names in their metadata, which KSP can read. However KSP only cares about the name before the file extension, not what the extension is or anything like that. So even if the model says "myTexture.png is its texture file, KSP will load myTexture.dds if its in the same place. You can also override textures via the MODEL {} node in the config of course if you need to reuse a texture from another folder or whatever. So basically you can export it as TGA, PNG, MBM or whatever and then convert it to DDS. There's a KSP-specific tool to do this automatically: http://forum.kerbalspaceprogram.com/threads/98672-WIN-KSP-to-DDS-texture-converter Its a very slick program. I converted several hundred textures from my mod in one batch using the program, it did any flipping or sizing needed and even deleted the old files.(its optiional) That should be all you need.