nholzric

I made a new space cruiser I was able to launch the habitat portion in career but switched over to sandbox to test out the design before launching the drive portion. Here I'm getting ready to test out the heatshield over Duna. This test was only from an orbit near the edge of Duna's SOI down to 20km altitude - I have a hard time waiting for launch windows so I expected this test to be fairly tame since I was *only* at the edge of Duna's SOI. By the way, I love the new cheat menu. It makes it so easy to jump over to a sandbox game, copy over some craft files, and do some testing. I've been practicing launching from Duna and now I get to test out my cruiser design without spending the time launch, refueling, and transferring it in career. Love it. So the test didn't go very well. As you can see this design is not stable during such an extreme aerobreak maneuver; it spent the next couple of minutes flying backwards through Duna's atmosphere. The good and bad news is that 20km is way to low, it didn't escape the atmosphere for another go-round so maybe if I test with a higher periapsis it will fly straight. The other bit of good news though is nothing blew up from over heating! After more testing: 1) The radiators seem to be complete overkill, I fired the engines at 100% for about 1/3 of the ships fuel with the radiators activated and nothing overheated 2) The heatshield may be worthless, in orbit of Kerbin I went to the edge of Kerbin's SOI and then set a periapsis of 40km. Things got very explody very quickly... and then the ship started tumbling and things got even more explody - including, ironically, the heatshield.

I landed my first space plane today! It is carrying 5 crew returning from Minmus. I have a hitchhiker shuttle that brought everyone down from Minmus; the space plane rendezvoused with the shuttle at the Kerbin Space Station. We landed safely! Not exactly on the runway, or very close to the launch complex at all, but safely none the less. And we probably got 1/5 or 1/6 of the way closer to the space station in powered flight, maybe there'll be a runway landing next time. The space plane launches on a big'ol rocket. (I always get frustrated building useful SSTOs) Recovering from the desert returned 15k funds and the rocket costs 60k funds so maybe not the most efficient but way more fun than a pod!

The first time I noticed the attachment nodes was when I decoupled a satellite with a resource scanner on top and the satellite got stuck between the rocket body and the scanner. No scanning for me on that mission! So it sounds like I've had the same problem as @McQuacker and ever since then I've turned the truss and nodes off. Having automatic nodes inside fairings sounds like a good idea, I'm just not sure how to use them yet.

That's correct, I have an adapter from type 2 to 1.25m and then a 1.25m nose cone. I'm really curious how much this open node, or mismatched node, drag matters. We understand it intuitively, but just like the antenna causing drag in the cargo bay I wouldn't be surprised if our intuition and stock game mechanics diverge in a measurable way.

I've had the same problem - detach a rocket body (with probe and power) from a space station which has a signal in order to de-orbit but discover that the built in antenna on the probe can't connect to a signal across the 10's of meters to the space station. My space station, just like your "relay satellite" didn't have a "relay dish" on it. But here's something I don't understand - my early satellites around the Mun sometimes cross link with each other, and they don't have relay dishes on them. Are there some situations where regular (non-relay) antenna will be used to as a link? Is a "relay dish" only needed for transmitting science or conversely only needed for transmitting control?

