natsirt721

It probably isn't possible. Drag increases with the square of the velocity, so it is likely that at the sorts of drags experienced on an escaping body at 1km no (sub-relativistic) speed is sufficient to clear the atmosphere. There is an old aerobrake calculator here that can probably be reverse-engineered to acquire a solution, although it might use valid equations - it was accurate before the atmospheric revamp. @alterbaron do you think that is doable?

You would need many thousands of high-power lasers to properly move a lightship, agreed. But the nice thing about starting from home is that you can always build more! With a battery of tens of thousands of individual lasers you can cycle them on and off (to allow for course corrections, which as you point out would be necessary). Put them close to the sun to utilize its free energy and it is feasible to engineer a vessel with a reasonable acceleration. A 10 meter radius terrawatt laser would have an intensity of 1x1012W / (10m)2π = 3.18x109 W/m2. This is 2 orders of magnitude greater than the solar surface intensity of 6.33×107W/m2. Now imagine thousands of these pouring their stuff into a single sail, and the newtons add up pretty quick. Lasers can also be focused to reduce inverse square loss, to a point.

Something almost certain to be in 1.3 is upgradable parts via the tech tree. The functionality was added but not implemented recently and the next step would be to utilize it. This may come with a science point / tech tree revamp, but not necessarily.

So, something like and angle limiter slider in the VAB? Could be nice. Would impact radiator performance, but I can definitely see the advantages especially for the XL and 3x2 panels.

I agree that the system is very kerbal in nature. I was expecting more from the description of SAS than it was providing, and that disconnect was the source of my ire. Also probably should have seen the 'get a mod' response.

I've got an engineer and a pilot at a mining outpost, and 2 scientists at a lab near the north pole. The engineer is for the ISRU boost and the pilot is to drive my cruiser rover to farm surface sample contracts. Even though Minmus seems to be the community's choice, I prefer using the Mun for fuel because it makes logistics a lot easier. No plane change and shorter transit times trumps low gravity and flat ground IMHO. My career game is still getting off the ground though, so perhaps in the future I'll migrate outwards.

With the understanding that KSP2 is probably not going to happen any time soon, the one feature I would most like to see would be destructible terrain. Being able to dig into the Munar surface and place base modules directly on the ground would be very cool and another step towards realism. ISRU would actually require digging a giant pit instead of using magical ore-straws. You could land pretty much anywhere and with enough effort bulldoze a plateau to land rockets on. Being able to grade roads for easy transit would greatly improve overland travel on low-grav bodies. Plus, you get impact craters whenever you crash!

Well, I think a sandbox mode in addition to 'space tycoon' mode would be retained. Sandbox is a good way to start new players who need to learn how to build rockets properly, or for more experienced players trying out new things they couldn't otherwise afford/accomplish in tycoon mode.

Not sure if this has been mentioned already, but in the Niven/Pournelle book The Mote in God's Eye the Moties (aliens) sent a beam rider to a nearby star system. It was mentioned that the humans were confused that the Moties didn't use the beam to decelerate the craft, instead using a solar sail or some other method to decelerate. In order to use the same beam to decelerate, the ship would be sent out on one leg of the path, then charge the ship up to 10kV and use the Lorenz force from the galactic magnetic fields to approach the target star from behind. Winchell's site has more on it, but it's such a vast expanse I'm not even sure where to begin looking for it, If the first ships deployed are terrawatt lasers, then you can remotely establish 2-way travel between stars using only laser-launch systems.

I don't think there has to be a game-given motivation. KSP is a sandbox game at heart, career and science mode are just constraints. In the end, you do what you want, how you want. That's motivation enough for me.

In my experience (1000+ hrs) SAS has always had a really difficult time negating steady-state error. As I understand it, SAS uses a PID controller to maintain a constant heading, and the wiki confirms this. However, the integral gain must be set to zero (a PD controller), because the system simply does not respond to steady-state error. You can see this yourself with any spacecraft where the thrust vector doesn't intersect the CoM. Setting the SAS and engaging the engines causes the craft to slew. The SAS will stop the slew after a few degrees (depending on the strength of your control schema), but it doesnt even try to get the heading back to the original state, even if the control axes are not pegged. It seems like the directional holds are slightly better at countering error but this may be blind optimism. If anyone has any insight into why this may be it would be greatly appreciated.

