Jump to content

Search the Community

Showing results for tags 'physics'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP2 Dev Updates
    • KSP2 Discussion
    • KSP2 Suggestions and Development Discussion
    • Challenges & Mission Ideas
    • The KSP2 Spacecraft Exchange
    • Mission Reports
    • KSP2 Prelaunch Archive
  • Kerbal Space Program 2 Gameplay & Technical Support
    • KSP2 Gameplay Questions and Tutorials
    • KSP2 Technical Support (PC, unmodded installs)
    • KSP2 Technical Support (PC, modded installs)
  • Kerbal Space Program 2 Mods
    • KSP2 Mod Discussions
    • KSP2 Mod Releases
    • KSP2 Mod Development
  • Kerbal Space Program 1
    • KSP1 The Daily Kerbal
    • KSP1 Discussion
    • KSP1 Suggestions & Development Discussion
    • KSP1 Challenges & Mission ideas
    • KSP1 The Spacecraft Exchange
    • KSP1 Mission Reports
    • KSP1 Gameplay and Technical Support
    • KSP1 Mods
    • KSP1 Expansions
  • Community
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
    • KSP Fan Works
  • International
    • International
  • KerbalEDU
    • KerbalEDU
    • KerbalEDU Website


There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL



About me



  1. 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.
  2. Purtroppo non posso programmare, ma penso che qualcuno che trova interessante la mia idea potrebbe rilasciare la mod a cui sto pensando. La mod riguarda (come probabilmente avrai già letto) sui fluidi: un sistema che cambia il modo in cui funzionano le stive di carico e parti simili, ora se metti una stiva di carico in un aereo e ci metti delle parti avranno resistenza, sollevare... e quindi comportarsi come se fossero fuori, la mod dovrebbe risolvere questo problema e migliorare la fisica dell'acqua, come rendere inutili le prese d'aria sott'acqua, aggiungere alcune prese d'acqua con i motori ad acqua... sarebbe anche bello farlo così che nelle stive di carico non si vede acqua (sott'acqua) se sono chiuse, ma se si aprono si riempiono d'acqua e cambiano assetto e riempimento d'acqua. Sarebbe anche bello rendere più pericolosa l'esplorazione subacquea, aggiungendo la pressione dell'acqua che cambia con la profondità e facendo anche in modo che i kerbal subacquei indossino sempre una tuta intera. So che è piuttosto difficile da creare, ma sarei davvero felice di vedere un mod come questo essere rilasciato Qui lascio un'idea delle aggiunte della mod, dimmi se pensi che siano buone o meno Miglioramenti: Le baie di carico possono essere riempite d'acqua se vengono aperte sott'acqua e cambiano galleggiabilità, anche le baie di carico sono impermeabili quando sono chiuse La pressione aumenta sott'acqua, i cordoli e le parti possono essere distrutti se portati sott'acqua due ali staccate una di fronte all'altra si comportano come nella vita reale, non producono doppia portanza e resistenza, e un velivolo dietro l'altro ottiene la turbolenza tutte le parti aerodinamiche si comportano sott'acqua come farebbero in IRL (più controllo con le superfici di controllo) Parti: Cisterne di zavorra (Mk1, Mk2 e Mk3) Prese d'acqua Pompe dell'acqua Motori subacquei radiali Regolari motori subacquei Pozzetto resistente alla pressione Parti che resistono a forti urti (ad esempio potrebbero essere utilizzate per siluri lanciati dall'aria) Varie: Migliore visione subacquea I kerbal possono nuotare sott'acqua I Kerbals hanno bisogno di bombole di ossigeno per andare sott'acqua con l'EVA Do you think this could be cool?
  3. Jan Hloušek on Space Engineer's developer team has a rather interesting thread on various third-party physics engines. In particular if you scroll down, Havok physics 2022 seems much better than the rest of the alternatives. If KSP 2 is still using Unity's PhysX underneath, would it be beneficial to swap it out during early access to see if there are performance and stability improvements? What are people's thoughts on his thread?
  4. 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.
  5. KSP Version: 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 as well.
  6. Hallo, ich habe die aktuelle Version ü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 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!
  7. KSP version 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...
  8. Mismatch between "Vehicle Actions" control panel and Parts Manager in controlling items KSP version 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.
  9. 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)
  10. 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
  11. 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
  12. 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: 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: -
  13. 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.
  14. 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.
  15. 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.
  16. 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?
  17. 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?
  18. 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?
  19. 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.
  20. 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
  21. 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...
  22. 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!
  23. 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
  24. 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.
  25. I'm having a weird bug with drag being produced by parts that are stowed inside a cargo bay. The weird thing about it is how inconsistent it is. I designed my plane in the SPH, when I launch it it takes off, accelerates, goes supersonic and to orbit, no problem. If I revert to launch and try again though, this time the parts inside the cargo bay are producing excessive drag and this time my plane won't even pass the speed of sound. I had the bug once during testing, I sort of dismissed it, put a short fairing on one of the things inside the cargo bay just in case, and proceeded to send that spaceplane to another planet where it is now. Problem is, now the aero engine is freaking out again and I'm kind of stuck there moving at very low speeds. I tried quicksaving and reloading, as well as opening and closing the cargo bay, hoping to force the game to recalculate what is shielded and what's not, but it didn't work. I also noticed after some time that the engines were maxing out at their stationary thrust (they're supposed to work like jet engines) instead of going past it as I gain some speed, which probably also contributes to my relatively slow speed. I did tons of test flights with that craft where everything went fine, but now it seems to be stuck with that weird aerodynamics behavior and I obviously can't revert to SPH now. I have a modded install but I don't think that any of the mods I have installed should affect aerodynamics (I might try installing FAR and seeing if it solves the problem though). I was wondering if anyone ever had the same bug and managed to find a way to beat some sense into that stubborn physics engine
  • Create New...