Search the Community

The way the runway levels up is very weird. It starts off so bumpy that it is easier and safer to just take off from the grass right next to it. What I'm proposing is that the runway start off very short, and progressively get longer, instead of the runway starting off very bumpy and getting progressively smoother.

Maneuver nodes can't be made when not connected to Commnet, but it should be possible to delete them. I want to be able to warp to a point in my orbit instead of worrying about a burn I made three KSP years ago!

You should know there should be a button to stop the use of all of a certain type of resource

Every who played KSP know that Kerbin orbit start about roughly above 70 km but i wonder why not make atmospheric drag affect even at higher altitude like it is in real life. So even satellites on LKO are not safe like it was on real life, and make Kerbol affect the Kerbin atmosphere

So when you place stuff in radial symmetry in VAB you have the options to place the part 1, 2, 4, 6 or 8 times in radial symmetry. Now, when you want to attach child parts to these, they have to be either placed single or in the same symmetry setting as the parent part. My suggestion is this: Allow placing of child parts in a fractional (e.g. halved or quartered) symmetry count (not sure if that's the right way to call it), if the result is a full number. Or as a complete list: parent 4 times -> child 1, 2 or 4 times parent 6 times -> child 1, 2, 3 or 6 times parent 8 times -> child 1, 2, 4 or 8 times If this is not understandable or if anyone has suggestions on how to word it better, please tell me Edit: remembered that 2 times symmetry for child parts on 6 times symmetry on parent parts also fits in the list

I remember back just before 1.0 there was a mod that allowed you to toggle a button in the hanger menu of a thruster or engine to essentially make it a giant RCS thruster as it it was controlled by the RCS system. I really think something resembling that would be amazing is the stock game for when you want to use RCS thrusters on a large to massive craft. The mod also auto adjusted the thrust of the thrusters on your ship during flight(if you wanted it to) so the center of thrust would always be directly on the mass. It was an amazing mod if someone can find an updated version of it. I would like to know if it would be possible for Squad to make it apart of stock KSP or any problems that may occur by trying to do so.

Are there any plans to get KSP supported by the Curse Client or (preferably) Steam Workshop? I've tried using community-developed mod managers, but they haven't worked out for me. Now the game goes Challenger whenever I try to launch it. What I need is a simple mod manager. I'd like to be able to add, remove, enable, and disable mods on the fly, much like games using the Steam Workshop.

Hi folks, it is Casualnaut back with another suggestion for the glorious Squad development team. I was wondering if there could be an end-tier rover wheels that used the Rocker-Bogie System JPL uses on the Mars rovers. They would come in entire sets of 3 wheels, and would crawl up terrain like this: Image provided by Wikipedia Note: I may edit the thread as responses come to make it the best suggestion possible.

this will improve the game greatly!

I have been making a new rocket, and I was surprised to find only one launch escape system (I'm inexperienced). I am wondering if squad can add more launch escape systems in stock?

Searched and couldn't find anything resembling this so here we go. I feel that KSP needs some sort of a quest, to guide you in your exploration of the stars. Using the in-game easter eggs, lead the player on a scavenger hunt to discover more clues about the nature of the Kerbal universe, their origins, and possible lore explanations for the game. Starting out would be simple, visit the Proceed from location to location, using kerbnet to locate these locations (already built in game), heres the path that I'm currently following in my 1.3 career Who put those monuments there, where did kerbals come from? hopefully some answers will be revealed. Thanks for stopping by!

Please someone merge (or tell me how to do it) the stock and small RSS so it should looks like this: correction: ...same orbits but same time apart. test: I will use these acronyms, please don't take them: SSU, SSS

In my opinion, Asteroids are a great part of the game, they teaching you how to rendezvous with objects on awkward trajectories, allow you to build very nice stations and give you the ability to top up on fuel on deep space exploration missions. However, there are only two areas in the system where asteroids appear, (Kerbin and Dres) and they are both located fairly close to each other in the inner system. What I'm proposing is a Kuiper Belt (for once, something we don't have to ADD the K to ) analogue which would be located in the space between Jool and Eeloo, with asteroids rarely encountering each planet. This would give deep space explorers the chance to refuel, while adding another realistic counterpart to the Kerbol System. (As a side note; We know Bop and probably Pol are captured asteroids, and this would answer the question "What asteroids?" Also, as Jupiter has around sixty-five moons IRL, I think it would make a lot of sense to have asteroids be captured by Jool, maybe giving it around 5-10 asteroid moons, and it would be great fun to name them and potentially fling any ones you don't like into Jool's atmosphere.)

So this feels like exactly the sort of thing Kerbals would come up with, plus it would settle the 'is the runway flat' debate forever, and be awesome to actually use:

Hello All I have lots of mods installed... And I'm sure most of you guys have got a lot installed as well. So I was thinking if maybe in the main menu there could be a tab where you can view all mods installed and if possible, disable/enable them. The KSP Modding community is a grand one and I'm sure it would make a lot of people happy if this was a thing. Cheers, WhiskyHotel3

I had an idea of adding building that would be in the game usually used for the career mode. Like for tourism you could actually do fight to city and airports to get cash, and you need to do it in a certain time to get cash. and adding cities to show kerbal has a population at least

The physics toolkit in KSPEdu is very good, but it's missing one thing: torque visualisation. I've used KSP with Infernal Robotics to investigate torque with students, and it works pretty well. You make a satellite with 2 fuel tanks and 2 small engines, each on the extendible piston part from IR, so you can change the force radius to change torque, and change the mass radius to change the moment of inertia. (You can also cheat to add or remove fuel from the tanks to change moment of inertia also.) This would take more work to do in KSPEdu, but even without IR parts, a way to see/measure torque would be very helpful. I think something similar to the force visualiser part would work well. Thanks!

Hey there! I haven't been playing ksp for a while now, but in the meanwhile, I came up with an, in my opinion, good idea! Currently Ksp offers you a bunch of planets, on which you can land on and visit different biomes, to get more science. And thats pretty much all you can do with planets... In my opinion kinda boring . So my suggestion would be to make planets more interactive, and therefore much more interesting. As you may know, rocks are not solid. You can walk through them... But this is just one thing that bothers me. In my opinion planets also look a little bit boring. The textures are bad and surfaces can be either solid or fluid only. There isn't any kind of action on these planets. I mean, imagine big dusty storms on Duna! Or Geysirs on Jools moons! Just these little details would make the game so much more awesome! What do you think guys? I'd love to hear your opinion! Thank you very much!

I think that in the career tech tree, unmanned probes should come BEFORE manned crafts and parts. It makes no sense to send kerbals up before satellites. (That is, if you can get "Stayputnik" not to stay-put :P) It would be way more realistic and easier starting, since you don't have enough money to keep hiring and killing more kerbals. -Thanks for reading

I know that there has been talk in the past of bringing back the old part models. I believe I have a method of doing so. Basically, some new parts with the old textures (smoothed out, but staying true to the original textures) would be added as cheap, low-tech items for an early space program. TCFF-01 A cheap but heavy fuel tank. Its designers insist that TCFF does not stand for "Tin-Can Full of Fuel." TCFF-02 The half-size little brother of the Tin-Ca-... I mean... TCFF-01. BR-1A One of the first rocket engines ever produced on Kerbin. It was quickly adopted by smaller space programs because of its cheapness and was used as first-stage propulsion and as a heavy-duty grill. BR-1B The gimbal-capable cousin of the BR-1A. It became popular as a cheap upper-stage rocket and carnival ride. X-01 Command Pod The original command pod. Because it was built in 2.5m size while most industries were focusing on 1.25m size, it was phased out. However, some rookie rocketeers have taken a liking to the old surplus pod and have been putting it to good use. APE-LAF The Atmospheric Propulsion Engine for Low Altitude Flight is the first jet engine ever produced for space programs. Its design was highly controversial since the APE series was not a rocket and its target industries focused on space travel. APE-HAF In response to the controversies surrounding the APE-LAF, the High Altitude Flight variant was developed. Its designers claimed that, while it still required oxygen to function, it was technically a rocket since it burned fuel directly as opposed to spinning a turbine. APIS After complaints of the APE series of engines sputtering and not working, the Atmospheric Propulsion Intake System was slapped together. It was fascinating to pilots because of the mysterious blue glow that it would emit at high speeds. ACM Mk1 When space programs began asking for a more permanent and aerodynamic alternative to command pods, the Aerodynamic Command Module was developed. Its designer insists that it is not a nosecone with controls and a window thrown into it. ACM Mk1b After slamming a plane into the side of a hangar and flattening the front of the ACM, it was accepted as a new variant. ACM Mk3 The chunky prototype of the Mk3 Cockpit. While heavier, the ACM Mk3 is cheaper and slightly smaller. C7 SLG C7's own Static Landing Gear. Intended as cheap, heavy-duty landing wheels. Not the most aerodynamic of aircraft equipment, but it gets the job done.

Hey, For me, at least career mode isn't for most fitting, because i cant build whatever i want. So Science mode is mainly what i play, But i think there should be more career stuff in science. Example: You can upgrade Facilities by science points instead of fully upgraded ones. And another main thing is that contracts in science mode, because sometimes it gets boring. I am glad that kerbal experience can be turned on at science mode, but it still needs more career options. Of course this can be achieve by playing career and max out money and then remove science points when upgrading facilities and reconfig contracts, but it does not feel same. i am really glad if these thing get added to KSP. Cheers.

Following up from a thread in gameplay, my suggestion for the next release is a revision of the fuel transfer mechanism. Instead of the rather rudimentary ALT+click to fill a tank, you should be able to specify how much fuel/ox/monoprop you would like to transfer. This could be acheived (I'm guessing) by making the fuel/ox/monoprop sliders manually adjustable, as they are in the VAB. It would also be helpful to be able to lock liquid fuel and oxidiser together so you could transfer in the right ratio. Another option might be to be able to specify how much fuel you would like to transfer from tank A to tank B (eg manually enter a value - say 30 monoprop - to be transferred. There may already be a mod that does this, but as someone who tends to play stock, it would be nice if it was included in the main release. KSP is a stupendous game, good work devs!

How about Solar Flares and Radiation management - could include a basic spectrum of challenges, eg: seperate shielding types for different threats (neutrons, charged particles, EM etc) This would make manned travel far more costly than unmanned, at least beyond the Kerbin magnetosphere (with the exception of the Van Kallen belts ofc.) so some extra advantage of taking crew would be appropriate - such as enhanced sciencing (but that is another topic). Want to bum around Kerbin-Mun-Minmus? Not much in the way of shielding required, unless you intend to spend significant time orbiting within the Van Kallen belts. Want to get to Duna? Gonna need some shielding. Want to get to Jool? Gonna need shielding for the journey AND take into account the radiation environment of a gas giant. Want to get to the far reaches of the system? You will probably want a nice tasty nuclear engine. With a nice heavy shadow shield. Extra challenge. Extra detail. More ways to customise your craft ideas. What more do you want?

When the information panel is displayed for a docked docking port, include a readout of the current angle of the face of the docking port relative to its partner. Include + and - buttons to rotate the partner docking port (and attached structure) without undocking. This would allow a much greater degree of precision in the construction of structures and vehicles in-situ. For example, two short 2.5m vehicles with two Rovemax XL3 wheels each in mirror attachment could dock with Clamp-O-Tron Sr. ports to form a large rover. It would be much easier to ensure that the wheels are all facing in the same direction with this method, rather than undocking and rotating a potentially unbalanced structure. Something like this:

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.