Nuke

the phrase 'planet sized fuel tank' keeps echoing through my mind.

i think as you approach space you actually want to spray gas out in as big of a cone as possible, where close to the ground you want to keep a tight column of flame. this is actually one of the reasons for staging.

go watch dr. strangelove, you will feel better. i personally love nuclear weapons. they are the reason we never had a hot war with russia. war in the industrial age was getting out of hand weapons were getting really good at turning meat into puree. as soon as nukes came around nobody wanted to have a big war anymore. small wars were sufficient. all thanks to the likes of fatman and tsar bomba. they will probibly save our butts somewhere down the road. its the only feasable means of interstellar travel we have at the moment. i like to think of them is really efficient batteries with a rather high discharge rate and capacity. our long term survival as a species will depend of very high energy technologies. nukes are making us discipline ourselves for that future. if we die now from nuclear war or when the sun explodes because we banned nukes and couldnt build an orion drive, i dont see much difference. just because you hold the power of armageddon in your hand, doesnt mean you want to burn.

i was just trying to point out the issue of 'automation addiction', cases where dependance on automation caused a crash. a well trained, experienced pilot should have no problem operating in either vfr or ifr. in the context of space planes heavy automation is the only way to fly, manned controls are at most an emergency, last chance or your dead, omg were all gonna die, backup.

conquest. definitely conquest.

i thought about attaching arrays of large nuclear water rockets to an ice dwarf, using the ice as fuel. never really considered what the deltav of such a ship would be. would probibly be a feasible interstellar generation ship.

this is an engineering problem, a solvable one.

lots of plane crashes have resulted from pilots improperly configuring the autopilot. one instance where a pilot set the decent rate in meters thinking it was in feet, and the plane subsequently flying itself into the ground. also you got pilots relying on their instrumentation even though they could look out the window and tell that something wasnt right. 'the computer says were fine so were...' *plane crashes* automated flight is better off being implemented in an all or nothing sort of way. though i think i saw something on the news a few months ago about drone crash rates being like four times greater than piloted crash rates. i dont think that applies to rockets at all, but spaceplanes is a different matter. i dont think you are doing any kind of exotic maneuvering with a spaceplane that you would normally do in a military drone that would endanger the craft. so its an apples to oranges comparison anyway.

it also avoids an extra layer of maned flight certification that the ship would have to meet before you could even put a test pilot onboard. being a commercial spaceplane kind of brings with it a whole bunch of legal issues that a government agency could circumvent. instead go with the automated system and when you have your automated cargo hauler up and running then you can worry about getting a manned rating for the thing so you can haul astronauts up to leo. sorta like what spacex is doing with dragon.

i just read the faq on their webpage. was going to link it but i cant seem to find it.

velcro, lots and lots of velcro.

i think they plan to get a manned rating for the craft for taking astronauts to leo. they will be in a special crew container that can be installed into the cargo bay. not sure if they will be able to patch manual flight controls into the ship as an extra layer of redundancy for manned flight (crew pod could come with a backup fbw control system, should the primary system fail). but unmanned launch capability makes sense for when all you are doing is launching a satellite. but if you need to, for example, transport crew to the iss or carry out repairs on hubble, you still have that option.

nozzels bend down to keep them pointed into the airflow. the engine also needs to curve to line the thrust vector up with the cg. this is because most of the launch mass is fuel and it will change greately from ground to orbit. so the engines are configured to compensate. also ninja'd

you could also potentially use waste heat for extracting water from martian soil. you could actually dump a lot of waste heat into the ground. dig a hole and bury a cooling loop. then have a sub surface membrane capture any moisture liberated in the process.

yea, dont let the fact that we are still using first and second generation pressurized water reactors be an indication of the state of the art in nuclear technology (perhaps circa 1970, and thats being generous). were probibly going to use a liquid metal cooled reactor with radiators (like the ones flown in space by the soviets, us), and thats assuming we haven't cracked fusion before we get to mars (neither one seems to be happening any time soon).

i live in alaska (which seems to be the tropics lately) and wherever you have an exposed pipe you usually have to put a heat tape on it. which is just a small low power heater that has one job, keep the pipe from freezing. combined with insulation they are super effective. but given the thin atmosphere the heat transfer characteristics (and correct me if im wrong) would probibly make it hard to disperse waste heat into the atmosphere. so you could probibly just have a heat exchanger on the pipes to dump the waste heat into whatever you are moving over the pipe. this would serve double duty of getting rid of waste heat and keeping pipes from freezing.

