SebLavK

I don't think every new version release after 1.0 was planned before hand by SQUAD. They are all hot fixes for some game breaking bugs and numerical values. That's the reason they are numbered 1.0.x The fact that some new features are implemented with these is because they were ready by the time, or they were developed along with the fixes, even being part of the fix. The next big update will be 1.1, and that won't come out in a few months. If you see the time in between big releases (0.17-0.24, 0.90, 1.0) as too short... Then I can only say I disagree

I'll try it with the mod and check it out, but I suspect what you mean is part of the explosion effects, which have just a little amount of debris, but the effect is the same for every explosion

They can't be, there's no tea on board the ships, only snacks!

That's the first time I see that! That's a very interesting concept. I guess I thought of a similar thing, but never tried to make that. Although, aparently it wouldn't work anymore. But really, what I'm proposing is just a visual effect, it wouldn't change the gameplay in the least.

dV efficiency is measured in the dV you need to get into orbit, but only the dV that the injection stage has, the lifter. You can get any amount of payload into orbit, as long as the lifter's dV is around 2900m/s. The way you put it, using 4700m/s dV with a .22 payload fraction, you wouldn't be using all that dV... Or at least shouldn't need to

How much TWR does that first stage provide? You shouldn't need more than a TWR of 2 at launch pad. If it's bigger than that, you can limit the thrust of the outside mammoths, or use different engines. I see the wings you use as fins have no control surfaces, those could make a difference. Maybe add some vernor engines as well to the bottom to provide more pitch authority, instead of reaction wheels, which add more weight. The fuel used to power these is negligible compared to the mammoths. Try doing a manual ascent. I like to keep my orientation pointing just outside of the prograde marker, but I don't usually launch rockets as big as yours. It's ok for the rocket to fight against your control, meaning that you always have to make little corrections. Starting to turn as soon as lift off usually makes the rocket tip over slowly while it goes up. Play with this, see if it tips over too quickly or to slowly, and help it along the way.

Can you provide a picture of the rocket?

I've found that what really matters is having the proper acceleration while ascending through the thicker part of the atmosphere. Fly too slow, and you'll waste energy fighting against gravity. Too fast and you'll waste it fighting against drag, which will increase exponentially with your speed. I usually try to keep the G-force meter around 2Gs until I reach 12-14km, while flattening the rocket's trajectory as much as I can without having a big AoA (Angle of Attack, the angle between your attitude and your prograde marker). So, to answer your questions I've noticed that the last part of the flight does matter, and if done efficiently you'll be left with more dV to use on orbital maneuvers. A fine balance between your attitude/prograde marker and your altitude, flattening your trajectory as you get higher is very important. Yes, it's better to flat it more than 30º, but don't do it too soon or you'll be wasting energy again. You might need to force it a little. Too much and you'll have a high AoA, which will mean you'll have a lot of drag, and even danger of your rocket flipping over. This does not matter in the upper atmosphere so much, if by 25-30km you're not flat, forcing your rocket to flat will save you some fuel. Basically, getting into orbit can be compared to driving between two opposite points of a square, you can follow the sides (making a 90º turn), or go through the diagonal, covering less distance. This is the difference between burning up, then eastwards when you reach the Ap, or flattening your trajectory as you go, reaching the Ap as you circularise the orbit.

Whenever a part explodes it dissappears and the rest of the ship is now disconnected of it, in as many pieces as that part was attached to. For example: before the radial decoupler bug was fixed, if the boosters hit, say, an orange tank and made it explode we got a flashing explosion and the ship separated into two (or more) parts. The engine is now disembodied and there's a gap between it and the rest of the rocket. Where did all that mass go? Where are all the little orange bits of metal and fuel? Or, should the engine still be attached to a different fuel tank, it would close the gap and press against the top, maybe even exploding more parts and making them vanish. I'm not asking for procedural damage, like a scratch on the side after two ships bump into each other. I'm thinking of the same effect we get when solar panels enter the atmoshpere, all the bits and pieces fly scattering everywhere but don't actually have any physics for them. It's just a visual thing. When a part explodes, it could be followed by bits of metal going in all directions that last a bit more than the explosion flash does. There needn't be a different effect for each kind of part, just a generic effect with a different magnitude based on part size

Well, 1.0.X models aerodynamics more correctly, so even structural panels should generate lift if used correctly. Some real aircraft us wings that have symmetric airfoil, like a small cessna, so to generate lift they need some angle of attack. Those wings at an angle of zero won't produce lift. If you look closely, wings in KSP appear to have symmetrical airfoil, but are instead coded to generate more lift, as if they were cambered... Only that they generate the same when your plane is upside down. You can check the effect here (Wikipedia) I don't know if it's possible to tweak lift and drag effects in the debug menu?

