nli2work

you don't want to just run contrast adjust on normal maps. don't use "Generate from Grayscale" on a normal map to increase the strength. Duplicate the normal map, and set the top layer to Overlay in PS (or equivalent in your editor), drop the opacity on the overlay layer till you have the bump strength you want. as for the shaders they appear to work fine, SquadCore or Legacy (from PartTools1.1 pack). Legacy Shaders from PartTools 0.23 works as expected too, though overall a little darker.

springRatio increases the mass the wheel can support. damperRatio counters bounciness from spring decompressing. The tweakble sliders, range 0.05~2, most likely are multipliers to the values in the config file. Unfortunately there's dynamic adjustments going on in the suspension module and it's very hard to get any predictable behaviour out of them. I have no idea why the lower tier stock wheels are configured as they are. You don't want to set suspension all the way down, there are extra colliders in the wheels to prevent them from clipping into the terrain when the wheel is on its side. When you reduce suspension all the way down, you increase the chance the extra collider rubbing against the ground and popping the wheel up. you might want to give GoSlash's stock landing gear fix a try.

scale it up with MM?

mediocre question... when MM adds a MODULE{}... is it added at the end of the config after all the other MODULE{}? or at the beginning before all the other MODULE{}? my config has a number of modules, two depends on two others and references their index. If MODULE{} added by MM is at the beginning, I can adjust the index references accordingly; if MODULE{} is added at the end, then all is well.

No idea... engine doesn't have anything to do with Firespitter... Try removing the ":NEEDS[!Interstellar]" part after PART at the very top, does the engine load then? Edit; just tested with Interstellar-Extended in 1.1.2; everything seems in order.

Do you still have any control besides throttle while using Frameshift drive? or is it in a set direction till you drop out of FTL? Existing FTL drives from KSPI-E or USI are bulky. A small engine part that's the size of 1.25m rocket engines would be cool, but would kinda throw the game way out of balance.

Unity 5.2.4? assetbundles from anything newer than 5.2.4 gives you empty compiled assetbundle and you get the errors from OP when attempting to load the empty assetbundle. Check the assetbundle with UnityStudio for content?

I see. I think that's more of a gameplay mechanic to prevent players from zipping past their intended destination by not paying attention than anything else... like the game saying "you wanna stop here? yes? yes? yes? no? no? okay next station/planet" I mean Elites Frameshift drive is like sublight engines right? you point in the direction you want to go, and throttle up? Point to Point jump via gates is something else entirely, for moving between different Star systems like in EVEOnline? In KSP you would experience a shift passing in/out of different SOI. but you'd have to try pretty hard to pass through multiple SOI between your start and destination.

USI's Alcubierre drive works that way. fully throttle controlled frame shift speed. haven't looked at what it looks like from IVA, but it probably looks something like going through a flashing light tube judging by how the warp bubble mesh is. wont' be as pretty as Elite Dangerous I'm sure. but works the same. the model and FX is just cosmetics.

yeah https://www.dropbox.com/s/40hby7wtt6cx8gn/multiStrut.zip?dl=0 Edit: fixed attach nodes; should be stack. not surface.

just visually, in the same way multiple thrustTransforms have multiple particle emitters, but over all engine thrust isn't multiplied by the # of thrustTransforms. I don't know how exactly quantum strut ties the lineRenderer and Joint creation so I don't know if it's easy to do or not. Essentially 1 lineRenderer per transform, but only 1 physics joint pert part.

yep. Currently the strut just emits from 1st transform that matches the name assigned in the strut module. I embedded 4 transforms in the part hoping it'd look like 4 struts attached radially. in other words the emitters would work just like thrustTransforms in engine modules, visual FX is attached to all thrustTransforms in the part.

Yeah I agree... I imagine it'd be very difficult to get a reflection probe cubemap that combines all the different flight scene camera views properly. as far as reflection probe, only 1 is really necessary, placed at the active vessel COM, near clip plane large enough to exclude half the vessel if not all of it... this would produce most accurate reflection for most instances. Edit: the Lilleman/Specular shaders should still read (A) from the Diffuse map to control Shininess I think.

I was trying to clarify the difference between a mesh and skybox and figure out what KSP is really doing. You can take a flipped box or sphere, apply a cube map material to it, center it to a camera, and it would look exactly the same as a skybox material assigned in the lighting panel in unity 5. However PBR shaders will only react to the skybox material from lighting panel and look correct. Of course you can add a reflection probe to force the PBR shader to reflect the mesh geometry with cube map material, but that's a really expensive way fake something that is normally done already with a proper lighting setup. With the current way KSP is setup it looks like there's a real skybox that's the Galaxy cube map. Explains why metal PBR is pitch back, because that skybox is mostly black. This means there two ways to make PBR shaders work properly in game... 1. Fade clear flag from color to skybox as vessel transitions from surface to orbit, same time when KSP fades in the real skybox. Probably the easier way. 2. add a skybox while on surface, and fade to galaxy skybox when transitioning to orbit. Maybe harder, but would make surface look much nicer, and should be more accurate as far as vessel lighting goes.

