nli2work

Interesting. To the test pad!

by skinning to a joint I meant a single joint that the mesh is linked to, this because blendshapes in Unity is part of the Skinned Mesh renderer, which I believe requires a joint as root. The root joint doesn't need to be animated. all the actual animation is done with blendshapes. similar to how you might do the head, single joint moves the entire head, while blendshapes drive the expressions. Raidernick was doing something like this recently, not sure how that worked out.

no official answer honestly. Unity does support blendshapes with skinned mesh component; the mesh needs to be skinned to a joint I think. I don't know if blendshapes will work in KSP, but I'm pretty sure skinned mesh will. Haven't had the time experiment myself.

IIRC NathanKell mentioned for atmosphere curve 1 = atmospheric pressure at Kerbin sea level; roughly 101 Pascal. 0 is outside Kerbin atmosphere, above 69km. This would mean Duna sea level is about 0.4 on the atmospheric curve. An engine would have higher ISP at sea level on Duna than on Kerbin. Oxygen requirement is controlled by this block in ModuleEngine; in this case, IntakeAir consumption is 15x LF consumption. if you remove this propellant requirement from the jet engine config; you would have a jet engine that works in vacuum and does not require oxidizer. if you remove all propellant blocks, you'd have a magic engine that runs forever. PROPELLANT { name = IntakeAir ratio = 15 } There is a relevant tag in ModuleIntake checkForOxygen = true; I think this restricts jet engines to run on planets with oxygen rich atmosphere, Kerbin and Laythe; if you set it false, the engine will probably run in any atmosphere. I haven't tested so can't confirm 100%. MODULE { name = ModuleResourceIntake resourceName = IntakeAir checkForOxygen = true area = 0.01 intakeSpeed = 10 intakeTransformName = Intake } The compilation of modding info sticky thread is still good source of information, even though it's somewhat out of date. Much of it is still applicable. I recommend bookmarking it and look there first for basic information.

Thanks! I enjoyed working on these. the two propeller are my favorites. I believe AJE removes FAR's global engine nerf and replaces stock ModuleEngine with AJE ModuleEngine. FAR reduces all engine thrust by 50% IIRC. With FAR, the propellers produce 39kN (Trianka) and 48kN(JeyTew) of max thrust, velocity curve restricts top speed to about 300m/s; the turbofans under 200kN, probably still overpowered. I haven't tested them all that much to be honest. All the engines have Intake module to make them FAR friendly. I haven't tried it without Intake Module. I think they would probably be okay because FAR has built-in special exception for Firespitter propeller modules. Visually I figured the opening in front just behind the blades act as intakes. For tail mounts I have radial intake that will come with the fuselage parts. Currently adding couple airbrake parts to make landing more manageable. Should see full release in the next day or so. My oversight! the engine body uses texture from the fuselage parts that I haven't released yet. That should be fixed in a day or two. I will definitely make a separate engine body, something like the P51. and single set of blades. Those won't take long. The Jey-Tew will stay as it is officially though. I'm too attached to it. Overall I want to keep the parts generic enough that people build planes that capture the feel of historical planes, but not exact replicas. yes reverse thrust is a Firespitter module, I will add that for the next update.

you can export one project as a Unity package; and import the package to a different folder. this is closest thing to merging projects option in Unity. Best to make sure project folder structure is same in both projects, or you might end up with multiple parttools in same project.

it's documented in the forums. but burried pretty far back and in different threads.. sometimes it's easier just to answer it than to dig up the old links. there's a mod called Advanced Jet Engines that is designed to give much more realistic performance characteristics for jet engines. but I have no idea how to use it.

nice! this will allow much greater flexibility in landing gear designs.

stock jet engines use standard ModuleEngine or ModuleEngineFX. for engine performance behaviour they are the same. EngineFX has more robust FX capabilities. three section that matter for jet engines are This puts a lag on engine's actual thrust and your throttle setting. higher the value the quicker the response. I believe the scale is 0~1. 1 is instant response. same as setting unseEngineResponseTime = false. useEngineResponseTime = True engineAccelerationSpeed = 0.2 engineDecelerationSpeed = 0.35 This is common to all ModuleEngine and ModuleEngineFX; determines ISP based on atmospheric pressure. 1st value is Atmosphere pressure; 2nd value is ISP. separated by space. 0 is vacuum; 1 is 1 atm, sea-level on Kerbin. planets with lower or higher atmosphere pressure will affect the engine ISP differently than on Kerbin, still based on this curve you define. You can set as many keys as you like, KSP generates a graph based on the keys you set. generally 3 to 4 is enough. atmosphereCurve { key = 0 1200 key = 0.3 2500 key = 1 800 } works similar to AtmosphereCurve. thrust as dependent on velocity. 1st value is velocity, 2nd vale is thrust multiplier. thrust multiplier can be any value; generally between 0 to 1.2. useVelocityCurve = True velocityCurve { key = 0 0.5 0 0 key = 1000 1 0 0 key = 2000 0.5 0 0 key = 2400 0 0 0 }

