Search the Community

KSP Version: 1.3.1.1891 (Windows 7 x64), fresh install, fresh sandbox savegame. I keep this particular KSP install for such testing only. Mods / Add-Ons: All Stock Description: if there is a long enough part inside a cargohold that consists of two shorter ones, then drag is applied to the payload. (I think its because the game thinks that payload part is clipping through the cargobay. Although visually it is only clipping through its front or its back as it is longer than the cargobay.) I also think the problem is known. But I'm not sure. Also I'd like to know if it's gonna be fixed or not. The reason I'm reporting this is because there are many modded parts that are longer than the longest cargobay available. Fuel tanks for example. It also limits how one should attach their payload inside cargobays. UPD: not every part bugs. Incomplete list of parts which I've tested (yes = causes the bug): - FL-T800 Fuel Tank: yes - Modular Girder Segment XL: no - M-Beam 200 I-Beam: no - Mk1 Cockpit: yes - Orange Tank: yes - RT-10 Hammer Solid Fuel Booster: yes (omg i've ignited it inside my cargobay.. omg.. oh nevermind it didnt explode) As a lil' bonus I've also tested the situation when a small part is placed between two cargobays. It didn't bug at all (tested with 2x FL-T200 Fuel Tank). Steps to Replicate: 1) Create a plane with two connected short cargobays so they make a longer one together. 2) Put a long enough part inside - its length must be longer than one of the short cargobays. Example: two connected Mk3 Cargo Bays CRG-50 and an Orange Tank inside. 3) Attach additional parts like a Cockpit, landing gears and an engine (if the payload isnt a fuel tank - then attach a fuel tank too of course). 4) Launch the craft. 5) Make aero forces visible in parts' gui menu through the debug menu. 6) Open the payload right-click menu. 7) Accelerate and watch its drag. Result: The payload's drag isn't zero although it must be as it is fully enclosed. Fixes/Workarounds: - attach the payload differently (if there are multiple crafts or parts as a payload); - use different nodes; - use the largest cargobay available; - don't put larger parts inside Other Notes/Pictures/Log Files: Both Mk3 and Mk2 cargobays have this problem. I believe its an internal technical logic problem, not a bug. Its just how the game calculates drag. But still it is a problem. Craft files: Mk2: https://www.dropbox.com/s/kk4h6y8h4alamx0/Bugged Mk2.craft?dl=0 Mk3: https://www.dropbox.com/s/fe4zaluf436nniq/Bugged Mk3.craft?dl=0 Screenshots (the right part-menu reflects the payload on both screenshots): Thank you Squad for making one of the best games! No sarcasm involved. Bugs happen. (I believe there is no need to include logfiles. Will attach if Im wrong.)

There is a problem I have frequently found myself in that perhaps you have too. Say you are landing on a surface with low-gravity, but the surface is at a slight incline, you hit it at a weird angle, and your lander tips over. Or suppose you are in a rover on that same low-gravity environment, you get going too fast, hit an uneven part of terrain, go spinning in off the surface and land upside down. Well, you could just over-build all those things so that never happens or can right themselves if they do end up in that situation, but what if you have crew with you? Why not use them? Something I have tried to do, but found it awkward and difficult, is to get a Kerbal under an edge of something I am trying to flip right-side up and either jumping or using an EVA pack to thrust upward, but the force imposed by them is usually hampered because it cannot get a firm purchase on the object I seek to impart that force on, often deflecting off, wasting the effort. It struck me as a little unfortunate because crew ought to be able to use their bodies to perform mission-necessary actions: they already do that with flags, and surface samples, manually deploying solar panels, and fixing broken tires. Why not flipping overturned components? This does not feel like too much. Super-Kerbal levels of strength are not necessary if the gravity is slight, and often all that is needed is a good "nudge" so the reaction torque and RCS (if applicable) can get going. I was thinking, a Kerbal on EVA who is firmly grounded on a surface might be able to right-click a nearby part and perform a "Lift Up" action, which would impart a small force on that specific part in a direction normal to the surface (as determined by gravity.) This would allow clever Kerbals to figure out how to maximize the effect by selecting a part where they have good leverage from the center of mass. If we want to go wild, maybe make this a function of Engineers who have a small jack in their toolbox (they already fix broken tires so we can deduce they have that on hand.) Based on what I know of the engine, this should not be too complicated, but let me know if I am off-base here.

