Search the Community

Abstract I hereby propose a system to avoid players breaking physics by traveling faster than the speed of light using futuristic drives. Introducing futuristic engines in KSP is needed to deal with the insane distances between stars in order to avoid mega time warps that would fast forward time by hundreds of years. From this arises a problem. Namely, people abusing said engines to break known physics to travel faster than the speed of light - even if using cheats. As an educational game this should be prevented to not spread misinformation about the cosmos. A simple yet realistic (relativistic haha) system to deal with that is time dilation! A space ship approaching the speed of light experiences time more slowly. Down to a full stop at the theoretical limit of the speed of light. At that point chemistry stops working (no time -> no chemical reactions etc.) and a space ship could not accelerate faster. You'd be trapped actually, hence only a theoretical limit. You can't reach it. Since the player is not part of the ship just an observer from a different dimension, time dilation would only affect the ship. Not the ingame clock. How this could be implemented: Reaching a threshold of lets say 30% of the speed of light every engine would start to lose thrust in tangential-exponential fashion. Optionally also reaction wheels and even Kerbals themselves for the player to notice that something strange is going on and he is not just running into a bug. This could be solved with a local time-warp factor <1 that only affects the craft and everything in physics range. If you'd EVA a Kerbal at 99% the speed of light he would also move 7 times more slowly. The ship would rotate 7 times more slowly and produce 7 times less thrust. Or 0.14x thrust: t = t0 / sqrt(1 - (0.99c)^2/c^2) t = t0 / sqrt(1 - 0.99^2) t = t0 / 0.1414 The bottom figure shows the relation between the time of the player and the time of the Kerbal as our velocity is approaching the speed of light c. The closer to the speed of light the more time it takes for the Kerbal to do anything the player asks it to. Up to about 0.3 or 30% of the speed of light the graph can be simplified as linear. This means time passed for the player and time passed for the Kerbal are equal. Hence no calculation is needed for optimization. f(x) = x/sqrt(1-x^2) Conclusion Adding Time Dilation into KSP is necessary to deal with problems that arise from the educational nature of the game and from players being players trying to break physics. Those who dare would be surprised and left in awe as to how much attention to detail the developers put. There are simply no cons besides a few minutes of development time. Thank you! Sources: Calculation by ChatGPT Graph by GeoGebra Calculator PhD. in Kerbal Astrophysics and Goo Dynamics.

KSP Version: 0.1.1.0 21573 OS: Windows 10 21H2 CPU: AMD Ryzen 5 3600 GPU: Nvidia GeForce GTX1660 Ti Expected Behaviour: Orbit around airless celestial body should remain unchanged when no force is applied. Observed Behaviour: When craft is below a specific altitude and time warp is set to 1x, the periapsis will steadily decrease while the apoapsis steadily increases. Changing time warp to any value other than 1x arrests the behaviour. Behaviour reappears when time warp is returned to 1x. At the Mun the altitude threshold is about 23 km. At Minmus the altitude threshold is about 27 km. Steps to Replicate: Put a craft in Mun orbit with the periapsis below 23 km. When (sea level) altitude drops below 23 km the orbit begins to change. This behaviour stops when the altitude of the craft rises above 23 km. Fixes/Workarounds: Keep Mun orbit above 23 km (Minmus above 27 km) or use time warp values other than 1x. Mods: None. Tested at the Mun and Minmus. This bug was present in 0.1.0.0 as well.

Hallo, ich habe die aktuelle Version 1.12.5.3190 über Steam und den ReaSolarSystem-Mod. ModuleManager, RealismOverhaul, Real Fuel etc. sind auch an Board. mein Problem ist dass ich nicht mehr genug Delta V habe um in den Orbit zu kommen. Ich hab lange gegooglet und anscheinend muss ich die TWR in der physics.cfg für RSS anpassen. ich kenne mich mit sowas leider gar nicht aus und hab keine ahnung wie und wo ich das machen kann. Nach Mods hab ich auch schon geguckt. SMURFF soll helfen aber ist nicht mit 1.12.5 kompatibel. Ich hoffe mir kann hier jemand helfen. Sonst muss RSS wieder weg. Auf Kerbin geht alles. Vielen Dank im Voraus! Google translation provided by moderator: Hello, I have the current version 1.12.5.3190 via Steam and the ReaSolarSystem mod. ModuleManager, RealismOverhaul, Real Fuel etc. are also on board. my problem is that i don't have enough delta v left to get into orbit. I googled for a long time and apparently I have to adjust the TWR in the physics.cfg for RSS. Unfortunately, I don't know myself with something like that and have no idea how and where I can do it. I've been looking for mods too. SMURFF is supposed to help but is not compatible with 1.12.5. I hope someone here is able to help me. Otherwise RSS has to go again. Everything goes on Kerbin. Thanks in advance!

