Dr. Jet

Is there any documentation on how to (re)configure Regolith? I just tried MKS/OKS mod and was unpleasantly shocked to find that: 1) Kerbin "Water" biome have scarce water in crust and ZERO water in actual water. 2) Mun have water resource in huge plain openings of giant craters and does not have it in narrow fissures (Canyons) 3) Minmus, which is described as iceball, have no water in most biomes. Haven't checked Duna for CO2 atmospere and water at icecaps, but almost sure it's not there. All that nonsense was produced by random resource generation, I suppose. Is there any way to tell Regolith which biomes must have which resources? I mean something like this: [table=width: 600, class: grid, align: center] [tr] [td]Water density[/td] [/tr] [tr] [td]Planet[/td] [td]Abundant[/td] [td]Decent[/td] [td]Scarce[/td] [td]None[/td] [td]Random (decent)[/td] [td]Random (scarce)[/td] [/tr] [tr] [td]Kerbin[/td] [td]Water,Poles[/td] [td]All other biomes[/td] [td]Desert,Badlands[/td] [td]-[/td] [td]-[/td] [td]-[/td] [/tr] [tr] [td]Mun[/td] [td]-[/td] [td]-[/td] [td]-[/td] [td]All other biomes[/td] [td]Polar lowlands[/td] [td]Highland craters, Canyons[/td] [/tr] [tr] [td]Minmus[/td] [td]All biomes[/td] [td]-[/td] [td]-[/td] [td]-[/td] [td]-[/td] [td]-[/td] [/tr] [tr] [td]Duna[/td] [td]-[/td] [td]Poles[/td] [td]-[/td] [td]All other biomes[/td] [td]-[/td] [td]Craters[/td] [/tr] [tr] [td]...[/td] [td]...[/td] [td]...[/td] [td]...[/td] [td]...[/td] [td]...[/td] [td]...[/td] [/tr] [/table] Explanation: Water is pretty abundant on Kerbin. And kerbals know where to find it. Mun is barren planet with no atmosphere. Freezing nights, scorching days and vacuum around. Small amounts of water (ice) could resist evaporation only in eternal shadows of deepest craters and fissures, especially polar craters. But that's just an assumption. Minmus is an iceball. Literally. Be fast to mine ice until it evaporates. Duna is pretty arid. Polar caps are thin. Small amount of ice could persist at craters... possibly... [table=width: 600, class: grid, align: center] [tr] [td]Ore density[/td] [/tr] [tr] [td]Planet[/td] [td]Abundant[/td] [td]Decent[/td] [td]Scarce[/td] [td]None[/td] [td]Random (decent)[/td] [td]Random (scarce)[/td] [/tr] [tr] [td]Kerbin[/td] [td]Mountains[/td] [td]Highlands[/td] [td]All other biomes[/td] [td]Water,Poles[/td] [td]-[/td] [td]-[/td] [/tr] [tr] [td]Mun[/td] [td]-[/td] [td]-[/td] [td]-[/td] [td]-[/td] [td]crater biomes[/td] [td]non-crater biomes[/td] [/tr] [tr] [td]Minmus[/td] [td]-[/td] [td]-[/td] [td]-[/td] [td]-[/td] [td]-[/td] [td]All biomes[/td] [/tr] [tr] [td]Duna[/td] [td]-[/td] [td]-[/td] [td]-[/td] [td]-[/td] [td]All biomes[/td] [td]-[/td] [/tr] [tr] [td]...[/td] [td]...[/td] [td]...[/td] [td]...[/td] [td]...[/td] [td]...[/td] [td]...[/td] [/tr] [/table] Explanation: Kerbals do know where to mine and where to not mine on Kerbin. They are smelting metal for rocket parts afterall. Mun is small light planetoid thus unlikely to have any rich deposits, but you may find remnants of ore-rich impacted asteroids within craters... or may not - if those were icy-type. Ore can be present on Minmus only in form of small asteroids, impacted and frozen in ice (bigger asteroids woulds have broken Minmus apart). No predictions of where you can find those. Duna is heavier then Mun and its rusty color speaks of iron deposits being there... But WHERE?

