nli2work

just push it out from the surface a little bit.

cast/receive shadows work just like standard mesh renderer; same for Materials list. KSP doesn't use Light Probes far as I know. I don't know exactly what it does or how it works. Quality is vertex weights and bones. Unity supports maximum of 4 bone influences per vertex. the setting that controls how many bones you want to influence a vertex in a mesh. Update when Offscreen will keep the mesh from being culled from rendering when bounds box is outside of camera's view cone. The bounds box is used to estimate whether a skinned mesh object is in view or not. if the bounds box is not in view, the entire mesh is not rendered, even if parts of it are still in view of camera. If some bit of the bounds box is inside the camera view cone, then the entire mesh is rendered and updated with whatever bone animation there is. I don't know how much of a performance hit it is to always render a skinned mesh object, but probably not a big deal for simple things. Bac9 did mention Kerbals are expensive to render because of skinned mesh. mesh and root bone are not really changed much, assigning wrong mesh to bones not intended for it is pointless.

ALT-F12 will bring up debug window to reload assets; Textures may or may not update. take care not to highlight any building in KSC, as clicking a button in debug window will be interpreted as clicking on the highlighted building and take you to SPH/VAB while database is reloading, and things break. MM 2.3.x also has reload database option, ALT-F11 If you look in KSP_Data/output_log.txt(best place to look if anything goes unexpected), you will see the textures, model and config have loaded, because they are in Gamedata/ look in the compile section of the log, and you'll probably see an error compiling wiseTelescope, model not found.

what onklesiendruck said. as it is now, KSP is looking for wiseTelescope.mu in Parts/ folder instead of model.mu in wiseTelescope/ folder. alternatively you can delete the entire MODEL{} block since everything the part needs is in the same folder. KSP will load everything from the folder and compile them automatically. I'm not sure what final size you are looking for... is it 1.25m standard size? you wanna reconsider rescaleFactor = 0.8. MODEL{} applies rescaleFactor twice (for whatever reason, maybe a bug). so if you are using MODEL{scale = 1.25,1.25,125} AND rescaleFactor of 0.8; your final size would be 1.25*0.8*0.8 = 0.8 (of whatever size the MU is);

I do plan on using it soon The long list of settings is a bit daunting to look at at first to be honest.

surface attach cockpit is a great idea, perfect for airplanes... why ddint' I think of it myself! Nevermind about modulejettison unless you have a stack node on it. the module does not like surface attach nodes one bit.

very nice! You could use module jettison to add the "spine" behind the windows so it only appears when something is attached to the aft stack node, to smooth out the transition into the tail section.

non-FSpropellerSpinner engines start with throttle at 50%, but not running at launch. engines with FSpropellerSpinner (can't say for FSengine module, I believe B9 engines use ModuleEngineFX) , like B9 turbofans, Karbonite turbofans, and my propeller engines, start with throttle at 50%, and running at launch; so the vessel is under propulsion as soon as it is loaded on the launchpad or runway.. Though not considered staged by KSP, if you press space bar, the staging sound will play. This only happens when KSPI is installed along with Firespitter. presumably KSPI Experimental, since KSPI isn't compatible with 24.x

is there a fix for KSPI + engines using FSpropellerSpinner = engines launch in the activated state? it's happening with B9; Karbonite; and my RF engines.

I think smokeScreen would handle this quite well. it has settings to adjust particle size, emission rate, growth rate, velocity, based on speed, altitude, air pressure, air temperature, etc.

I have a few of these tucked into the Kerdoz command pod. Any internal space collider can be set to be a camera transform, and you can pan around to get a look at the entire interior.

you need Infernal Robotics for that.

the collider doesn't scale down with the wing it seems. it will scale up ok. but if wing is smaller the collider becomes larger than the wing. Is that normal?

try the output_log.txt usually it'll say what is throwing the error. Won't tell you which part, but can tell you which plugin and from there you can narrow it down to parts associated with the plugin

Cheers! great to see it go official. Thanks to everyone involved in putting the whole thing together!

Doesn't look like this will get stickied. I'm putting it here maybe it'll be easier to find in the future. INFO-KSP-floatCurves-and-you-the-magic-of-tangents

did you mark the mesh collider as "Convex"?

if you mean moving a part attached in VAB/SPH, it won't work. If you mean in Unity, it's a matter of attaching the component directly to the animated part; or childing the collider to the moving part in Unity. You can move the collider if you child it to a moving transform in Unity, landing legs and gears do just that. animating the collider properties like radius, height, won't work, you will get an error about animation curves when attempting to load the model.

the pivot of the object with PartTools is the CoM. works the same whether it's just one mesh object, or multiple. assuming it's not being shifted with CenterofMassOffset in config file as well.

that's just the sun rise. actual firing is not nearly as dramatic. If I can figure out how BD's module works yea. but so far I haven't been successful and he's not very forthcoming with information. but at least there will be few basic IVAs fro the cockpits.

to add part tools, select an object, click "Add Component" in the inspector panel. in the search field start typing "part" and the options will narrow down, then highlight PartTools with arrow keys and hit Enter.

I adjusted the target's positions, but whether the two arms are in a dependency loop or not doesn't appear to affect their behaviour in any appreciable sense. I've since adjust the heirarchy order to do without the loop, keeping the new target's positions at the same point where the two arm tips join. Originally I kept the upper arm target offset beyond the tip. What you are getting might have to do with the order the CONSTRAINFX blocks are ordered in the config file, they are processed in that order each frame, and if the order changes, their orientation per frame changes as well. there is one benefit of setting up everything correctly before exporting though. the part list icon doesn't have active constraints, so it shows the part as it is exported and you get this,

The pivot is independent of the mesh. take lo-fi's most recent image. +Y is pointed along the arm. you can rotate the pivot such that +Z is pointed along the arm or +X is pointed along the arm. Unity doesn't allow you to edit the pivot directly. so sometimes mesh objects need unity Gameobjects as mover dummies. In your GIF above, the object's +Z is pointed along the arm, which is how you want it for LookAt to work in KSP. With the LookAt constraint applied, the starting orientation of the arm doesn't matter at all. One thing to watch out for is that starting positions are the same with the animation on or off. In game the starting position is animation's frame 0, the animation is always on. So things might look good in Unity when not in play mode; but look shifted in KSP. the transform window only shows the object's rotation, translation and scale relative to the parent (if no parent, the parent is "World", indicated by the Axis marker on the top right of scene window)