Hello! I’ve been playing KSP for a while now and have become quite confident in my abilities. Although, I’m still having trouble with gravity assists. Is there an equation of some sort that I can use to calculate my speed after the slingshot/brake? Ex. Before assist craft is going x m/s, after the assist the craft is going y m/s I also would like to know if there is an equation I can use that will tell me the orbital velocity at a certain altitude above a body. Ex. At h meters with d degrees of inclination, the craft must be going x m/s to maintain a circular orbit If you have any other useful equations that would be nice, thanks!

I don't know if this has been asked, but here goes. Is there a reason that the whole system is grossly underscaled? I am a curious physicist.

There's a line in the original "Star Wars" where a Death Star flunky reports, "Orbiting the planet at maximum velocity." For a long time, I decided this meant that they were orbiting Yavin at faster-than-orbital velocity, using constant expenditure of energy to avoid moving into a higher orbit. This sounds sensible (in a technobabble sort of way). But is this even possible, even with continuous input of energy? Wouldn't they simply be boosting their apoYavin of the other side of the planet or otherwise changing their trajectory, without increasing their orbital velocity, no matter what? Yeah, I know, trying to apply real physics to "Star Wars" is a pretty useless exercise. But is there in fact *any* possible way to increase orbital velocity while keeping orbital altitude constant?

Hi, everyone! I have a nasty problem to solve. Half by physics, half by math. And hope UE4 can help me with that too. I have an object in the space. We know the center of its mass (C). There also a lot of engines/thrusters. We know where are they placed (P1...Pn) and in which direction they turned (D1...Dn). Each engine has maximum thrust (0...Ti). All those values we know. Tasks are: 1) We should be able to move (strafe) the object in the space by custom normalized vector (V) with custom thrust power (0 <= T <= 1). 2) We should be able to turn the object on the place centered on (C) with custom thrust power (0 <= T <= 1). 3) Of course, there are situations, where it's impossible. If so -> T = 0. Any thoughts or formulas?

I was wondering if KSP simulates the Magnus effect, If you don't know what it is click here.

I built this probe to fly into the sun, but upon decoupling the second to last stage, this happened-https://youtu.be/DEPa5NtZqgU Please disregard my video recording skills, I recorded it with my phone. Anyway, if anyone has advice or knows why this is happening, please comment.