1) There no lights on Lunokhod rovers IRL. Those "eyes" are TV cameras. 2) Nodes were moved in patch to re-orient rover horisontally and make it fit with old Luna-17 model. 3) Due to model and/or config changes, nothing fits now as it should even after re-rescale, so further support will be removed. Thus there are no more working configs for Lunokhod missions at 0.90. P.S. Maybe one day I will catch an inspiration and draw stockalike Munokhod-1 + Muna-17. But that's very unlikely in short terms. Don't have time to even update properly.

My mod has the patch config for it, so both Lunokhod and Luna 17 from corresponding mods worked correctly at 0.25. Still should work at 0.90, I believe.

When you are trying to configure dual-axis solar panels (which is actually an engine exploit), you should provide suncatchers and pivots for each AXIS, not for each PANEL. Something like this. GameObject->MainPart->RotativeCollar-> ->Suncatcher1 ->EmptyObjectForRotation-> ->PanelBase1->PanelBody1->Suncatcher2 ->PanelBase2->PanelBody2 RotativeCollar and Empty Object is what you should actually rotate as both panels have common axis and keep the same direction - there is no need for 3-rd suncatcher and config module. And don't forget that your Rotative collar does not produce electricity. If that's not comprehensive enough - PM me again - will send you a blender file with working hierarchy. BTW are you using Unity animation or imported (Blender, Maya, etc.) animation for panel deployment? If it's Unity - plz PM me when you finish... Maybe your part won't have that nasty animation bug my part have...

Your idea is very nice, but... 1) Stock "Oxidizer" is not LOX. Why? Let's just sum up some known facts. It is used along with stock "Liquid fuel" which is almost undoubtely a replica of RT-1 (Kerosene). KeroLOX is OK, but is not the only available Kerosene-based mix. It is available at the lowest tech level (Kerbin 1940-s or 1950-s). LOX was used at earliest german rockets, but there were lots of tries to replace it with something less cryogenic and more manageable at 50-s. Nitric acid, dinitrogen tetroxide, dioxygen difluoride, etc. It lets multiple ignitions on ANY engines - even the most primitive ones. IIRC KeroLOX requires additional ignition systems to do that. It can stay in tanks for YEARS - even under the burning rays of Kerbol at Moho orbit. LOX is cryogenic and thus not very storageable. Not a single LifeSupport mod treat it as a source of breathable oxygen. So it's NOT an oxygen, right? At least not a pure oxygen... Summing up the facts above, we can conclude that "Oxidizer" is some kind of hypergolic oxidizer allowing self-ignition rather then LOX. Most probably it's one of many HNO3/N2O4 mixes that were used IRL along with kerosene. Hydrazine/NTO looks more realistic LFO decifer then Kerosene/NTO, especially in terms of self-ignition. But since both are viable and LF is treated as Kerosene... On the other hand - you need to make MM configs anyway... 2) Treating monopropellant as hydrazine is plausible (especially concidering N2H4 being the most common monopropellant). But hypergolic N2H4/N2O4 (hydrazine/tetroxide) mix in this case will look like "Monopropellant/Oxidizer" and that's just ODD. Maybe an MM patch replacing all parts "Monoropellant" with "Hydrazine"? 3) Methane is a must for any ISRU mods support. It's a byproduct of Sabatier process (both life support oxygen regeneration and ISRU fuel production) and also was and is concidered as an alternative fuel for real nuclear drive projects, providing better thrust at cost of lower ISP (comparing to liquid hydrogen) while not being as highly cryogenic. So... we should have such fuels and mixes: Kerosene - for jets and propellers Kerosene/NTO (skipping the nitric acid part) - robust early/lowtech mix, not messing with cryogenics Hydrazine/NTO - effective hypergolic mix for both engines and RCS Hydrazine - monopropellant for RCS and smallest probe engines Kerosene/LOX - cheap and dense lower stage mix, more efficient than Kerosene/NTO, less expensive and poisonous then Hydrazine/NTO, but needing cryogenic tanks for long term missions H2/LOX - highly cryogenic mix - either use it as low stage or face severe boiloff CH4/LOX - not-so-highly cryogenic mix - mostly for ISRU refuelling capability and to utilize LS byproduct H2 - highly cryogenic nuclear propellant severe boiloff!) CH4 not-so-highly cryogenic nuclear propellant (less boiloff, more thrust, less ISP) Xenon - ionic propellant P.S. CH4/NTO mix is possible but not viable. P.P.S. ÚÑÂтðтø, üþöõü þñÑÂуôøть ÿþ-руÑÂÑÂúø, õÑÂûø ÑÂтþ уôþñýõõ.

