Blu_C

I'm not sure if this is because I am running mods (though I doubt it, as the parts I noticed it on are all stock), but Kerbal Engineer seems to get the TWR wrong by an order of magnitude when in the VAB or hangar. For example, using the simplest rocket possible (Mk1 Pod, parachute, RT-10 Solid Booster) shows a TWR of 31.29 in the VAB, when the TWR should be ~5.2. Upon launching, however, the correct values appear to be used.

Real Fuel and MFT were originally the same mod but were split into their separate mods, so there will seem like there is overlap. Real Fuels allows players to make use of real fuel sources with their own characteristics. MFT allows players to reconfigure tanks to use a different type of fuel from the game (and several supported mods), but otherwise uses the same abstract fuel sources in the vanilla game.

Not a big deal. Since they were all new parts I'd guessed they simply still in the works or overlooked. EDIT: And I seem to be running into a problem. I've added the following two lines to Squad_modularFuelTanks.cfg. This allows the menu to pop up, but it then states that "This fuel tank cannot hold resources" so I'm not sure what I am doing wrong. @PART[mk2_1m_AdapterLong] { //!RESOURCE[LiquidFuel] {} //!RESOURCE[Oxidizer] {} //!RESOURCE[MonoPropellant] {} MODULE { name = ModuleFuelTanks volume = 500 type = Fuselage } } @PART[mk2_1m_Bicoupler] { //!RESOURCE[LiquidFuel] {} //!RESOURCE[Oxidizer] {} //!RESOURCE[MonoPropellant] {} MODULE { name = ModuleFuelTanks volume = 300 type = Fuselage } }