This is a really good point, something I didn't even consider. I suppose you can use multi-porting for increased structural strength, but with auto-strut now that isn't even a constraint.

I think any paid DLC for this game would have to be pretty groundbreaking and add some seriously novel mechanics, otherwise someone's just going to mod it in for free.

Previously I had expressed some grievances regarding the way that KSP handles signal strength and data transmission. After some time with my nose buried in information theory books and 30 year old PDFs about the DSN, I propose an improved system that is a little more realistic, but not too technically challenging. First, the concept of bands. The DSN is capable of operating in several bands, and these are; L-band (1-2 GHz) S-band (2-4 GHz) X-band (7-11 GHz) and more recently Ka-band (26-40 GHz) Lower power bands are available earlier in career mode, and the Tracking Station is capable of operating on higher energy bands with upgrades. Also included with the L3 station would be the ability to use a 500 GHz infrared laser communicator (with a new part or 2), which would provide a wide-band long-range communication link with properly equipped vessels. Higher power bands provide more bandwidth and less distance attenuation, but have higher energy costs per mit. Early antennae would only be able to utilize the L-band, but with the as-yet unimplemented part upgrade system they would be available to use a higher power band with the proper tech (eg, the Communotron 16 family would be L-band only at unlock, but could be upgraded to use the S-band later on). The late-game antennae would be capable of utilizing all bands, but only one at a time. This would be selected during vessel construction via the context menu, and would be fixed at launch. Each antenna also has 2 qualities (for determining signal) for each band. The first is the transmitter power measured in decibel-milliwatts (dBm), and the second is the antenna gain (also in dBm). The antenna also has a noise power, but this is independent of the band used. The tracking station also has these qualities for each band as well as a 'nominal bandwidth' value (~1-10Hz, except for the laser communicator which would be in the high kHz range), and upgrades will adjust the values to optimize for increased communication bandwidth and longer-distance communication (ie, higher power, higher gain, less noise power). Working with real-world values is difficult in KSP because of the reduced system size, but I have here a worked example with some conceptualized values. Before we get started, here is a quick unit conversion: dBm = [10 * log(W)] + 30 (watts to decibel-milliwatts) W = 10 ^ ([dBm + 30] / 10) (decibel-milliwatts to watts) Tracking Station: Level 1 L-band transmit/receive Gain: +50 dBm gain is directly proportional to the square of the antenna diameter and inversely proportional to the square of the wavelength Power: 30 kW = +44.8 dBm power is simply the transmitter power, a 'chosen' value Noise Power: 4.00e-20 W or -173.9 dBm thermal interference on the receiving end. directly proportional to bandwidth and dependent on the boltzmann constant Bandwidth: 10 Hz Bandwidth choice is arbitrary (read: defined by the hardware), but is usually higher on manned missions in cis-munar to allow for direct voice transmission. Unfortunately, this isn't a modelable feature so the bandwidth should stay low to keep the noise power down. Communotron-16 in Mun orbit, L-band transmit/receive Gain: +3 dBm Power 0.1W = -10 dBm Noise Power: 1.38e-20 W or -176.8 dBm Munar orbit is ~11.5x10^6 m from kerbin (give or take), so distance attenuation is calculated by: l^2 / (4*pi*r)^2 Where l is the wavelength and r the distance (units of meters, result is in watts). L-band has a wavelength of ~20cm (0.2m), so this equation evaluates to ~2.7e-10 W or -95.6 dBm To calculate received power, simply add the transmit power, the gains of the transmitter and receiver, and the distance losses. Uplink Signal: 50 dBm (station) + 3 dBm (probe) + 44.8 dBm (station power) -95.6 dBm (distance loss) = 6.5 dBm or 4.6 Watts received at Mun Downlink Signal: 50 dBm (station) + 3 dBm (probe) -10 dBm (probe power) -95.6 dBm (distance loss) = -48 dBm or 0.000015 Watts received at KSC Now, we can calculate the signal-to-noise ratio (SNR) for the uplink and downlink, and this is done by dividing the signal by the noise power of the receiver. Note that this has to be done in Watts because of the logarithmic nature of the decibel system. Uplink SNR = 4.6 W / 1.38x10^-20 W = 3.33e20 Downlink SNR = 1.5x10^-5 W / 4x10^-20 W = 3.75e14 Using the Shannon-Hartley theorem, we the calculate the maximum bitrate at which information can be exchanged across the link. This bitrate is used for determining probe control on the uplink side, and for determining data TX rate on the downlink side. C = B * log(1+SNR)/log(2) where C is the bitrate, B the available bandwidth, and log the logarithm base 10. This equation can be simplified by taking the numerator and using a logarithm base 2 without the denominator, but I figured I'd put it in calculator-friendly mode for those of you who don't know how to do change of base. Using this, we calculate our max bitrate in each direction: Uplink bitrate = 10Hz * log(1+3.33e20) / log(2) = 681 bits/s Downlink bitrate = 10Hz * log(1+3.75e14) / log(2) = 484 bits/s As you can see, these numbers are pretty small compared to modern communication standards, but they are probably within an order of magnitude or two of the balanced values. According to wikipedia (nb: not-necessarily reputable source) the 20W transmitter on the Apollo LM could support a 56 kbit telemetry link or a 1.6kbit backup link, ergo the base values for power, noise, and gain require a bit of tweaking (especially for the higher power bands). As mentioned above, the downlink bitrate determines the rate at which science can be transmitted. This requires a re-scaling of the 'mit', as these rates could transmit any experiment in less than a tenth of a second, however the 'mit' system seems to be arbitrary right now so this isn't a huge deal. The uplink bitrate would determine whether a probe was controllable or not - too low of a bitrate (set arbitrary value here) and the probe can't effectively receive commands from ground. Alternatively, a minimum receive power could be used as the limiter rather than bitrate - this would allow the player to calculate probe controllability a little easier. The actual transmission system works like so: Antenna also have a 'power per mit' value, which depends on the band being utilized. Higher power bands require more EC/mit, but due to the difficult task of converting EC to Joules (EC/s to Watts) I haven't run any numbers here. The rough estimate I've seen is 1EC = 1kJ (1EC/s = 1kW) but I'm not sure how well this is balanced. The transmit bitrate for an antenna would be tweakable by a percentage slider; this allows the player to continuously transmit data at a slower rate than maximum which may be necessary do to electrical constraints. For use with relays, each link would have a bitrate calculated, and the lowest bitrate would be the bitrate for the channel. When a probe desires to transmit data to KSC, the downlink bitrate is calculated and a 'long action' similar to how the MPL works begins. The antenna begins transmitting data at the calculated downlink bitrate times the percentage slider (and consuming EC at a proper rate), and science will either 1) begin to accumulate at KSC until all the data goes through OR 2) build up in the antenna until it has all been 'transmitted', from which another action made on the antenna will 'commit' the science to KSC. The former would be ideal, but I'm not sure how KSP would take to incrementing the science over time, especially through warp. On the player end, they would require a signal distance attenuation table for each band, and the would simply sum the tracking station gain, probe gain, the loss in the table, and the transmitter power to get a received power. The bitrates would be calculated under the hood, and be displayed on the probe antenna's context menu. Send and receive power would be displayed in the current signal strength bar next to the chronometer. The purpose of this redesign is simple: to increase realism in the science process. Yes, the 'unlock points' system has its flaws, but that doesn't mean the transmission system has to be garbage as well. The New Horizons probe took over a year to broadcast all of the data it collected at Pluto, and the Voyager probes still have a non-zero downlink bitrate (~200 bits/s IIRC). Why can I send back all my data from Jool at lightning-speed? Separating the uplink and downlink signals also allows us to create one-way links, for what that's worth - another realistic scenario that the current system cannot simulate. tl;dr: The CommNet mechanics are trash and it wouldn't take much effort to make it better.

