Dr. Jet

Both SETI and ETT put Firespitter Biplane parts (primitive airplane) at the very beginning of tech tree (but not "Start" node IIRC). A single probe launch will suffice for opening.

0.9.0.4 mini-patch to counter TweakScale bug. You'll still need a latest DEV version of TweakScale for correct solar panel scaling though.

It seems that syntax like this MODULE { name = TweakScale type = stack scaleFactors = 0.625, 1.25 defaultScale = 1.25 } stopped working. I mean, module is there and it shows a dialog to change size, but no other size than default is available (sandbox mode). Other configs that does not include scaleFactors string do work fine.

Yep. Something is wrong with latest TweakScale builds and I can't find out what... yet. But it looks like pre-configured pattern overrides are disabled for parts Try to delete /ChopShop/ModuleManager/TweakScale.cfg - my parts will behave as if TweakScale was not installed.

Nice to see that this nice mod is getting alive again. Some bugs: FSbomberWing - missing collider. FSbomberCockpit - mesh mismatching with other bomber parts (and other 2.5m parts). FSbiPlaneWingCenter - collider trouble (wings cannot be properly attached with angle snapper on) There are still glitchy FSWheel{}s and weird FSengine{}s around. Hope they will be gone soon. Some suggestions: Replacing FSengine{} with ModuleEngines{} is very nice! ModuleEnginesFX{} may be even nicer as it has more tweaks. But anyway don't forget please to set "resourceFlowMode = STAGE_STACK_FLOW_BALANCE" for LF(kerosene) propellant. It is needed for CoM balance and vital for drop tanks to work properly. Add air intake to FSoblongNose (it looks like actual piston engine) for sake of FSnoseEngine. Those are designed to work in pair but neither one has an air intake. FSoblongNoseLong, FSoblongTail and FSoblongFuselageHalf should possibly have FSFuelSwitch{} config like FSoblongMultiTank. FSplanePropellerSpinner{} (at least) should be included in stock KSP (though I already mentioned that before).

It's just a suggestion. Could be a pull request if original version was on GitHub. To use it or not is completely up to you. But if I understand KSP engine correctly, same textures placed in different folders are treated as different textures thus occupying excess memory. Shared assets folder layout prevents it.

Re-packed those awesome parts into nice and tidy smaller package with DDS textures and without texture clones/substitutes. 5-10 seconds faster loading and a bit of memory saving. PARTS ONLY package. http://www.filedropper.com/irreworkparts Recommend such folder structure for next mod update. P.S. No, robostruts and wheels won't work. I didn't touch any plugin code - just re-packed the parts.

Turn them before attaching. Then if you STILL have troubles press and hold ALT key while snapping to disable surface attachment - like with a spaceplane payload.

Sad. In flight. Nodes attract to each other but don't snap, then you have to rotate with Q/E to finally snap at 90°. I was sure it was made with colliders... until I imported a .mu in blender... Good... On the other hand... core is INSIDE... no clicks will be available... It's already done with empty objects and NODE{}s. I won't be able to precisely set normals otherwise. Aah... So there are additional non-documented parameters... Interesting... MODULE { name = ModuleDockingNode referenceAttachNode = top nodeType = size2 undockEjectionForce = 0.25 minDistanceToReEngage = 3.5 acquireForce = 3.5 acquireTorque = 3.5 acquireRange = 3.0 captureRange = 1.5 } This one is from kerbal wiki. MODULE { name = ModuleDockingNode referenceAttachNode = top nodeType = octo captureMinRollDot = 0.99999 snapRotation = true snapOffset = 45 } This one is from Near Future Construction. Again some juicy UNDOCUMENTED features... Need to catch learn them all!

I started a small experiment with dodecahedric modular system. The trouble is that nodes are perfectly normal to surface of dodecahedron and parts snap perfectly normal to surface too, but their rotation around that normal is... not perfect. This brings 2 questions... no, 3 questions. Is there some way to force snap angle in VAB (around node normal)? If not... Nertea's Near Future Construction has docking port that snaps only at right angle. How to replicate such behavior? (I thought it were some strangely shaped colliders, but no, colliders in model are pretty basic.) Is there some way to safely add 10-12 docking nodes on one part?

Better post it at https://github.com/MuMech/MechJeb2/issues. More chances that some developer will read. And, yes, Landing Guidance is the most ruined part of latest MechJeb after Spaceplane Guidance.

Latest Interstellar Fuel Switch does this IIRC.

Smalll button near left kerbal portrait (becomes visible on mouseover) turns on the stock transparency. Stock looks even better than JSI (as for me) if model was treated as I wrote above.

You forgot to press CKAN button at SpaceDock.

