asmi

AFAIR Squad just doesn't WANT to implement that. To tweaks, just lack of proper implementation. These two things are completely unrelated. Again, there are no "tweaks" that only permits latter, but not former, or vise versa. It simply is ABSENCE of a feature. Collisions in Orbiter are trivial and relatively easy to implement, but author has different priorities right now and frankly I argee with him that collisions are not THAT important since the space is HUGE and EMPTY and due to lack of asteroids there is almost nothing to collide with.

It is not that complex. For example it is implemented in Orbiter. There is no universal analytical solution to the problem, but integration gives you VERY accurate results. Infact Orbiter's physics model is so accurate that I was able to get into Orbiter, set up ISS orbit and date to values from NASA site, and then fly Soyuz mission using MCC-M's cyclogram as if it would be a real-life mission.

With v1.3 the only survivable reentry I was able to come up with that would be more or less repetitive (meaning I've done it on first try ) was to drop Pe to ~38-40 kms, then as you "bounce off" atmosphere heatshield cools down and also bleeds off enough speed so it was safe to drop into thicker air without burning out. If currently all it gets to reentry is to drop vertically down it kinda kills the fun... Maybe you can speak to Ferram as to include high-G desintegration? But again in real life crew would be dead long before any structural damage is done to the capsule...

Actually that part doesn't make physical sence since atmosphere is much less dense up high and so should cause less heating although for prolonged time.

Great! Will test it out tonight!

Isn't SRB in Ares I supposed to be gimballed?

I'm planning something much more complex - multiple resources, mining bases with ground structures, etc. I'm still thinking it through and doing some proof-of-concept things, like the one above. Once I have this more of less finalized and all technical implementation concepts nailed down, I'll create a topic here so everyone will have a chance to provide input.

Problem solved:

Before 0.20 I was using KW Rocketry pack, but it's not yet updated for 0.20...

Nope, just checked - clicks still fall through (checked with parts list by putting UI over parts list and clicking).

It's likely caused by reentry profile being too steep. Set you Pe to ~25km or so and the capsule will have enough time to dissipate all speed and slow down to subsonic speed just in time for chutes to deploy. Just tried that and it works like sharm!

I second that. Also would it be possible to prevent "clicks-through" GUI (when you click something on GUI the click also "falls through" whatever is under it)?

In real life planes don't burn at Mach 1. Infact at speeds up to Mach 3-5 the driver for the design is structural stress, not heating. Only when you go to hypersonic speeds the heating becomes a concern. Vast majority of SSTO planes speed up when they are in upper atmosphere, so while heating can be a problem there, it can be managed by protecting areas that are going to be exposed to airstream. Remember that hypersonic airstream has VERY different properties and behavior then slow subsonic one.

I guess devs work via Internet. I seriously doubt Squad is in position to relocate devs.

I just don't get the point of this discussion. Players who wants the "god mode" will unlikely stay in KSP for long as these challenges adds playability. Current reentry mechanics are somewhat equivalent to requesting a feature that would allow you to turn on engine and after certain amount of fuel is spent, you're in orbit - no need to worry about orientation, piloting, etc. If you don't like it and think that piloting should matter - then I don't see why whould you be against reentry heat as it's just one more variable that you have to take into account during building of a spacecraft. My example above demonstrates what current situation is like - if during reentry you can just take your hands off keyboard/joystick and relax, why can't you do that during ascent? Both are equally utterly unrealistic, both don't make any sence, yet some players are asking for the former, but no one - for the latter. Oh, and in regards to heat during ascent - in most cases you're simply not moving fast enough during ascent to heat up, but if you'll stick to stupid "MOAR BUSTERZ" concept you can theoretically burn up. Also reentry heat will likely come with improved aerodynamics and so more aerodynamic shape of the vehicle will help to reduce heating.

Basically the title says it all. I'm thinking about embarking on resources implementation since it's unlikely that we'll see it done by devs for at least several months (my guesstimate), and in order to implement resource maps that would overlay planets, I figured the best way to do that is to modify pixel shader for the planet rendering so it would read my resource map mask and color areas where resources are. Does anyone have anything in this regard? Thank you!

There is Canadarm already.

That is a natural reaction of a rocket - try throwing something more or less streamlined with one end heavier then the other into the air light end-forward - you'll see it will turn upside down in flight. And the more "bottom-heavy" your rocket is the bigger the problem will be. Try adding control surfaces to the very bottom of the rocket - usually it fixes the problem.

Thanks, Romfarer! Do you have any plans to update your robotic arms so they would not blow ships up during docked ops?

Seats, parts, blah, blah... The most important for me is the fact that this radial (un)attachment bug is finally gone! For mods - MJ works fine, so is BobCat's Soviet Pack (and now I can actually attach that damned 2-3 stage decoupler! - before it took 10+ minutes as it just didn't want to attach to correct node) - except of Launch Clamps bug that showed up when I was flying the Buran uphill (I assume it's caused by Lazor mod that is used for manipulators), Soyuz works like sharm, EdTools (I don't know the real name of the mod - it expands VAB and offers some new options) works as well. Gonna try to put back all my mods tonight to see if it starts running out of memory like it did in 0.19.x.

And it's because of that API's existence coupled with presence of many talented modders out here, KSP retains players between updates, because, let's face it - right now stock game is about 20-30% of what is possible with mods. And I think Squad shall encourage and support modders to the best they could, as mods play a critical role of maintaining interest to the game while devs are working on next updates.

I think the DLCs are supposed to ADD something EXTRA that is not in stock game and was not promised to be. Like DLC that would turn Kerbol system into real Solar system (you know, real-size Earth, Mars, Venus and such). I'd buy such DLC instantly even if it would cost $100.

So for all practical purposes IS a pod, just that it's de-manned and have to be manned in order to be used. Thanks for the explanation!

What I really want is on-demand loading of parts. I've got a tons of parts installed and wish I could install more, but I can't since KSP crashed with OutOfMemory errors despite having 32Gb RAM on my computer. This is caused in part by the fact that KSP is 32bit app, so maybe devs would introduce 64bit version as well? This shouldn't affect mods compatibility since they are developed using .NET which is architecture-independent.

I really don't get this obsession with flags. They sound cool, but I'm ready to bet money that after initial excitment wears off they will be boring in no time. I think devs should concentrate on features that offer long-term playability. Resources is IMHO number one on that list.