I would argue that losing instantaneous thrust is a huuuuge price to pay for a maximum thrust indicator. If anything, I would advocate for both to be displayed at once, probably on one line (eg "Thrust: 45kN / 60 kN"). In a vacuum max/instantaneous thrust may be fixed but while in atmosphere that value changes with altitude. Losing that display - especially for air-breathers - would impede a lot of people trying to do more technical designs. This may be a difference in mission design philosophy, but I typically try to calculate thrust, acceleration and dV before I execute my node and plan accordingly, rather than calculate it on the fly (pun intended). The only times mass changes is 1) When altering the parts of a ship (ie docking) or 2) Expending fuel (ie burning) so I don't really see why you need a real-time display of mass at every point during your burn. I guess I am failing to see the need for the UI including a value of m-dot or a more accessible indicator of mass, and as I said before, total instantaneous fuel consumption is already displayed in the resource tab, which (when calculating if you have approximately enough fuel to complete your burn) is the important number anyway.

I would not set up a large-scale ISRU plant on Tylo or on Laythe, as the higher gravity means you're going to waste a lot of fuel just moving your fuel around. Maybe a small plant used for refiling landers, or a lander with integrated ISRU. Bop and Pol are attractive locations, as their low surface gravity and high orbits allow your tanker to aero- or gravity-brake down to the inner bodies with minimal fuel expenditure. If Laythe is where your base of operations is, you can directly aerobrake there and save some time as well. You are almost certainly going to need some large propellant storage on-orbit, unless your lander can handle a landing and takeoff from Tylo and Laythe with wetmass to spare for maneuvers. If you're going reusable, I would design a 2-part lander. The lander segment has 3.5-4kps dV with a small onboard ISRU plant. This allows to land, refuel, and take off from any given body around Jool. The second part would just be an NTR attached to a fuel tank. This allows for more efficient orbit-to-orbit transfers around the system, and it can be refueled by the lander. Keep in mind that the small drill has a minimum concentration value (2% IIRC) so you're going to want to ore-scan all the bodies before you land.