So heres the thing, basically every inline mounted auxiliary part such as decouplers, batterys, reaction wheels and cargo bays have bugged drag calculations(including those rounded rear hatches but i didnt feel like making a custom plane just to add it to my testing). Any 1 of these parts will effectively double your drag. These bugs are not limited to only the parts ive tested, as far as i can tell, literally every size and shape of said parts is affected. Ive run a couple of tests as you can see below. Every plane configuration is exactly the same other then parts that are in question added to the plane (original plane parts are white and test parts are orange). First test with base line results: Nr1. Base line: ~360m/s with drag being ~55Kn. Base line v.max ~1000m/s with drag being ~110Kn. Nr2. Same plane configuration, but with added reaction wheel. Plane is unable to accelerate past 350m/s with its drag being ~160Kn. Nr3. Same plane configuration, but with added 1 inline battery. Plane is unable to accelerate past ~340m/s with its drag being ~160Kn. Nr4.Same plane configuration, but with added inline decoupler. Plane is unable to accelerate past ~330m/s with its drag being ~160Kn. Nr5.Same plane configuration, but with added inline cargo bay. Plane is unable to accelerate past ~355m/s with its drag being ~160Kn. Nr6. Ive sized up the plane to see if the amount of drag scales with the size of the craft, and it looks like it basically does: Nr6.1 Base line ~750m/s, drag is ~600Kn. Nr6.2 Base line v.max = ~1100m/s, drag is ~1100Kn. Nr6.3 Same plane with inline decoupler. Plane speed is ~750m/s with drag being ~1050Kn. Plane is unable to accelerate further. All of these drag errors are effectively making it impossible to make xeon ssto's, put any sort of cargo capacity on planes or just have auxilary power or reaction wheels, not to mention the numerous implications it has on rockets.... tho i guess there not affected as much, it just dumsters there efficiency, as every vertical stage is going to effectively double your rockets drag. Hopefully this gets noticed and is fixed relatively soon. :)

KSP version 0.1.1.0.21572 Win 11 22H2 Processor 12th Gen Intel(R) Core(TM) i7-12700KF 3.61 GHz Installed RAM 32.0 GB (31.9 GB usable) NVIDIA RTX 3080 Ti filed.teeth: Even when set "prograde out" the shroud slides directly through the rear craft the forward section is separating from. Shot 1 is prior to stage separation. Shot 2 shows shroud sliding over nose of rear stage. Shot 3 shows shroud sliding out behind rear of ship. Not a game breaker, just something to look at after the important stuff is done...

Mismatch between "Vehicle Actions" control panel and Parts Manager in controlling items KSP version 0.1.1.0.21572 Win 11 22H2 Processor 12th Gen Intel(R) Core(TM) i7-12700KF 3.61 GHz Installed RAM 32.0 GB (31.9 GB usable) NVIDIA RTX 3080 Ti [11:03 PM] OP filed.teeth: Craft outside of comm range (landed on Duna) with no antenna. 1st screen shot shows that with no crew inside, control panel will not function- this is expected and proper action. 2nd shows that Parts Manager CAN control accessories, in this case retracting solar panels. Might be deliberate, equivalent to the old F12 over-ride, but letting devs know in case they are supposed to match.

