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
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website
  • KSP Pre-release
    • 1.2.9 Pre-release Branch
    • 1.2.9 Pre-release Modding Discussions
    • 1.2.9 Pre-release Bug Tracker


  • Developer Articles

Found 44 results

  1. 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 (*) ! This will allow you to switch between vessel that are far away or even to see an orbital station from a flying plane. Download Issues (*) This mod allows to extended the physics range but it will not prevent the consequences of doing it. You might experience some of the following effects: phantom forces, light glitches, vessel shaking, landed vessels colliding with the ground, vessel teleport, vessel de-orbiting
  2. 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?
  3. 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.
  4. 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!
  5. I was wondering if KSP simulates the Magnus effect, If you don't know what it is click here.
  6. 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
  7. 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?
  8. 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
  9. 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?
  10. The first ripples of an arising dispute between Experimental and Integrated Integrals are shaking kerbins science community. Integrated Integrals is insisting that time is continuous and can be divided into infinitely small timespans. While Experimental is claiming to have prove that time progresses in small packages. They call it Klanck time. It was painfully clear that this conflict had to be resolved as fast as possible. Your mission is to design and run an Experiment that proves which side is right and wrong. You may use all the mods and cheat menus you like, as long as no physics is influenced. Submissions will be “published” if the concept is new, or if the experiment shows a more significant difference between both models of time. Please don’t give the answer without giving the prove!
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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?
  16. 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!
  17. 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.
  18. 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?
  19. So, I think I'm the first to suggest a feature like this but I think that metal fatigue should be a feature in the game as this will add another layer of complexity to those who think that surving the heat and aero forces isn't enough also this would make the game less about placing struts everywhere. "How would it work?" I hear you cry, well. Let's say you have a reliable SSTO, it's served you well building your new space station, and getting you to eeloo. But one day you forget to do a maintenace check or you don't have the parts to repair let's say the pylon holding your engines to the wings and when reentrering they tair right off and you need to launch a new one. R.I.P SSTO 2Eeloo Mk3. I say that this should be an option as for newer players it might be overwheming. I'd love to see your input on this!
  20. So, anyone care to explain the natural phenomena that results in this? It kind of moved as I did, so felt like it was a natural occurrence rather than a graphical glitch, but I'm at a bit of loss to explain it exactly.
  21. So here I am taking a new ship for a spin. I try a targeted launch with MechJeb, it takes me within 2.7 km of an old 1.1.2 station that hasn't been given me crap yet; map says closest approach at 1.4 km. I timewarp to the sunlit side, and halfway through to the closest approach, I spot the station at 870 m. I dump the rest of the launcher, and fire up the Rendezvous Autopilot. The approach burn is executed flawlessly, but the final relative velocity kill burn doesn't happen; I try again, same thing. As I find out after turning the autopilot off, the controls, including throttle, RCS and orientation, freeze up within about 300 m of the station, and then upon reaching a certain distance. I took a look at the debug console, and there's a ton of errors. Possibly related to Log:!AmlSZuL0ax7C0BW8DlfPVp5D2WuB Mod list courtesy of AVC:
  22. Hello everyone, I am trying to find out when and how often mars-->jupiter-->saturn windows happen. However, I seem to be unable to find a site allowing me to see when mars--jupiter or jupiter-->saturn windows occur. I searched, but only got kerbol system calculators. I'm gonna use it outside KSP, so 'use KAC' is a really annoying answer which I keep finding. Does anyone know a site where I could find them? Edit: also nice would be the time between to windows or how to calculate that Edit2: Thanks to wikipedia, a friend of mine and excel, I found everything I needed! I can conclude that a window for a transfer mars-->jupiter-->saturn will occur every 102,... years. My physics teacher will be proud, and that guy who did an orbital mechanics project of 12 weeks finding the deltaV for a normal mars--> saturn transfer will envy me! Thanks in advance!
  23. I was watching MythBusters the other day and came across... The original video - Basically (if these links don't work) the bees can't lift the laptop because of a few reasons but a major one being Newtons 3rd law. If the bee is pushing air down it can fly up, but if the air is hitting a large surface it pushes the surface down, and if the surface is attached to what ever is trying to fly up, it won't fly. I asked myself, is KSP's physics realistic and good enough to prove this law, I set up a rig as the following (sorry for no images) 1. Simple probe core 2. Fuel tank 3. Rocket engine strong enough to lift the whole thing 4. 2 long metal girders which hold a large flat surface made up of structural sheets of metal I ensured that the metal sheets were far enough from the engine to be able to see the flame, I proceeded to offset the metal sheets to ensure there were no gaps. I went to launch it and to my surprise it did not generate thrust, I tested numerously to see if it was a glitch in the launch pad, I remade the rig with the metal sheets separated a little. This caused the metal sheets to wobble (closing and opening its gap) each time it opened the thrust fluctuated from 0 to almost normal engine thrust. After seeing the results I flipped the girders upwards (lots of air resistance) yet it was able to lift off (this entire experiment was also done with hacked gravity which made no effect on the 0 thrust). I am really proud of Squad for having these very realistic physics in the game which I can imagine to be a pain (Results from newest release 1.1.2ish I think) Serious JOB WELL DONE! (I don't think physics were this good in the past KSP versions though)
  24. Hi, I found two bugs so far in KSP 1.1.1 unmodded (both 32 and 64 bits clients): 1) When I have a ship sitting on a RE-I5 skipper on the launch pad (for example a cockpit, two X200-32 and a RE-I5) with engine and SAS off, it starts wobbling more and more until it crash on the side. 2) Sometimes, in the upper atmosphere my SAS will go crazy (at around 40 000 m, 1000 m/s). It is difficult to reproduce, I will update my post if I find the cause. Edit: I could not isolate #2. I'm not sure if it is a bug. When a rocket can bend just enough, the SAS will overuse the engine's gimbals. Thanks, Felix Nicol
  25. I have had KSP for years but never bothered to make a forums account till now. The reason being is due to a slight problem. My rockets go way too fast. For instance, a command module with a flea booster gets to 10,000 meters on half throttle. This makes the game virtually unplayable, because bigger rockets get shot down by aerodynamics. This problem never occurred on any of my previous computers. Pls send help specs: windows 10 home edition quad core Intel i5 nvidia 960m