All this makes me more convinced the real issue isn't reflection probes, but KSP's environment and light setup. Reflection probes are really meant to be part of the game level instead of attached to moving objects. When moving objects are withing the RP's bounds box, they get the RP's cube map applied to their shader so they appear to reflect the immediate environment and other objects in the same RP bounds. Maybe a better way to approach all this is to update the RP once per KSP reference frame change? and set the bounds to contain the physics bubble, something like 3000? you'd only need 1 RP for all loaded vessels; and should be much better performing than 1 RP per vessel.

wait wait, so KSP's starmap skybox is not really a skybox, but a sphere mesh object attached to the game camera???? by real skybox I mean the cubemap in Unity's lighting panel... that's what PBR shaders need to work properly. I guess that explains why PBR generally looks poor in KSP in it's current state.

would it be easy to set struts to use list of transforms instead of just first transform the module finds? total strut strength doesn't multiply, just distribute among the transforms. I think that could allow other modders to embed transforms in parts for quantumm strut activation using MM to add strut module. if player doesn't use quantum strut, the transforms are harmless in the other mod's part.

This is really interesting! The reflection probe turns out to be a pretty effective way of a behind the scenes look of how things work in KSP I did a chromeball test, amped up brightness and saturation to 2; 2048 reflection map; timeslice mode 0. I think the biggest problem is there's no skybox at all in the surface reference frame, and terrain doesn't get reflected. This is bad for metalness workflow as metal surface gets most of its colors from the environment (the 2 black squares on the chromeball have 255 R). you see the grass that's part of KSC static mesh, and water; you don't see reflection of Kerbin till about 60km up (not sure what the real in game distance is); when the planet becomes a mesh object instead of terrain object. This could be a culling mask thing. Skybox fades in by 60km as well, but the reflection skybox doesn't get updated till you switch away to Map then back. and there's gaps between the cubemap faces. TRReflection suffered from the same problems apparently, in surface mode the reflection clear flag appears to be white. Two of the 6 faces in reflection cube map are rotated for some reason. http://forum.kerbalspaceprogram.com/index.php?/topic/84273-unity-layers-and-tags-constantly-updated/ Maybe this can help figuring out which layers to reflect and which ones not. I think you can get much better performance by adding a skybox for surface reference frame, replace the gradient thing whatever it is. PBR shaders should already account for skybox without the need for reflection probes, plus a good skybox will make surface look much nicer. Granted it might be something better as part of EVE mod. reflection probes can be added as a Part Module to specific parts similar to TR. other PBR shaded parts nearby will pick up on it when in the same vessel. easiest fix though is probably set clear flag to the sky color from the surface mode atmosphere gradient; and switch clear flag to skybox at the same time KSP switches to skybox.

so how do I interpret the data from F12 thermal display? Internal/Skin Temp; ThermalMass; easy enough maxTemp/maxSkinTemp; thermalMassModifier in the config CondFlux: Conduction? i.e. between Parts? +/- = in/out? modified by heatConductivity in config? ConvFlux: convection, heat carried away by atmosphere, +/- = in/out? modified by heatConvectiveConstant? RadFlux: radiation, +/- = in/out? heat emitted as calculated with emissiveConstant? IntFlux: Internal Flux? from effects of active radiators? and core heat? +/- = in/out? SkinToIntFlux: heat transferred from Skin to Internal, modified by skinInternalConductionMult; how to read this? + is Skin to Internal; - is Internal to Skin? SkinT.Mass: skin thermal mass... is there skinThermalMassModifier? or use same thermalMassModifier as above? mass * surface area? AR: CoolingParts x/y? radiator only cools parts with in certain branch level? heat from rest of craft has to pass through part/part conduction? AR: headroom? what is this? AR: ExcessHeat heat accumulated in excess of radiator's RadFlux? AR:XferAmt: heat transferred from Part to the Radiator? AR:AdjXferAmt: ?? heat transferred between Radiators close together?

Editable in game is awesome. linear interpolation is more predictable than specifying keys in the part config too. Win win!

Getting self-reflection not much else. The big white area covers the large shield, which should be polished gold. Exported with KSP/DIffuse, I assume is replaced with Lilleman/Diffuse in game? what does RP size do? 0.05 seems really small for RP bounds? Or is it actual size of the RP sphere? anything inside the sphere (part hosting the RP) shouldn't be reflected? Lilleman/Diffuse in Unity: http://i.imgur.com/gsUHLVg.jpg Edit: aside from self reflection, that actually that looks rather correct for mirror-like surface in space.

no, thrustCurve is part of ModuleEngine and ModuleEngineFX, controls fuel flowrate based on ratio of fuel remaining. You check for parts that use SolidFuel and add thrustCurve{} to it's engine module.

or a MM patch to add thrustCurve to SRB parts.

will test it out later today. got a part that should really shine with reflections. Is mask inputs still this? R = Metal 1= full metal? G = Gloss 1= full gloss? B = Nothing A = Occlude R channel input seems to be broken on Lilleman/Specular; the rest seems fine. techinically you only need 1 PBR shader and set input textures to the proper channels on the shader no? I guess direct replacement by name is much easier to deal with. But no real need for specular property in any PBR shader if you are going with Metalness workflow. KSP/Diffuse and Specular can both be replaced with Lilleman/Diffuse

img removed