Not sure if this has been reported (I checked and didn't see it when I skimmed the past few pages), but most of the MK2 Fuselage parts don't work with this. The only one that appears to work is the Mk2 to 1.25m Adapter, all the other ones do not bring up the menu when I go to edit their contents. It isn't really a huge deal since there are several versions of most parts, but the Mk2 to 1.25 Adapter Long and the Mk2 Bicoupler are both parts I would like to have the ability to change. Is there a way I can add them to the config? I've already located them (in the SPP subfolder inside the Squad folder).

Sort of. Currently KSP only uses the the 32-bit version of Unity, which puts a restriction on how much memory it can access (4GB max). Even if your computer has more than 4gb of RAM available the program cannot 'see' it since it is only 32-bit. Eventually KSP will presumably switch over to 64-bit unity, but as I recall currently does not use it because of bugs with the 64-bit version. In short, if you use a lot of mods (especially ones that add a lot of textures or are otherwise memory intensive) then getting the Active Texture Replacer mod is a good idea, otherwise you are likely to run into insufficent RAM crashes.

Are you running any other mods? Which engines in particular are overheating? How badly are they overheating (i.e. do they explode)? Really, you need to give more information before anyone can help you.

There are notes earlier in the thread about what you need to do. Basically get the latest Firespitter .dll and the latest ExurgantEngineering .dll and you should be good to go.

I can confirm this issue. I have found a work around but it is a pain in the but. Basically after I set the node I will then enter it into Kerbal Alarm Clock and then delete the node so it is restored when the alarm goes off. That 'fixes' the behavior for me, but I need to do that every time and haven't really done any actual testing as such.

This is irrelevant, as the version of Unity that Squad uses is 32bit only, thus while your computer may be capable of using more than 4GB of RAM, KSP itself can only make use of 4GB itself.

Having a problem getting the file from spaceport. Any time the download 'finishes' it actually appears to be ending prematurely and since the zip is damaged it refuses to extract. Is there an alternate download source from the one linked in the first post?

There is a .23 version posted a few pages back, but it is still just a dev build mostly for testing.

Thanks, I wanted to make sure this wasn't just some sort of odd conflict with the mods I have installed before I went saying there was a bug (though I suppose I haven't ruled out mod conflicts yet, so I'll go ahead and test with a clean install sometime in the next couple days when I have time).

Has anybody else been having issues where trying to target Mission Control with a dish has the dish report that it's target is Unknown, while failing to target anything?

Now that I've gotten to play around with things a bit I have another question. What determines the order of the buttons? I presume it is the order in which the mods were installed? One potentially good feature for the future could be the ability to re-arrange the button order. It isn't too huge of a deal currently, but this was a mod that was desperately needed and I expect a lot of mods that add buttons to the UI will make use of this sooner or later. I could see the the ability to re-arrange the buttons becoming quite useful once the toolbar has more than 3 or 4 on it.

Ah, you have to move your mouse right to the very edge of the screen, not just to where the button had been previously like I was trying. Thanks, that's all I needed.

This is probably an obvious question, but after the button tool bar has been set to auto-hide how do you make it visible again? I ask because there isn't anything obvious stated, either in this thread or in the documentation provided (it appears that all that is mentioned is that auto-hide is available). Is it a permanent thing at this moment?

Kept a lot of notes about this particular mission, so if you want the TL;DR here is an album (LINK) that keeps it to the highlights. Recently, thanks to a several missions, most notably its first mission to leave the sphere of Kerbin and a couple probes landed on the Mun (in addition to Jeb landing on Minimus) enough research was done that it was determined a space plane that was worthwhile could be developed. A bevy of research craft were made starting with the X-1 that was developed as an atmospheric research craft and learn how aerodynamic forces interacted with a craft at different altitudes and airspeeds. The X-2 was a simple single seat space plane capable of sub-orbital hops, allowing research into how reentry forces would impact an air frame. Finally the X-3, a project with many difficulties that had to be overcome, endeavored to create the KSC's first official SSTO space plane. Christened the Aurora, this new SSTO had a very modest cargo bay and was the first Aerospace craft to successfully launch a satellite into orbit and land at the KSC again. It so out-shined expectations that it was sent back to the design team to have it's cargo capacity increased substantially. Once the re-design was completed the result would be the most complex craft ever deployed by the Kerbal Space Program. Behold the Aurora II(a), seen here in it's take-off configuration. Eager to prove the capabilities of the new craft the scientists de-orbited the old KS1 model communication satellites and tasked their new SSTO to deliver a payload of the newer KS2's to replace the old, obsolete model. A total of five satellites were stowed in the cargo bay and the lengthy process of preparing the craft for take-off was began. The Aurora II actually has a problem in that it's fuel capacity for the jet engines is actually too large. Only 50 units of fuel are needed for each engine to reach orbit (and have some left over for landing), but the tanks for them hold over 300 units each! As such the extra fuel was taken out. Afterwards the main tanks in the body were set to balance their fuel loads, both to maintain a favorable center of gravity and to make sure the rocket engines didn't run dry. This is a hugely important step, during early tests Jeb once forgot to set the the fuel load to balance. It was a very embarrassing walk back to the KSC, and Bob still hasn't let up about it. Also the probes themselves had all their monoprop. drained form the tank and were sent up empty to be filled from the Aurora II's own tank once orbit was achieved. This was both to keep the CG properly forward and to reduce mass. The Aurora II's own Monoprop tank was about 20 units short, again to save weight and ensure there was enough fuel, given the size of the payload. With the craft prepared Bill and Bob drew straws to see who would have to go up with Jeb. Bob won, much to Bill's displeasure. Flaps were deployed to 15 degrees, the jet engines were switched, and the Aurora II began to roar down the runway. Rotation speed for the Aurora II in this configuration is ~125m/s and takes roughly 2/3 of the runway. You have to be really careful while close to the ground not to break the rocket engines since they stick out so far in back. Once you're airborne, however, just retract the gear, pitch up to 35 degrees, and retract the flaps. Even so heavily loaded the jet engines are powerful enough to reach roughly 100m/s climb in short order. This attitude is held until about 14km up, where the nose is lowered in order to give the craft time to pick up speed. These particular engines will function quite high, able to continue burning as high as 22km easily. Over 18km the throttle is gradually trimmed back to be safe and avoid an asymmetrical burnout, but with the air being so thin the Aurora will continue to gain speed with as little as 1/3 throttle. Eventually, though, the jet engines just won't cut it any more... This is Jeb's favorite part! Time to punch it and nose up to 35 degrees again. The fuel budget is really tight for this mission so the RemoteTech 2 flight computer is used to allow fine control over the attitude and make for the most efficient burn possible. The flight computer is actually used quite a bit from here on out, though the exact parameters are picked out by the pilot. Generally speaking the nose is held up at 35 degrees until the time to apoapsis reaches 50-60s, which happens much faster than you would think. Even though they haven't yet broken 30km Jeb is getting ready to lower the nose. The biggest danger during this phase is lowering it too much. Even though the atmosphere is really thin up this high it does cause you to lose energy so too shallow of an assent will waste fuel as you fly through all that air. On the flip side if you are too steep you are wasting fuel fighting gravity rather than letting the wings do the lifting. It took about a half dozen flights to begin to learn the optimal angle during the early tests for the Aurora II, and it can change significantly depending on the payload. One thing that has been suggested by the scientists, but not tried yet, is climbing up to ~20km on the jet engines, then beginning to dive to pick up more airspeed while still running the engines before skipping back up again. If this worked it would mean more speed could be gained using the efficient jet engines, allowing larger payloads still to reach orbit. Obviously this would require taking more liquid fuel along, possibly making those large wing tanks prove their worth. This was not done here, however, because testing is still needed and there were concerns that the heat would get too high resulting in air frame damage. Once above 50km the atmosphere has thinned sufficiently to enter the orbital configuration, which is a fancy way of saying the Aurora II is rolled onto its back. The throttle is cut for this maneuver to save fuel, but that is fine as the current apoapsis is 74km and the Aurora II is only taking this initial burn to 80km. The reason this is so important is that the only two solar panels the Aurora II has are on the bottom and power is necessary to run its life support systems. Even with it's sizable battery power will not last for the duration of the mission so keeping those panels pointed toward the sun is critical. As a bonus this roll gives Jeb and Bill a great view of the planet below (though Bill doesn't seem to appreciate it). Initially placing the satellites into a higher 100km orbit was considered, and is possible with the Aurora II's fuel reserves, but it cuts things very close and so the lower altitude was decided on to provide a safety margin. One important consideration was that at such a low altitude and with only 5 satellites making up the network they actually won't have line-of-sight to each other. A sixth satellite was considered and it may be possible to deploy 6 in a single mission, but again things were decided on the side of caution. Luckily these satellites don't need to communicate with each other, only to the GeoStationary ones above, relaying communications to and from the far side of Kerbin. So in this case 5 satellites will work fine, even though normally 6 is the ideal. Once reaching the target 80km Jeb fires up the rockets for the insertion burn. That maneuver node you see is just there to mark where the burn would be taking place and how much delta-V was required to circularize. We aren't actually paying attention to it though, burning straight prograde into an eccentric orbit. While we want the 5 satellites in a ~80km orbit what we really want is for them to have an orbital period equal to that of an 80km perfectly circular orbit (31m15s) so that they remain roughly equidistant from each other. Some 'wobble' is fine as long as they don't drift out of position. To that end what we are doing is burning for an orbital period of 37m30s at which point we will deploy one satellite every orbit for 5 orbits. The satellites will then circularize under their own power using RCS. Beyond the orbital period we don't actually care what our final apoapsis ends up being, so long as the periapsis is somewhere around 80km. Most of the burn is done with the main rocket engines, however fine tuning is done with the Aurora II's own RCS thrusters to ensure the orbital period is exactly 37m30s. Once this is complete final checks are done, making sure everything is in order. All remaining RCS is pumped into the satellites, giving them just over 20 units each, and the Aurora is positioned so that when the satillites are released they'll drift away in the direction I want. In this case they are released toward Kirbin. Having them drift pro or retrograde is just asking for them to collide with the Aurora II when the circularize, and as it was there were several that came within meters of striking the Aurora II. These are really basic satellites; they don't need to do much. Single RCS tank, 2 RCS thrusters, antena, OKTO2 probe body, battery, and 2 solar panels, and an attachment port for KAS in case I decide they need to be refueled in the future. They are each secured in the cargo bay Clamp-o-Tron Jr.'s and released using action groups (1 group for every satellite). Technically I could have used decouples or seperators, but I felt that Clamp-O-Trons felt more in the spirit of a fully reusable craft. Also there is the risk of the ejection force altering the orbits or leaving unnecessary junk. With the Clamp-O-Trons things just nicely drift apart when the magnetic clamps are disengaged. Simple and elegant. Each satellite was released well in advance of it's burn so that they would have ample time to drift away from the Aurora II. The OKTO2 probe has a 3km antenna integrated into it so the satellites could be deployed with their antenna retracted. All I had to do was activate the Aurora II's own antenna (cleverly hidden inside along with a probe body and the main battery) so it could relay commands. Between the Action Groups for controlling the Aurora II and those for controlling the satellites I had to really think about how to properly organize everything and even so I ended up using the abort button to toggle the RCS thrusts on and off for the cargo (to keep them from firing inside the bay and 'ruining' the satellites). Once the probes reached the Periapsis they activated their RCS system and burned retrograde to circularize. I quickly found that burning a little early, and a little high would help make a more circular orbit - though again the critical thing here is not how circular but rather the Orbital Period. We are aiming for 31m15s, and so long as the Periapsis stays above 70km I'll be happy. One thing that worried me was that the RCS thrusters would take forever to get the velocity change, but it turns out that these probes are so light even 2 thrusters have a lot of pep. Another concern was that 20 units of RCS fuel wouldn't be enough to circularize. In fact it is plenty. Half as much could have been taken and there still would have been some left over. Oh well, that means they have a nice reserve, so refueling won't be necessary for some time. Once the orbit was established the name was changed from Aurora II probe to ComSat KS-2-A, which is a pretty boring name but Bill picked it out. At least it has the advantage of identifying what model the satellite is, what it is for, and which individual one it is. Now just to do this for the four more times for B through E. It only took ~3 hours of mission time to deploy all the satellites into their orbits but the mission had to be significantly longer in order to wait for the KSC to be in position to attempt a landing. It isn't too critical in this case because plenty of fuel and oxidizer was left over, but it is good practice. In the past the orbit was always brought down right to the surface, but the heating can get pretty intense even with the wings slowing the descent. Coming from such a high altitude Jeb was concerned that the steeper angle would prove to be too much and so chose to set the periapsis at only 10km. Of course he could have circularized down first, but who wants to wait ANOTHER orbit? After the deorbit burn the rear most tanks were drained into the front one, which was set to balance its liquid fuel load with the wing tanks. The Oxidizer could have been dumped but was kept as ballast, keeping the center of gravity forward of the center of lift. The ballast probably wasn't necessary but at the very least fuel that is returned can be used for future missions. Here the RemoteTech 2 flight computer is used again, this time to hold the nose at 20 degrees. The high attitude will help give a higher angle of attack. Higher AoA = More lift = Slower descent. In the past a 10 degree up was always used, however nothing this steep had been attempted. The plan was to dip into the atmosphere and then skip up slightly with the wings, while using flaps and air breaks to slow down. Even with this precaution, and the higher periapsis than usual, things got pretty hot - about 100 degrees more than any of the test flights - but it was still well within safety parameters and neither precaution was probably necessary. The skip also kicked the Aurora II much higher than expected, ultimately getting up to something like 40km again (up from ~30). In order to counteract this full air breaks and full 45 degrees of flaps were applied. The nose was also lowered to reduce the angle of attack (though not below the horizon, as Jeb has learned that only tempts the reentry gods). Normally flaps generate additional lift, but they also increase drag and above 20 or 30 degrees they increase drag much more than any additional lift, so surely It was then that he realized that 40km up there isn't much air for the flaps or air breaks to catch. While they did start noticeably slowing the Aurora II it quickly became apparent that it wasn't anywhere near enough. Well, it is a Kerbal mission, so you know what time it is now. SNAFU! Unfortunately by the time the problem was noticed it was too late to use the trick of making turns to bleed off airspeed, so much to Bill's dismay they sailed over KSC going just over Mach 5 at 34km above sea level. You can see in the picture that Bill is just resigned to his fate, knowing that at best he will be walking home and at worst he'll be SWIMMING. It was at about this time that the scientists back home realized that if they had dumped the Oxidizer the lighter craft may have been slowed by the air more. Oh well, something to keep in mind for next time. Jeb is made of the right stuff, hoewver, and looking down at the KSC in glee as he comes up with a plan. Once the altitude had dropped far enough he pulled the Aurora II into a turn and reactivated the jet engines to keep from stalling. The hardest part of the maneuver is actually figuring out where to point the nose to get roughly headed back to the runway. Having overshot so much (by the time the turn was made Jeb and Bill were quite far over the ocean) there really weren't any references to fly by. Thankfully it turns out that Jeb is really good at dead reckoning and was able to more or less line up with the runway from that far out. Once they were able to see the airstrip only minor tweeks were necessary. The awesome glide ratio of the Aurora II really came into play for the last bit, letting it fly quite slow now that it was so light. Even having overshot by so much, pulled a turn, and only carrying the most minimal power for the flight back the Aurora II came in very high. Ample use of airbreaks and full flaps, plus a lowered nose were more than enough to correct that issue this time, and the landing was almost perfect. All that was left was to activate the wheel motors and taxi back to the hangar. Bill claims he never doubted for a moment that Jeb would figure something out. Who knows, he may even be telling the truth. Why are you telling them to put something else in the cargo bay so we can do that again? Just let me undo my seat belt so I can esca -- err... -- switch out with Bob. Here is the end result of the mission. There is an extra satellite in there, which is a Moho probe waiting for it's transfer window. Those links you see going toward the bottom of the image are targeting a relay station I have on the surface of the Mun, acting as the lynch pin for a network giving intermittent coverage of the whole Munar surface in preparation for a massive scientific survey. List of mods used: FAR, Deadly Reentry v4, RemoteTech 2, TAC Fuel Balancer, TAC Life Support, Kerbal Alarm Clock, B9 Aerospace, Precise Node, Enhanced Nav Ball, Kerbal Attachment System (for the probes only), Kerbal Engineer Redux, KW Rocketry, Texture Reduction Packs (Squad, KW, and B9).

