nli2work

the smaller pod has integrated RCS and Monoprop Engine. its small size required some extra parts to be created as the 0.625m parts I can find right now are still too large for it.... I've got a micro-sized Klaw and lander legs built and tested so far. probably scale down the stock lights for some light options. the tiny lights from SurfaceLights mod goes pretty well with it. I'm considering adding a ring structural element for additional attachment surfaces. I'm going to add solar panel capability for the tiny pod's glass surfaces because it'll spare me of creating tiny solar panels, and it's also commercially available tech today.

for scale this is what I learned so far. KSP rescales everything by 1.25 default. you can force different scale factor with the line "rescaleFactor = 1.0", 1:1 or "= 2.0" double size; " = 0.5" half size. etc. in your modelling app set system unit to meters and display to generic without any unit; in Unity, set model import scale factor to "1" keeps the numbers the same and remember KSP's rescaleFactor setting and you should be alright. Animation wise you want Unity 4.2.2 for best support for legacy animation tools. in newer Unity versions legacy components are no longer supported and things start to break.

this covers all the basics on part size and generic animation on orientation you want the root object, the one that has Part Tools attached, to have 0,0,0 Pos and Rot. and 1,1,1 Scale.

good call Justin. I never noticed LV-N's fairings during stage separation. Looks like ModuleJettison will do what you need, you just need a separate module for each fairing piece. The KW fairings uses decoupler nodes, same way stock radial decouplers work. Looks like that's more complex for what you need.

separate them by shaders you intend to use in KSP; hidden parts; and animations. if there're no hidden parts, animations; or multiple shaders. combine them into one object. each shader requires separate mesh; hidden parts like engine fairing require separate mesh; and moving parts need to be separate mesh

this would go really well with JSI Transparent Pod!

jettisonedObjectMass I believe is for treatment as debris. Direction is X Y Z. probably 1, 0, or -1. I'm not sure if ModuleJettison{} will be flexible enough for what you are attempting. for splitting the fairing into sections you might want to check out KW's fairings and see how they are set up.

I see, new in later releases. I tried HotRockets in 0.23, but didn't keep it for long. I'll look closer at the SmokeScreen plugin next chance I get.

large undertaking with the new ModuleEngineFX and older ModuleEngine both in play. from what I've gathered so far... ModuleEngine only makes use of "fx_" type, the older prefab particle emitters you've listed above, all have lower case prefix. they are configered by the older X,Y,Z,wX,wY,wZ parameters along with string for engine state that emits the particle. ModuleEngineFX can use both older "fx_" particles, and newer particles defined by EFFECT{} module. EFFECT{} module lets you configure with particle and sound with nested nodes with name of the engine state you want. particles can be older "fx_" types; or custom emitters exported with parttools as *.mu file. KSP particle emitter is basically a collection of legacy Unity particle parameters in a single component. KSP particle emitter will add the Unity components necessary to create a particle emitter: Ellipsoid Particle Emitter; Particle Renderer, Particle Animator. KSP Particle will prevent you from changing the parameters in those added components however. KSP doesn't seem to like straight legacy Unity particles for some reason, FX *.mu will not load if exported without the KSP particle component. Biggest caveat is "Simulate World Space"; for engine flame FX it is best turned off, and only use local space. something to do with transitioning from atmosphere to vacuum I think. as long as you use older "fx_" smoke trails you should be fine. Smoke trails only show up in atmosphere, only three landable bodies in KSP has atmosphere. there are 3 stock smoke trails fx_smokeTrail_medium - used on pre-ARM solid boosters fx_smokeTrail_light (fx_smokeTrail_aerospike) - all pre-ARM liquid engines and air breathers. smokeTrail_aerospike is used on the Rapier engine, though Aerospike uses smokeTrail_light; I don't see a difference between the two in game. fx_smokeTrail_VeryLarge - all ARM engines. soild and liquid. Smoke trails are aligned to Y axis, Engine flame and flameout sparks are aligned to Z. so you need a "smoke point" transform for smoke trails to flow in the right direction generally. Hotrockets uses stock KSP particle mechanisms and doesn't require any plugins. A quick look at SmokeScreen makes me think it's a plugin that enables all the Unity legacy particle parameters in KSP. so if you want absolutely the best looking particles, you want to use that plugin. I suspect CoolRockets effects can be made with SmokeScreen plugin with proper parameters. for full details on the parameters best to refer to Unity's documentation for legacy particles.