Joint Simulation and a better solution than Autostrut. Disclaimer: I am not a physicist. The current system used to simulate the connections between parts on a vehicle is incredibly rudimentry. Tall rockets have a tendency to 'flop' if additional struts are not placed around every joint connection. Some have found that autostrut can reduce the problem, others have discovered that editing config files to increase the forces used on the joints can reduce the floppyness. Neither of these solutions are ideal because they are reactionary 'duct tape' solutions to the problem, rather than a revaluation of the core problem. The Problem: The Flop The inline joints binding parts together are not capable of accurately resisting the forces acting on the parts. This is because the joints in question are points. They exist at the node connection between the two parts and apply forces to keep the parts in a line. This is insufficient, as the actual connection between the two parts is not a point, but rather a disk. Forces should be distributed across the whole surface area. This is why adding struts around the edges of said disk solves the flop. Additional physics joints are able to better simulate the interactions between two cylinders. Adding many physics joints about the edges of the part's connection would work, but a better solution would be to design a physics joint that does not have these problems in the first place. Unity's built in physics types were not designed with beam interactions in mind. They are meant for ragdolls, which are typically lightweight and floppy. My Proposed Solution: Disk Joints A simple solution would be to create a joint that has a radius, a disk. When determining the forces needed to pull the two parts back into alignment, we can take into account the radius of the disk, as well as three defined constants describing the disk's resistance to force on each axis. The Torsional Force (blue spinner in the diagram) is the disk's resistance to being twisted. This is not much of a problem in Kerbal Space Program, so I will skip talking about it. The bending force takes two flavors. As the parts in KSP are radialy symetrical, this will simplify the process dramatically. A cylinder will resist being bent because of compression (red arrows in the diagram), and because of rotational resistance ( green spinner in the diagram. I could not find the name of this force online). The disk joint's resistance to being bent will take these factors into account when calculating the amount of force needed to right the connected parts. Larger parts will have a larger radius, which will make them more stable. Structural parts will have larger resistance constants, which will make them more stable. If you really want to take simulating vehicles to the next level, show wikipedia.org/wiki/Euler–Bernoulli_beam_theory to someone who understands physics.

I was in orbit around Eeloo. I undocked my lander to see it going about 5 m/s in a random direction away from the transfer stage without changing its orientation. I went to EVA bob from the transfer stage and he instantly teleported away from the craft in an orbit completely different from that of the transfer stage except for eccentricity. Intended result: Bob does not teleport hundreds of kilometers from the transfer stage when he EVAs Hardware spec: RTX 3060ti

Here, I bumped into a building and a part attached, most probably its collider gets Motor.SetTorque at the collision (which is a very wrong way to do physics of detached objects in Unity) - so the detached object gets infinite motion (of bumping into surface collider and then rolling in the direction of Torque vector) indefinitely (no fading of motion on friction at all, as Unity physics engine would do to to a Torqueless object eventually): keeps on going: and it even goes around obstacles like buildings maintaining its Torque vector: Rollin, rollin, rollin (c)

note: collider problems mentioned in this post may be the problems of wheel colliders and\or at the same time problems of objects' coliders around KSC 1. those are supposed to climb over obstacles on distant planets but they cannot overjump a tiny rail? (the response force of hitting a rail even slowly is very high - are you using Motor.SetTorque on collision??!) 2. for Kerbals wheel colliders do not exist you can run, jump and do hoops through this wheel and also you fall through it

Hey there, I think I've seen similar bug report somewhere here, but just don't have time right now to go thru 37 pages of bug reports, so here goes: build a rocket (or take an example one from "stock craft") - launch from launchpad and several seconds later press "EVA" on pilot' animation - the entire rocket gets "broken" and exactly at staging points (decouplers) Repeated several times for several vessel designs, seems like hardcoded physics bump there

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.

Hi, after doing a Mun mission and then loading a save (landed on Mun) the following happened: My lander started falling through the Mun's surface. When I've tried to fly it back up it got destroyed at between -1 to 0 m height. - Lander falling through the Mun surface after loading a save When I loaded the save again, in addition to falling through the surface strange additional parts appeared around the craft. - Lander sinking in Mun surface with strange additional pieces KSP Version: 0.1.0.0.20892 OS: Windows 10 Home PC specs: Expected behavior: Lander does not sink into the surface after loading a save. It shouldn't have any additional strange parts. Observed behavior: Lander starts sinking into the surface of Mun after loading a save. When done second time, strange parts started appearing in addition. Steps to replicate: Launch game and build a Mun lander Fly it to the Mun and land Save game and quit Launch game and load save Workaround: Fly slowly up before the whole crafts sinks under surface. Once it's clear of the ground and at ~200m height do a quicksave and then load that quicksave. Mods: SpaceWarp, flags Other notes: -