Excellent mod! The only important feature lacking is MechJeb integration. I mean feeding contract waypoint coordinates to Landing Guidance or Rover Autopilot would be nice, no?

I looked at your model. Engine collider is neat and accurate, but it don't look like GREEN Unity collider. Did you use BLUE Unity collider instead? BLUE colliders fall through the ground every time. GREEN ones don't. Cut the bottom part of your collider and make it GREEN to succeed. OR just add GREEN BOX collider to the bottom in Unity, not touching the model.

Any ETA on Science Bay IVA? It's my favorite part in the pack, but no IVA... makes the crew sad.

Speaking about "command stations" feature... It seems bugged. I have a station with 7 crew, stock 2.5m probe core and active omni antenna. In the same orbit 22 km away there is a probe with active omni antenna. Neither station nor probe is connected to KSC, but apparently probe IS connected to station (omni-omni). Station is "Local control"led and should work as "command station", right? But it does not. "No connection" is displayed on probe whatever I tried... Update: It seems that problem is with omni-omni connection... When I HyperEdited randezvous distance to be less then 3 km - probe inbuilt antenna kicked in and provided a green command link with zero lag (to the station I suppose, as it was still out of KSC link zone). When I tried to fly probe away - link disappeared out of 3 km zone. Update 2: Rebuilt probe with dish antenna, pointed station's dish to it and vice versa. Still the same sh*t - connection disappears out of 3 km radius... AND also probe's dish target becomes "unknown target" instead of station.

Use Firespitter. Early vehicles like biplane are fine with all those bumps.

Exactly! What I suggest to do - is to experiment with same-sized SP Mk2 craft. It should be barely glide-stable at 120 m/s and should not flip over the 2.5m rocket when launched on top. Than just sum up the lift coefficients of it's parts and divide them between Dreamer parts. BTW. Make your landing gers physicsless (PhysicsSignificance = 1), if you haven't already. They are NOT FAR-shielded when retracted (and provide extra drag in stock model). The same refers to cargo bay payload - it's NOT shielded, as cargo bay is not something separate and Dreamer body is not concidered by FAR/NEAR to be shielding part. Right now I recommend to stick with NEAR. It's not overcomplicated as FAR, but pretty stable and gives you much, much more fun then stock "soup". It's most likely that Squad will implement NEAR or NEAR-like model. Implementing FAR model in stock... is impossible. Squad tries to keep game simple even at cost of realism. I had some experience with complicated colliders (look at SP tails and lander tanks from my mod). It's quite simple in fact - most efforts are spent on low-poly subclones for green colliders (and you generally don't need those everywhere - just in some important places). Landing gear is simple. I've managed to make even ACTIVE (motorised) landing gears with stock modules alone (though it was hybrid of rover wheel and landing leg modules). Most common things one screw at when making wheels or landing gears are: 1) Proper Unity parts hierarchy. (covered by tutorials from KSP forum) 2) WheeelCollider parameters. (unluckily no tutorial for those - just keep experimenting until you got something working) 3) Improper animation import parameters (anything other then "Legacy" is wrong). If you share corresponding blender and unity files, I'll be able to help with landing gears and tidying up the colliders.

