nli2work

New product: Kaptain Kerbin! Rigidity Enhancer©, and, for a limited time, Vessel Surface Self-Illumination kit included at no extra charge!

You have to compromise for the sake of your own sanity, unless you enjoy setting up constraints for dozens of actuators. Numbers quickly add up considering each actuator group consists at least 2 or more pieces. In game set up really depends on the engine. Some cheat with single transform, while others set up individual constraints per. There're 3 different constraints in KSP; LookAt; Position; Orientation. It's not really feasible to do a step-by-step kind of tutorial as they can be combined in numerous ways to move things in game different ways. LookAt points a transform's Z+ at another transform; there's no upVector control so you will get flips if the target transform moves around a lot. Almost all landing gear; wheel; leg parts use this. rotator does the looking; target gets looked-at. MODULE { name = FXModuleLookAtConstraint CONSTRAINLOOKFX // repeat for as many as you need inside of MODULE{FXModuleLookAtConstraint} { targetName = getsLookedAt rotatorsName = doesTheLooking } } Position places one transform at another transform's position. Orientation sets one transform's orientation to match another transform. This is in World rotation, so if mover's orientation was offset from the target, it will snap to match the target's orientation. Position and Orientation are both part of same module; Position and Orientation have no offsets so if you need offset, you have to nest multiple transforms. MODULE { name = FXModuleConstrainPosition matchRotation = true matchPosition = false CONSTRAINFX // constrain block; repeat for as many as you need inside of MODULE{FXModuleConstrainPosition} { targetName = targetTransformName moversName = affectedTransformName } }

judging by the way it's wobbling, it's some non-wheel collider. probably capsule... but where the hell is it coming from? I don't see it in the MU, don't see it in the config.

Notice how the legs magically lifts the tank up well before any part of the leg touches the ground. Looking at the MU in blender and testing the config file line by line... I don't see anything at all that would contribute this behavior.

try it with box colliders, and more thickness.

Was gonna record a clip, but forgot. here we go. no audio but should be clear enough.

I logged a report on issue tracker at lowest priority back in pre-release, the entry has since been removed, so I guess it was intentional. As for decals, maybe geometry is an option? Could be a real pain if your decals are super intricate, but it does offer some extra flexibility like using texture/mesh switch from FS

use MODEL { model = path/to/mesh //no dot mu texture = textureName, path/to/texture // not necessary if texture is in same folder } instead of mesh = model.mu

new wheel stuff is sketchy enough as it is, does not play well with model scaling at all.

There's no LOD meshes in any stock models. It's safe to assume KSP doesn't implement LOD for geometry. I'm sure it's possible to add that option with a plugin if you already have the code.

Ok I see what you mean, at least better than before. All in all I think it'll work well enough. When Squad switches to standard shaders, I expect all the parts and textures will get remade; the textures at least... or they might borrow your code. Who knows. I think your assumptions will work for Metal/Gloss, though giving the controls to the end user might be more confusing since they likely won't know what Metal/Gloss values are intended to do. Simple sliders for Reflection brightness and saturation should be enough in-game, I expect this is the biggest reason most players will use this mod, for real-time reflections. The masks can be generated at load time with values from a config file. Power users can adjust the config file if they feel the need to. For Occlusion some kind of unsharp mask should work better since occluded areas are most likely seams and not large flat surfaces. Seams most likely are where there's high contrast in diffuse texture values.

not sure what you mean... just one consistent implementation is enough, either Metal or Spec. I expect asset creators will have their source material to create the necessary masks. At most a simple conversion utility like MBM2DDS converter is enough. Nothing like Squad's Wheel stuff please. Metalness values are consistent every where far as I know, 1 = metal; 0 = non metal. The only real point of confusion is Rough/Gloss map; that is more less solved by inverting one for the other. Not sure if I really understand your algorithm to be honest, It looks like you'd get the same result for Metal/Gloss/Occlusion since you're just basing the return on texture's grayscale. What's the point of that?

I don't know if you will be able to get fully accurate conversions... there's no way to guess what the material surface properties from just the Diffuse and Spec maps. High Spec doesn't necessarily mean Metallic surface; high metallic surface doesn't necessarily mean high Spec surface. This may help coming up ways you could get decent conversions through code. https://www.marmoset.co/toolbag/learn/pbr-conversion

color sandstone is relatively cheap material (looks like Eucl3D is charging ~0.25USD per cm3), you can print the entire launcher + shuttle affordably. Each stage printed as a craft file; and the shuttle as a craft file. you can ask them to scale the craft files so the largest piece (1st stage) prints in the 4" scale. at ~2.5cm diameter, you can print the stages with a hole through the center where you can use a rod to reinforce the assembly, though I doubt it'll be necessary. or print the upper stages and shuttle hollow.

anything like this in the animation clip?

is the import animation type set to Legacy? Unity 4 and later defaults to "Generic". for KSP it should be "Legacy"

Part list icon doesn't show any translucent shaders, flagDecal or otherwise, I assume it's by Squads design. Best thing is set the decals or other transparent mesh objects to Icon_Hidden. I haven't tried Cutoff shader. that may work in part list icons? .

Eucl3D prints sandstone/resin full color models, GhostEye will not be printable as single piece, except perhaps very small print, ~2" longest dimension, with thick wings. Probably printable as 3 pieces: 2 wings, and fuselage; you may have to order them as separate craft files. The shuttle is be a better candidate for printing with less large flat surfaces, to minimize stepping effect, and all around thicker cross sections for better strength.

Someone got the Futurama allusion! :D:D:D Testing don't always go well...

tack the command seat onto the Mk1 pod. a simple MM patch can fix this up easy.

In all seriousness... I think you have a better chance asking for a Kerbal mod on Civ-V mod forums.

now I'm just rubber necking.

Import Tangents is important if you baked normals in your 3d App from a hi-res model. If you used a converter from GIMP or photoshop, importing tangents is not as important, calculating from Normals would work just as well.

too light a load can give jittery wheels, this is a constant "buzzing" type of jitter. try dialing up/down Spring/Damper ratio depending on the load. . versus other kind of jitter where the wheel pops up once in a while, that could be non-wheel collider hitting the terrain. It's hard to say what exactly is causing the problem, too many variables in the kitchen. Double check the layers for the colliders, matching transform names in the config files, before tweaking values. if you have LookAt constraints, it could be the looker object flipping when the look-at object passes gimbal axis.

don't overwrite anything in Gamedata/Squad. never. You don't need to do anything other than extract PBRShaderLoader into Gamedata. The effects are very subtle by default. If you are expecting something super chrome shiny maybe it's best to wait till there's a final release. Well dang it... the only axis you can rotate the scene skybox is Y; so that can't work for anything except in orbit maybe.