I've seen a lot of people complain about wobbly rockets, and parts from videos seem to be a lot more wobbly and fall off far easier then in KSP1, when personally I feel like ksp2 should have improved on the whole "wobbly rockets" thing - when you just want to play the game, it gets annoying to have your rocket just flop. Ignoring autostrut, which I'm aware isn't in and fixes that problem, I do think that by default rockets should be far less wobbly. I'm also aware it's a changeable value in the game files, but it should, again, be far higher on default, ideally having less wobble then ksp1. Another input I have is that if autostrut is included, it should really be something that isn't embedded in some option somewhere (I only found out about it by the very end of me playing ksp1), and instead some option in the VAB. Alongside this, it could even be worthwhile to have it be turned on by default, and it being able to be toggled off if you want for whatever reason a floppier rocket.

TLDR: The behaviour of the J-404 "Panther" is wrong. This post details why I believe this is the case, and proposes solutions that could be readily implemented based on a few physical principles. 1) The adjustable nozzle behaviour when afterburner is on is incorrect, it should increase in area, not sit at minimum cross-section 2) The flames coming out of the engine when the afterburner is off make little-to-no sense. Let me preface this by saying that I have an experience on two different fronts. I have been playing KSP1 for around ten years now, and I have graduated with a degree in Aerospace Engineering, currently working on my MSc. in Aerospace power & propulsion at an unspecified Dutch university. I will not go into the absolute nuance of the problem and will leave a lot of study to the reader, as I don't want to overcomplicate KSP2 with little details that won't impact the gameplay or immersion. As I loved the first game, I want to make a post each week about a different topic on how we can make the jet engines and rocket engines in KSP2 more realistic. Any and all feedback is welcome, I am not infallible and will inevitably make a lot of mistakes. A lot of the theory is simplified so that it is more accessible. Today, I want to talk about the J-404 "panther", and the theory behind adjustable nozzles on afterburning engines. A) Introduction The engine seems to be modeled after a generic military low-bypass afterburning turbofan engine, such as the F-100 found on the F-16 and F-15 aircraft. This type of engine is equipped with an adjustable nozzle, that is, a nozzle that can expand or contract depending on the exact mode and conditions in which the engine is operating. This changes different cross-sectional areas of the nozzle, including the throat and the nozzle exit. In this specific case, we assume that the nozzle is purely convergent (although in reality the aft-most section diverges slightly, but this has little-to-no impact on the main point I will argue here), and that the nozzle exit and throat area are the same. Note: we will ignore the thrust vectoring for this exercise, and focus on just the concept of contracting and expanding the nozzle exit area. B) Problem (* refers to section D, Theory) 1) The expected behavior. The task of the nozzle on a jet engine is the acceleration of the flow to high velocity with minimum pressure losses, producing thrust. As the nozzle converges, the flow accelerates, the pressure decreases, so does the temperature and density. Assuming that the flow is choked at the throat (which it would be for this kind of engine), M=1 at the throat. This choking condition is crucial to the process, because it defines what happens when we increase or decrease thrust and/or add afterburning. When in a choked condition, increasing the pressure before the nozzle will NOT increase the mass flow. However, increasing thrust increases the mass flow through the engine, both in the injected fuel and in the air intake. The increase in thrust and hence mass flow has to be reflected then in the widening of the nozzle. If the nozzle stays at the same area, the pressure in the nozzle will increase, not however leading to a significant increase in thrust, because the mass flow is constant.* When afterburning, this issue becomes even more apparent, where the mass flow, temperature (and hence volume), of the gas increases. If the nozzle is fully contracted when the afterburner is switched on, it should begin rapidly expanding to allow for the increased mass flow, otherwise there will be nearly no increase in thrust. 1) Current behavior. The engine is that for the full range of thrust setting, in "cruise" mode, the engine nozzle doesn't change. As mentioned above, it is not ideal, but it would still run, just inefficiently. However, when the afterburner is switched on, the nozzle contracts to the smallest possible cross-section, and stays that way for the entire thrust range. This should be the other way around! Yes, when switching modes, contraction is understandable so that the correct conditions for the ignition of the afterburner are created, however once ignited, the engine nozzle should increase to maximum cross-section as thrust is increased. 2) The expected behavior. The combustion chamber is where the flame is contained when operating without afterburner, and it must be ensured that (almost) all combustion takes place here as to prevent damage to the turbine and other components. This doesn't depend on the thrust setting, flame is contained in the cc. (Not even the whole cc, just in the central-part of the chamber, near the front, where circulating flows "hold" the flame). 2) Current behavior. Flames are seen reaching several meters out of the engine without afterburner running. This makes little-to-no sense, as those flames would have to go from the combustion chamber, all the way through all the turbine stages, all the way through the nozzle, and then outside, and still be burning. Especially with methane, the combustion process taking this long is not realistic, unless you are dumping fuel like the F111. C) Solution 1) Without afterburner, the nozzle should expand slowly with increasing thrust. If applicable, you may want to implement the same for an increase in altitude, as the ambient pressure changes, the ideal pressure ratio changes, to achieve optimal thrust. This is a choice based on how advanced the engine is supposed to be. However, for the afterburner, the engine should be open at a maximum cross-section for the full thrust, and slowly decrease for lower thrust levels. Generally, the engine cross-section should be larger when the afterburner is operating. 2) There should not be any flames leaving the engine with the afterburner switched off. D) Theory / References Here I would like to expand on some of the arguments I have made in the text above, and most importantly link to the sources I have used in this text. The main source for the theory is Fundamentals of Aerodynamics - 6th Edition, by John Anderson. Specifically chapter 10 on compressible flow through nozzles, diffusers, and wind tunnels. Two topics are treated, first why we might want to adjust nozzle area, and second the idea of choked flow. The thrust of a jet engine can be simplified to an equation: Ftot = Fv + Fp where Fv = (Vj - V0) Fp = Ae (Pe - Pamb) The two above parts of the thrust are the thrust generated by the acceleration of the flow, and the difference in pressure, respectively. By taking the derivative of the total thrust equation, we will find that the maximum thrust, and hence the optimum operating point, is when the exit pressure and ambient pressure are equal, making the pressure thrust zero, but the exit velocity maximum (Fp=0, Fv=max). The exit pressure ratio is a function of many variables, most importantly the exit area of the nozzle. By increasing or decreasing the cross-sectional area we can vary the exit pressure, therefore ensuring that the engine is at most times operating at the desired design point, delivering the optimum performance. For a convergent-divergent nozzle where we can achieve a certain pressure upstream, then decrease the pressure towards the throat, and with further expansion decrease the pressure to ambient, this can be achieved, however in this case of the convergent-only nozzle, the exit pressure is equal to the pressure at the throat, and this is where the concept of choked flow has to be introduced. With relation to the equation of Fv, we can observe that to increase the thrust, we need to increase the mass flow and the jet exhaust velocity. To illustrate how mass flow behaves, we begin with a convergent nozzle where the pressure upstream and ambient are equal. In this case, the exhaust velocity and mass flow are both zero, as nothing is driving the flow to exit the nozzle. As the upstream pressure increases, so does the mass flow, but as we begin to approach M = 1 at the throat, the mass flow increase slows down, eventually staying at a constant value when M=1 is achieved. This is a called a choked flow, and any pressure increase beyond this point will not lead to mass flow increase. This is caused by the limit of convergent only nozzle, where M=1 is the maximum achievable. By comparison, in convergent-divergent nozzles, the expansion can continue further in the divergent section, driving the flow to supersonic speeds. It is left as an exercise to the reader as to why this is the case. As mass flow follows = density * velocity * Area and M=1, where M = velocity / sqrt( gam * R * T) for a constant velocity locked by the M=1, mass flow can only increase by increasing the Area, or increasing the density. One might argue that the velocity increases because of increasing temperature T in the flow with the afterburner running, which is true, however also the density decreases in that situation. Observing that M=1 is the condition with maximum mass flow and velocity, and hence thrust, we can safely assume the nozzle will be choked for the purposes of achieving maximum thrust. Then, when the afterburner is ignited, multiple things happen: a) The fuel flow to the engine is increased significantly (increased mass flow) b) the temperature of the flow increases c) the volume of the flow increases (as density decreases). Then the engine has to deal with a decreased density flow with very high temperatures. The pressure is assumed constant over an afterburner. For the same velocity and area of the nozzle, but significantly decreased density, the mass flow through the engine will decrease, actually decreasing the thrust produced. As the mass flow on the nozzle-side decreases, the flow upstream in the engine will have to react, and the overall mass flow into the engine will also decrease accordingly. To prevent this, the nozzle should be open to the increased volume of gas. Lastly, illustrations of the problematic behaviors are shown in the images bellow, beginning with the flames leaving the engine when afterburner is not running, and then ending with the nozzle being at maximum contraction for the afterburner. I look forward to your comments and discussion on this topic. ~VM Appendix A: Images P.S.: To not be just critical, the shock diamonds look incredible and I am really excited about the expansion of the exhaust gasses with increasing altitude, I will return to some of those topics in the future for sure.