Ah ha, I almost didn't post this because it seemed like too simple a question but this is an interesting discussion - thanks everyone! @Val Thanks for the tip about air intakes. Is there anything in game that would clue me in to how many air intakes are enough - other than engines stalling out at high altitude? Other than the adjustable ramp and shock cone exceptions what you're saying is more than one intake (from the same tech level) per engine is just causing drag. An engine's performance does not depend on the amount of air supplied, as long as it is "enough" it will run and if it's not enough it will either supper and/or flame-out. The batteries and antenna aren't attached to the cargo bay walls but they are attached to the wall of the tank in front of it. Visually they are in the cargo bay but I can imagine from a coding perspective how they would act like they were mounted on the surface of the craft. I know how to fix the design to remove these parts' drag. @AeroGav Sorry about the pictures not showing the back - at least the pictures are not in the dark! I do have a reversed nose cone to cap off the main body. Assuming total engine output at constant altitude/speed is a good measure of drag then we can run the experiment of if empty nodes matter. But even better, concerning this areo data option you mention, I've seen the different colored vectors showing lift and drag coming from each part but does this areo data option show net scalar values for your craft? If so, cool, I should have been using that. @Raideur Ng Agreed, it's too bad the "fast looking" MK2 parts apparently have a lot of drag. I wonder if this is a design/balance thing (meaning there's some parameter in the part saying drag=lots) or if it's an artifact of a wider frontal cross section and you and I are just fooled by the aesthetics.

Hey, I'm wondering if you can explain why one aircraft goes faster than the other. In the following screen shots I'm at about 1.6km altitude. The second aircraft tops out at 334 m/s, the first aircraft is throttled down to 334 m/s and I have the various air intakes visible. This guy has about 365U of airflow per Panther engine. It's hard to see in the picture but he also has an antenna, barometer, and atmosphere sensor hanging off the belly (more drag?). Since this guy is pretty much at stead state his one Panther producing 45.9 kN of force means his drag is about 45.9 kN. This guy has about 430 U of airflow per Panther. Inside his cargo bay he has an antenna and batteries but I assume those don't add to drag with the cargo bay closed. This guy is also pretty much at steady state and his two Panthers are producing a combined 149 kN so his drag is about 149 kN. Is the reason the second guy goes so much slower that he has 3x the amount of drag - such that 2 Panthers on the second guy can't outperform the first? Is this the correct line of analysis or is there something else I should be looking at? Thanks!

Sorry, I put this in the wrong thread, my game is unmodded. I was using the older build (I downloaded from the store when the silent update was released, I don't know how I screwed that up), but I just downloaded the new build (128?) and the problem still exists. Astronauts are missing from the Astronaut Complex (but still count towards my total astronaut count) and I can't enter any of my flights from the Tracking Station.

I was building a Minmus station for a contract in two launches. Once the second piece docked the contract wouldn't complete, it didn't detect the coupla module from the first launch - this probably the issue mentioned by Arsonide here [url]http://forum.kerbalspaceprogram.com/threads/138829-Possible-new-bug-Cannot-complete-orbital-station-contract-%281-0-5%29[/url] I was also have trouble with this station where the crew would disappear after transferring crew from one module to another. This has been mentioned in other recent posts and is solved when reloading the vessel. But at one point I became unable to enter my Minmus station from the Tracking Station. I could click on it and it would focus the camera but the button to enter was grayed out. The Kerbals were also missing from the Astronaut Complex, they weren't in the "Lost" tab and they were not subtracted from my astronaut count. I quit the game and reloaded it and it was not fixed. I quit KSP and reloaded the game and now I can't access any of my vessels from the Tracking Station. output_log.txt is full of the following, presumably from me clicking on the various vessels in the Tracking Station. [quote](Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at KnowledgeBase.UpdateVesselInfoList (.Vessel v) [0x00000] in <filename unknown>:0 at KnowledgeBase.FixedUpdate () [0x00000] in <filename unknown>:0 [/quote]

Awful idea, this will force me to come up with more creative ship names or be forced to stare at an insipid label for the entire flight. (Just kidding, this would be pretty cool!)

I have a thread at the following link concerning how to let the player discover or explore interplanetary trajectories. Basically, there would be maneuver node like objects, I called them "transfer nodes" that, instead of being placed on a ship's trajectory, would be placed on the trajectory of the body the ship was orbiting. If I was orbiting Kerbin, I would zoom out and click on Kerbal's orbit to place a transfer node. Just like a normal maneuver node, I would adjust the three elements of a potential maneuver while monitoring the dV requirement. I could slide the transfer node around Kerbin's orbit allowing to me discover transfer windows up to one revolution later (a whole year for Kerbin) or more if there's a "next rev" button. http://forum.kerbalspaceprogram.com/threads/108944-Transfer-Nodes This doesn't address the zoom problem or how unwieldy maneuver nodes can be. I think your inset view is a good idea, or at least starting down the right track! Thanks for sharing! Brilliant! The one thing the transfer node idea has going for it is the "self discovery" aspect - the player can fiddle with the transfer nodes until he "discovers" a transfer window or at least an inexpensive enough transfer. The transfer node idea has a few problems though, for example I'm not sure if it is possible or how the dV cost of the transfer node would be related back to a ship; ultimately the player wants a maneuver specific to a ship and its current orbit, I don't know if it's possible to make that translation from transfer node to maneuver node in a useful way. Your coloration idea sidesteps this translation issue and sounds very intuitive for the player.

OH OH! Pick me! I have a Minmus mining operation, too! Right now, 0% efficient. I hope to launch the converter unit sometime this weekend. Also, I don't have enough power to run even one drill. The solar panels were primarily for cooling - thinking the drills will heat up the tanks which will be cooled by the panels, don't know if this is a good design yet, I'm open for suggestions. I plan on launching a power until eventually with MOAR SOLAR PANELS. Also, I plan to have a truck with an orange tank shuttle between the base and a landed orbital shuttle to transfer fuel (and the truck will probably have a fuel cell to help power the base). Neither the power until nor the tanker are designed yet. Several funny stories. First, the silver tanks and Twitchy's on the top are just the drop tanks, I'll detach them eventually. But when I was landing the drilling unit the first time I had positioned the engines directly over the tanks - for symmetry. I noticed my mistake when I wasn't getting any acceleration.. and then two tanks exploded... and then the drills started overheating. That episode ended up lithobraking at about 70m/s. The current design still heats the tanks and panels but thankfully Minmus is pretty forgiving in terms of required dV so it made it down intact. Second, the boosters that launch these assemblies have enough dV to land on their own, it's just everything would be oriented the wrong way and I wouldn't know how to uncouple the payload on the surface. So, the result right now is the mining module launch ended up lithobraking about 1000 units of liquid fuel on Minmus. Will I ever mine that much? On Minmus, maybe, maybe not. But it's for science! (this is my first surface base and I'm so proud!) Lastly, I originally though I'd land the fuel shuttle rocket on some sort of launch pad assembly with a docking port figuring flying up to a docking port facing up is way easier than flying to a docking port facing sideways. And hey, I'm a bad*ss pilot (in KSP - when no one's looking) so no problem... It obviously it didn't matter too much where I landed the first module. The second module landed all of 600m away from the first. I probably could have gotten closer if I wanted to but the Twitchy's were heating the tanks and I was anxious to set down. But yeah, I'm disabused of the notion that I can land on top of a docking port. Actually, I'm disabused of the notion I *want* to land on top of a docking port - you know I totally could if I wanted to, because I'm awesome.

Win! I've avoided the full sized claw because I've heard it can cause unexpected world-ending events (or something similarly inconvenient) when used on the surface for fuel transfer. Does this have the same problem? I don't have the details on the original problem, if this has the same issues are there a couple of do's and don'ts to avoid ending the universe?

Added a second component to my first ever base. It's ALIVE! (and it needs more batteries...) The rover doesn't move nearly as well on Minmus as it does on Kerbin. On Minmus the breaks don't work (at all) and it's an effort to get it up to 3m/s. Is Minmus slippery? Do rovers adjust their controls in proportion to the gravity? Do some wheels work better on Minmus than others? I figured I would have to be very careful to keep it from flying off somewhere or flipping over but in reality it's a struggle to get it moving.

Rocket occlusion. I knew wings, intakes, and jet engines were all more sensitive to being blocked. But I didn't think about rocket engines until I was making my final approach to Minmus the other night. I was using two of the orange side-mounted deals ("Twitchy's"?) and was already a little worried about TWR even on Minmus. I was in map view when I throttled up and my speed wasn't changing. I switched to flight view just in time to see two of my ore tanks explode. I thought to myself "That's okay, I have five more ore tanks" but unfortunately directly below the two exploded ore tanks were my two drills... and I didn't have any extras of those. I lithobraked at 70m/s.

My two cents: Trying to recover of every discarded stage is a distraction. From my perspective people got overly excited when money was added thinking that means they should try to recover every last spent booster. If you can, more power to you - it's a challenging problem. But I don't think that's a required or even encouraged activity - even if it's somewhat supported - so it doesn't justify a lot of effort to be made easier.

LOL Fair point. Hopefully it's a dual rather than a brawl. "Telling, not showing" That's probably the heart of it. Even if it was insta-scan of certain latitudes, the player would have control over what he cared about and, if he didn't already know, "learn" that to cover the entire planet he needs a high inclination. I admit the immersion is a big part of it for me too, but that's preference. Some of us like climbing down ladders to do science ("immersion") some of us don't and that's cool. But the "telling, not showing" is what surprised me about the new mechanic. I would be fine with an insta-scan of some or all of the planet that's in view. At least then the orbit plays some role. Give it a maximum distance and an angular field of view. That would eliminate most of the time-warping compared to a scan-sat type mechanic, it would make the sensors useful for a little longer per planet visit, it would make the orbit important - I think that would address the major objections to the current system, it sounds like a good compromise. In fact, this is very similar to how the other scanner works and they would still be complimentary since it is impractical to survey an entire planet with the narrower field of view. --- Last night I landed my first base (ever) on Minmus. Very excited. I had already done the ground test on a number of different biomes as I was collecting science. Before I landed the base I had a satellite with the narrow field of view scanner :: in a polar orbit :: trying to get an idea of what the maximum concentration was (I think I landed on 5 or 6% - is that good?). So RoverDude said one of the features of the new mechanic was the multiple sensor types and how they play together which sounds great! In contrast to the hubris of the title of this thread - the fighting words - let me be completely humble. I don't understand the interplay. What did the surface scans do for me, did they make the narrow band scanner more accurate? Do either the narrow band or the surface scan change the orbital heat-map? I'll poke around other threads, I'm sure there's an explanation. I am having fun but I'm still in the stage of excited to be excited about the interplay.

My first surface base EVER! Bob the engineer is looking quite pleased. The launch was horrendous. I *think* I was experiencing wobbly-bugyness due to fairings. The fairings were huge and there were struts going through them in order to keep the base and rover in the picture from wobbling. I had to keep the speed down in the early atmosphere and no matter what I did the rocket would spin wildly at around 30km. By turning off the two outboard engines I was able to regain control and even though I started loosing altitude at around 50km I had enough fuel to pull out and make it to Minmus. Bob is anxiously awaiting the arrival of the mining module to the new Minmus base. Here's the mining module on approach. Using the exact same launch sub-assembly as the hab section in the first picture, this launch was 100% easier. The fairing was slightly better shaped but probably the biggest difference came from the lack of struts penetrating the fairings - the mining module is much more stout than the hab+rover. The astute observer will predict how this landing ended. I see what you did there KSP - very clever. The engines are obstructed by both the ore tanks and the mining gear. This used to not be a problem, and therefore not something I paid attention to. In this instance however I lithobraked at 70m/s. All I need to do is rotate the engines a few degrees around the tank - it'll no longer be symmetrical but they should a) produce thrust and not explode important things below them so probably worth it.

I was just launching a little probe, had just reached orbit and when I jettisoned the fairings I was suddenly "landed" at 71km and 2200m/s. There was a piece of fairings stuck to the probe. Of course I couldn't switch to the Space Center and back to try to fix things because I was "driving over terrain"... thaaaaaanks fairings.

Well said Little Square Dot - thanks! I'll take a moment to reiterate that I am a little surprised that RoverDude took such offense to this thread. I'm thankful for all the work that's gone into KSP - I've gotten more than my money's worth! The "insta-scan" thing is something I think should have been done differently and I'll confess I intentionally put a point on the wording of the OP. But keep up the good work RoverDude and SQUAD, etc. This weekend I designed my first ground base. It'll be module with a rover that assembles the pieces once they land. My plan is to deploy it to Minmus: "For Science and Fuel!" As a pre-req, after an epic Mun science gather system I finally unlocked the narrow-band scanner. I've been taking surface sample-scans in the various Minmus biomes; those don't seem to do anything to the coarse insta-scan view from space, maybe I'll see evidence of the surface sample-scans with the narrow-band scanner. Hopefully they aren't useless since the surface sampler is unlocked before the narrow-band. SO, any day now - but probably over the next week or so - it will be time to demonstrate the power of KSP's fully operational ISRU scan/mining mechanic. I'm excited! But that doesn't mean it's any less disappointing when that gorgeous wide-band scanner outlives its usefulness 10 seconds after arriving at a planet. That's all. I don't know if going straight to the narrow band scanner will work - if someone wants to weigh in I'm curious now too. But you're definitely not alone in preferring to skip a more complex scanning mechanic and going straight to the mining action.

Hey, great point! KSP has a long and glorious history of using wing-parts to do non-wingy things. Like you said, back in version ye'old-ksp when the Mun was added, wings were the go-to landing-legs. They were much less fragile than engine nozzles.

This thread won me over. If you want to tweak the LV-N to encourage other engines, you've thought of some interesting ideas. I'm a big fan of increasing the cost of using the engine using various mechanisms. The monetary cost is an obvious place to start. I also like the idea of making the LV-N bigger and heavier that way it's still useful for large interplanetary ships - their "proper" domain?? - but not so good an option to slap on any old inter-munar transport or lander. Until reading this thread I was miffed at their cowling - how if you clustered several together they could knock each other off when they were activated - but really that's just another cost to using a powerful engine, I get it. If you were trying to be stingy couldn't you deactivate all your fuel tanks to prevent the LV-N from stealing fuel at spool-down? I prefer the idea of a variable ISP depending on throttle. In Manley's Interstellar videos there was an engine where the ISP dropped the higher the throttle. Generally speaking the LV-N is using an energy source to heat fuel so maybe it works the same way - this seems like a reasonable mechanic to complicate the LV-N's use without making them incomprehensible. (Chime in if you know how they work and this is completely wrong)

Brilliant, thanks Slashy and Meithan for the explanation. When I attempt design by calculation I often compute minimum TWR and sometime maximum out if curiosity but it's rarely a driving factor. If one was determined to smooth the boundaries, you could probably present the charts as TWR +/- some percent. Not a suggestion or request, just thinking out loud.

I've noticed landing speed is ridiculously low these days, even with aircraft that don't have oversized wings. Rather than add complexity to the stock parts, you could probably employe some maneuvers (S- turns) to show down and then exploit the low stall speed to stop before the end of the runway.

Someone suggested you can only change the selection if the nav ball is up. This seems to work for me but since it was intermittent before I was paying attention to the nav ball I'm not 100% sure. Even if this fixes it, it is nonobvious enough to need "fixing" imo