I didn't think of this distinction. Most of my space planes end up ditching their jet engines since there aren't many places in space they are useful outside of Kerbin. But yeah that is my experience. SSTO's are great for a reusable vehicle to refuel and send up again (say, if you were to set up a remote base on Kerbin for some reason), but they aren't very good at all for getting a payload up as they carry a bunch of dead weight with them.

There are some advantages that planes have as a launch vehicle. Probably the most important one is that Jet Engines have a very high fuel efficiency compared to any of the rocket engines and they also have a good TWR. This means that they can lift more mass for less fuel making the whole launch vehicle smaller and more efficient. This lets you get up to around 18k pretty easily (and higher still if you abuse air intakes properly) which you will notice is well above the majority of the atmosphere. It also isn't out of the question that you can get your orbital speed around 1000m/s without too much difficulty and a half way decent space plane. This means that when you switch to rockets you need both less oomph to get into orbit and that the rocket engines will be more efficient as the lower atmosphere means higher ISP (again meaning your craft is more efficient). If we had a better aerodynamic model it would also mean that the lifting of a payload would be aided by the wings, further improving the efficiency of lifting payloads at lower altitudes. On the landing side the Space Plane is much more flexible when it comes to land. Yes with practice you can get pretty close to a landing target, but a space plane can get closer still. In fact if you arbitrarily decided to shift landing points for some reason (such as noticing something interesting on the way down) a Space Plane is clearly superior as any rocket is going to have serious issues in doing the same. Obviously this only holds for planets with atmosphere though, without atmosphere a space plane is no better (and probably worse) than a traditional lander. On the down sides, in my experience Space Planes get difficult to fly after a particular size threshold, which means that for very large payloads a more traditional rocket is still probably a better bet. Also because the aerodynamic model is a bit rubbish currently you really don't get the full benefit from a space plane, you pretty much may as well just strap a bunch of jet engine boosters to a traditional rocket to get you up to ~18k before dumping them. This is actually what I have taken to doing recently, and have a very efficient launch vehicle I've designed for satellite sized payloads. It is basically 2 jet engines that lift things up to 18k, then a couple of SRB's (one after the other) kick the satellite into an elliptical orbit where its own weaker engines can get it to where I want it. Depending on how 'reusable' I'm playing I may even attach parachutes to the parts I'm dropping so they can be 'recovered' and 'reused'.

