martscht

Hey there, I just wanted to drop a quick bug report: When using this mod, my Map goes all wonky. To clarify, this is what the map-view looks like when loading a vehicle (it loads into the standard vehicle view): Then I switch into one of the camera perspectives using the '-' key and hitting 'M' results in the map-view looking like this: I run three other mods along with this: KerbalEngineerRedux, Procedural Fairings and the Subassembly mod. Also, quiting the game and reloading does not resolve the issue. If this has been mentioned before, sorry about reposting, but it does seem like a big deal.

Oh, didn't see this. Thanks! Guess mods can shut this thread down...

Well, the way I thought about it this wouldn't happen, because the payload wouldn't be IN the fairing, but instead all the parts and the fairing would be ONE single part. Thus, if the stress on the fairing becomes so high that it breaks the part breaks. Therefore all the things within it would break, because they are still one part. The parts contained in the payload would only be loaded when the fairing is decoupled. Yeah, but the game itself is full of potential abuse. For example CoM-shift due to relocating fuel makes it possible to travel without using any fuel (there's a Scott Manley video about this...). Also: the CoM calculation would still be made, but the part (the payload) would only be one single part. So it would basically be the same thing as using a double fuel-tank instead of two singles (here the CoM shift is also only computed for one part, instead of two), which I wouldn't consider "abusing" the systems. Yeah, but 1) you'd be hard pressed to fit 1000 parts under a single fairing (though I'm sure many would try...), 2) the lag spike would be the same "hiccup" you experience on the launchpad, when the entire vessel is loaded - the difference is only, that you don't experience the lag for the entire flight between initial load and fairing decouple, and 3) this lag-spike could be the ingame explanation for creating an event horizon which allows us to travel to other solar systems ;-D!

I know fairings are in the "what-not-to-suggest"-Thread and this is why I post this as a discussion subject - I'm merely interested in whether this is possible in the way KSP is currently set up. So, my basic idea was that when you put a payload fairing around a combination of parts (e.g. a lander) everything that is within that fairing is handled as a single part (i.e. the "payload"). So on initial vessel load all parts would be loaded and then everything in the fairing (e.g. marked by being in the stages above the fairing decouple) would be frozen in that load constellation and handled as one part, making the physics simulation a lot lighter. When the fairing is decoupled the freeze on the parts is lifted and they are then handled as they normally are. Since I don't know much about programming and the code underlying KSP: does anyone out there know whether this possible and feasible? Perhaps this could even be handled in a mod? Anyway, let me know what you guys think about this.

I think this is a really good question. I used to use them to power rovers (back when they rode on the spaceplane landing gear) but ever since wheels have power I haven't used a single ion engine. Sometimes I'd simply strap one on a satellite for orbital corrections and such, but since orbits don't deteriorate in this game, there's really no sense in doing this either. Nowadays I just use the Ant-Engine on my satellites because with 2 miniature fuel tanks that still gives you roughly 2000 m/s. allmappedout basically made the only valid point for using them I can think of...

Hmm... I know it's not that realistic a challenge, but I want to try this. I've done the orbit thing already (though I have no screenshots to prove it) but going for the Mun could be a nice challenge. Just a question beforehand: is the map view allowed before take-off? I was thinking I could time-warp to launch window using map view and then do the rest from IVA-view. Because of the radar altimeter I think landing is actually easier from this view than from the standard view.

I'd guess you could add the orbital period for a vessel (in seconds): 2*pi*sqrt(a³/(G*M)) because this allows you to compute the time required to wait for transfers as (phi[final] - phi[initial]) / ( sqrt(G*M/a[target]³) - sqrt(G*M/a[origin]³) ) and the time required to wait for the correct ejection angle as ejection angle / 360 * period