Hi. I have a problem. Whenever I make a maneuver node, its delta-v requirements slowly change. This makes it impossible to accurately use the nodes. Here are some screenshots to show what is happening. There is no rcs/sas/engines running. The node does not change during timewarp, so it must be a physics issue. The predicted apopsis after the maneuver does not change. How can I stop this from happening? (if the embedded album does not work, here is a link: http://imgur.com/a/pHNpx). Thanks!

To start off, I would like to say that there are two things that mods cannot do effectively for this game. Multiplayer, and better physics. Other than that, mods all the way. Now I would love multiplayer, but it will never happen as some players resist it. (Resistance is futile). Now the second thing that mods can't accomplish, physics, is not resisted by any player. So here are my suggestions: - Allow kerbals to walk on moving surfaces. This will definitely make the people at mission reports/KSP storytelling extremely happy, and it will make any player happy. It adds so much functionality when kerbals can actually do things on the decks of ships and the wings of planes. This feature could be done by making kerbals "stick" to things they walk on more, and by making kerbals have a realistic weight and realistic aero so they don't decelerate at 5g when they jump out of a cockpit. - do the same for planes so planes could taxi on flying airstrips - do the same for rovers, for the same reasons - this isn't physics, but weather should be added, mostly for wind purposes -waves

I've been designing space stations as of late. One thing I try to do with them is give them proper self-illumination so I can actually see them at night. (I have plenty of mods and one of them make night-time in space pretty dark...) My first station is over 200 parts and counting (still missing a few nodes.) I think about 20% of the part count is just lights and RCS ports. I just realized the lights and RCS are physics-less. Does that affect the physics processing KSP does since the mass and drag are just added to the parent part? I'd like to think it makes it a little easier, but this is KSP: I can't assume the best case scenario regarding how it does things. I'm asking because the surface lights from B9 aren't physics-less. I like their looks, so I tend to spam them a bit on my designs (spaceplanes especially.) I'm thinking of using them on my next station, a small-medium fuel depot. This one is a bit more practical at about 75 parts for better loading and processing. But I realize about 18 parts are already just lights. So does PhysicsSignificance help with physics processing & frame-rates to any degree or is it purely based on part count? (The >200-part station is now chugging along at about half real-time now.) It if leans towards part count, I'll probably redesign the fuel depot to use Stack Inline Lights for lighting. (And/or saying screw it and launch it as one vessel rather than building it modularly; those docking ports add up...) EDIT: Then could you clarify the MET color indications? Could a yellow indicator be cause by an overworked GPU? For the record, I'm on an i7-4771 @ 3.5GHz w/ 16GB RAM & an AMD HD7990. My game runs slowly (less than real-time) but is playable (not choppy at all) with the >200-part station. I just took at look at the station with the Debug Menu's Performance graph. Says I'm running at 21FPS, but movement and camera control is quite smooth and even (other than the stutter from GCing every few minutes.) I'm guessing the 21FPS is more physics frames processed than visual frames rendered/displayed? 21 Physics FPS seems to jive with the approximately half real-time rate I was guessing at. Oh, this was with nearly max graphics settings other than Texture Quality (Half) and ground scatters (Off) and with forced DX11 in this case (trying to save on RAM; had Out of Memory crashes as of late from editing the station). I think my Physics Delta in the settings is 0.04... EDIT2: Huh... I just my Physics Delta. I was at 0.05 for 21FPS. I tried it out with extreme settings and got: 33.2FPS @ 0.03 (consistent and smooth) ~10FPS @ 0.12 (choppy & stutters between 8-11FPS) I never did quite understand how Physics Delta worked. I did notice that the frame rates I wound up at equal 1/Physics Delta though. Is that setting effectively a "minimum frame rate" setting or something?

About This is a KSP mod based on a initial piece of code written by BahamutoD for BDArmory and improved by myself and test with the help on the entire BDAc team. Basically it extends game physics range and the terrain loading distance. This will allow you to switch between vessel that are far away or even to see an orbital station from a flying plane. REQUESTS AND IDEAS TO IMPROVE THE MOD ARE ENCOURAGED! Donations = Motivation Download https://github.com/jrodrigv/PhysicsRangeExtender/releases Issues https://github.com/jrodrigv/PhysicsRangeExtender/issues Changelog (*) You might experience some of the following effects when the range is extended > 100 km: vessel shaking, lights flickering, phantom forces, etc.

I am playing KSP with a bunch of mods. the game was running fine and then i had a game crash. i had to re validate, update my drivers and restart my computer to be able to get KSP to load again. when it did finally load and i tried to launch a plane from my hangar but i was unable to lift off as my speed couldn't go above 13m/s. i know it was working before because i had no problem gaining speed and flying with the exact same plane i was using. i thought it could just be the liquid engines but when i loaded up my rocket fueled plane it had the same effect. i could not gain speed its as if the physics had been changed by a mod or something was affecting the atmosphere. i tried deleting my physics file and re validating but that didn't fix it either. i opened the console config with shift F12 or w/e it is and looked up the default values online and the numbers were the same? any ideas on what could be causing these physic issues? or mods that might tamper with physics? i dont have the real physics mod installed thanks

So I've been trying out the stock ships recently, because I always build my own and I wanted to see if they were any good, and I noticed that several didn't work, not taking off or only just taking off or falling over for no apparent reason. I was wondering if this happened to everyone or if it's just my physics being weird as usual, because it seems to not work properly a lot, with other people seemingly being able to lift much greater weights with much less thrust and fuel. I don't know if there's any solution for this, or if it's something that happens to everyone, and it's just me not being able to play the game. If anyone could give any advice or help in any way, I'd be very grateful.

Hi, So I was playing KSP and I noticed that cylindrical objects - like jettisoned stages, fuel tanks, etc - seemed to fall with an attitude perpendicular to the flight path, Basically they fly/fall sideways. The weird bit is that this even happens with parts with nose cones so that it has the least drag with the nose into the wind as it were. I mean here even the centre of mass is shifted slightly forwards. It got me thinking, though I understand a fair amount of physics I can't figure out why it doesn't fly aerodynamically? -And once sideways it's incredibly hard to orient any other way (as you'd expect). So am I being an idiot here and missing something I really should've learnt by A-level physics, or is there some underlying phenomenon at work here? Cheers, Jack