The thud is really only useful for surface-to-orbit operations, places where fuel usage is less of a consideration and form factor and control are dominant to efficiency. For a medium-sized orbit-to-orbit ship there are a plethora of engines which perform better. Maybe use them to augment control on large ships? Radial-attach lets you leave the bottom node open, useful for vacuum lander cranes and whatnot. The large gimbal range lets you land asymmetric payloads with a little more ease. They can also be used in career to make a proto-shuttle with the Mk2 parts, as they are the only engines available before the KS-25 with enough gimbal range to do a proper shuttle. I never considered using them on first-stage launch vehicles as SRBs usually provide enough extra thrust for my needs, but I'll see if I like using them. Someone mentioned they improve control for recyclable first stages, something that I'm currently working on in my career game.

I think KAC could be appreciated by everybody. KAS/KIS or some similar system should almost certainly be implemented at some point in the future. KER is nice, but as was mentioned earlier it could be overwhelming for new players.

I suppose that the docking ports themselves would provide the torque, but it would have to be a very small value. I don't think this will work though. Imagine 2 vessels docked by 2 docking ports. If you rotate one, do you break the link on the other? The torsional stress might be strong enough to tear parts off of one or both vessels. It would require a lot of safeguards to be done properly.

This sounds to me like 'this mod is useful and i want it in stock', correct? Alternatively, you could just learn the specs of your engine. Acceleration is also available from the map screen, but it doesn't update until you ignite the engine IIRC. For calculating dV, you just need wet mass / dry mass / isp; one is available from the mapmode, one is available by subtraction, and one is inherent in your design. Fuel consumption isn't a useful statistic if you know how to do the dV math. I guess what this boils down to is: learn your parts?

Even the largest class of 'roid right now is still fairly small in terms of what we've seen IRL. However, the Kerbin system is at ~1/10th scale so those medium 50km asteroids are going to boil down to about 5km. That being said, 5km is still significantly larger than any other procedural asteroid. They would be practically immobile, but if one were willing to use a good fraction of the mined propellant they could probably be nudged around a bit. The issue with large asteroids in KSP is that the draw for mining the belt (IRL) isn't to get fuel, but raw mineral goods. The carbonaceous asteroids there are only mined to support the mineral extraction services, something that KSP doesn't need. Fuel extraction is much more practical if you can extract it at places you're already going, i.e. planets or moons (Saturn's rings, Deimos, Europa etc.) - hence KSP's small mobile asteroids. Having to stop near Dres in order to fill your tanks is going to add a ton of time to your trip, because even with NERVAs it isn't really practical to use anything other than low-energy transfers. Unless you've got a gigawatt fusion rocket and can do the trip in 100 days or so, your transit time (first to the belt, and then to Jool or whatever, including time spent waiting for transfer windows) is going to be significantly increased. Of course, there is always the humble fuel tanker, but in the end, you're still moving your fuel around before using it. I think comets and KBOs (kerbier belt objects?) would be a neat addition, however the dV required to rendezvous with a long-period comet would be absurd and they would probably go unappreciated by most players. It would make neat challenge though!