Not so much. The key to a Geosync orbit is that the Orbital Period is exactly the same as the rotational period of the planet. For Kerbin that is 6 hours exactly. The orbit doesn't actually have to be perfectly circular for the satellite to remain on station, though if it isn't then it will appear to drift very slightly back and forth with regards to the ground. So to manually get a satellite in a Geosync orbit simply adjust the orbit until the period is exactly 6 hours. This is easy with MechJeb's orbital information readouts (honestly those additional information readouts are the best reason to have MechJeb installed).

I will now go sit down and have a sad.

Have a question for RemoteTech 2. Was there a change that limits how many times the signal can be bounced to reach a satellite? I ask because I've been trying to set up a Com array around Kerbin and have been noticing odd things with satellites being out of contact when I think they should have signal. Some details: I'm setting up the network at ~500km above Kerbin and have been careful to ensure that the satellites have all been dropped off with an orbital period of 1h4m15s to ensure that there is a minimum of drift. Because these are supposed to be cheap satellites for only bumping the signal around the planet before a longer range relay shoots it farther away these only carry cheap omni-directional antennas (the 5.0 Mm ones) which I determined should have more than enough range for all my kerbin orbit operations. In spite of this satellites that are on the far side of Kerbin remain out of contact. I've looked at the signal pathways being generated and it seems like the signal no longer gets passed along after 2 bounces, even if another satellite is theoretically in range. Sometimes it will even show a link to said satellite, though instead of a thick green line it will be a narrow brown one (which I suspect simply indicates a link with no path to a Command station). Can provide images if necessary, but it feels like I'm missing something painfully obvious.