I'd like kOS to calculate the velocity at periapsis for me with the apoapsis height, periapsis height and apoapsis velocity as variables. However, if one is using the specific orbital energy v2/2 - µ/r = constant, you must know the standard gravitational parameter. I could hardcode the values into my script for every celestial body, but I want it to be as general as possible (if you decide to alter the default masses with mods etc). How do I get rid of the dependency of µ in my formula?

Okay, this is a rather technical question that is probably best answered by a Squad programmer, but if anyone else knows feel free to chime in. I have been thinking a lot about aerodynamics lately, and in particular the vortices that form in the wake of atmospheric compression. Obviously these are essential for lift, but controlling them is essential for managing drag. I wanted to know how closely the Kerbal Space Program aerodynamic physics engine models these vorticies. For example, are there advantages to putting small strakes to break up airflow before it builds to a larger vortex behind the craft? Will long swept wings generate smaller vorticies than short square ones? Is there any lift advantage for adding bulkier perturbations in the topography of the airframe on top of it compared to on the bottom? I know the answers to these as concerns of real-engineering, but I want to know how closely they apply in KSP, since they would impact my design choices.

Hey guys, understand this is a bit of an ask but I've come to the end of my tether with trying to calculate these. If any of you are nerdy enough to give these a go I'd greatly appreciate it. http://prntscr.com/d52ktz?

While driving/flying propeller based crafts for more than 10 minutes all parts of the craft get increasingly jittery (and eventually break/crash). Tested it without mods as well, in KSP 1.2.0.1586. I'm guessing the problem is that the amount of rotation builds up and the accuracy of the whole physics engine decreases. Is it viable to normalize the rotation values once in a while to prevent this or should I stick to quicksaving & loading (which makes everything stable again)? Or maybe the cause is something different. Either way, stock propeller enthusiasts would appreciate the help.

Sorry, this doesn't have anything to do with space, or at least very little - but at least it's got the physics part, right? When you're calculating the resonant frequency of a tube (open-ended in my case), you have to add an end correction as the theoretical resonance is lower than it is in practice. I've found a few sources citing approximately 1.2r, but some conflicting, and some saying that it has not been theoretically proven at all. Nowhere have I found an explanation why.

The last time I put up a recipes of disaster I asked for any "recipes" that would break the game mechanics. But that was for KSP 1.1.3, now what about ksp 1.2? I played around with the pre-release but didn't find anything unusual, but I know that other people have been doing a through search for the recipes of disaster. If you do, would you mind to share them to the forums?

