Search the Community

Showing results for tags 'suggestion'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • The Daily Kerbal
  • Kerbal Space Program 2
    • KSP 2 Discussion
  • General KSP
    • KSP Discussion
    • Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (PlayStation 4, XBox One)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Community
    • Welcome Aboard
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • Making History Expansion
    • Making History Missions
    • Making History Discussion
    • Making History Support
  • Breaking Ground Expansion
    • Breaking Ground Discussion
    • Breaking Ground Support
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL





Found 108 results

  1. 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:
  2. 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
  3. 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!
  4. 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!
  5. 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
  6. 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.
  7. 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.
  8. 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!
  9. 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?
  10. 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:
  11. 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.
  12. In the current system, any science transmissions are multiplied by your signal strength, reducing the science return for your experiments. Before 1.2, transmitting science only incurred a proportional penalty for transmission versus recovery, but now this proportional penalty is again divided by signal strength. This seems non-intuitive - If I collect n bits for return, I should be able to return all of n of those bits, and a weaker signal just means that the transmission will have to have more redundancy to prevent data loss. It seems silly that my data is just lost to the ether because of a poor signal-to-noise ratio, when I should be able to constantly re-broadcast the data until I have 100% of it accumulated on Kerbin. The Shannon-Hartley theorem seems to verify this, but I also don't know much about information theory and this could have exactly 0 bearing on the situation that I'm discussing. I propose that instead of a proportional science penalty, there would be a proportional time penalty, incurred by requiring more bits to be transmitted as a function of signal strength. At full strength the required bits to transmit would be that listed for the experiment, and with decreasing signal strength, a logarithmic or pseudo-logarithmic function to determine how many redundant bits should be transmitted. If the Shannon-Hartley theorem is valid here, the S/N term would be a function of signal strength, and the bandwidth the advertised bandwidth of the antenna doing the transmitting. This would require some interaction between the science dialogue window and the antenna system, as the dialogue window would require knowledge of the primary antenna onboard the spacecraft. I do realize that this would greatly reduce the penalty for having poor probe connections, however if the signal strength to S/N conversion function were curved steeply enough, it could offset this by requiring an extreme amount of time and EC to transmit data. Something that could be useful here would be a manual bandwidth limiter to ensure the probe didn't deplete its batteries right away in the event of an hours or days long transmission. At this point I'm just spitballing, but let me know what you think of this idea. EDIT: whoops, wrong forum. I need to not make posts when I'm tired.
  13. Hey all, Shower thought for the day What would happen if your science return for an experiment was dictated not only by the number of times you'd run it in that biome, but also the number of times you done it on that body? E.g. first Mun surface sample gets 100% (of current setting), second gets 50%, third gets 25%. This would stack up with same-biome diminishment. Reason for thought These forums are full of people who maxed the tech tree in Kerbin's SoI, and I'm not convinced that's "fun"TM Sure, you can dial science gain down to 10%, but that ultimately pushes players to repeat, repeat, repeat the same thing. A diminishing return strategy would reward firsts and encourage players to get out of their comfort zone - which generally works out as a good thing. And yes, I know we can just be disciplined and promise ourselves that they'll only do n landings on any particular body, but ultimately most of us don't have that level of willpower. Sooner or later, I'll realise I need just 50 more science points for a thing I want, and I'll crack and send a cheap expedition to Mun rather than designing a massive Jool mission for it. Just because it's easier and I can Just an idea for discussion, if anyone's of a similar mind Edit; alternative as raised further down the thread: The first time a specific experiment is transmitted/recovered from a particular body would reward double, or even triple, science.
  14. I think this is a well-known problem throughout many versions of ksp, but (I believe) because the Mk2 cockpit is a single all-in-one nosecone, it generates a monstrous amount of re-entry heat. I have trouble not exploding the thing on relatively gentle reentry angles (40km periapsis) just returning from 450k orbits (still true in 1.2 despite pointy-object aerodynamic changes). The inline Mk2 and Mk3 cockpits have separate parts as noses (like a shielded docking port) which seems to disperse the heat better and solve the issue. Just about any re-entry is quite harrowing with the Mk2. Is this the intended (rather than simply emergent) behavior of the Mk2 cockpit? I wish there was a way to add more ablative coating at the cost of increased weight, but that is perhaps getting into modding territory. It does look pretty damn good imo though, so I'd hate to have to switch to the inline Mk2.
  15. Here's what I'm thinking: If realistic water buoyancy can be implemented, why not ground effect? It would open up a whole new avenue of designs, like ground effect vehicles. It would also make takeoff and landing in spaceplanes and aircraft easier, as the amount of lift is increased as you approach the ground. However, that could be balanced out by reducing the effectiveness of control surfaces. It should also be easy to implement as the effect kicks in at or below the length of an aircraft's wingspan; This data is easily obtained, as it is already in the engineer's report. Please feel free to give your thoughts, whether for or against this. Thanks!
  16. When assigning Action Groups, it would be very useful if we could use a Delay within the group so we could program a series of events just with 1 button press. We could get some really neat and creative things going on with just adding this one thing. I'm sure there are countless things we can come up with, but the great thing about it is it would add so much play value to the game, for such an easy thing to insert. You'd probably want to be able to assign a value to the Delay, and all the actions would need to flow top down for it to work. Just an idea.
  17. What if - Part 2 I was Just drinking my coffee on my monitor, while watching the Orion Rocket Getting ready for launch to duna, when this came up to my mind. -Gene Kerman- Suggestion 3 What if.. There Was Baby Kerbals?.. I know this might seem crazy Baby kerbals going to space... but it would be actually funny to see that i never saw any mod maker or person do that . so Squad if your intreseted this idea is for you Suggestion 4 What if There was a Astroied Belt in Outermost Kerbol system? that would be a pretty intresting place to go , if your reading this and your a modmaker , this is a idea because i dont think squad is going to do it Suggestion 5 What if there was a Space Elevator in the KSC in only Sandbox mode that you can put your spacecraft into and then go to space to test them? i Personally think this idea has the worst chances of getting into the game but thats just a dream, If your a modmaker , Well you guessed it , another idea Please Vote on the poll on what idea you think is the best
  18. Picture poor Jebediah sitting inside a MK1 capsule atop an overly complex rocket (aren`t they always?) waiting on the launchpad. He is smiling despite knowing that he is being sent to Duna on a one way mission (or at least until the Space Program decides to send another vessel to collect him) all on his own, within a space suit, within a tiny capsule and with no other entertainment than a minute window that will show nothing but cold cold space for the whole 200+ days of journey. Once within Duna`s sphere of influence Jebediah can look forward to a couple of days of achieving orbit, landing and performing a couple of experiments on the surface. After that, nothingness... nowhere to go, nothing to do, no one to speak to... alone in the planet, the omega kerbal. So, you guys get what is bugging me: we have great mods to deal with the lack of life support gameplay, great mods to give us more realistic aerodynamics and soon communications networks in 1.2 all fine and dandy... Kerbals however seem to have 0 mental health needs, they will happily be put into a capsule for months on end... You might say it is an acceptable break from reality, but I for one make sure that any mission that is going to go longer than 1 month HAS to have at least two kerbals in it and a some kind of crew cabin (usually the hitchikers storage container). It is not neccesary for the game mechanics, but it makes me feel like I am at least giving my little kerbalnauts the chance of leaving the cockpit and taking a shower, sitting down, just plain go somewhere else. Still, even that might be "less than enough" for missions that count their duration in years instead of months... what to do then? Well, send a robot instead! And I am not talking about those crude drone core`s than can pilot a ship and even land it, I´m talking about humanoid robots that can do everything (well, almost) a Kerbal can do without the mental breakdown that should come from being in an enclosed capsule with no company or entertainment for years. Hell, you can even send them to distant planets to set up surface bases, get them going, and then send the actual kerbals. Robots would not consume life support (great advantage) but would have no specialisation or leveling in career (big disadvantage), they wouldn´t be able to send crew or EVA reports, but they would be able to take surface samples and take experiment results from sensors just fine. They would be unlocked in career mode with one of the later drone techs. I would love to build a mod that offers precisely that as I think it would add an interesting role-playing edge to the game that, as of now, is lacking. I worked as a 3D designer for a few years so I offer myself to build the models (the idea is to use the current mesh, textures and animations from Kerbals and make some changes to make robots out of them, piece of cake!), I am however painfully ignorant when it comes to building mods and what it entails, I would need help (plenty of it) in that department. Any takers?
  19. Hi KSP! I wanted to say that the aerodynamics are quite advanced, very beautifully and awesomely made! but I can't support it none the less. for two reasons: 1. "Monoplanes produce more lift than for example triplanes, having less wing bodies. that is because triplanes have wings that are so close together that their aerodynamics mix (don't have enough space)" (That is what they thought me on school) So the problem here is: In Kerbal Space Program you can cheat by putting wing(s) in each other and producing more lift, for example. You see that often in large or unrealistic crafts. If this isn't the case anymore (in 1.2) I will be very happy! And I wonder if I ask something very complicated. But for me it ruined my motivation to make aircrafts in KSP. 2. There are no proceduraly generated wings, if not using mods. This limits imagination and options drastically. PS. I really love KSP! I want to thank everyone very much for making such an awesome game!! PPS. You could check the "Gabe Flags" I made ...
  20. Hi, I'm playing on Kerbal space program since 0.9 version, I was wondering about the futur of KSP, and I was wondering, why don't you port it into the game? I think it would be an amazing featur to add, to be able to literaly create your own part in game, thanks to some tools, with a new building. Starting with something like real fuels did in his mod. Be able to select the size and the shape of your fuel tanks. And it would be limited by the techTree, and the type of engine you are able to take. This way you would be able to implement more and more featurs without much work on part creation. Of course you would have much more work somewhere Else, but it will increase the amount of possibility. At the start you would be able to change tanks, or engines power, size, shape but at the end you could creat your own pod, the materials you want to use on such part etc. For the ones who don't want to spend so much time on it you can give basic parts. But you can change the way they work (adding parachute in the hull of your pod, adding detechable parts etc...). Something you could add is the type of material used for each parts etc.. At the end you would be able to creat a custom station with custom parts inside, science experiments etc. Create rockets the shape you want with any materials like Iron, wood whatever with there own caracteristic. Even Create your own cockpit for planes or capsuls. (with IVA mod it would be great. Thanks for reading
  21. Sorry if this is on a no-suggest list or has been discussed to an end already, so far I've only found really old threads that got no actual answer, so I decided to try my own luck: Alright, so I just discovered NVIDIA Surround and was trying different applications with it... And who would have thought, but KSP actually works! The only "problem" I'm facing is that the UI spans over all screens, which, for my setup at least, looks really weird (having to move the mouse across two and a half screens just to exit the VAB after part selection... yeah). Is there a way to fix it? Like, have one "main" monitor and the others just for extended FOV. Native support would be great ofc, but a mod would also be cool. I do call myself a programmer, so I guess I could try hacking something together if anyone cood tell me where to start... I have never developed a mod for KSP though, and generally don't know the games code. And I suspect for something like that you would need to know at least some things about it...
  22. I would like to have end-caps for all the sizes of fuel tank. They would not have to match the colour of the tanks. The end-caps would have an airlock with a top/bottom indicator or perhaps a built in ladder. These airlocks would not be able to hold a crewman for flight but would facilitate the logistics of the crew. By right clicking the airlock I could EVA any crew-member in the vessel. By telling a kerbal to board at the airlock, the available sections for crew would be highlighted and I could select which compartment to board. In much the same manner as transferring a crew member can be done now. The end-caps would be surface mountable so That I can place a 1.5 end-cap anywhere to use as a regular airlock. I would like this added to 1.2 so please get cracking at your earliest convenience. ( Too far?)
  23. Can you add boat parts and make that World War 2 engines used in planes like P51-Mustang or Yakolev Yak-3?
  24. Hello, I was trying to get into KSP in a less freestyle way, that is, throwing stuff into the air and see if it lands in a not fireball form. So I decided to try the tutorial and it is hard to follow, the text constantly jumps to the right side of the screen, the text itself is tiny and it is written in large blobs of text. All those together makes the tutorial really hard to go through. And I have a feeling it can be fixed easily by having the tutorial voiced, have somebody that is clearly and well spoken to voice act the text. Have the tutorial pause by itself whenever it teaches something mid flight and make sure this whole thing can be turned off as an option before starting a tutorial. Have a nice day!
  25. The Story So Far: Prior to KSP v1.0, mass ratios of tanks varied wildly. For some fuel types, there was a consistent progression across tank sizes, for others, there was not; and across fuel types, there was no consistency at all. In KSP v1.0, Squad made the decision to standardize all the fuel tanks in KSP to a mass ratio of 9:1 - meaning one ton worth of tankage holds 8 tons worth of propellant. All the fuel tanks...? No! A small holdout yet remains in the northern reaches of Gaul in the form of the xenon tanks. Their mass ratio still sits at 2.2727:1 - meaning one ton of tankage holds just 1.2727 tons of propellant. It's almost a fifty-fifty split between dry mass and xenon! Why It Matters: The rocket equation consists of two parts that are multiplied with each other. One is the effective exhaust velocity, which we know in the derivative form of specific impulse (Isp). The other is the vessel's mass ratio. Therefore, the mass ratio is at least as important as Isp for the performance of a rocket. You can argue that it is even more important, because while Isp only defines the rocket's dV, the mass ratio defines the rocket's dV in the same way as Isp does, and in addition to that, also defines the rocket's TWR. A better mass ratio gives you both more dV and shorter burns. Another consequence of the mass ratio going into the rocket equation lies in the maximum dV any given rocket stage can achieve with a specific engine (more precisely, with that engine's Isp). Because even if you add the entire observable universe's mass in terms of fuel to a rocket that somehow weighs zero kg despite having an engine and other stuff, you could still not exceed the mass ratio of the tanks you are using. Therefore there's a hard limit of dV you can never exceed with any given engine, and it depends entirely on the tank's mass ratio - and the way it curves towards that limit with increasingly diminishing returns depends on it, too. Why It Should Be Addressed: In real life, the mass ratio of a fuel tank depends on a great many factors, including the physical properties of the propellant itself. So you could argument that it is realistic that different fuels have tanks with different mass ratios. However, for xenon specifically, real life tanks are not anywhere near that low. In addition to that, as mentioned above, Squad made the conscious decision to remove all tankage mass ratio differences from the game (except xenon, which as it would appear was forgotten). And there's good reasons for doing this, reasons I've experienced myself multiple times while helping out with the mod Near Future Technologies. One pack in this suite of mods introduces new engines, which run on several different new fuels. I'm doing the balancing of those engines, and over time, I've tried various different approaches. Among them were approaches that had all the fuels at different tankage mass ratios. Although this offered increased freedom in assigning stats and part niches, it also made everything a whole lot more complicated to manage and balance properly. But that's not the main reason it was a bad idea. No, the main reason is that none of the players noticed it. None whatsoever. Not a single person who hadn't followed the dev thread discussion ever admitted to being aware of these differences. And, I mean, why would they? Fuel tanks are just fuel tanks. When you build literally any other spacecraft in KSP, you plop down the payload, you plop down a number of fuel tanks, and then you sit down and start comparing engines for thrust and Isp. Engines, not tanks. So the only thing those players noticed was: some engines just had better stats than others, no matter how you turned it. And these players then came to the mod thread and complained that their favorite engine was underpowered, or that another one was really broken, and that our balancing was super bad. All in all, mucking with tank mass ratios turned out to be unnecessary complexity that didn't add any depth, only confusion. Squad, I wager, knows this full well, for they have a forum full of active users who love to discuss engine balance while equipped with many different variants of half the data. And with the introduction of such things as the monoprop engine, and the move of the LV-N to be liquid fuel only, KSP moved rapidly towards a situation where engines could not be directly compared to each other anymore. So they made LF/Ox, LF-solo and Monoprop tanks all have the same mass ratios. Voila, engines could now be compared again! Except, you know, the often-forgotten Dawn ion engine. What The Actual Effects Are: The Dawn has so wildly different stats from all other engines, both in thrust and Isp, that comparing it to other engines is fairly straightforward on the surface: the dV you get is simply just "higher", and the thrust you get is simply just "lower". It clearly gives the Dawn its niche. However, if you sat down and compared the actual stats, you'd quickly discover that this engine doesn't perform the way you think it does. Namely, it always significantly underperforms compared to what your on-paper math says it should do. And the more fuel you add, the worse it gets. To illustrate, I've done some math on a vessel that is comprised of 10 tons of dry mass, including a Dawn engine. I've added enough fuel to hit several different propellant fraction targets (percentage of vessel mass that is fuel). At each of those targets, I determined how much more dV and TWR the vessel would get if its tank mass ratio was 9:1 instead of 2.2727:1... and then converted that into how much less "effective Isp" and "effective thrust" the Dawn gets compared to a hypothetical LF/Ox engine with the same stats. I also calculated the difference in total mass between the vessel with the LF/Ox tanks and the vessel with the xenon tanks. Spacecraft mass is important when designing your lifter, after all... and that difference is the extra mass you have to lift just because you're using xenon (in addition to being responsible for the drop in effective thrust). Base Stats 4200 s 2.00 kN n/a Propellant Fraction Effective Isp Effective Thrust Vessel Mass Difference 15% 3739 s 1.80 kN 1.38 tons 20% 3564 s 1.73 kN 2.09 tons 25% 3378 s 1.66 kN 3.04 tons 30% 3175 s 1.59 kN 4.36 tons 35% 2952 s 1.53 kN 6.29 tons 40% 2703 s 1.46 kN 9.44 tons 45% 2417 s 1.39 kN 15.45 tons 50% 2072 s 1.33 kN 31.50 tons As you can see, the Dawn effectively drops to barely half the performance a player would infer from looking at its stats alone by the time the propellant fraction hits 50%. This is not the Dawn engine's fault. It's the xenon tank's fault. What I Propose: Simply put, adjust the dry masses of the xenon tanks to fall in line with all the other fuel tanks in KSP. I've even gone ahead and calculated the numbers - you just need to put them into the configs: - PB-X50R: 0.03143 becomes 0.005 - PB-X150: 0.055 becomes 0.00875 - PB-X750: 0.4125 becomes 0.065625 Meanwhile, doing this obviously results in a massive buff to the Dawn engine. But consider the following: because of the poor xenon tanks currently in the game, the Dawn engine needs to have artificially inflated stats (in both thrust and Isp) in order to deliver the performance that it is designed to have in typical usage scenarios. As such, there should be no problem with adjusting those stats down once the tanks are no longer killing it. Since the Dawn engine is a direct nod to the NSTAR ion thrusters on NASA's Dawn spacecraft, currently in orbit of Ceres, why not take the Isp directly from that? Instead of 4200s, it would now have 3120s. Looking at the table above, that falls pretty much straight in the middle of what you effectively get right now anyway, on average... a perfect fit. The thrust could be set at 1.5 kN, a nice round number that's also reasonably near the average effective performance today. 1.6 kN would also be valid, but from my gut, I'd choose the lower value. Xenon-fueled spacecraft are already getting another stealth buff in requiring less lifting power to put them into orbit. In Closing: From my amateur viewpoint, I consider this change to be simple, straightforward and requiring only little testing - it doesn't affect many game systems, and the required changes are so few and simple, a ModuleManager script could do it. I'd love to hear everyone's thoughts and comments on it!