Tested with N.E.A.R.: - Ascension stability (with included launcher) is OK. It's not amusingly good, but OK. With stock parts it's NOT stable even with 8 winglets at the bottom of the rocket. BTW, your FAR/NEAR LKO launcher should have around 3600 dV, not 5000. Maybe worth concidering an MM patch. - Atmospheric stability (without launcher) is very high. It's WEIRD to see that on a Spiral-alike "flying bast shoe"... However it's OK for me, as it dampens my piloting mistakes. - Stable gliding at 80 m/s is just an overkill for such craft. You possibly should lower lift coefficient to something more realistic. Resume: Weird but flyable. About model itself: - You really should use Mesh Collider (blue) for main body (+2-3 invisible primitives for green colliders) and cargo bay doors (no greens). Right now kerbals are falling through when trying to walk on top. Also unable to correctly surface-mount parts at some places. - Rear landing gears - wheelColliders could use some non-zero suspension distance. - Wings control surfaces seem to be not animated. It's not an issue, as mod is still WiP, but nevertheless... - FS module for landing gears is overkill. For such simple stiff non-steerable things stock module is all you really need. - Main body of cargo-bayed Dreamer have a transparent hole at front. It's clearly visible in VAB and when using docking nosecone. Maybe some normals were accidently inverted? - Air brakes have spoilers AG commands though they don't react to brake button or work as spoilers. When assigned to AG as "Toggle Air Brake" they work fine. About IVA: - AWESOME! Best shuttle/spaceplane cockpit i've seen yet. Beautiful and with (almost) full MJ integration. - Bottom (landing aid) camera is looking rearwards and upside-down. - First pilot (Jeb) seat should be left one (near the camera screens), not right one.

Look at my decoupling blisters for how to config such decoupler/retrorocket hybrid right. I believe welding with UbioZur tool leaves some unneeded config pieces that block simultaneous firing. Can't prove though as I haven't tried welding since 0.22. Not seeing the actual config, I can just quess possible troubles... 1) More than one "stagingIcon =..." line. It's a guaranteed glitch. 2) Lack of "ActivatesEvenIfDisconnected = true" in config. 3) More than one MODULE [ModuleEngines]. I'm not sure how multiples behave in 1 part. On the other hand I'm pretty sure that single should handle all "thrustTransform"s from MODEL subparts right.

DMagic Orbital Science have both parts to squeeze science out of anomalies and missions to do it. Missions are buggy though... When you have more than one anomaly on a planet - you never know which one will count for mission completion.

What is really interesting - is how this birdy behave in FAR/NEAR physic model. Pteron for example was still unable to defeat CoL bug when I saw it last time.

Would be magnificient to see this as a MechJeb module. Much smoother control it shows.

Old versions of DRE gave you 3-4 seconds of chutes actually burning on overspeed (with FX effects!) and part exploding. Now it's just a momentarily "tear off", which saves your parts but instakill predeployed chutes. Sad thing is that DRE author think that it's BETTER than old way of treating overspeed. Basically you have no other choice than to configure chutes to predeploy at 1500 and deploy at 500. DRE kills them otherwise.

So they finally fixed that? Glad to hear.