Add a copy of your outer hull mesh to IVA model (keep it's normals "outward"). Set DepthMask shader for that mesh copy in Unity. Re-build IVA model from Unity. Profit! Works with both stock and JSI transparency.

It's a Squad/Unity united bug. Though Squad looks happy with what they did to wheel clipping and they didn't even marked that issue as a bug. I already tried a "layer 26 workaround", but it sucks. Anything you place on surface of rover will BLOCK the TR-2L wheels. And even if not - while riding around your wheels will suddenly stuck at some moment, rendering rover flying high. Tried to find a "clipping-safe" offset. Oddest weirdness, as the clipping itself.

Haber Bosch unit (wip). Not so tightly packed as I hoped initially...

Thanks! It was very... unsuspected. Are there any other useful KSP tags that weren't properly documented?

At last the thread was moved to somewhere where it's open again... Let's continue: /KSP/Alpha/Translucent_Additive - what's that? It looks very weird in Unity when set instead of /KSP/Alpha/Translucent. /KSP/Bumped_Specular_(Transparent) and /KSP/Specular_(Transparent) - they seem to neither use alpha channel, nor follow "opacity" setting for actual transparency. How to use them and what for? Porkjet's tutorial about proper usage of KSP/InternalSpace/* shaders is still eagerly anticipated. /KSP/FX/ScrollingUnlit - ??? /KSP/LightWrapped/Specular - ??? /KSP/Standard_Bumped - looks very promising. It even has "metallness" parameter! But it surely needs a thorough tutorial. Let's say we want WHOLE texture to look metallic and glossy - can we do it with just one texture without extra "mapping" textures? /KSP/UnlitColor/ - At last! A simple textureless shader! But why Unlit only? DiffuseColor, SpecularColor and EmissiveColor would be much more useful. BTW, not exactly 1.1 question, but... how to set shaders for decals (FlagTransform) so that they are invisible in part list (before flag texture even applies)? Setting no texture results in disgusting white rectangles, setting fully transparent substitute "texture"... it will work... but Squad parts don't use that.

https://github.com/RemoteTechnologiesGroup/RemoteTech/releases/download/build-develop-528/build-develop-528.zip is not available for download. Github error?

Still no advance with Fischer-Tropsch. I can't comprehend the parts. Though I've found a real industrial (non-laboratoric) FT-reactor cutted in half. and promisingly short scheme of Haber-Bosch reactor.

Annoying undisableable message is a strange way to collect feedback from my pov, but since you asked... Exception occured while saving contract parameter 'ReachSpecificOrbit' in contract 'CleverSat.CleverSatRandomShift': System.NullReferenceException: Object reference not set to an instance of an object at ContractConfigurator.Parameters.VesselParameterDelegator+<GetPathFromParam>d__15.MoveNext () [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[System.Int32].AddEnumerable (IEnumerable`1 enumerable) [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[System.Int32]..ctor (IEnumerable`1 collection) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable+<CreateReverseIterator>c__IteratorF`1[System.Int32].MoveNext () [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.Aggregate[Int32,String] (IEnumerable`1 source, System.String seed, System.Func`3 func) [0x00000] in <filename unknown>:0 at ContractConfigurator.Parameters.VesselParameterDelegator.OnParameterSave (.ConfigNode node) [0x00000] in <filename unknown>:0 at ContractConfigurator.Parameters.ContractConfiguratorParameter.OnSave (.ConfigNode node) [0x00000] in <filename unknown>:0

Patch 0.9.0.3 is out. Fixed Unity animations for all chute parts that made "Engineer's Report" to improperly estimate vehicle size. Thanks to Venusgate for reporting this bug. Added forgotten drogue chute. Fixed Counterweight part to be tweakable again. Thanks to Deimos Rast for repoting this bug. (Hopefully this will NOT lead to problems with CRP other then small noncritical warning in log.) Fixed a couple of typos and leftovers for stock rover body fixing patch. Well... impeller is working as it is. No need to set exact planets as it depends on atmospheric pressure. No pressure = no atmosphere = no thrust (at least it was so when I last checked). But you are right, thrust curves are weird. It should have much higher thrust in Eve's "souposphere" and much lower thrust at thin Duna's "ether", though atmCurve seems being set properly.

Found the root of evil for Counterweight part. ModuleManager has changed some features. It appears that nice unintrusive %RESOURCE_DEFINITION{} solution won't work anymore... Strangely you was the very first to notice, as problem exists since KSP 1.0.5 at least (checked old build) and is visible even with CRP installed (but not visible with RealFuels). I won't bundle heresy (CRP contains goddamned "Karbonite" and "Karborundum"), so the only solution left is dumb alphabetical overriding. It shouldn't break anything, since resource is a direct copy from CRP... hopefully... Also it appears that "LeadBallast" is only tweakable now with RealFuels interface, but not with stock one... so I will use "Lead". BTW, parachutes are almost ready. Some final checks for actual balance and I will update.

SETI supports my mod, thus uses independant re-location of parts, I was talking about stock tree. It's not a "minimum", it's an "off" setting. While antenna is stowed it still catches signal up to 100 km (enough to reach 50 km altitude where you usually deploy fairings and stuff). Another typo? Will check it. Hm-m-m... Have checked it with RF but not CRP... Already have an idea how to fix. Plays fast in VAB? Really don't know how to fix - plenty of mod parts have the same problem. Main animation is quite slow and comprehensible. On the other hand, it actually DOES NOT have to hit the ground like Dmagic parts, only landed state is counted, since it's stock science module. Aligning it right serves just cosmetic reasons. Well, patch for RealChutes is possible, but why? RC already have inline chutes, and they are way better than mine. My chutes were made for those who don't want to install RC, but do want to balance return stage parachuting. The only reason would be that CLS-passable part since RC inline chutes are not passable... But you can just use an RC-supporting para-dock part from Sum-Dum or Ven's Revamp. Backside of using stock textures. Will look into that but no promises. You see 2 of 3 if you have TweakScale. It's a part of de-cluttering patch. Smaller one will be tweakscale-able. "A bit of an odd duck" seems too english for me to understand. Is it "underpowered" or "overpowered"? When I was tweaking this impeller by try-and-fail (I guess it was the first non-Firespitter electric propeller in KSP), main goal was to make it flyable on all 4 stock atmospheric planets. If you have better curves for it, I will implement them. I suck at texturing. Really. And all parts that looked like metal in 1.0.5 (partly saving me from shame) now look... strange.