edwardc

Hi, Every time I build something in the VAB using parts I have researched and own I can launch directly just fine. However, if I leave the VAB and return, like click launch but forgot to do an action group and then use revert to hangar, clicking launch after that always gives me the error that I'm using experimental parts and I'm unable to launch. All consumables (batteries and fuel tanks) and engines are affected. I have to remove them all, re-add and then I can launch fine. Even using the FL-T100 fuel tank which is the first one you get causes this. Using v1.0.2 in career mode in normal difficulty. Clean game started to make sure nothing from an old save was causing it. Very frustrating as having to make the smallest change means I must rebuild the ship from scratch. Cheers Ed

why...? why would anyone liquify Kerbals??? They're supposed to die of old age, drifting aimlessly through space. Back on topic though, depending on how difficult you want to make it you could restrict it to a certain biome on a certain planet but that just sounds annoying to me. It'd be too easy to miss. I do agree that it shouldn't be too easy to find. Maybe limit it to planets with atmosphere or enough gravity to pose a challenge in returning. The reward should determine the difficulty. So maybe, single cell fossils on the Duna with a small reward or small invertebrates on Eeloo with big reward. It could use one random occurrence but make it reward more the harder it is to reach. There is already enough research around, this would just be a "Nice one!" sort of surprise.

I would love this. It's makes space planes so much more appealing. The tricky part would be on how to handle it in the VAB. I suppose you could use the sub-assembly system for payloads. But the height and width will need to be checked... I suppose the overlapping system already does this. Idea: The part is tube shaped like a fuel tank with attachment points top and bottom as per usual. The payload door can recess and slides open. (pic attached for visual aid.) The VAB already has the ability to change the state of landing gear so the same mechanic can be used to open the doors in VAB mode. Once the doors are open, another attachment point can be seen inside the cylinder on the top face. Bad part / needs thought: How do you stop your payload from shaking around in there? Can the internal attachment point be a docking ring by default or should the first part be one?

Hi Guys, After reading about some probe/rover finding traces of microbial life I thought, why isn't this in KSP? So, my suggestion: At the start of a career mode game, randomly set one of the planets as containing microbial life. This can only be discovered by taking a soil sample and analyzing it in the Lab module (or similar). Why It encourages you to plan your missions more carefully in that you have to send a Kerbal and be able to return. You also don't know what planet the life can be found on so you have to hunt for it. It could have a nice research point payout as a reward (cash/fame in later versions) to encourage the search. Yes I know this is "just another research mission" but when the final game is out, we'll need a lot of these mission types for fame and fortune. What could be more fame inducing than finding other life in space? Comments?

+1 This functionality already exists as the warp rate changes based on your altitude. Having it drop to X1 in another condition should be fairly simple.

Combine the hose and the receiving port. The Receiving port could be in the center of the wheel. So it's just 1 new part that would need to be on any ship/station you want this functionality on. The regular Alt+right click would probably be used after that.

This is a small suggestion. On the antenna, you can see the battery charge and the current status, transmitting/done. On some of my smaller probes with low battery and a single solar panel, transmitting takes a while so I get to watch the thing recharging for a tiny burst of info and then repeat. What I'd like to see: Data remaining 13/48 Mits So that I can get an idea of how long it's going to take. The total should include all instruments in the current transmit batch.

A possible solution to this is to break the tech tree up into categories. If I'm doing research on something, I should hopefully know what the heck I'm aiming for. I have a goal don't I? It's not a case of, "Hmm, let's do some research. What have I found? Oh look! It's a hair curler!" Scientists only do research with a goal in mind. You could have the fuel tank line where the tanks get bigger and bigger with a side line for miniaturization. Wings in their own mini tree, engines in another. You might think that you could then just focus on the engines and tanks but the exponential cost will get you. By breaking the trees up like this you have to seriously adjust the costs. You could then also consider hiding what the next item. "Would you like to spend another 300 points researching new fuel tanks?" instead of the current "Would you like to buy the blueprints for...?" Reason? When you start research you don't quite know what you are going to get, you know what area you are researching, just not quite to what extent you'll succeed.

Another difficulty option you could consider: Easier means a weight reduction % This makes launches, landings and handling easier. Also less fuel consumed. It covers quite a lot. And it's quite easy to implement. Anywhere where the weight is read, there is a tiny bit of maths saying weight = %configvalue% * %difficulty% where normal == 1, easy == 0.75, super easy == 0.5.