Fairly self-explanatory. If you EVA a kerbal and walk into a part of a craft, you will apply a force onto the craft. This works even when on the craft itself, thus creating a kraken drive.

This post is simple and can be very useful for everyone. Seeing the new parachute physics made me think that maybe the physics systems got a lot of attention for KSP2. Please come up with ideas of what and how to test in KSP2 to see if the STOCK physics simulation quality is improved. I will start with: 1. Air intakes should not have the same drag coeficient as nose cones. 2. How slippery the ground is (for wheels and landing legs) should depends on the material it's made of (not only on the gravitational acceleration). 3. Test wheels. 4. Properties of a part should vary according to where is placed, not according to where it's initially attached. 5. Clipping tanks and pods together should account for combined external surface, total internal volume and the weight of the walls: A clipped with B = A + B - (A intersected B) 6. Materials strength should be more realistic (don't take into account only G-Forces and pressure). 7. Very wide fairings should not be viable (atmospheric drag should apply greater resistance). 8. Any part that's floating in the air should require structural support (struts). 9. We should not be able to visibly pull apart two parts (like docking ports). Parts should not visibly compress and auto-clip into each other under high acceleration. 10. Climbing ladders orientation should account for the direction of gravity (no more going down the latter upside down). 11. Lack of persistent rotation. 12. Clipping craft into each other when time warping. 13. Kerbal surviving high speed crash by jumping out of craft at the last second. Test collisions in general. 14. Test the stacked decouplers exploit and other kraken drives. What other tests could we do day one?

Do wormholes break the First Law of Thermodynamics? Here's the problem: Say Jeb wants to get up to the top of the VAB so he can parasail down. To do so, he takes his quad-taxi and flies up to the top. In doing so, he has increased his potential energy. Now, Bob, trying to stop Jeb, uses a wormhole with one end on the ground and the other on top of the VAB. In doing so, he has also increased his potential energy, but because he entered the wormhole and immediately popped out on top of the VAB, I'm not sure where the energy came from. Does this break physics, or this just normal?

I've been thinking about it and I think this subject needs to have it's own thread. Nate said that time warp will be using a "non-eliptical solver" - I think he's referring to the on-rails warp. But remember that in KSP1 we can physics warp under acceleration. So what about the new physics warp? Will it still be a separate thing? Is it still going to be buggy? Will on-rails warp and time warp be merged? Will non-eliptical solver warp be allowed in atmosphere? Will we still have speed limits depending on altitude? Any theories or evidence?

I'm very excited to hear that automated delivery routes are confirmed and can't wait to over-engineer a logistics network. Positivity First: It sounds like resource routes will be established by performing a delivery with a truck or rocket manually first. Once a single successful loop is completed, a new delivery route will be unlocked. This is an excellent design choice because it requires a player to achieve sufficient mastery for each route, and since some routes will be harder than others, the available wealth for a player will grow in proportion to their skill. Even better, the tedium of repeated manual hauling missions is eliminated (I've certainly done this in KSP1). There are two aspects of delivery routes that could cause problems if not implemented well: #1 - Variable dV requirements for routes that cross multiple SOIs If you want to get from Kerbin to Eeloo, the dV required will depend on the relative positions of those planets and the order you perform your maneuvers. This gets even less repeatable when gravity assists are considered. One potential exploit could be a player manually running a delivery route at the optimal time with very favorable gravity assists, and then getting future deliveries for less dV than they really should cost. Personally, I wouldn't mind this, and if a player is smart enough to exploit this... maybe they should be rewarded for it? This is one of those cases where I believe satisfying gameplay is better than realism. That said, I think there should at least be some sort of in game acknowledgement of this issue. Another possibility could be imposing some sort of handicap on a player while proving a delivery route... such as 10% greater fuel consumption. #2 - Will automated vessels be under control of the Physics Engine Please don't do this for the following reasons: It will cause delivery routes to spontaneously fail off-screen at no fault of the player due to kraken like bugs. Even if KSP2 has far more robust physics than KSP1, delivery routes would also greatly expand the number of failure modes. It wastes CPU - The rigid body physics calculations are computationally intensive and may be fundamentally limited in how much they can be parallelized. This cost is worth it for craft the player is actively looking at and piloting, but not for stuff off screen. Even if different vehicles far away were give their own physics threads, it would wouldn't take long to saturate even a high-end CPU. One possible exception - It may acceptable to physically simulate delivery vessels while they are close to a player. For example, if a player is piloting a space station and an automated freighter comes in to dock, this could be a reasonable because it only needs to scale with the number of players and if a kraken occurs, the player will witness the failure and learn something immediately. Discussion of possible deliver route implementations Since it hasn't been explicitly confirmed is exactly how the automated resource routes will behave. Let's consider 3 possibilities (there are many others): Exact Record/Playback This implementation would be like trucks in Satisfactory. You press "record", pilot your craft manually along a delivery route, then "stop" the recording when you close the loop. The craft would replicate your actions exactly. Tradeoffs: [-] Please don't implement this [-] Would only work for land-based routes. Orbital targets would change relative positions between iterations of the delivery route, so rigidly executing the same maneuvers at a different time would not work. [-] Not robust - It is not realistic to expect a vehicle to perfectly execute recorded instructions each time. If the player barely grazed the edge of some scatter while recording, it may cause a collision during a random playback. Ghost Ships on Rails - After recording a resource route, your craft will repeat that same route, but will be non-collidable and on rails [+] Robust - Players still have to prove route viability but don't have to worry about spontaneous failures due to FP rounding errors or kraken-like bugs. [+] Moderate CPU - This should be little more than viewing a bunch of craft in the tracking station, or rendering a few ghost ships docking at a resource depot. [+] Provides visual feedback/beauty to the player to appreciate as they build up their industrial infrastructure. [-] Still has the problem of different maneuvers required depending on relative celestial body position. Since these are ghost ships, some cheese is allowable here, for example "draw a curved path from Kerbin to Jool that looks reasonable". These automated ghost ships should achieve these paths "magically" without burning their engines (except maybe for visual purposes). Abstract Network - Delivery routes would behave like the KSP1 relay network. After manually executing a loop, the UI could draw a line between the source and sink and you could utilize this link in some sort of logistics/production management UI. [+] Very robust - No moving vehicles means no spontaneous failures [+] Very Low CPU - All you need are some new UI elements but no actual craft to render or track [-] Not as cool - It may be hard for some players to suspend their disbelief if a stack of ore magically appears every 6 hours in their station without seeing anything dock.

do you think KSP2 will have ground effect? it's one of the things that causes planes to have more lift near the surface than in the air which means that if it gets added one could make vehicles that glide over the seas of planets for example

Hello everyone! I know that the planet / moon roster for initial game release is probably already set in stone, but there is a lot of room for future expansion in the KSP universe. So I'm going to make a compilation / list of (mostly crazy and probably not possible IRL) planet / moon physics ideas. Any feedback and extra ideas are more than welcome! - binary system with a common atmospheric bridge (maybe generated by gasses from vulcanism like on Rask & Rusk) - that could maybe allow armospheric flight from one planet to another - planets with a lot of vulcanism without / with normal / very thick atmosphere (there are very big differences related to vulcanic explosions behavior) - solid clouds you can land on (like in Interstellar) - maybe above a gas giant, porous ice clouds - water world with huge tsunamis (like in Interstellar) - foam world (water world with oceans that have a thick layer of foam above, with only mountain peaks clear for landing) - classic half hellscape / half frozen planet (planet tidally locked to star, one half in perpetual darkness) - planet like Crematoria in Chronicles of Riddick, with extreme moving heat wave during daytime - planet with a lot of tornadoes and localized storms - rainy planet (serene or with howling winds) - spiky planet (like carbon spikes) with very few places to land on - furry shores planet with aluminum lands and mercury seas (check the chemical reaction https://youtu.be/IrdYueB9pY4 ) - Dune - planet with a lot of sinkholes and lava tubes - planet with dust streaming off of it - radiation and winds from the nearby star would blow off material from its circumference, there would be liniar winds - rogue planets - Europa / Enceladus like moons or planets, with very deep oceans under the ice, geothermal vents - very, very old planet - planets with unstable, varied orbits (like in three body problem) - swamp / mist world - merged double planet (with 8 shape) - metalic planet / moon - some kind of disk world - matte black planet (dark like charcoal) - egg shaped (gravitational pull) - planet surrounded by orbiting liquid bubbles that periodically fall back down - very cold planet with levitating quantum locked metal islands - planet or moon cracked / split in half (Doom vibes) - ice VII / X body - bromic acid seas, Belousov-Zhabotinsky reaction (video) - phosphorescence / triboluminescence - Mercury (II) thiocyanate / calcium gluconate (video) - ferrofluid lakes / volcanoes - climate / seasons! - very tight and fast orbit around a red dwarf - a pulsar with high radiation levels and you can see it's beams even when landed on a planet (like in Galaxies Unbound) - black hole with orbiting system - planet with two perpendicular orbiting debris disks, at different altitudes - giant impact crater or crack / trench / canyon which contains all the planet's atmosphere (like atmospheric density differences on Duna) - a desert where we can take our rovers and do high dune jumps like at Baja - 10+ km cliffs like Verona Rupes on Miranda (Uranus moon) so we can jump off it - celestial body with giant atmospheric or liquid vortex (let's say you could fly inside it and touch the bottom of the ocean) - N-ary star system - planet with a quartz crystal (of any type or even mixed for colourfulness) surface (Z.O.M.G) - planets with different oxides for different colours: copper oxide soil for a blue surface, bismuth oxide for yellow, chrome oxide for green etc. (Z.O.M.G) - brown dwarf (Z.O.M.G) I will add more...

The question is in the title, I imagine not, as that seems quite daunting to implement, but it would be really interesting to see the MET clock on board a spacecraft to reflect to time elapsed on board the ship, or to run into the exponential decrease in acceleration as you approach c. Even accounting for the 0.1x scaling of the Kerbolar system, distances to the nearest stars will still likely be measured in light years I imagine, so these long range crafts will likely want to reach these speeds, which is why I wonder if KSP 2 plans to tackle it. Interested to hear what you guys think!

Yesterday I played Universe Sandbox and I turned the sun into a black hole as it had a mass like the sun, nothing changed, but when I started playing with the mass of a black hole, the whole solar system started to crumble, then when I went to sleep I dreamed that our the solar system a black hole flew in from deep space and that black hole wants to suck us in

Dear Forumites, I'm posting this question as I did not find any references to these topics. Basically: 1. Any idea if the Devs plan to allow multiple simultaneous vessels with active physics in different parts of the solar system? 2. What method would be used to simulate physics on ship parts? Will each be simulated independently (As in KSP1 which causes lag after a certain number is reached). Or after the ship is build, the physics will be rendered for just that ship, and all other attached parts will be graphically rendered but with different graphical destruction reactions and still be a part of just one unit. If these questions have not been asked/answered in the past or can't be answered yet, no stress, I understand! Thank you for any information.