asmi

Launch clamps glue my rocket to the launchpad even when decoupled in 1.2. And the mod seems to not like large stock ASAS - its connection to other parts stacked above and below breaks even when it wouldn't without the mod.

yea I've noticed that - thanks!

NathanKell I've noticed you didn't update source code in source control for quite a while. Can you please update it?

When testing Soyuz, keep in mind that its launch sequence includes igniting engines at T-15 at 30% throttle, T-7 at 70%, and T-3 at 100% (apparently 3 seconds are necessary for the engines to reach full thrust).

Why don't you just ask mod authors for models? I assume you're talking about modded parts.

Right now it's all identical to the Earth, except for the lack of upper atmosphere (I mean _really_ upper, beyond 120-150 km).

I gotta say that atmosphere looks so much better on big Kerbin.

Remember that sometimes mixture ratio is defined as mass ratio, and other times - as volume ratio. These are different things, so be careful with that.

This means that your trajectory is not optimal. Most likely it's gravity losses.

These number are well in line with what happens in reality as far as I know.

Fine, but can you please please please add option to disable all heat production for engines in MFSC? I really hate this stupid system!

I normally start gravity turn once I reach 60 m/s of speed. The most important thing is to do it gradually and watch you apoapsis.

Why don't you just take BobCat's Soyuz-U/FG and change parameters to real ones from Wiki or some other source? The beauty of realism is that you don't need made-up number - use real ones

I was trying to do something like that, but faced odd behaviour of KSP's Orbit class - but that was back in 0.19-ish times. Maybe I'll try to do that again once I get a second. Such mod would definetly be very useful as you won't need to worry about final stages flying around just above the edge of atmosphere.

I thought you was talking about SLS a.k.a. The Senate Launch System, that is in process of wasting taxpayers money being built now. They light up sustainer on the ground. Atlas-V is ideal combination - KeroLOx first stage, HyrdoLOx second stage.

Which is just wrong - do I have to remind you what kind of fuel the most powerful engines use? Using hydrolox for first stages is extremely stupid idea in RL since they are waaay too expensive, usually have TWR like crap and so require additional boosters. In RL Delta 4 costs over twice the price of Atlas-V while having inferior performance.

Can you also fix it so it would work with part names containing spaces (i.e. BobCat's mods)? Maybe use quotes to indicate where strings starts and ends, like it's common in OS's command shells?

Wow! "I want it! I want it so bad it's driving me mad!" © The Beetles

I'd recommend getting Stretchy Tanks, since without it your LVs will contain insane amount of parts.

The purpose of clamps is exactly to allow simulation to settle down, if you disable physics before start, it will starts settling down during launch, and you don't want this to happen I'm off today to finalize alpha version of ECLSS mod - BobCat is waiting, and I just can't let that man wait

I think we can leave it for now as a "day 2" item. Speaking of which, I guess we need to start using a bug tracker to keep all these things in one place.

I agree that there should be some sort of automation for that rescaling, otherwise it'll be a day job for all of us to manually rescale all the parts in all mods (not to mention that a fair amount of them prohibit such distribution).

Speaking of which, here is how I sniffed all of that (maybe it'll be useful to you guys): private static string FormatComponentName(Component component) { var str = component.GetType().Name; if (component is PQ) { //special case for PQs as they represent terrain patches var pq = (PQ) component; str += string.Format("({0}/{1})", pq.subdivision, pq.sphereRoot.maxLevel); } return str; } private static void DisplayObjectProperties(GameObject currObj, StringBuilder sb) { var comps = currObj.GetComponents<Component>(); var compList = string.Empty; compList = string.Join(", ", comps.Select(FormatComponentName).ToArray()); var parents = string.Empty; var curr = currObj.transform.parent; while (curr != null && curr.gameObject != null) { parents += string.Format(" <- {0}({1})", curr.gameObject.name, curr.gameObject.tag); curr = curr.gameObject.transform.parent; } sb.AppendFormat("{0}, tag {1}, name {2}, {3}, {4}, {5}, {6}\r\n", currObj.name, currObj.tag, currObj.transform.name, parents, compList, currObj.transform.position, currObj.transform.localPosition); } //and then whereever you need add this code: foreach (GameObject go in FindObjectsOfType(typeof(GameObject))) { var sb = new StringBuilder(); print(string.Format("GameObject name = {0}", go.name)); DisplayObjectProperties(go, sb); print(sb.ToString()); } That is a big problem for any physical engine, but Bullet tend to do better due to increased precision and so reduced rounding errors. P.S. Do all of that really belongs to release thread? This is clearly DEV content... I'm gonna leave it up to NathanKell to release it since he is playing the prime violin over here... Oh guys - I just thought of something - since now we know how to move KSC just about anywhere, why don't we implement such an option? I'd love to move it to real KSC's and/or Baikonur's latitudes as it represents a major challenge on it's own.

There are three - KSC, KSC2 and IslandAirport. I figured I'd kill three birds with one stone, but yes, for the sake of avoiding surprises down the road, let's do only KSC for now.

As for terrain smoothness issue - that's totally expected given the scaling. However since the terrain is procedurally-generated, there should be a way to increase heightmap resolution so the generator would produce higher-frequency details. I'm gonna look into that tomorrow as it's too late over here...