Search the Community

Showing results for tags 'physics'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • The Daily Kerbal
  • 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
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website


  • Developer Articles

Found 65 results

  1. Yesterday i was testing a new plane i´ve built, when i noticed something odd... So i changed the design a bit to exploit make good use of it Here it is on KerbalX: Should i even report it is a bug? This is great, like the ladder bug How this works:
  2. I understand waterskiing or hovercraft are not exactly core functionality for KSP but since I have struggled with this I'm going to list it anyway. Problem 1: Waterskiing When landing something on water, it immediately sinks in, which causes a massive drag spike. In reality, if you're going at all fast, water behaves more like a solid surface to start with: you would skip or ski on the surface until you slow down enough to sink. Consequently, things like seaplanes do not behave like in real life. If this was made more realistic, seaplanes, fast boats, and similar craft would become possible. Conversely, splashdowns might become more dangerous. Problem 2: Ground effect In real life, a plane flying close to the ground experiences a good deal of additional lift from an air cushion that forms beneath its wings. This makes aerodynamic landings easier and vessels like hovercraft or ekranoplans possible. Since KSP does not model ground effect, we can't do this. I think this would be a pretty simple change as you'd only need to adjust the amount of lift generated by distance to the surface up to 15 m or so to get close enough that it felt more or less right. This would significantly expand the range of craft we can make, as well as making planes easier to fly and things more realistic in general.
  3. Yeah, so I would have liked to post this in the Addons section because I'm looking for help from coders and/or math geeks, but since it isn't really KSP-related, I decided on this place. Mods, please do move the topic if you feel it would fit in a more specialized section. Anyway. Here goes: I'm making a little 2D arcade space game that basically puts "Lunar Lander"-like elements in a tiny solar system with orbiting planets and moons. Fuel efficiency is obviously going to be an important gameplay point, and so I want players to use gravity assists etc. For that, I need to be able to show predicted trajectories. And that's where it gets complicated. I'm using Game Maker, and the tutorials, discussions or even marketplace scripts that I found on the topic rely on Game Maker's built-in physics. And those don't help me because obviously I don't have a constant "down" direction for gravity to pull in. I've only got relatively basic skills in GML (and I know even less about other languages) and while I'm not exactly sh!t at maths, high school was a long time ago. So I'm looking for help creating (or finding somewhere in the GM marketplace) something that will allow me to graphically display a projected trajectory. Since I'm not using GM's built-in physics, so far it's all just simple vector addition (current veloctiy + sun gravity + current grav-well gravity). But I have no idea how to draw a prediction, since my gravity direction changes constantly, and I have multiple sources of gravity AND distance thresholds at which they become active, like SOI's in KSP. Somehow I think that a frame-by-frame prediction of next x and next y over thousands of frames would kill most computers running this game. So. Is there anyone out there who... a) can point me to someone who knows this kind of stuff (the person/people who made MechJeb maybe?) b) can help me find something on GM Marketplace that would do the trick c) can help me directly with coding this d) ...has done this before and could help me port it into GML? Thanks very much.
  4. KSP Version: (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: Mk2.craft?dl=0 Mk3: 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.)
  5. 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.
  6. 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!
  7. 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.
  8. Orbital velocity

    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?
  9. 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?
  10. I was wondering if KSP simulates the Magnus effect, If you don't know what it is click here.
  11. I built this probe to fly into the sun, but upon decoupling the second to last stage, this happened- 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.
  12. 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: Thanks!
  13. 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
  14. 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?
  15. About This is a KSP mod based on a piece of code written by BahamutoD for BDArmory and improved by myself. Basically it extends game physics range(1)! This will allow you to switch between vessel that are far away or even to see an orbital station from a flying plane. (1) This mod allows to extended the physics range but it will not prevent the consequences of doing it. REQUESTS AND IDEAS TO IMPROVE THE MOD ARE ENCOURAGED! Donations = Motivation Download Issues Changelog (*) You might experience some of the following effects when the range is extended > 100 km: vessel shaking, lights flickering, phantom forces, landed vessels colliding with the ground, etc.
  16. 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
  17. 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.
  18. 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
  19. 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?
  20. Vortex modeling?

    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.
  21. 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.
  22. 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 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.
  23. 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.
  24. 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?
  25. 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!