asmi

For those disappointed about resources (or last of thereof) - as long as I follow KSP, resources has always been "one update away". It least this announcement allows me to keep working on resource mining system as stock won't be ready for at least several months

Why would anyone want to kill the major portion of fun that on-orbit assembly of Mir is? I've assembled it like 10 times already, in all kinds of orbits, including 51.6° where it actually was.

SLS is just as non-existent as Ares-V is The only difference is that SLS is not yet cancelled, but its time will come

BobCat, if you have a problem of VAB being not large enough, use this mod: http://forum.kerbalspaceprogram.com/showthread.php/31580-Plugin-0-20-EditorTools-(EdTools) This will make it HUUGE so you can stuff like five times taller rocket into VAB

Awesome, thanks!

Hey BobCat, out of curiousity I've just measured G-load during final chute deploy - it's 81+G!!! We definetly need to increase a bit the altitude of chute deployment so the craft would slow down more...

I second each and every word! You don't see Orbiter players asking a lot of questions over there that are covered in manual as "playing Orbiter" basically means "reading manuals" - you won't fly very far in Orbiter without reading mans. ßðòõû, ýõ þñрðщðù òýøüðýøѠýð øôøþтþò - ýð тþ þýø ø øôøþты, чтþ ÷ðôðют øôøþтÑÂúøõ òþÿрþÑÂÑ‹!

I don't get the point of this. BobCat will do it they way he wants, if someone disagrees - you're more then welcomed to get tools together and do it your way! Heck, I'm sure BobCat won't even mind including your creation into the pack if you so desire.

Fine! Does it involves any modeling, or it's purely config work? If latter, would you be so kind as to provide what text do I need to insert into *cfg to make that happen?

BTW - I use Soyuz escape tower a lot during my landing system tests for small landers and rovers!

Why is it so? I'm pretty sure that the largest part of users who actually use your mods are what I call "seasoned KSP players".

Speaking of LES, BobCat, would it be possible to fit two different sets of engines in LES, both activateable (cool word ) via action group commands - one just like current one for abort, and second set - much less powerful - for nominal jettison. The reason is that currently if I jettison LES at the time in happens in real life (about the time of strapon sep), it's so light that it flies away onto escape trajectory! So right now I'm forced to jettison it much earlier (at 3-4 km ASL) so it would actually fall down to the planet.

Hi Romfarer, Can you please introduce some sort of oscillation damper perhaps for when the arm is attached to something and then it slowly but surely starts oscillations that lead to destruction. Like, I don't know, resonance detection or something as there clearly is something resonating. It really drives me nuts that after I spend like 20 minutes lining modules up only for it to start oscillating and shake itself apart... Thank you in advance!

Trained humans in a right pose can survive much higher accelerations than 8g. Infact Soyuz capsule during backup ballistic descent pulls out up to 10g acceleration, and no one ever died or suffered any injures during these ballistic reentries. But the orientation and pose of human matters a whole lot in this case - the reason astronauts are in fetus poses is that it was determined that humans can withstand maximum acceleration this way. Human beings can survive very high bursts of acceleration if it's short enough. For example Soyuz LES subjects humans to accelerations up to 15g for a very short time! The reason for that is obvious enough - LES needs to pull humans out of exploding rocket, or outrun the rocket which engines are firing at full thrust.

Field name most likely is obfuscator's work. Yea, in general I agree, but this feature itself is incomplete, so for now it's acceptable. As I've said above, I've isolated this inside a class so if/when this part is changed, the codebase can easily be fixed.

You've got to keep in mind, that in absence of documentation we're bound to use such ways - I don't like it either to be honest, but we've gotta deal with what we have. I've isolated this code into separate class for that exact reason - if it would become broken in future versions (BTW it's confirmed to work in 0.20.2), it could be fixed in one place, and not scattered across the codebase making such a fix a nightmare.

Do you want the code that works, or one that looks "healthy" (btw what is it?), but doesn't work? You've asked me how did I do that - I've told you, if you don't like it feel free to find the other way. I've spent almost a full day in dotPeek + debugger trying to find the way, I've found it, it works, so it's good enough for me.

As promised, here is the code: Just call this method and pass celestial and texture to display it, or pass null instead of texture to hide resource.

The Soyuz-TMA-M spacecraft is indeed launched by Soyuz-FG rocket, but Progress-M-M is launched by Soyuz-U rocket, the main difference is Soyuz-FG has max acceleration capped at 4G (man rating requirement), while Soyuz-U AFAIK puts out up to 5G. As for ST, there are actually two different versions - Soyuz-2.1a ST and Soyuz-2.1b ST, the latter one has more payload capacity.

One thing to keep in mind - people complain because they love KSP and care enough of it. Those who doesn't love it don't bother positing anything here.

Lagrange point is not the only thing we're missing. Current implementation also precludes implementing cool things like multi-star systems (if we ever get another star systems in KSP).

The very basic math for n-body physics is incredibly simple - it's basically second Newton's law plus equation of motion. However the problem is with timewarp when dt becomes so large as orbits become very inaccurate, so better integration techniques have been devised, and subsampling is now an option since CPU performance is high enough to allow that. Orbiter comes with technical documentation that outlines this question very well, so I'd suggest reading it to everyone interested. I was actually considering developing mod for KSP that would introduce n-body physics, but never got enough time for that

Sure, once I reach home I'll post code sample. It actually uses current (VERY rudimentary but still) support of resources in stock game. Basically you need to provide a texture that will be alpha-blended with terrain texture during rendering (it's classic alpha-blending mechanism result_color = resource_texture.rgb * resource_texture.a + main_texture.rgb * (1 - resource_texture.a)). So you can start working on building this texture, and this evening I'll show you how to "connect" it to renderer.

Yes, even in high timewarp with multiple missions in progress.

No you again mixes things up, and I KNOW these things are unrelated. Orbiter's model is different in a sence that it models only vessel's motion, and it's up to vessel itself to implement flexing. All APIs and other things for that are in place. I've actually had collisions implemented at some experimental build of my GC (I'm one of D3D11Client's devs if you haven't figured it out by now ) and it was working so I know it's possible to do.