1) You definitely want to be able to fix things. Nothing would infuriate me more than spending a few hours on a super long meeting up, docking and joining of my multi part super space fortress only to have the main engine be broken. Early in launch I don't mind not being able to fix, that's what "Abort" is for after all Newer parts would generally have more problems than more established bits. If you've used an engine for years, usually all the quirks get ironed out. Also, there should be a lessons learnt part to avoid it "happening again" now that you know what went wrong. 3) I think this is already in place. There's a g-force meter on the right of the nav ball. Soon as it hits the upper red things start ripping apart. I've had this happen plenty of times already. Side note: parachute failing is insta-death. If this happened while I was landing on Jool I might say something unpleasant.

Hi Guys, What and Why So, this suggestion comes after many ejected parts collided with my main ship and caused damage. I've tried using Sepratron 1s but sometimes they just fire too early or spin wrong and once you use a radial decoupler, you can't have the sepratrons on the next stage as the part is no longer attached. So, as a tweak-able setting for some parts, I suggest a timer that can be set and starts it's countdown on stage activation. Simple Example: I have a rocket core with 4 radial boosters. Each booster has a Sepratron I with a 5 second timer set. Each booster also has a parachute with a 45 second timer set. During launch my radial boosters run out and I stage and eject them. (Timers start counting) After floating away for 5s (to give a little clearance) the sepratrons fire to clear it completely. After 45s the chutes deploy so the falling empty tanks and engines can be recovered (assuming career mode money additions) Alternate use This could also then be used for remote deploying of small probes and rovers. If I have a main ship with multiple rovers I could stay in orbit and use the timers to launch them at the planet and have the timers retroburn the probe engines (assuming correct orientation) and deployment of chutes. Risk Parts with timers may no longer be within range of player's focus and then get unloaded from memory. I know models are only loaded when within range but I honestly don't know how physics, collusion etc work on out of range items if at all. It's possible that remote probes with timers just "freeze" as they leave your range and crash. How/Where As to how/where this can be implemented, I'd suggest on the staging list along the right in the VAB. Right clicking an item there shows a menu item "Timer" or "Delay". Selecting it just gives a text box where you can enter a number in seconds. This could then be overlaid on the icon like the symmetry count. A zero second delay is instant and need not be displayed obviously.

Items can already receive a glow effect as seen in the action grouping screen. Selected items/groups glow blue. Why not have a "Highlight fuel flow" button. When active, selecting a tank makes it the source, it then glows red. All tanks receiving fuel from that tank then glow green. This should make it very easy to spot a bad connection.

+1 This should be a dual system. Fuel hose and extension lead for electricity. I had to make a rather complex recharging station for rovers (pre-solar) like a drive-though docking/charging car wash thing. On stilts.

So, you want a hanky-chute? Something the size of the RCS thruster model?

After reading this my first thought was that spikes can work in both directions. I had this picture of a Kerbal kebab stuck on the Mun. I don't think the planet meshes distinguish between soft ground and solid rock. Unless you want the low tech spike to lightsaber it's way into solid rock. I think it would be interesting to have but I'd probably use girders instead and fake the landing gear.

You could over-simplify this idea. Some planets/moons are radioactive. When when get close enough with your orbit it messes with your controls/navball (not too much I think) unless you have radiation absorbing tanks on board. I'm thinking the goo takes could leech this radiation up and add a research option as a side benefit. "After being exposed to the radiation from %%planetname%% the goo appears to have attained self awareness. It starts demanding danger pay and overtime."

Just to further my suggestion (despite a lot of conflicting arguments posted above) on why I want this and hence, suggested it. Yes, a lot of information CAN be discovered about planets remotely using telescopes and orbital calculations etc. That's great, we use it in real life all the time to save costs and life. Now, this is a game. Where Kerbals have a courage and STUPIDITY meter. They also only considered using electricity with space flight LATER in the research tree. I really don't think they have the foresight to do a lot of advanced remote research on planet statistics. If we're arguing realism, computer models can predict ~90% of Kerbal research anyway so what IS the point of the research tree then? When you have items with descriptions like "trashcan full of boom" you have to take it with a pinch of salt, nay, a fistful. The idea wasn't to make it more obscure for people. In fact, I don't think I've EVER actually used the atmospheric pressure/height and gravity values in working out what I need to land there. The most I've done is (if atmosphere then add parachutes). To be honest, I think most people just playing for fun don't really care. A lot of the rockets I've seen are way overpowered with extra fuel & boosters "just in case". The values are only of real benefit to those that want to fine tune their ships to be as lightweight and efficient as possible. If you want that level of precision, surely you'd want to probe your destination more anyway just to be sure? As it's already been proven, you can max the research tree with just 2 launches. This feature could be enabled on career and sandbox would just show it all anyway. Kerbal is still growing and expanding as a game. This idea was just to give us more to do as features are added. Pros: It's a relatively easy thing to add. It doesn't actually complicate the game more as it's just showing/hiding/changing labels based on a research item. It adds another objective or 2 per planet. Cons: It annoys some people to have more objectives.