very cool! look forward to it. If I come up with anything part wise will send them your way.

I guess it'll have to be a separate part instead of integrated into the pod. bugger.

Should be able to. The pivot is clear of any obstructions once deployed. I think I figured out why it's flipping after grabbing though... fffuuuu... I see why it's flipping, but still don't see why it would throw NullReferenceError on release.

the position should be no problem... I'll rename the node to match stock.

partially solved... The grappleNode was colliding with craft's collision on deploy. kind of obvious now that I think about it. Also explains the clunky design of stock klaw. the caps can't touch the grappleNode, but has to block collision with other parts. now the contraption deploys, grabs, and releases. But on contact the node flips 180 degrees, and becomes non-functional after release. The "Release" button doesn't reset. The dreaded NullReferenceException error on release.

the config has settings of captureRange = 0.05 captureMinFwdDot = 0.866 captureMaxRvel = 1 maximum range is 0.05m MinFwdDot is most likely the dot product of the two vectors: your klawn node and the surface normal. fairly safe to assume that 1 means perpendicular. 0.866 works out to be 30 degrees. MaxRvel, max relative velocity. self explanatory.

after a day of trial an error I've gotten thus far model and animation working ModuleGrappleNode working but not both together. I've picked the Klaw apart in blender... ModuleGrappleNode requires named Transform, check transform needs collider, check in game all the right click menu appears correct, the collider is working I can see from the debug log the Module is attempting to create the grapple joint when the deploy animation plays and I get the following lines that seems relevant [Error]: NpScene::createJoint: desc.isValid() fails! [Error]: NpScene::createJoint: desc.isValid() fails! [Log]: [Grapple Joint]: joint lost any ideas?

it'll be a command pod. I wanted it to be a command seat, but pod is the only way to get RPM IVA functionality.

Looks like glass pod gets a whole line... "Humpty Dumpty", 1.25m glass pod. and "Mono", 0.625m sized pod. intended more as a hard-shell EVA system. can operate as pod or ultralight lander in a pinch. Size0 docking behind the pilot and handy Klasp under so you can stay put near the work area without worrying about drifting off.

Thanks for putting it together!

Oh I gotcha. Yeah PNGs are good as well. Anything lossless is preferable going into Unity.

I switched to TGA Compressed after reading a thread on PNG loading time issues due to a bug with Unity, PNGs resulted in dramatically longer loading time compared to TGA or MBM formats. It may or may not be applicable now. here's the thread by Novasilisko http://forum.kerbalspaceprogram.com/threads/35225-Some-lesser-known-bits-of-info-for-addon-developers

I'm pretty sure KSP will only read the 1st collider component on a mesh object. The rest are discarded, either in game or by part tools. Multiple colliders require multiple game objects child to the parent object with Part Tools component. Will have to test it some more Hatches are a pain, make sure the Hatch trigger only intersect 1 collider on the model. Capsule collider might work better than box collider in some instances. There was some discussion as far as best texture format for KSP. But going into Unity I suggest a non-compressed format like TGA or BMP. JPG is a compressed format and going back to TGA from JPG won't improve the texture quality. From Unity to KSP I settled on TGA Compressed for easy of editing later, load-time, 32bit RGBA, and final size. For KSP, best version of Unity seems to be 4.2.2; if you already have a large project in a newer version, there are some fixes to allow more complete legacy animation functionality.

KONKEA maybe... KIKEA close enough to warrant reconsideration.

Those are some pimpin rims! Looks great!

KSP particle is based off of unity legacy particles. Which I guess is easier to script for. same scenario as Animation vs Animator components I suppose. What's the SRB smoke and InfiniteICE engine you are referring to? From looking at the Squad config files, there are two smoke trails, maybe 3? All the old engines use fx_smokeTrail_light and new engines use fx_smokeTrail_veryLarge. I think most of the problems stem simply from the code base being spread over long dev time and we have old and new code working together and sometimes not. Edit: Simulate World Space seem to work fine if you put it on a horizontal vehicle ala SPH... but if you try a vertical launch, even from the runway, it bugs out one way or another.