IIRC, the space shuttle's ceramic tiles were not ablative, and were to be replaced after a few flights or if they sustained damage. The only thing missing is the texture for it, the behaviour is already modeled somewhat in the game.

(I'm on my phone, so bear with me) Now that you mention it that way, instead of a lot of options to configure (which might look horrendous with everything enabled, and would not be as obvious that it's configurable) this could be a "programmable" warp. This button, perhaps, would pop up a small window with simple settings: Warp to > Ap, Pe, AN, DN, sunrise, midday, sunset, midnight, etc... Warp for a set amount of time > DD,HH, MM Warp until > Ore depleted, electricity recharged, altitude X... Seems like a big feature, and more of a mod description. Not quick or simple to implement. My opinion remains, I think it would go against the simplicity the developers want for the ui and the controls

The developers said long ago that they wanted to keep the ui minimal and functional. Just by reading the OP's title I started thinking of buttons near the warp arrows. Although it's a nice idea, I feel many would complain about having a button that did X, and not a button that did Y. A lot of games have a clutter of icons that will do things you'll only need every so often, and that just take space and complicate things. I like KSP because it's very straight forward in the way it looks, with the right amount of minimalism. Besides, there's so many things to think about already...

Not at the moment. But the same goes for flags, if we could put flags anywhere, how would they look on "non-friendly" parts, like a structural part, or the tiny ones?

Basically, only the command pods. Or put in another way, any part that carries a flag. Also: The idea of a decal that you "stick" to any part is very nice. But I see that a bit difficult to implement - what would happen if you tried attaching it to an octagonal strut, for example?

I'm not entirely sure about whether you can tell the specialisation when a kerbal is in EVA. However, by clicking on the hatch of a habitable module, you get a list of the kerbals in that module (and you can also transfer them between modules).

Looking around KSP's reddit (/r/KerbalSpaceProgram) I found this: It's a custom flag used to print the word "Atlantis" on the side of the ship. This could be a stock feature that puts the save name you use at VAB/SPH on the ship. It could also be tweaked to put any other name, the same way flags can be turned on or off. Here's a link to the original post

What this means is that if you have a cargo bay made of multiple bay parts, whatever is inside can fill all the space within. If that "wall" wasn't there, a part that ocuppies some space of both cargo bays (indeed, crossing that "wall") wouldn't be registered as being shielded by either of them. This is the problem with modular cargo bays, as you can make a lot of different configurations. The way the code works now will only let you have it "closed" or "open" at all times, not both depending on the circumstances. A way to fix that would be to compute a procedural box that takes everything into account, and I'm sure that's not easy. I do wonder, though, what this has in relation to the shielding bug Scott Manley discovered on his stream, where a part becomes shielded again after it's been taken out and the bays closed. I've already had a few problems with batteries and goo containers inside service capsules after crash landing in the sea.

They will most probably release when someone is near by their servers... To stop fires from the massive downloads

The first thing that came into mind while reading the devnotes was rocket smoke coming out of the launch pad, or the sparks used to ignite the engines

I like the idea of a group of college friends make a small bunker a few hundred yards away from a launching site, then a whole space program infraestructure starting to evolve as a nation's interest in science increases. This looks like a redneck camp messing with fireworks, no offense to the modeler. That plane doesn't fit in the images, much less seem to have come out of that barn

An easy implementation of this could work just like the recovery system does. Instead of deleting the ship and reimbursing the value of its parts (minus a recovery rate), the ship would get stored "as is". Crew would go back to the roster, science collected and experiments recycled for another use. There would be no recovery of funds, but also no construction costs. The only funds spent would involve filling fuel tanks. Cargo bay contents would prove more difficult, as the game only sees parts connected to nodes. New code would have to be written to discern between what is the main craft and what is its payload.

I'm not sure if it's a new feature or it was there before. I've noticed an asterisk in some of the staging icons when building in the VAB/SPH, on the top left corner. Sometimes they appear after rearranging the stages, or when adding new engines, decouplers, etc. At first I thought these meant that there some 'errors' in the order, like a decoupler that disconnected an engine further up in the staging list, but I found this to not be true. I'm using the 64bit KSP 0.24, in case it's particular to this version. I'll try to upload an image if need be

In Scott's interview with the team, Felipe said that he decided to scale down the asteroids to playable levels. Even Gilly has a very high density to account for its gravity. If the game had n-body physics (and I'm not going into the chaotic end it'd mean for the system), we could see big enough asteroids that could keep a well placed probe in position on its surface. Right now I think the biggest asteroid would be around 18m in diameter, but I stand uncorrected. So in the end, you could send a mission to grab an asteroid and find an orange tank, it'd be same gameplay wise. That was just an observation, I like the way they work right now

Meaning that they don't exert any gravity on other things, even the bigger ones, so you can't land or walk on them