While I want this there is a small complication. Your projected path will be where Jool isn't. So while your view jumps to Jool, the projected path might be on the other side of the solar system where the intercept will occur. The camera would have to jump to a position in space with nothing but prediction icons. Those aren't great for the fine tuning things like aerobraking.

In the testing world we call this a 'feature', not a bug... It's just a dust bowl you're sinking into... yes, that sounds about right. Quicksand is quite possible on another planet. Nothing at all to do with the collusion mesh being slightly misaligned.

Kerbals are pretty dumb and by their own admission thought several planets were specks of dirt on the lense. Having them know fine details about the planets from the get-go doesn't make sense. They are just starting their space programme after all. Telescopes can only provide so much info. Yes, atmosphere can be seen but these are Kerbals... At the moment, you can see all the statistics for any planet by just selecting it. Most people won't even need to check this as they know it off by heart by now but this would make it more immersive for newer players. Plus it adds more uses for probes. My idea: Make the details of planets hidden at first. Unknown atmosphere, unknown gravity etc. To discover these you need to send a probe with the appropriate science tool. Put a gravioli sensor in orbit to uncover the gravity and escape velocity. Send a PresMat barometer into the atmosphere to get it's density and altitude or even existence. Things like radius and mass could be left as is or given as estimates until the probe confirms them by just being in orbit. All this should obviously be transmitted back to Kerbin like regular research. If this is approved this shouldn't be too hard to implement as it's just replacing the static text with a variable and an if statement to check if a few new research items have been completed to decide what text to display.

Here's an idea. Simplistic maybe, but possible and hopefully not too hard to implement. As Vexx mentioned, you might NOT want these items to connect, so why not make it the builders choice? Have a button that creates these connections only if the user wants it. How do you work out if there should BE a connection? Easy enough (I think), the nodes should have the EXACT same co-ords in the VAB. Let's face it, if you've used the correct parts these nodes WILL have the same co-ords. So the function runs, checks for unconnected nodes, does a check for duplicate co-ords and finds the 2 overlapping spots on part A and part B. It then creates a 0.0001 length invisible, zero weight, zero drag strut joining the two. Strength the usual between regular joins. If the user disconnects/moves ANYTHING in the VAB, destroy ALL these connection types. Make him do it as the final step to creating a stable structure. This avoids needing to check them all every time parts are shifted. [Edit] These invisible struts should transfer fuel power obviously Yes, doing this the proper way with parent arrays might be hard, take longer, but this is my 2c to try get a quick work-around to make us all happy.

Surely it's 'just' a matter of running a script to check if the objects altitude less than the terrain altitude and setting the correct height. Once written, the script could then be run after any terrain adjustments to correct all the objects. I'm thinking something like (sudo code): For(each object) { if object.height <= terrain.height { object.height = terrain.height + 10; } }

I know my mspaint skills... (or lack thereof) so I'd suggest a few helper tools for the chalkboard. Some basics like circles and ovals just to draw the orbits etc a bit neater. Otherwise you are going to have a LOT of VERY squiggly flight plans. But then again, that actually might be more accurate seeing how my rockets fly.

I like the colour idea. If you put it in the landing tutorial as a popup description you should cover new players. Existing players would probably read the patch notes. Mountains in the dark when I forget lights are my least favorite way to crater...

I second this. When I first started I made myself a landing practice craft. It was a rather simple rocket but had 4 landers, 4 rovers and 4 probes radially attached all with remote guidance units. The idea was to launch once and have multiple attempts at landing without killing Kerbals. (I don;t like quicksave, feels like cheating). The staging was a nightmare. This sealing system should also lock up monopropellant usage I think. All my lander's mini tanks were empty even though the main rocket had plenty. It was quite a pain refilling them all.