Colonel_Panic
-
Posts
410 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Colonel_Panic
-
-
Unfortunately, quickloading overwrites the latest autosave.
Quicksave and autosave are different. Quickload takes you back to the last quicksave. Alt-F9 can load an autosave though.
yeah, it looks like that's what happened... darn. All that work. :c
Good to know for the future, I guess... and perhaps I should quicksave more often. I guess this is the end of my career playthrough, until I feel like hacking my way back to where I was.
-
Long story short I'm playing in campaign mode, playing a relatively strict game with permadeath but having quickload and revert flight enabled. At some point I was messing around with control schemes jumping in and out of menus, and when I went back into the game my plane was already on the runway. I tried to take off, but it immediately exploded. I hit escape, but the revert flight option was greyed out! so I held down quickload.... I thought the game was saving my progress periodically, and it would just load to the last stable point, but I was wrong and it loaded the last quicksave point I made, like a week ago.... and all my progress is now gone, and all my ships are invalid (locked parts). I can't seem to find anyway to undo that load and load back the original save from when i booted up the game. Is there any way to fix this or did I just {snip} myself? Thanks.
-
To clarify, my ship didn't blow up from overheating, just watching the heat accumulate and spread from tank to tank was a little unnerving, and I wanted to know if there were a particular design method to managing heat.
overheating is a fairly realistic issue with some propulsion systems like that (have you tried radiating heat in a vacuum?), so I don't see it as a "problem" per-se. Not as long as there's a solution for it, anyway. Gameplay wise I'm fine with it. As said before, this is kerbal physics... not every theoretical technology need be perfectly realistically balanced.
I could just use plane tanks, but what's this I hear about fuel flow issues? I want to stage drop tanks and leave them behind with the heavier part of the lander before making the return trip... fuel flow management is kinda important.
I agree that stock KSP should let you tweak your fuel tank ratios within reason (some tanks may only be suitable to some types of fuel), but what about in terms of a short term solution in 1.0.2?
-
So yesterday I built a new lander using a nuke engine, and noticed the mechanics had changed since I last played... so much so, in fact, that it turned out to not have enough dV to complete the mission! Partly because I was carrying around dead weight in oxidizer instead of extra fuel.... Anyway, Jeb is now floating in space and rethinking his life while I plan a rescue mission. I hope I gave him enough spare life support supplies.
I also noticed heat seems to be a major problem now. Together this raises a few questions...
Are nuke engines now more practical on spaceplanes? it seems that without the need for onboard oxidizer, this would be the natural choice for planning SSTO missions with limited wet weight. Has anyone yet built a good spaceplane design with 2 turbojets and a nuke? how about 2 nukes and a turbojet?
Is there a good method for bleeding off the extra heat they generate? It seems like ship designs centered around nuke engines could now benefit from dedicated heat radiators, to keep the engines and fuel tanks cool during long burns. Thermal management is now a practical part of logitstical planning, and I consider this a win, but only if there's an actual way to manage it.
-
He's not after a rocket, turbines move reaction mass no matter what atmosphere they're in. He's just after one that provides all it's own propellant rather than pulling some out of the atmosphere; you'd need a lot of oxidizer but it'd still be more efficient in a reasonable atmosphere than a straight-up rocket as it's not relying on the propellant for all the reaction mass.
Turbines for methane atmospheres which just provided oxidizer would be another thing.
^what he said.
I really don't know what Eve's atmosphere is supposed to be composed of, but if it contained, say, a high amount of methane, it would be worthwhile to have special methane-breathing engines that used oxidizer as fuel for the sole purpose of EVE spaceplanes.
-
You mean like this? http://en.wikipedia.org/wiki/Air-augmented_rocket
Basically, you want to suck air in the intake with a compressor and possibly a bypass fan, inject both fuel and oxidizer, burn them, run the exhaust through a turbine and then out a nozzle to produce thrust, right?
I also definitely support having jet engines that operate in a reducing atmosphere and carry onboard oxygen.
Yes, exactly, well, more or less.... a ramjet based design would be useful for high speed and transatmospheric flight, SSTOs, etc..., but even a turbojet based design makes sense when you're thinking outside the box of terrestrial atmosphere. Kerbalnauts may want for example to operate an aircraft on Eve for short distance, low-speed flights, and the cost of fueling it would make efficiency gains easily outweigh those of raw speed or thrust.
Sir, that's called a hybrid rocket, less efficient than a jet engine and less performance than a rocket.But, may I interest you in a Nuclear Thermal Ramjet
I don't need anything especially exotic. Anything is more efficient than a jet engine that produces no thrust due to lack of breathable oxygen.
That said, thinking outside the box here, it makes sense in a non-terrestrial environment to pursue alternative propulsion engines capable of utilizing compounds present in alien atmospheres. Just because an atmosphere lacks oxygen doesn't mean it lacks the potential for harnessing the power of exothermic chemical reactions when introduced to other compounds carried as fuel.
-
Incorrect. If you did that, it would look like this:
AIR1 - 1
AIR2 - 1
AIR3 - 1
ENG1 - 2
ENG2 - 2
The air for 1-3 goes into ENG1, pushing the necessary 2 air. The leftover 1 unit of air is pushed into ENG2, which is not enough to sustain it and it flames out.
Also check my last post, I edited because the formatting threw it off. order is top down, and it wraps back up to the top at the end of the cycle.
So in that case, how WOULD you prevent asymmetrical flameout?
-
I think you misunderstand the concept here. It would not be as efficient as an air breathing engine in an oxygenated atmosphere, but the energy of combusion can be much more efficiently harvested to produce thrust by turning a turbine. Think of it as a turbojet with direct oxygen injection, or an internal combustion engine with a prop and NOS. The idea is you're using a tank of oxygen to allow combustion, and it's still more efficient to do it this way than just dump propellent out the back, so long as you have an atmosphere to swim through.
This is the reason speedboats and submarines use propellers and not rockets, despite being unable to breathe water.
-
Unless they've changed the behavior for air intakes, this is somewhat correct. I am not sure if the old behavior is still valid, but it would be an artifact of the order of attachment for intakes to engines. The pool of intakes to engines would look like this if you attached two intakes, an engine, another intake, and an engine:
AIR1 > AIR2 > ENG1 > AIR 3 > ENG2
So in effect, air collected by 1/2 intakes is first pushed to ENG1, then past and pools leftover with AIR 3 which goes into ENG2. What would traditionally happen is that as you went higher up, ENG2 would flameout first as AIR3 would be exhausted and only the scraps of AIR1/2 get pushed into ENG two, whereas ENG1 is consuming two intakes entirely by itself. Excess air from AIR3 that ENG2 isn't using also does wrap around back to AIR1/2 pool.
A math example of this:
Order AIR1 AIR2 ENG1 AIR3 ENG2
Produces 5 5 5
Consumes 3 3
This would result in 10 air going to ENG1 with 7 leftover air going to ENG 2 (total of 8 to ENG 2) leaving a total of 9 air in the pool.
As you went up in altitude, the intakes produce less, so the next model:
Order AIR1 AIR2 ENG1 AIR3 ENG2
Produces 1.5 1.5 1.5
Consumes 3 3
Here we can see that while ENG1 still has just enough to continue to operate, ENG2 is receiving no 'spare' from AIR1/2 and thus ENG2 starves and flames out. In order to balance this, it was always a factor of putting an even number of intakes before each engine to ensure that the pool fed correctly into each engine.
The new model does help in terms of starvation, so it's rare that you will need more than one intake her jet as mentioned by Arq, but these rules still apply if you are using more than one intake. Never place your engines and intakes in symmetry mode on planes without remembering this as it can cause asymmetric flameout.
If this is correct, would that mean that you could avoid flameout by always placing all your intakes before placing any of your engines? I'm not sure if I understand what the implication here is.
-
I made a post in reply to another thread on this subject, and thought it belonged here. This would be a good way for stock KSP to handle fuel flow without having too many problematic side effects: http://forum.kerbalspaceprogram.com/threads/119607-Airbreather-fuel-flow-logic?p=1908956&viewfull=1#post1908956
Hmmm, I would suggest a fourth option: treat jet fuel like rocket fuel, however, include a fuel balancer part. Quite simply, a part that, when active, automatically transfers fuel between all tanks which are directly connected via crossfeed to the balancer. That way, you can choose the behavior which best suits your design, be it for balanced weight distribution, drop tanks, etc... tank segments separated by non-crossfeed parts or decouplers would need to have their own balancer. Balancers would be able to manage/reverse the flow of fuel lines when active. As a bonus, we could apply the same logic to xenon and regular rocket fuel. One or two balancer parts could have balancing turned off/on for different fuel types, allowing the default behavior for all fuels to be the same.Except monopropellant. That should still ignore crossfeed rules for the most part, but maybe still only draw from the active stage?
Shouldn't this really belong on the suggestion forum?
[with regards to toggling on/off fuel flow] Fuel tanks and other crossfeed parts should be controllable via action groups.
-
Quite simply, it should be possible to run a jet engine in atmospheres not containing oxygen, as long as you provided your own oxygen source (oxidizer tanks), and it would have the benefit over rocket engines that it would still be far more fuel efficient for providing thrust. This would allow construction of spaceplanes made specifically for atmospheres on bodies such as Duna and Eve. Perhaps even including special methane-breathing engines that require ONLY oxidizer to run in atmospheres containing the combustible substance (Eve?)
Before anyone suggests it, I am not looking to run Kethane mod. I want something simple that adds only 2-4 engine prototypes and maybe special air intakes for this specific purpose and doesn't need exotic resources to work. My VAB has enough useless parts already.
-
Hmmm, I would suggest a fourth option: treat jet fuel like rocket fuel, however, include a fuel balancer part. Quite simply, a part that, when active, automatically transfers fuel between all tanks which are directly connected via crossfeed to the balancer. That way, you can choose the behavior which best suits your design, be it for balanced weight distribution, drop tanks, etc... tank segments separated by non-crossfeed parts or decouplers would need to have their own balancer. Balancers would be able to manage/reverse the flow of fuel lines when active. As a bonus, we could apply the same logic to xenon and regular rocket fuel. One or two balancer parts could have balancing turned off/on for different fuel types, allowing the default behavior for all fuels to be the same.
Except monopropellant. That should still ignore crossfeed rules for the most part, but maybe still only draw from the active stage?
Shouldn't this really belong on the suggestion forum?
It certainly does.And then drop-tank users have to fiddle around with the clumsy right-click fuel interface trying to enable tanks while flying.
Fuel tanks and other crossfeed parts should be controllable via action groups.
-
That's brilliant! A further refinement: the Klaw is a light probe that drags the part into position and docks it to the "furnace", that way you don't have to move the whole thing and can have an orbital "recycling" station. A couple of mainsails would create a good kill volume...
Rune. Something good came out of a necro!
That would require WAY more time and resources than just de-orbiting the thing.
-
-
Can you please upload a save file with the space station in orbit? I made an account just to ask that
, thanks.I'm really nooby at ksp so I can't assemble it at all.
I don't have any save files that are compatible with the current version of KSP, sorry.
Please see the tutorials in my signature for help with all the basics of launch and assembly you need for this kind of project.
-
Ahh kk my problem is I cant dock without MECHJEB I am getting better but I most the time run outa fuel. I have been aiming the port outward I want to dock to as in pointing away from the planet. The booms for me did not seem to move right but thats prob because I had SAS on or something. Thanks for the reply
yeah there is very limited fuel for the deployment, but it should be more than enough if you turn off MJ/SAS and maneuver using only very short controlled bursts to dock. Get the main capsule close to where you want to set up, and take your time. You have virtually unlimited battery on those power masts so you have all the time in the world to line it up perfectly. They are a challenge to dock as they're not typical craft, and MJ won't do it well.
If you think that's hard though you hould have tried the original version where you had to attach a tiny RCS tug to the side and try and maneuver the whole heavy thing with thrust on only one end. (;
-
How do you mount them ? I tried decoupling them one by one but they wont dock/control right after that ... I also tried to dock fist then decouple and that still has the same issue .. when I take the boom parts off one by one it gets less stable to try to dock to the next part ... ? I guess I could build a craft just to mount them but ... I think I am missing something ?
It's been a while but IIRC...
Turn off SAS/ASAS and only use it temporarily as needed to stabilize. dismount a boom and switch to it, then click on the docking port on the end you want to attach to the station and 'control from here.' Use very short, precise firings of RCS and take your time, as you have a large moment of inertia and not much torque.
-
A bit late to reply here, but thanks much for all the compliments! I will likely be revisiting this station soon in the new KSP version, however I am now using TAC LifeSupport and Biomass mods, so it will no longer be stock (and will feature greenhouses etc). Let me know if there's any interest in that!
-
Good info in here folks, thanks.
One thing I'm not really clear on, is someone mentioned the best time to launch is when the starting body is opposite the desired ejection angle, but shouldn't it really be somewhere between 70 and 120 degrees from it? Since you want to burn at the periapse... Is there any "rule of thumb" someone can provide for where you want your moon of choice and kerbin's prograde/retrograde to be with relationship to each other when using this sort of maneuver?
You got a lot of degrees of freedom to avoid such things, but it may be also a good argument to put the station near Mun.Transfer from Minmus LO to 70 km Kerbin periapsis: 160 m/s (227 without Minmus Oberth effect)
Transfer from Mun LO to 70 km Kerbin periapsis: 265 m/s (375 without Mun Oberth effect)
Difference between apoapsis at Mun level and Minmus level from 70 km periapsis: 66 m/s
So you spend 265 - 160 + 66 = 171 m/s more if you make your station near Mun.
I would almost say it's worth the added comfort.
There is one other thing which makes Minmus easier--getting to the surface of minmus and back is far easier and cheaper than on Mun, so less fuel is wasted in getting to orbit. Even if you're refueling your vessel in orbit, you still need to bring fuel from wherever you're mining it to get it to the station to top off your tanks, so if you're using the moon as a fuel source, minmus is going to be the obvious choice.
Perhaps it would be wise to have bases on both Mun and Minmus so if one of them isn't going to be in the right spot during a shorter launch window, we can use the other....
-
I don't think you can use Kerbin to gravity assist out of Kerbin's SOI, though you get more benefit from the Oberth effect if you drop to LKO on your way out system.
A better profile would be to start from LKO and use the Mun for a slingshot. Though the Mun's gravity is low enough that it's hardly worthwhile, I just do the transfer burn from LKO.
Maybe gravity assist isn't the right term. The thing is that launching from Kerbin takes a lot of fuel, as does burning to Kerbin escape. So the idea is to circumvent both of those by establishing a colony on either Minmus or Mun (using Kethane etc), with re-usable landers and a fuel depot as a staging point for interplanetary travel. Escape from Minmus (and to a lesser extent, Mun) is virtually free due to low gravity, no atmosphere, and extremely low orbits, and if you escape to retrograde, that puts you on a close pass to Kerbin, where you can do a prograde burn at the periapse which will get you (due to the already elongated orbit), a virtually free kerbin escape as well... from there it's just a matter of burning your ejection to intercept. This saves (in the example of Minmus) up to 5100 delta v over a launch from Kerbin from liftoff to escape.
Here's the problem though. The direction you eject from Kerbin depends almost entirely on the position of minmus when you make your retroburn. If Minmus is in the wrong position in its orbit, you could lose several months waiting for it to orbit around to the right position to put your ejection on the right path, but by then you may miss the transfer window to your destination planet.
-
Hi, has anyone made a tool or mod that helps calculate optimal launch windows for using Mun or Minmus as a departure point and Kerbin as a gravity assist? Because of the long orbital periods of Mun and Minmus, it can interfere with planning a launch if you're in the wrong point of its orbit during the ideal window.
In addition to the above, I'd like to know whether Mun or Minmus would be more optimal for a staging area for interplanetary flight, and whether there are cases where a direct ejection instead of slingshot may be almost as efficient.
-
Are you sure the gimballing is disabled on outer engines? It will always be a little wobbly due to its extreme length, but should be manageable. If you have too much trouble you can always try disabling gimballing all together, or throttling down the engine.
EDIT:
Also, I HIGHLY recommend selecting the probe core at the top of the service lifter stage for 'control from here' during ascent. Since it is nesarer the ship's moment of inertia, it will sway less, creating less navball wobble, which contributes to control feedback with MJ or SAS.
-
Since the version 0.21.2, is it any easier to send up the (stock) terminus core to LKO, cause I tried it a few times yesterday and so far I can't seem to get it to circularize to a 100km orbit without it going out of control (and going without mechjeb since I have not done a clean install yet).
I can't tell you because a recent update broke all of my saves. The Terminus core had enough fuel to reach minmus orbit directly from the launchpad, though, so I can't imagine it would have been nerfed enough to prevent LKO. Make sure you're following the launch instructions and recommended ascent profile in the OP. There are specific details pertaining to toggling off the outer engine stage gimballing prior to launch. Without MJ it may be difficult to maintain control below 50km due to the high drag of the cupola module. Be sure to follow a shallow ascent profile and keep your nose pegged on the prograde, avoiding any sharp maneuvering. IIRC the staging is designed to utilize the LV-Ns for additional thrust and better efficiency as soon as you're out of the thickest part of the atmosphere.
-
Maybe i'm missing something obvious but how do you deploy and attach the power expansion?
It's a little tricky. Originally I was using tugs but that didn't work so well, so I added a probe core and RCS to each module so they're self-guided. un-dock the piece you intend to deploy, then switch to it and dock with the station. The two L-shaped pieces connect to the clamp jr docking ports at the base of the main power mast with the 'L' at the end pointing out parallel to the main mast, then the panel booms attach to those so they align with the other panels.
_\m/
, thanks.
O.A.S.I.S. Stardock and station systems [Update: New Terminus Core]
in KSP1 The Spacecraft Exchange
Posted
Thanks! Since these craft files were built many versions (and at least one aerodynamics update) ago, please feel free to let me know if they still work, or if you have trouble loading or orbiting them.