I'm planning my first asteroid capture mission, and (without having played the tutorial mission) I got curious to learn how much fuel and thrust I would need to put on the capture vessel in order to bring the asteroid into a useful orbit around Kerbin. I spent a lot of time trying to learn something about it, and thought I would share. I would really love to hear your thoughts and feedback! The lovely little space rock I have in mind to make my own is one SDD-569, a class A asteroid. SDD-569 is approaching Kerbin for a leisurely flyby at a periapsis of ~2,079 km, well inside the orbit of the Mun. This puts SDD-569 into a sharply looping orbit around the planet, before it flies back out into parts unknown. I'd like to drag the asteroid into a circular orbit, and then bring it down to about 500 km for future research and exploitation. Can we calculate how fast is SDD-569 going with respect to Kerbin, based on what we already know? Since energy is always conserved, the total kinetic energy for a given object (from orbital speed) plus its potential energy (from gravity) never changes. The relationship of kinetic energy to velocity is a consequence of Newton's third law: In other words, for a constant mass, v2 is a measure of kinetic energy. The vis-viva equation describes the conservation of energy for a small body orbiting a much larger one: GM, also known sometimes as μ, as is Kerbin's gravitational parameter, which the KSP wiki reports is 3.5316 x 1012 m3/s2. This parameter is the product of the gravitational constant of the universe with Kerbin's mass, which is effectively constant. a is the semi-major axis of the orbit as measured from the center of the celestial body. Kerbin's radius is 600km, so we add that to the altitude of SDD-569 at periapsis to give a = 2,679km. r is the distance between the two objects at a given time. An object moving fast enough to escape Kerbin's gravity is in an orbit with a semi-major axis that is effectively infinite. At periapsis, this simplifies the vis-viva equation to describe the kinetic energy that an object must have in order to overcome Kerbin's gravity from a given distance r: In other words, escape speed from Kerbin orbit at the moment of periapsis (r = 2,679km) is ve = 1,623 m/s. But since SDD-569 is tracing a hyperbolic (i.e. open) trajectory through Kerbin's SoI, it must be traveling faster than this, or else it would be captured. How much faster? Consider the other extreme case of the vis-viva relation, where the asteroid has shot past Kerbin and the distance r between them trends towards an infinite apoapsis. Setting r =∞ in the vis-viva equation tells us how fast the object is still going at that point, which is called its hyperbolic excess velocity: (where μ = GM) So for the flyby of SDD-569, the hyperbolic excess velocity is v∞ = 1,148 m/s. This characteristic energy is over and above the energy needed to escape Kerbin's SoI from that distance, so the total energy possessed by SDD-569 relative to Kerbin at periapsis is: This gives a total velocity for SDD-569 relative to Kerbin at periapsis of 1,988 m/s! By how much do we need to reduce this so that it drops into a nice 2Mm circular orbit from periapsis? In a circular orbit, the distance between the two objects r and the orbital radius a are always the same. Thus the orbital velocity is: Not coincidentally, this is the same as its hyperbolic excess velocity, because r = a. So at r = 2,679km, an object in a circular orbit around Kerbin travels at 1,148 m/s. So, to get SDD-569 into a circular orbit from its flyby periapsis, we need to bleed off Δv = 840 m/s. To then bring SDD-569 down to a more convenient altitude of 500km, we would do a Hohmann transfer, which can be calculated with the standard formula, and works out to another 614m/s Δv to descend to a 500km circular orbit, for a total of 1,454 m/s. What’s more, the spacecraft sent to capture SDD-569 needs to match orbits with the asteroid in order rendezvous. That means that if the spacecraft starts from, say, 500km above Kerbin, it will need to expend that much to get to the asteroid in the first place. So, starting from a 500km orbit around Kerbin, the total Δv budget for this mission is 2,909 m/s. Next up: Asteroid capture planning, part 2: How much fuel do we need to bring? Mission to SDD-569: Where the rubber meets the regolith! Did I get this right? If you have feedback or ideas, I would love to hear them!

I was wondering, anybody know a way to break the physics of the game? Just write a detailed discription of your procedure in the comments below. Thanks everybody for looking in to this.

Hi guys! I love KSP (as I'm sure most people here do), I have over 1040 hours on it, yet I can't build to my full potential because of the render physics distance!! I have built a Low Earth Orbit Station (80km) with the 'USAF Airborne Laser' from the BD Armory Mod and I REALLY want to strike the KSC with the Lazers :D. Unfortunately, the KSP physics render range is not that far. Would ANYONE know of a mod that can help me with this? I'm not too good with coding and stuff so I can't really edit the game's....laws of physics. Any help would be much appreciated!! Cheers James.

So one of my scientists was doing a tour of the base in a small rover, collecting all those sweet, sweet science points from every interesting feature*. He parked up against the VAB tanks, climbed out of his mobile lab and-- >warp< >stretch< >stretch< >poof< Some bizarre physics error caused him to flick into the air, stretch wildly in one direction, then another, then explode in a cloud of dust. I'm not complaining about the physics bork; I'm sure someone is already working on that. The question is: my crewman is now listed as "missing"**. He doesn't appear on the list in the Tracking Station, and he definitely exploded into a cloud of dust so... my questions would be: Is he actually "missing", as opposed to "dead"? Is he recoverable? How? Thanks in advance... * - But not, of course, the pond beside Admin. Or the flag pole, tanks, etc. by the launch pad. Their omission is... odd. ** - Not "dead", like his predecessor who happened to be on the ladder of a craft when it was recovered. Seriously, what's the deal with that?