• Content Count

  • Joined

  • Last visited

Everything posted by MBobrik

  1. I don't claim to know what is wrong with your simulation ( you would have to show your code to be able to), but the "naive" method of numerical integration ( simply summing up acceleration x timestep into velocity and velocity x timestep into position ) has very poor stability when applied to orbital dynamics. And as a result, the orbit will always drift (though most probably not much as what you've shown ), even for small timesteps. Google some numerical methods, the leapfrog method is a bare minimum.
  2. Landed 2 pieces at once. One landed at 4.2 m/s though it was designed to land at 5m/s the other was designed to land at 7 m/s and landed just fine separately w/o any control .
  3. I don't think that it is actually implemented that you can destroy stuff that way.
  4. . I would also add that with panels and rover wheels you don't have to hover. just build a rover/lander, that has a low sloped panel, land near the pod, force yourself under the pod, secure it with landing legs, and fly off to Kerbin. But beware, you can't time warp while doing this. So, if the capsule has enough chutes to land on its own, steer it into a reentry trajectory and release it. When not, you have to release it, ( or it will clip trough you anyway ), zero relative velocity, time warp, and catch it before entering atmosphere so you can land it on your chutes.
  5. I was talking about the surface. The fuel rod interior could be pure ( at the working temperature liquid ) plutonium. Only the outer shell holding it together would be oxide.
  6. The standard reaction goes like 2CO <-> CO2 + C. temperature shifts the equilibrium to the left, pressure to the right. I am sure that say 2000 K would be enough to shift the equilibrium even at 93 MPa so far to the left that even reactions like CO2 + M -> CO + MO ( where M means any metal ) would proceed quite rapidly, but if the surface of your reactor is nothing but refractory oxides like PuO2 and BeO, then you have nothing to worry about oxidation at all - everything that could be oxidized already is...
  7. The supercritical working fluid has to expand to cool down below ambient temperature just like a gas does, because there is no phase change involved. So, the open cycle heat pump would be little more than a vacuum pump that keeps a tube at low pressure at one end and a small opening that sucks in ambient CO2 and lets it expand on the other.
  8. Working fluid would be the same ambient CO2 that is all around. The heat pump will be open-cycle too.
  9. What about a plutonium fueled helicopter ? Turbine, CO2 pump, power generator and heat pump on one shaft, and the helicopter rotor driven through a gearbox. EDIT : Even crazier and simpler design. screw turbine, pump and gearbox. Make the rising plume of superheated CO2 spread and draw with it upwards a lot of ambient CO2. Then place a large helicopter rotor above it. It will spin up and you will be able to fly solely through induced autorotation ( and will even be able to drive the heat pump and generator with it )
  10. . You won't need any cooling when you are immersed in hot supercritical CO2. Just go open-cycle, suck in CO2 from bottom solely through buoyancy, and above the reactor core a lightweight turbine propelled by the rising buoyant CO2 before being released back to the atmosphere. The Venussian Greenpeace would not be happy about the rising radioactive plume, but, of course, there is no Venussian Greenpeace
  11. The plutonium would weight around 3 Kg but you would need some more Kg of neutron moderator around, beryllium carbide is the material of choice, which is lightweight and efficient. So, say, the entire reactor w/o shielding, turbine and cooler would weight around 20-30 Kg. Together it may be below 100 Kg, conservative estimate. . EDIT : The best insulation available
  12. You would have to drill a lot to get hot enough to have a meaningful temperature gradient relative to a 750 K atmosphere. I think that the best solution is a high-temperature plutonium reactor. Plutonium has a critical mass of mere EDIT:10 kg ( even less with a beryllium reflector ) using the locally available supercritical CO2 as coolant and working fluid. You wouldn't need to worry about shielding, the 60 kg/m3 dense atmosphere will do the job fine all on its own, just hold the reactor on a long pole away from the crew quarters. . One more thing. the 4kw value is most probably overrated. I took the thermal conductivity of the best insulation available with thermal conductivity of 0.006 W /K /m2 I came with like 300 W for a 9 m diameter sphere and 450 K temperature gradient.
  13. from http://www.universetoday.com/36816/winds-on-venus/ from http://hyperphysics.phy-astr.gsu.edu/hbase/solar/venusenv.html . . Maybe there could be a reasonably sized wind turbine ( shaped more like a water propeller because of the atmosphere thickness ) could supply the required energy even with wind speeds of only 2 m/s, but any prolonged calm would result in cooked astronauts.
  14. using stock only you have a few choices - match not only docking ports and their heights, but also the type of wheels, and rover weight per wheel. - calculate how much the wheel suspension will be compressed given the target planet's gravity and rover mass and offset the docking port height accordingly - dock using landing legs, length of which is more or less independent from how much weight they are carrying - dock vertically ( and use landing legs to either lower the top piece or raise the bottom piece ) EDIT: you could also use the idea from above, to place the docking port on something deliberately made wobbly and thus flexible, I have however zero experience with this
  15. . It just tends to make far more mess than it cleans up. A bug( or feature:) ) of the physics causes that in a collision always only one of the colliding parts gets destroyed. never both, so you can't reduce debris count that way.
  16. when you want an all-stock in-game solution, build a bulldozer rover that pushes all pieces of debris onto the launch pad or runway. when you launch the next ship, it will be cleaned up = deleted.
  17. To destroy Titan, not just scorch it, blow up the atmosphere, or melt the surface, you would have to supply more than its gravitational binding energy. Which is 2.8e29 J. Which would need approximately 5e21 Kg of methane, or, given its liquid density, a global ocean of methane 125 km deep on the surface. And then we would have to add 2e22 Kg of oxygen on top of that. But the Titan has not even a fraction of the required methane so the point is moot. . But if you are just out to blow up Titan using oxygen, and it doesn't have to be through methane-oxygen combustion, you can do it with far less. Just accelerate a 150 million ton heavy block of frozen oxygen to 99.9 % c and smash it into Titan. Kablam, Titan gone !
  18. . the accuracy breaks down, and for the best methods I've seen, the inaccuracy reaches a whopping 0.0001 % per orbit when having less than 30 points per orbit... which is, methinks, for the purposes of KSP, negligible . . Get yourself better apps
  19. I did the maths and aerospikes save the weight(scaled by thrust ratio) difference's worth of fuel mass after cca 26 sec at sea level. so they are better over LV-30 on any stages that burn longer than 26 sec. Which most of my first/second stages are. EDIT : When I've done the same calculation again, I came with different a number 49.46 s at sea level. For different heights it's 74.61 s at 10000 m and 169.66 s in orbit The eq I used is t = (Mspike*Thrlv30-Mlv30*Thrspike)/(Fflowlv30.1atm*Thrspike-Fflowspike.1atm*Thrlv30-(1-EXP(-LOG(2)/5000*Height))*((Fflowlv30.1atm-Fflowlv30.vac)*Thrspike-(Fflowspike.1atm-Fflowspike.vac)*Thrlv30)) . note that the engines have different thrust so I scaled everything by their thrust ratio to make a comparison
  20. inclined low orbit PRO: - far less dV. CON: - launch window only once when your orbit just touches the site or twice when your inclination is higher. However, by a small change of inclination during landing/ascent you might be able to launch during say 20 - 25 % of Muns rotation. - incoming/outgoing ships will have to change their inclination, however this dV cost is negligible when done sufficiently far away Low equatorial orbit PRO - you can come up/down pretty much any time CON - you pay all the dV costs of high inclination change, which may be well over 300 m/s High equatorial orbit PRO - the higher up you go the less dV inclination change will cost you, faces however diminishing returns, as landing and taking off will cost more dV CON - It is so slow that you may wait comparably long to a launch window as with the the inclined orbit - very little help from oberth effect when leaving/entering orbit
  21. I've experimented with lithobraking on purpose, I've even built some rovers that landed at ~50 meters per second and braked by bursting all their wheels and followed by punching into the grund down with their reinforced bottom. I however found out that pure lithobraking is unreliable because other, weaker parts become disconnected or forced into each other and explode during impact.I suppose this will be a problem too when sliding.
  22. . there are stable methods in the sense that in 1 body case all orbits that contain more than a few dozen timesteps per orbit stay stable.
  23. . AFAIK the RemoteTech mod can do that. . EDIT: Another possibility would be of course to add an arbitrary cutoff where the influence from the other bodies is too small, just like the atmosphere cutoff so ships on low to mid orbits would be completely unaffected.
  24. . If your numerical solver can churn out extrapolation of several thousand orbits per second, this would not be more difficult than computing positions during max time warp. And one could still let the solver run asynchronously or iteratively , simply adding as many points to the predicted trajectory per frame as it during a fixed time slice, so on a low end hardware and a very hard to predict chaotic halo orbit, you would move a node and see how your trajectory forecast stretches continuously over a few sec.