the only plugin required is Firespitter. The Ka engines will only be loaded by KSP if you have Karbonite mod installed. I'll put up separate images to make it more obvious

awesome. Thanks!

Engines are go! links in OP a fighter using the Jey-Tew engine from the pack.

the config setting in the title is in the config documentation on the wiki, and some older threads, but doesn't seem to be in the newer versions of KSP configs. Searching the KSP API documentation I found this... http://anatid.github.io/XML-Documentation-for-the-KSP-API/struct_game_events_1_1_explosion_reaction.html anyone know one way or another whether fullExplosionPotential; emptyExplosionPotential; or explosionPotential are still in effect?

c'mon. no need for all this legalistic stuff. It's all text, any cool or not cool context is strictly in the mind, my mind voice is a little old british lady sipping tea while reading the forum posts to me, I get a chuckle every other thread. SirCmpwn's done a bang up job thus far. cheers on that.

you won't need to normal map it. just put those faces in the same smoothing group. you might add a couple edge loops between the tip and the base of the nose cone to smoothout the vertical triangles. I don't know how to do it Blender, but you can do this in Unity, though you won't have control over individual faces. In the Normals & Tangents section, change the Normals to "Calculate" in the drop-down. by default it's set to "Import". then change the smoothing angle to something like 50 and click Apply. you'll see the mesh change in the preview window and the main window if you have in the scene. smoothing angle means if two adjacent normals are X degrees or less apart; they are averaged into 1 normal. so a smaller number will give you more faceted look; a larger number will give you smoothed look. averaging between two normals that are two far apart will make the mesh look too round. generally a number between 30 to 60 is good to start with. You can experiment more and see how it works. This generally works the same in any 3d app, blender or not. I just don't know how to do it in Blender.

the ray cast checks for LOS across own vessel; is that by collision box of the part on the vessel? or something more complicated? If a part doesn't have collision box, the turret will shoot through it. correct?

I believe Stephm is using stock MLG? I think lo-fi's set up maybe possible with stock MLG... but probably a bit more complicated config wise to set up.

the 3rd one is based on J7W shinden, a ww2 japanese prototype interceptor. there was plans to make a turbine version but it was never produced, so who knows, maybe it could go a little supersonic. The last one would be subsonic, strictly piston driven. yeah they do all look similar, they all share the same main cowling piece, just slightly different shape. saves me production time. I'd still be modeling them if I was making each separately.

you could leave out the arms and legs. that would get around the animation problem. it'd be a semi-hard shell you wear for EVA. pickup and drop off with KAS. the helmet wraps over existing head/helmet.

the two on the left are prop-Fans. Ultra High Bypass turbofans. Left one is similar to Antonov AN70 engine; exactly the one you are looking at. second left is just kind of made-up based on UDF prototypes GE built in the 80s. two on the right are WW2 type contra-propellers; max thrust for both are around 325m/s; and drops to 0 just under Mach 1, which I think is accurate for non-turbine driven propellers. The fuselage parts are custom made, I'll be releasing them after I round out the set a bit with a tail landing gear and couple spoilers. because they are hard to slow down in FAR. I made these mostly just so I can build the 2 hero planes from Sky Crawlers.

so the gMeter prop I had rolling round my head... PROP { name = gMeter MODULE { name = JSIVariableAnimator refreshRate = 1 VARIABLESET { variable = PITCH scale = -45.0, 60.0 controlledTransform = PitchMover localRotationStart = -45,0,0 localRotationEnd = 60,0,0 } VARIABLESET { variable = ROLL scale = 60.0,-60.0 reverse = true controlledTransform = RollMover localRotationStart = 0,0,60 localRotationEnd = 0,0,-60 } } } What scale would I set for Roll Pitch and Heading Variables? in degrees? or radians? I've got nested mover dummies in the prop, everything loads, no error messages. but in game nothing happens. I figured my variableset is probably wrong.

Sanka MkB from Sky Crawlers; basically a J7W Shinden

Yeah absolutely! I can learn some from you about doing those configs too.

Yep! sure does. Interesting your code doesn't require module ID. all other plugins, ones that I've seen, that utilize multiple instances of same PartModule requires unique ModuleID... eg. Firespitter or RPM very cool, looking forward to this when you release it

this may be the cause of scale issue. It's good practice to reset all your scales to 100% before exporting. using MODEL{} node will give you complete control over the size in KSP. MODEL { model = YourMod/YourPart/YourPart //.mu part is automatically added at the end. texture = yourPartTexture, YourMod/YourPart/yourPartTexture //make sure name case and file extension case all match. *.PNG is not the same as *.png; //repeat this line for all the textures in your mu file. scale = X, Y, Z poition = X, Y, Z //omit if it's this is the only MODLE{} node. defaults to your MU's 0,0,0 rotation = X,Y,Z //generally omitted; useful when you are combining multiple MUs into single KSP part } in Unity, make sure all scale are set to 1,1,1 in your part config, you want to use "rescaleFactor = 1"; also on the collision mesh; if you want to use convex mesh colliders; the two parts need to be separate; alternative is using combination of unity's capsule and box colliders. you'll also want to reset the scale on the collider objects.