I think this is only true if you're unwilling to math your way to other planets. I don't use an information panel for interplanetary transfer, because I think all you need is given by the game. For example, my mission to Duna (without information panels) looked like this: Build a rocket good enough to get three Kerbs there and back. Warp until dawn of the 58th day (or the 285th or the 513th or... well, you get the idea). Launch aforementioned rocket. Get a circular orbit at 125 km. Wait until you are at Kerbin prograde. Warp/wait exactly 20 minutes and 1 second. Transfer. Encounter. Land. Using this mission profile and only stock parts I have not missed a Duna encounter. Sure, I've scattered the parts of my rockets across the Duna surface, I've run out of fuel and was stranded on Duna, I've lost Kerbs who insisted on EVA-ing with just a few minutes until atmosphere and so on. But the information the vanilla game provides is sufficient for exact mission planning. Though I will admit it's less comfortable when you have to write it down, rather than just looking at the extra window on your screen and say "ah, it's time to launch that rocket to Duna". But without information mods it is in no way a foregone conclusion that you're gonna be winging it. I didn't wanna rant here. I just wanted to show that getting more information is not always the solution when you haven't yet exhausted the information you already have.

I think it's a Scott Manley Quote:

I had to vote for the third option, but after some (okay, a lot of) work I managed to get to Duna. I think I avoided the frustration of the .16 to .17 transition somewhat by not trying to go to Duna first. For some reason most people will make Duna their first target of interplanetary flight. IMO that's a bad idea... I think of it like this: I'm driving on the freeway and throw a tic-tac at the guy sleeping in the passenger seat (going to the Mun). Now if I go to Jool it's like throwing the tic-tac out the window and hitting the back of an open pick-up-truck. Going to Duna is more like hitting the open window of a guy constantly changing lanes and accelerating and breaking in his Ford Fiesta. So to me it was sort of natural going for the easier target first and then gradually increasing the difficulty level.

I don't know if this is a problem that is specific to this mod, but when I'm in IVA-view and right-click to pan the view the Space-Engineer Window vanishes and I can't get it back. The last time this happened the only way I could help myself was a complete "re-install". Now it's happened again... any ideas on how I can get it back?

Hmm, in this Update it's been Mun, Minmus, Vall and Laythe (via Jool-Aerocapture). I also had a crash-landing on Duna (my Kerbals survived). To me getting to Duna is extremely frustrating because of it's slightly eccentrical orbit in combination with its miniature-size SOI... of course I could just get close and chase it down with time-acceleration, but I want my missions to be direct transfers. Waiting for 200 ingame-days while in no-man's-land just seems off to me (as does launching multiple crafts to maximize success probability or using MechJeb). Jool, on the other hand is fairly easy. Huge SOI, circular orbit, large margin for error. I'll try Eve next, but the launch window opens so late (somewhere around day 150 or something) that I've kept busy with other missions.

Sure, you can can calculate the wait time as (phi2 - phi1) / (omega2 - omega1) phi represents angles (with phi1 being the initial angle and phi2 being the final angle, i.e. the phase angle Olex's calculator gives you) in radians. Omega is calculated by sqrt(mu / a^3) where mu is the gravitational parameter and a is the semimajor axis. Again Omega1 is computed for your origin (i.e. Kerbin) and Omega2 is for your goal. The Period is computed as 2*pi/(omega2-omega1) (and is returned in seconds). Though there seem to be some problems in my calculation (perhaps my initial angles were off), because the angles aren't quite aligned at the time I predicted (I checked with the Kerbal Engineer Mod)...

With 119.5 km I got a straight transfer to Laythe: http://kerbalspaceprogram.com/forum/showthread.php/21522-Replicate-the-Jupiter-aerobreak-from-2010-the-year-we-made-contact%21?p=278467#post278467 And with a PE of 21.875 at Laythe I got aerocaptured there.

And a quick update: Using a periapsis slightly lower and a less inclined approach to Jool than last time. This time I went with 119.5 km. And... got a (somewhat) direct transfer to Laythe! After a bit of correcting to lower the periapsis into Laythe's atmo the approach looked kind of weird. But I'll take it. And did someone say "double-aerocapture"? Yep. That's what happened. And it's time for a beach-party! Edit: Somehow I'm experiencing some heavy lag on Laythe. I don't know why... even when just Evaing around...