Tweakscale support is already configured for all parts where it have sense. SPP Mk1 model is OK at 0.625 and 1.25 sizes, but looks crappy at bigger sizes. I'll make SSP Mk2 for those - maybe something with Gigantor-alike deployment. If you want to use more sizes with SSP Mk1 or any other part - just edit /ChopShop/ModuleManager/TweakScale.cfg TweakScale thread have a comprehensive guide about syntax. Oops... I see... I've included a wrong 1.25m config for those NOT using TweakScale. This should work: PART { // --- general parameters --- name = SSP_mk1_125 module = Part author = Dr.Jet // --- asset parameters --- mesh = model.mu scale = 1 rescaleFactor = 2.5 // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_bottom = 0.0, -0.05, 0.0, 0.0, 1.0, 0.0, 0 node_stack_top = 0.0, 0.05, 0.0, 0.0, 1.0, 0.0, 0 // --- editor parameters --- TechRequired = advElectrics entryCost = 5200 cost = 3200 category = Utility subcategory = 0 title = SSP Mk2 (1.25m) manufacturer = Dr. Jet's Chop Shop description = Smart Solar Panels Mk 2. No more dead spots! Two-axis rotation guarantee your panels to ALWAYS face the sun. Batteries included. Works better when activated by action group. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,1 // --- standard part parameters --- mass = 1.6 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 1 crashTolerance = 8 maxTemp = 1200 RESOURCE { name = ElectricCharge amount = 800 maxAmount = 800 } // Central pivot rotation. MODULE { name = ModuleDeployableSolarPanel animationName = start // To make central pivot ALWAYS active and get rid of surplus AG-actions - comment this line // sunTracking = true // And uncomment THIS line. raycastTransformName = MainRotator pivotName = MainRotator isBreakable = false resourceName = ElectricCharge chargeRate = 0 powerCurve { key = 0 0 0 0 } } // Solar panels deployment and rotation. MODULE { name = ModuleDeployableSolarPanel animationName = extend raycastTransformName = PanelC pivotName = solarPivot isBreakable = true resourceName = ElectricCharge chargeRate = 48 powerCurve { key = 206000000000 0 0 0 key = 13599840256 1 0 0 key = 68773560320 0.5 0 0 key = 0 10 0 0 } } } Will include this hotfix in next patch. Well... no. Stock Squad textures which I use don't fit well with cylinder shapes. P.S. I thought people were asking for 2.5 adapter to mount B9 S.A.B.R.E. Mk2. P.P.S. Check to myself - add KSPI precooler module to it.

v 0.6.2 - New SpacePlane+ parts: Wide Tricoupler (3 x 1.25m + 2 Ram Air intakes, capable of holding LV-N engine) and Drone Nosecone (air intakes, RT and RPM support), both using stock textures. - configurations for 0.625 jets, aerospike and aerospike adapter. - 1.25m configuration for SSP Mk1 (model looks quite crappy at 2.5m and above, so it will be SSP Mk2 with another model and animation) - new sample crafts - some minor bugfixes Picture doesn't show the frontal intakes of Wide Tricoupler... Those are just clones of stock RamJet-alike ShockCone Intake. Foreseeing a question about comparatively small fuel amount in Wide Tricoupler: side subfuselages don't host fuel, they are something like S.A.B.R.E. precoolers. And they are configured to have such function if KSPI is installed.

V 0.6.1 - New SpacePlane+ parts: Quadcoupler (2 x 1.25m + 2 x 0.625m) and 2.5m Adapter, both using stock textures. - Blister stripes are darker to draftly match SpacePlane+ side stripes color. Mechanical soil sampler is still experimental alpha with crappy config and texture. I have some ideas how to improve it, but cannot predict ETA. Now working on widened fuselage end with air intakes and 3x1.25 connectors, capable of holding LV-N in the middle. Should I make air intakes RamJet style or TurboJet style? Ramjet intakes are realistic for spaceplane... also half dipped ramjet intakes are used IRL in russian Moskito antinaval missile... on the other hand we don't have any ramjet engines (rear parts) in game except hybrid RAPIER (which is not a true ramjet also, as it provides nonzero thrust at zero speed). Turbojet intakes are less (if at all) realistic for spaceplane, but we do have decent turbojet engine... and turbojet intake fan can be animated. How do you think , should I include 0.625 jets configs for those not using TweakScale?

Either DON'T use FAR/NEAR or land by hands. Current spaceplane landing sequence is incapable of safe landing with aerodynamic mods installed. And noone in MJ team is currently working on better algorithm.

Which is realistic. Kerbals want to go to space, but at the beginning they don't know what will meet them there - behind the sky and how they should prepare for the flight. They should launch at least couple of unmanned missions to find it out and be able to design something capable of delivering living kerbals. Thus USA Explorer was measuring radiation levels, soviet Sputnik-1 was measuring temperature and pressure, Sputnik-2 was a test of experimental basic life support system along with monitoring living object condition (Mystery Goo experiment in KSP terms)... All those early unmanned missions IRL gave a precious knowledge needed to start a basic manned programms like Gagarin's flight. And that's by any means better then "launching" a single pod for kerbal "taking samples" at the launch site. They could do it without a pod actually. Which is full of annoying "features" in addition to the tree - like making most pods unsuitable for space travel not only for early tech levels but for the whole game. At least so it was in 0.23 version. That's your opinion, and my opinion is that a bit of realism never hurts.

So... What's the trouble? When you don't touch config leaving is pure stock with a "mesh=" - it should still display texture as you don't change it's name in .mu. When you touch config and replace mesh with model{} - in most cases you don't need to specify a texture - it will use the same file from the same folder. BTW... can't remember Taverio's Pizza pack fiddling with I-beams. What for? Linear Aerospike is just a SINGLE working model while circular aerospikes are handmade and tested by rocket enthusiasts in all world. BTW my part pack has an adapter for stock or stock-ish circular aerospike to use it in upper stages. Linear won't fit. It will, believe me. I fiddled a lot with constraints while experimenting with wheels. If you still want to replace stock model - just make more petals, place them overlapped and a bit cone-oriented (in-flight position) - like this. It's a real russian 1.27m turbojet AL-31FP. See a petals base? It's a coil dipped in another coil thus leaving no gaps when gimballing. Symmetrical petals are just controlling the nozzle shape (Bahamuto Dynamics animation module if you want implement this in KSP) - and exhaust direction is controlled by petal base (stock gimballing animation). This or something similar will look good and realistic. Extremely easy when you have corresponding tools. I was using this batch file. SETLOCAL ENABLEDELAYEDEXPANSION SET localdir="%1" SET DDSTool="C:\Program Files (x86)\NVIDIA Corporation\DDS Utilities\nvdxt.exe" SET mbm="C:\Users\User\Desktop\PNG Tools\mbm2png.exe" FOR /R "%localdir%" %%F IN ("*.mbm") DO ( CALL %mbm% "%%F" IF EXIST "%%~dpnF.png" ( del "%%F" ) ) FOR /R "%localdir%" %%F IN ("*_NRM.png") DO ( CALL %DDSTool% -dxt5nm -outsamedir -quality_highest -nomipmap -flip -file "%%F" IF EXIST "%%~dpnF.dds" ( del "%%F" ) ) FOR /R "%localdir%" %%F IN ("*_NRM.tga") DO ( CALL %DDSTool% -dxt5nm -outsamedir -quality_highest -nomipmap -flip -file "%%F" IF EXIST "%%~dpnF.dds" ( del "%%F" ) ) FOR /R "%localdir%" %%F IN ("*.png") DO ( CALL %DDSTool% -dxt5 -outsamedir -quality_highest -flip -file "%%F" IF EXIST "%%~dpnF.dds" ( del "%%F" ) ) FOR /R "%localdir%" %%F IN ("*.tga") DO ( CALL %DDSTool% -dxt5 -outsamedir -quality_highest -flip -file "%%F" IF EXIST "%%~dpnF.dds" ( del "%%F" ) ) pause Just set proper paths for where you keep nvdxt.exe and mbm2png.exe then drag any folder you want to convert on your .bat Guys in DDSloader thread have released some python script for even more automation, but I haven't tested it. Batch works fine.

What do you mean by "Size 2"? 2.5m cylinder or S2 form-factor (B9)? Both are quite easy to do but questionably useful. 2.5m parts couple great with S2 and Mk3 but they seem too fat for flattish Mk2 (1.25x2.5). Will bigger size configs and/or TweakScale integration be needed for SSP? Current design was made and balanced for ion-propelled probes, but if people want something bigger... Blisters were colored to draftly match stock FL-T800. What other parts do you have in mind exactly? I'm not an artist by any means, so any good ideas about model upgrading or retexturing are appreciated.