nli2work

this is in 1.1.1; might be shader related... the plugin breaks launch clamp, logs show these messages on vessel load, [LOG 17:27:48.517] Unpacking Untitled Space Craft [ERR 17:27:48.518] Infinity or NaN floating point numbers appear when calculating the transform matrix for a Collider. Scene hierarchy path "launchClamp1/model/launchclamp/obj_ground/obj_ground_mesh" [ERR 17:27:48.519] Infinity or NaN floating point numbers appear when calculating the transform matrix for a Collider. Scene hierarchy path "launchClamp1/model/launchclamp/obj_girdercap/obj_girder/obj_girder_mesh" [ERR 17:27:48.519] Infinity or NaN floating point numbers appear when calculating the transform matrix for a Collider. Scene hierarchy path "launchClamp1/model/launchclamp/obj_ground/obj_ground_mesh" [ERR 17:27:48.520] Infinity or NaN floating point numbers appear when calculating the transform matrix for a Collider. Scene hierarchy path "launchClamp1/model/launchclamp/obj_girdercap/obj_girder/obj_girder_mesh" [ERR 17:27:48.520] Infinity or NaN floating point numbers appear when calculating the transform matrix for a Collider. Scene hierarchy path "launchClamp1/model/launchclamp/obj_ground/obj_ground_mesh" [ERR 17:27:48.520] Infinity or NaN floating point numbers appear when calculating the transform matrix for a Collider. Scene hierarchy path "launchClamp1/model/launchclamp/obj_girdercap/obj_girder/obj_girder_mesh" Also spams "Look rotation viewing vector is zero" on revert or switching to vessel after relaunching game.

it's a Unity issue, something Squad can only work around, which is the reason we have the clip detection. Till Unity fixes the problem or Squad switches to a Unity version where this is fixed, all we can do is adjust wheel/vehicle designs to minimize blocking. There's a setting in ModuleWheelBase called clipObject = , point this to a mesh in the wheel part, a semi-transparent sphere centered on the wheel collider for example, to provide a guide for players. The clipObject is destroyed once wheelCollider hits the ground, after vessel is loaded. It's probably meant for debug uses, and looks kinda crappy when the vehicle first spawns, but better than nothing.

keep damper strength equal or less than spring strength. increasing spring ratio have less negative side effects as that in essence increases mass each wheel can support, better to over support than under support for takeoff/landings. low grav situation you'd want to tune it down to minimize shooting craft off the ground when wheelColliders switches on for physics unpack.

Yeah it's always a trade off between FPS and accuracy. Light probes also needs light maps to work, which I don't think Squad is doing at the moment. not even sure if it's possible with the way the scene scales in KSP. how often does bounds testing happen? what happens when parts come/go like docking two vessels and boosters drop off?

yeah there're 3 different ways Unity updates reflection cube map. either updating only on Awake, update each face sequentially over a several frames, or update all faces at once. All at once gives most accurate reflection relative to time, but most resource intensive. Have you looked at light probes? that's intended more for the effect you're after, though that might require some changes (likely big) on Squad's side. As for reflection probe bounds... maybe referencing the part's drag cube could help? or perhaps checking out FAR's voxelization process to estimate the bounds of full vessel on load?

That's a good starting point. I'd run it through the curve editor to make sure there's no unintended spline overshoots. A big dip/spike in thrust is much more noticeable than a dip/spike in ISP. Multi-propellant engines with big variance in fuel ratio like air engines will take more tinkering. I still don't understand why there would be fuel remaining with a simple 1-0 curve. A tweakable thrust curve in Editor would be really useful especially for SRBs where it burns just fast enough for TWR>1 for lower atmosphere, then faster burn rate for higher thrust in upper atmosphere.

how do I wildcard Modules only within a Mod folder? would this config have to be placed inside the ModFolder? @PART[*]:HAS[@Module[IWantToChange]]:FOR[ModFolder]{ }?

