nli2work

looks nice. you are paying a lot of attention to details, will pay off in the final result for sure

not unreasonable to think multiple nodes would add to joint strength/stiffness. I started testing because I really wanted to see how much I can benefit from it. results were unexpected to me. I just tested again with the same large tank scaled up 3x (that's about all the VAB can handle without extension plugin). holding 10x fuel. each tank weighs 720t. with 3 tanks and using node sizes 1, 2, and 3, same attach arrangement as before. Results were about the same. considerable rubber banding for size 1 node; negligible for size 2 and 3. Node size can go up quite high, 1000 or so. I think most benefit is from increased node size rather than number of nodes. and biggest beneficiary would be surface attach nodes since there's no green ball to block visibility. All assuming you are not using KJR of course.

the hidden Vulcan is another candidate, but of course it's pitch and yaw range are completely different from radial howitzer. would be nice if the settings made sense.

gave it a test. it doesn't appear to hurt anything, but doesn't seem to add anything either. Non-KJR install. I arranged the stack nodes for the largest NASA mission fuel tank. attached them together and tested size1, 2 and 3 nodes. 1xNode attach versus 3xNode attach flexes equally, presumably the game only selects one of the nodes when creating the joint, whichever one snapped together first in VAB. node_stack_top2 = 0.0, 3.74, 0.0, 0.0, 1.0, 0.0, 3 node_stack_bottom2 = 0.0, -3.74, 0.0, 0.0, 1.0, 0.0, 3 node_stack_top1 = 1, 3.74, 0.0, 0.0, 1.0, 0.0, 3 node_stack_bottom1 = 1, -3.74, 0.0, 0.0, 1.0, 0.0, 3 node_stack_top3 = -1, 3.74, 0.0, 0.0, 1.0, 0.0, 3 node_stack_bottom3 = -1.0, -3.74, 0.0, 0.0, 1.0, 0.0, 3 top to bottom: size1, size2, size3 nodes with KJR, node size doesn't make a differece. the part size determines joint stiffness. 1.25m and up appears to be roughly equal in stiffness. 0.625m joint is very weak.

quick question regarding JSIOdometer. the signs texture for SI display mode; is that still in a 10 Char vertical strip? or 8 Char? e.g 32x320? or 32x256? can't seem to get it to match up correctly whether I do 10 char strip with 2 blanks for char 9 and 10, or 8 character strip. What side does characterSize refer to, vertical or horizontal? I assume the unit is pixel? everything else I got working very nice. Great display module.

those are stock; either structural or Aero tab.

if you don't have KJR; node size affects joint strength, to what extent I don't know. if you do have KJR, node size no longer applies; supposedly KJR calculates joint strength based on the surface area. Ferram4 explains it little more here I suggest grabbing the invisible struts from B9 in conjunction with KJR

do you have Firespitter installed? newest version is 6.3.5 from here; all the engines require that plugin if that doesn't fix it I'll have to see the output_log.txt from KSP_Data. follow the steps here to generate a log file

try deleting the modulemanager.dll that is bundled with KerbPaint; also check for duplicate ModuleManager.dlls in Gamedata. there should be only one copy, the newest one is 2.3.5

if Squad fixed the orientation of IVAs to match external mesh, we probably wouldn't need the transparentPod module at all. The module is very process intensive as it has to reorient the IVA, swap shaders, and keep track of other pods in the vicinity and swap their shaders depending on when you are in or out of IVA. If you play with the pods a little bit, you'll see the lighting inside is all wrong when you see through the windows, because the IVA is in a whole different orientation than the rest of the world, in a different unity scene I believe. It's also why the windows are all black in the kerbal portraits. You can launch one pod without TransparentPod Module, and one with, and you'll see some very interesting things.

left mouse button.

don't know. looks like something is messing with Icon_Hidden layer in KSP. does it happen with all engines or just that one?

I just went through all the RF engines today and did a lot of readjusting. Piston propellers are down to ~500 mph top speed. turboprops top out around mach 0.8. ISP curves are now pretty much constant; low 2k for propellers; ~1800 for propfans. I'm entitled to a little fantasy, Rare Bear ain't so rare in RetroFuture world. setting up a few odometer displays using RPM, should go real nice for the IVAs.

that cockpit will be in RF 1.5. complete with IVA! RSI Hornet in KSP RetroFuture style in action

heh, I did the same thing first time, skipped a critical part of the video. also stick with FBX for exports from blender. his video shows the FBX export settings you should use.

follow Nifty255's video. it shows very clearly the exact steps you need to do to get a part into the game.

from a simpleton's (with respect to real engine behaviours, statistics, and most of the math behind all of it) perspective... what if you simply averaged (weighted by some predefined curve perhaps, 0 defined altitude = all velocity curve; 1 defined altitude = all altitude curve) the velocity and altitude curves for thrust? wouldn't that push the actual thrust toward velocity curve at low altitudes and altitude curve at high altitudes? seems like that would allow pretty reasonable performing engines and unrealistic engines at the same time. ISP would be calculated by the plugin instead of defined in the config?

make sure you are using KSP Shaders; make sure textures are in the right location under Gamedata, typically same folder as the MU file. check output_log.txt in KSP_Data; text search the log for your model; texture; and config file to see where things went wrong.

http://forum.kerbalspaceprogram.com/threads/45070 This IVA tutorial is still good. though without pictures it's a little hard to understand initially http://imgur.com/a/Vd2Zn I pulled some squad pods out with Parttools to get a sense of how the External and Internals are oriented relative to each other. may help clear up few things from TT's tutorial

not sure what the issue is? everything looks fine. there is no texture component in unity, it's part of mesh renderer component. you have "Tex" material assigned, and it's using settings based on your 3d app's material. the only thing you should do is set the rig to "Legacy" if it has animation, or set rig to "None" if there is no animation

This weekend maybe. I gotta do the tedious process of readjusting all the velocity and atmosphere curves. but some fun before doing that...

Ok I see. In that case, exporting the armature out and childing the mesh objects in Unity should work just as well.

can't just drag/drop it under the bone like in Unity? non-inverse-mode? I guess bones are special type of objects and doesn't work exactly the same as regular object.

back to the original question. the skinned mesh renderer component is added when you import mesh objects skinned to other objects (bone, mesh, dummies, etc), Blender calls it "Armature modifier"; max calls it "Skin Modifier". I'd just child the mesh to the bones in blender, exactly like how you'd do it in Unity. or you can child them after import. If the meshes don't bend or stretch or whatever, childing/linking/parenting is the best way to do it.

I'd consdier skinned mesh for a procedural Wing simple. the mesh is maybe 2 dozen vertices and whole rig is 3 bones. What you have is kind of complex. the amount of mesh being driven by bones probably affects performance more than anything else. I'd try just childing the armature pieces to the bone rig instead of skinning them, they are rigid parts anyway. it's just that it was easier to setup the constraints and animation in Blender and bake the animation instead of fiddling around with KSP's constraints no? unless the whole armature is a single piece of mesh? mesh and skeletons are tied together by the vertex numbers associated bone influences. essentially a big spreadsheet: vertex #222 is influenced by bone A @ 0.4; bone B @ 0.1; bone C @ 0.5. etc etc. For each frame the whole spreadsheet has to be processed to update the skinned mesh; reasonable to figure more vertex and more bones = bigger performance cost. so in relation to mesh and root bone; not much you need to do. unless the object in the scene lost it's link to the import file, then you just go back and reassign the mesh and root bone back to what it's supposed to be. for a mesh to be interchangable for skinned mesh render; the vertex order of the meshes have to be exactly the same or you get bits stretch off into odd places. I'm guessing most of the stuff, lot of people here know a lot more. I just happened to be messing with skinned mesh render last night because I noticed my pWings were being culled in SPH and in flight. and yeah you can make those bounding boxes much smaller, bigger bounding boxes just means they are less likely to disappear when near the edge of camera view cone. for something small it's usually not a big deal.