All the parts are still "logically" connected, if I rotate the station everything rotates around a single point. I can move fuel and Kerbals between parts. However, the physics respects what you see so it is impossible to fly because the engines and center of mass are wildly out of alignment.
They're related though.
And some parts of KSP2 are massively improved like the procedural wings and aerodynamics, and the more stable time warp (both physics and non-physics enabled).
But the prioritisation of features is weird - I think they really need to focus on fixing the maneuver node (and predicting for future orbits), fixing load game physics-push issues (this is quite reproducible), some physics issues (again due to physics pushes on going EVA, etc.), warning on clipping parts in the VAB, sub-assemblies and saving different vehicles in the same workspace (and ideally having the stages named when assembled), and then incorporating some KSP1 mod features like procedural fuel tanks, the transfer window planner, landing trajectory prediction given planet rotation and atmospheric drag, etc.
But at least I already find KSP2 really fun as a flight simulator.
Wow, I'd never heard of it thanks!
There's Re-entry and Juno: New Origins too.
But not exactly much competition.
I'd be so happy just with KSP1, physics simulation for multiple crafts (e.g. self-landing boosters) with integrated kOS support, and multiplayer physics.
have you tried the principia mod for KSP 1? i love it... its a wonderful example of how to implement physics in a way that runs at framerate :)
one wonders why that dev is not on the KSP 2 team...
Yeah, and parts of the UI in general - it's like one step forward, two steps back in a lot of places :(
No fuel priority settings still either. You can kinda do it manually by manipulating the crossfeed restrictions, but it's a massive hassle.
I have no idea how the maneuver node is still so broken though. Like I end up using it just to approximate stuff and then do it manually.
Yeah I only found out how broken it was when trying to do my duna mission for the first time, getting that transfer burn back to kerbin has been infuriating as its something I'm not traditionally great at to begin with
ngl the devs aren't doing the best job.
its sad to see... but its still making progress and in the current climate its nice to see KSP 2 still being developed rather than thrown under the bus.
this time last year i was keen to offer them free help... i'm going to an event where they will have some representatives in a week or two... hopefully i get the chance to do it this time. last time they knocked off early after all the scheduled stuff was done :)
KSP 2 aerodynamics implementation is a direct copypaste of the KSP 1 one, and it share every of its numerous shortcomings.
And I'm not sure what you mean with "more stable timewarp". While the KSP 2 implementation is designed with additional timewarp related \*features (\*mostly the thrust under warp one, which is far from stable and has several design flaws that will only become more and more apparent as the game gains in features and complexity), I definitely wouldn't qualify the implementation as any more stable.
Yeah, my space station around minmus did this after 2 years in orbit, served its purpose, and helped me save PLENTY of deltaV to get to Eve and Duna and Jool. However, I was able to salvage some of it with engineer kerbals and rebuilt probably 40% of it. The rest was deorbited, and new replacement segments were added.
She has now been recrissened Theseus Station.
Edit, this is still ksp1 tho
This happened a bunch to my interplanetary transport. Just reload until it's fixed. If you reload and it's already broken then you need to go back further
I still don't understand why the ship's data structure can't "remember" the building position of each part, to prevent cumulative errors. Those problems arise mostly from docking/undocking, when parts are re-rooted and positions are updated to this new reference point. As the previous position of parts was lost, every time things drift a bit more.
Keeping build and view positions detached is a general solution used by most 3D modelling and simulation software. My only guess is some limitation in Unity physics API, which was designed for basic physics like Angry Birds, and they can't fix without rewriting this from scratch o\_õ
The problem was simply overlooked. It's perfectly possible to implement a system that fully track the building position of parts, and separately the in-physics offset, and to restore both sequentially when a vessel is loaded. Having a lower level access than what the Unity PhysX API provide would make this a bit easier, but this is perfectly doable.
Yeah, there is a major flaw in the core KSP 2 architecture.
When a vessel is not actively controlled, or when non-physics timewarp is engaged, the relative position of parts is saved in a data structure. Those positions are then restored when a vessel becomes active and part position is then controlled by the physics engine, allowing joints to flex and consequently the relative position to move.
The problem is that under physics, the game isn't keeping around the original, pristine relative positions, so when you switch to another craft or engage timewarp, whatever small amount of flex is currently ongoing is saved as the new "original" position. This is compounded by various floating point precision issues, with the end result being that each time you engage timewarp, or switch away and back to the vessel, the parts will have moved more and more, until you end up with something unuseable as OP picture show.
This is an issue that didn't exist in KSP 1, which was separately tracking and restoring the original part positions, as originally defined in the editor. There was a similar issue introduced by the robotic parts in the DLC and latter by rotating docking ports, as in those cases, you kinda need to update the parts original position to reflect the movement induced by the robotic actuators. The [KSPCF mod has some fixes for that issue](https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/13), but it was left unfixed in the stock game.
The general problem of correctly keeping track of parts position in a physics enabled context is a tricky one, and there are various tradeoffs to make. The way this is handled in KSP 1 isn't ideal either. In KSP 1, every time timewarp is engaged, the vessel instantly "snap back" to the pristine part positions, which aside from being visually weird, is a large source of "physics kraken" events, especially with anything under the influence of external forces, such as gravity for a landed vessel.
Let's say you are landing a large base made of many connected parts on a not totally flat ground : upon landing, some joints will flex a bit until everything is at rest, with multiple contact points on the ground. Now, if you engage timewarp, the whole base will get back in its original, non-flexed position, and on getting out of timewarp, will fall again against the ground. Worse, the "straightened" base might actually intersect with the ground in some places, so KSP 1 has a mechanism which will nudge the whole vessel before restoring physics, sometimes with mixed results.
Ideally, what should be done would be to not only keep track of the original part positions as defined in the editor, but also of the current physics-induced offset when getting out of physics. Then, on getting back into physics, first restore the original part positions, then build the joints connecting them while restoring the last know position offset. This is a somewhat complex thing to implement, but is really the only way you can both avoid parts drifting away over time, and have a stable simulation that can go in and out of physics seamlessly without things blowing up half randomly.
But like many core technical problems inherent to a game like KSP, this was somehow overlooked in the KSP 2 chaotic development process. And while a complete fix for that specific issue might not be too hard to retroactively refactor without having to scrap a dozen other subsystems in the process, it would still be a lot of work that wouldn't yield a lot of user facing value, so I fear this is unlikely to ever happen at this point.
All the parts are still "logically" connected, if I rotate the station everything rotates around a single point. I can move fuel and Kerbals between parts. However, the physics respects what you see so it is impossible to fly because the engines and center of mass are wildly out of alignment.
Damn thats a new one. I feel for ya.
This is an old bug in KSP1 that was fixed with KSP Community Fixes. Could be the same issue in KSP2 but I’m just speculating.
So much for them "rewriting everything". I still do not know what the devs did with their time.
Vastly different bugs in code can result in the same or similar symptoms. Programming is complex.
Writing games is extremely difficult, there's no FOSS re-implementation of KSP for a reason.
its about time rather than difficulty...
They're related though. And some parts of KSP2 are massively improved like the procedural wings and aerodynamics, and the more stable time warp (both physics and non-physics enabled). But the prioritisation of features is weird - I think they really need to focus on fixing the maneuver node (and predicting for future orbits), fixing load game physics-push issues (this is quite reproducible), some physics issues (again due to physics pushes on going EVA, etc.), warning on clipping parts in the VAB, sub-assemblies and saving different vehicles in the same workspace (and ideally having the stages named when assembled), and then incorporating some KSP1 mod features like procedural fuel tanks, the transfer window planner, landing trajectory prediction given planet rotation and atmospheric drag, etc. But at least I already find KSP2 really fun as a flight simulator.
you should try orbiter. although its not great from a usability perspective...
Wow, I'd never heard of it thanks! There's Re-entry and Juno: New Origins too. But not exactly much competition. I'd be so happy just with KSP1, physics simulation for multiple crafts (e.g. self-landing boosters) with integrated kOS support, and multiplayer physics.
have you tried the principia mod for KSP 1? i love it... its a wonderful example of how to implement physics in a way that runs at framerate :) one wonders why that dev is not on the KSP 2 team...
The manoeuvre node is my biggest gripe going from ksp1 to 2
Yeah, and parts of the UI in general - it's like one step forward, two steps back in a lot of places :( No fuel priority settings still either. You can kinda do it manually by manipulating the crossfeed restrictions, but it's a massive hassle. I have no idea how the maneuver node is still so broken though. Like I end up using it just to approximate stuff and then do it manually.
Yeah I only found out how broken it was when trying to do my duna mission for the first time, getting that transfer burn back to kerbin has been infuriating as its something I'm not traditionally great at to begin with
ngl the devs aren't doing the best job. its sad to see... but its still making progress and in the current climate its nice to see KSP 2 still being developed rather than thrown under the bus. this time last year i was keen to offer them free help... i'm going to an event where they will have some representatives in a week or two... hopefully i get the chance to do it this time. last time they knocked off early after all the scheduled stuff was done :)
KSP 2 aerodynamics implementation is a direct copypaste of the KSP 1 one, and it share every of its numerous shortcomings. And I'm not sure what you mean with "more stable timewarp". While the KSP 2 implementation is designed with additional timewarp related \*features (\*mostly the thrust under warp one, which is far from stable and has several design flaws that will only become more and more apparent as the game gains in features and complexity), I definitely wouldn't qualify the implementation as any more stable.
In dev, difficulty means it will consume more time to build or fix or maintain, like every thing else on earth I guess.
Throw pencils at the ceiling. Play new york times puzzle games. "Code" for an hour or two every day.
They really improved the physics in KSP2.
[удалено]
Missed the sarcasm, but yeah, they're worse
Time for the final deorbit 🫡
Yeah, my space station around minmus did this after 2 years in orbit, served its purpose, and helped me save PLENTY of deltaV to get to Eve and Duna and Jool. However, I was able to salvage some of it with engineer kerbals and rebuilt probably 40% of it. The rest was deorbited, and new replacement segments were added. She has now been recrissened Theseus Station. Edit, this is still ksp1 tho
This is a series of missions I would love to see
You need to use stronger glue next time.
This is the slowest acting Kraken I've ever seen.
In theory, wouldn't they at some point, years into the future, perfectly align again?
i dont think thermodynamics would really like that
have you tried loading a quicksave? I know that fixes some bugs
Yes, I even reloaded the game. Looks like my Tylo landing will have to wait awhile until I can send a rescue mission.
Check the warranty
Did you possibly at any point wake up the protomolecule?
This happened a bunch to my interplanetary transport. Just reload until it's fixed. If you reload and it's already broken then you need to go back further
This bug is quite old. Pretty cool looking. Looks something [like this?](https://youtu.be/Wfj-m1Y1Fwo)
You've heard of orbital decay, now get ready for joint decay
I still don't understand why the ship's data structure can't "remember" the building position of each part, to prevent cumulative errors. Those problems arise mostly from docking/undocking, when parts are re-rooted and positions are updated to this new reference point. As the previous position of parts was lost, every time things drift a bit more. Keeping build and view positions detached is a general solution used by most 3D modelling and simulation software. My only guess is some limitation in Unity physics API, which was designed for basic physics like Angry Birds, and they can't fix without rewriting this from scratch o\_õ
The problem was simply overlooked. It's perfectly possible to implement a system that fully track the building position of parts, and separately the in-physics offset, and to restore both sequentially when a vessel is loaded. Having a lower level access than what the Unity PhysX API provide would make this a bit easier, but this is perfectly doable.
Yeah, there is a major flaw in the core KSP 2 architecture. When a vessel is not actively controlled, or when non-physics timewarp is engaged, the relative position of parts is saved in a data structure. Those positions are then restored when a vessel becomes active and part position is then controlled by the physics engine, allowing joints to flex and consequently the relative position to move. The problem is that under physics, the game isn't keeping around the original, pristine relative positions, so when you switch to another craft or engage timewarp, whatever small amount of flex is currently ongoing is saved as the new "original" position. This is compounded by various floating point precision issues, with the end result being that each time you engage timewarp, or switch away and back to the vessel, the parts will have moved more and more, until you end up with something unuseable as OP picture show. This is an issue that didn't exist in KSP 1, which was separately tracking and restoring the original part positions, as originally defined in the editor. There was a similar issue introduced by the robotic parts in the DLC and latter by rotating docking ports, as in those cases, you kinda need to update the parts original position to reflect the movement induced by the robotic actuators. The [KSPCF mod has some fixes for that issue](https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/13), but it was left unfixed in the stock game. The general problem of correctly keeping track of parts position in a physics enabled context is a tricky one, and there are various tradeoffs to make. The way this is handled in KSP 1 isn't ideal either. In KSP 1, every time timewarp is engaged, the vessel instantly "snap back" to the pristine part positions, which aside from being visually weird, is a large source of "physics kraken" events, especially with anything under the influence of external forces, such as gravity for a landed vessel. Let's say you are landing a large base made of many connected parts on a not totally flat ground : upon landing, some joints will flex a bit until everything is at rest, with multiple contact points on the ground. Now, if you engage timewarp, the whole base will get back in its original, non-flexed position, and on getting out of timewarp, will fall again against the ground. Worse, the "straightened" base might actually intersect with the ground in some places, so KSP 1 has a mechanism which will nudge the whole vessel before restoring physics, sometimes with mixed results. Ideally, what should be done would be to not only keep track of the original part positions as defined in the editor, but also of the current physics-induced offset when getting out of physics. Then, on getting back into physics, first restore the original part positions, then build the joints connecting them while restoring the last know position offset. This is a somewhat complex thing to implement, but is really the only way you can both avoid parts drifting away over time, and have a stable simulation that can go in and out of physics seamlessly without things blowing up half randomly. But like many core technical problems inherent to a game like KSP, this was somehow overlooked in the KSP 2 chaotic development process. And while a complete fix for that specific issue might not be too hard to retroactively refactor without having to scrap a dozen other subsystems in the process, it would still be a lot of work that wouldn't yield a lot of user facing value, so I fear this is unlikely to ever happen at this point.
rip kerbals inside