thrustCurve keys ratio of fuel remaining to control flow rate, in turn controlling actual thrust. easiest example is SRBs thrustCurve { key = 1 1 // full fuel, full flow rate. key = 0 0 // 0 fuel remaining, 0 flow rate } fuel ratio should never be more than 1, as your tanks can't hold more than maximum amount. setting flow rate to values higher than 1 will produce initial spike in thrust (and heat production and the rest), which Jeb will leverage for unintended uses I'm sure. There's a lot more to this I'm sure... the above is just from experimenting with an SRB in game. Using the simple curve above never burns all the fuel, the engine flames out when flow rate hits ~1% of max. NathanKell will hopefully explain in clearer terms.

These settings don't apply 100% to KSP since KSP implemented a 3rd party wheel system from VPP. Unity docs describe basic PhysX wheel collider. TsubSys determins when the wheelCollider becomes active during wheel/leg deployment. 0 is start of deploy animation; 1 is end.

The Four Riders of Kerbapocalypse

I think it's a transparency sorting issue, particles, part highlighting, KSP/Translucent shaders are all affected by this. KSP/Cutout shaders are not. There's not much we can do except write/fix shaders or wait for Squad to sort out the transparent shaders. There're maybe some build settings that need changing, that can only be done by Squad. Probably a combination of both. For now best you can do is split out transparent meshes to their own objects, which you probably are already doing as KSP only allows 1 material per object.

Enceo's wrapper tanks are designed for 1.25m center no? The hitch has 1.5m central column. should be okay for those. I sized it up to prevent clipping when attaching 3.75m tanks around the center. The scanner probe is basically a MX20D the army uses on their aerostats. I had to make 3d models of that thing for about a year... so it's kind of stuck in my head. doesn't BDArmory's airborne laser looks kinda similar too?

center shifts wheelCollider from the position in the MU. can be used to adjust the wheel without reexporting, best left to default of 0,0,0 groundHeightOffset sets spawn height, basically replaces the Bounds collider from earlier WheelModule. only used when vessel is initially spawned from VAB/SPH forceSharpness I think this determines how quickly full friction forces act on the vehicle. Higher increases responsiveness overall. Too low a value makes it very mushy; too high a value makes wheels jitter continuously. Defaults 10; I find values between 10~20 is decent. suspensionDistance, height of actual suspension, http://i.imgur.com/E9kYjaO.jpg suspensionOffset moves suspensionTransform up/down the suspension vector. e.g. you set suspensionDistance to 1m; targetPosition to 1; and suspensionOffset to -1; this in effect sets suspensionTransform to move between 0 to -1 relative to suspension vector's origin. This only affects the suspensionTransform's position, not the actual suspenion interaction with terrain or other objects, actual suspension will still be between 0 to 1m from terrain. pics: http://i.imgur.com/DPHxpvf.jpg targetPosition is where the wheelCollider will try to position suspensionTransform. 0 is fully compressed, 1 is fully extended. This is inverted from Unity's WheelCollider. Wheels generally sit around 0.5; Lander Legs sit around 1. Setting this to 0 is functionally same as setting suspensionDistance = 0 springRatio adjusts how much mass the suspension can support. Since there's dynamic adjustment and tweakable sliders in game, this will take a lot of testing for each wheel you make. Higher supports more mass, but can shoot vehicle into the air on unpack when wheelCollider becomes active. My guess is units are in kN from observing behavior in game. damperRatio adjusts force opposing oscillation due to springRatio force. 10% to 50% of springRatio value is good starting point. takes trial and error for each wheel part. groundHeightOffset video https://www.youtube.com/watch?v=OunIHXUWfoE wheelClip detection video https://www.youtube.com/watch?v=E9lZD3OemrM Big thread with lots of info on the new wheel modules.

whats it look like with Col1 selected?

you'd need some plugin to load the shader. after that it could work but on a cone shaped mesh attached to the engine. Heat refraction effect are generally post effect shaders, similar to pixel shaders like the stained glass sample shader from unity5, but operate at a different point in the render pipeline.

they are behind transparent glass panes? It's something affecting a lot of different parts, mods or stock.

which wrapper tanks? I was thinkin of making the central part flat and full width of end caps... like big flatbed

Pretty sure one of Necrobone's mods has some big lander legs

Is reflection probes absolutely necessary? It's really meant only for real-time reflections on limited meshes in limited range, and not for general lighting on every thing on large scales. Lighting effects from skybox (the environment) is already calculated into the Standard shader without adding reflection probes. The Flight scenes are not very similar to typical levels you'd build in a game. the VAB/SPH are closer to what typical levels are like. It's hard to test anything without knowing how KSP scenes, lighting, and render settings are. If the skybox in Flight scenes is always the star map, then you would have to use real-time reflection to get some decent looking ambient light effect. also would be hard to use hex or xxx,xxx,xxx,xxx for color settings in the config? there're two new parameters in deployable solar panel (and radiator) planetLayerMask and defaultLayerMask, may be provisions for future implementation of reflection on these parts. KSP has layers for ScaledScenery, Planets and terrain I think, on layer 10; and Local Scenery, static meshes like VAB and Anamolies I think, on 15; maybe some performance can be gained by setting reflection probe culling mask to these layers. It would mean no Part-to-Part reflection as most if not all part meshes are on default layer.

img removed

on a related note... is "draperPoint" value working in ModuleAnimateHeat? no matter what I set it to, thermalAnim starts around 800Kelvin (default draperPoint of 798). looking the module it should be maxTemp - draperPoint = Anim lerp starting point?

I don't know what I meant by "upgraded", probably whenever KSP/Standard shader gets activated in game :D... honestly it looks like a Unity problem, same thing happens with Unity's standard shader. I don't think there's much Squad can do about it short of modifying the rendering system. Saw some people talking about it back when Unity5 first released, not sure if there's a solution or just wrong build settings... if you have transparent on top of transparent you'll get things disappearing from some view angles. transparent on top of cut-off is okay. particles are affected too, highlight effect will render on top of particles when you mouse over the engine.

it would have to be a PROP {} to use Internal Modules unfortunately. can't mix Part Modules and Internal Modules.

yea, there's no animation. just assign the pivots in the internal module config. best bet is open up the stock navball for reference.

nest transforms for each rotation axis, just like a real nav ball. harder part is getting them oriented correct to work in game. takes a bit of trial and error.