Right, empty fuel tanks are not truly empty. Its nearly impossible to utilize 100% of the carried fuel in microgravity without some sort of variable-geometry fuel tank. If you look at the fuel budgets for the Apollo program as in this pdf (page 12) you'll see that there is 250 lbs of fuel mass labeled "Unusable", which works out to ~1.4 percent of the total fuel mass. 250 lbs of RP-1 and LOX will produce quite an explosion if detonated all at once. Fuel management IRL is wayyyyy more difficult than Kerbal makes it out to be, but having to deal with propellant boil-off and micro-gee fuel transfer and fuel mixing and ullage and whatnot is not nearly as fun for the average player. Behind every great spaceship are 100 great plumbers

I realize now that this would require a pretty major overhaul of the communications system, something I'm currently working through conceptually. Will make another post on this forum when I'm finished. Main concepts include: Signal strength is based on antenna gains and TX/RX power Vessels will have a different uplink and downlink signal strength, and require an uplink for control Antennas have a 'nominal' bandwidth, and the effective bitrate is dependent on this bandwidth and and signal strength Signal strength is no longer a percent value, but measured in some quantitative unit (dBm/dBw or mW) The sun has a massive occlusion zone due to interference Tracking station upgrades will affect TX power, antenna size, bandwidth and other characteristics to improve the overall TX/RX of the DSN Atmospheric signal attenuation? Multiple communication bands? Still on the drawing board for now.

I recently landed a 6t 4-wheel rover on the Mun with a SAS module for stability. As far as I can tell, you want to set the traction control wayyyy down, if not zero and override the friction control lower to avoid flipping. I used a traction control of 0 and a friction control of 0.6, but these will vary with the vehicle. Lowering the friction control will allow the rear wheels to slide a bit before catching, which is what really causes the roll. You're going to want to quicksave and play around with the tweaks until you find something that works for you. In my experience, using reaction wheels to mitigate rolling is the best way to design a rover. Keep the CoM low and build your wheelbase wide, and you should be fine. Don't try to turn faster that 25 m/s or so (on the Mun anyway) unless your SAS is crazy powerful. If your pilot can lock prograde, driving with SAS locked to prograde will help stability during turns. You also get some air control when you launch off a cliff or something. Something else to keep in mind is that you can set the friction control to 0 (I think this is a bug?), and the wheels become 100% frictionless. Your rover is now a sled. Have fun!

The Bussard ramjet would be sweet, except that 1) It has a minimum velocity of anywhere between 2 or 10 percent the speed of light to even take in enough hydrogen to sustain a reaction, 2) It is only really useful in interstellar space, and 3) Bremsstrahlung and synchrotron radiation limits the max velocity to about 12 percent speed of light, so what's the point. Also requires proton-proton fusion, and we can't even figure out D-T fusion! There is only one purely electrically propelled spacecraft AFAIK, and that would be a laser lightsail. Put a battery of solar-powered gigawatt lasers around the sun and shine them at your mirrored spacecraft. Like the solar sail, but with reasonable thrust. The problem with low-thrust propulsion is that IRL, you use a brachistochrone trajectory which is impractical given the way KSP handles physics and warping. This means no (realistic) ion drives, no solar/mag sails, no VASIMR. Current hall thrusters have thrusts in the 0.5 newton range, 4 orders of magnitude weaker than the Dawn. Radiation pressure at earth is somewhere in the micronewton per square meter, which means your sail is going to be a few kilometers on a side for a handful of newtons of thrust - again, impractical. At the core of it, friends don't let friends use reactionless drives. You gotta leave something behind. Laser lightsail / laser launch is the closest you're going to get, and the only one that doesn't strain the bounds of modern physics.