at the end of the day squad is going to make the game they want to make the way they want to make it. i really dont think this forum matters a whole lot. they might peek in to some of the more busy threads, or use the contents of the board to get feedback about features they recently added to the game (science for example). the issues brought up by the op is really just this board trying to police itself in lieu of actual intervention from squad (the do not suggest list being the exception). i know the 'theres a mod for that *link*' type posts can be annoying, especially when its a feature that really should be in the game (*cough* texturecompression *cough*). but sometime such a post makes me aware of a mod that i was not previously aware and those are useful. if you are going to suggest a mod at least participate in the discussion about the idea first. dont use it as an excuse to pimp your favorite mods, adding nothing more to the discussion. the whole stock vs mods debate is kind of laughable in my opinion. i play stock till im bored, then i play mods till im bored, then i play something else while i wait for the next version. if you got something to prove, go play orbiter. thing i like most about ksp is its one of the first games to make space games with realistic physics fun, and so i play it for fun, and that means mods.

congradulations, you like fractals.

there was at least one rodeo reference too.

i like how this article sounds like it was written by a redneck.

keep in mind that state of the art in radhard terms is 10 year old technology compared to what we are used to. i have a 10 year old computer that wouldnt run a modern version of windows very well, let alone any applications. though most of that is cruft that you dont need on a spacecraft os/applications. i think the biggest hunk of code in my game engine is actually the ui code. the most computationally expensive thing your computer does for you is to draw whats on your screen, even if its just ui graphics. this problem would be as hard as ksp's physics if a modern video card wasnt a friggin super computer. my graphics card (a geforce 560) can do around 840+ gflops, my cpu, an i7 3770k, can do around 85gflops. it gets that ~10x performance gain because its a special purpose parallel processing monstrosity designed for the sole purpose of letting you see whats going on with your system. the thing that makes computers slow is the need to interface with our dumb meatbag asses. when it comes to actual maths for space flight, like coming up with reliable positional data from the output of an array of sensors, a 486dx could do that job (this is the cpu the hubble uses btw, unless they upgraded it). the algorithms are complex, yes, but the time it takes the cpu to figure it out is imperceptible to us humans. thats an old cpu. on a modern radhard cpu it takes less time to figure out where you are than the time it takes for the signal representing the sensor readings to get from the sensor to the cpu (obviously with imperceptible latency, but thats manageable).

i never said they weren't. every time you improve a design you pretty much have to go back to a lower trl until the improvement is proven. there are lots of ways to improve upon the ion engine technology we already use (more isp, more thrust, better efficiency, higher power levels, better life expectancy), and each time that happens, we got to re-prove it. just cause we have ion engines doesn't mean we aren't playing around with new ones. hell were still improving chemical engines, using the same process.

the problem never was engines. there is such a backlog of experimental ion and plasma engine technologies, almost all have been ground tested and will probibly work, and just need to be tested in space to increase their trl. the real hold up is that a lot of those systems use more power than is currently available on a space craft. you dont launch a spacecraft just to test a system, usually you piggy back that system on another mission (especially if the rocket used to launch it has some extra dv for a secondary mission). if said mission lacks the power supply neccisary to power the experimental technology, then there is just no way to test it, and the extra space gets allocated for something else (like cubesats for example). for example, the iss doesnt have the power to run the vasimr engine. but with a battery bank its possible to fire the engine long enough to reboost the station. the only reason they plan to test it is fact it can piggyback on a routine resupply mission. once vasimr is proven, then we have a reason to start building spacecraft with better power supplies, and the other engines can piggyback on those missions for testing.

you just need to be able to look at the address/data buses. throw a comparator on the address bus, if the value on the bus matches another arbitrary value, intercept all read and write requests to that address with your own hardware. usually you copy the data into one register and out of another, that way you turn that address (or range of addresses) into your communications pipe. memory mapped i/o for the win.

not really. the agc was one of the first cpus to use semiconductor logic. logic was discrete (made with a bunch of chips, each performing a basic logic operation), mostly built out of 3 input nor gate ics. but the same rules of digital logic apply. at most you would need to change logic levels. agc ran at 3v high, 0v low, which would probibly work with modern 3.3v ttl (3v is enough to register as a logical 1). the way the pcbs were made for the agc is they same way they are made now. they used surface mount packages and multi-layered pcbs. the agc really is the forefather of modern technology. you could make them talk to eachother, question is why? the only thing that really changed was how much stuff you could get on a semiconductor die. eventually it became possible to put more and more logic on a single chip, which eventually made the modern cpu possible.