mhoram

Issue appeared with KSP Community Fixes installed, but thanks for the idea!

I would have guessed, that physics of part movement would be a system that is completely distinct from the system that moves vessels in orbit. Thank you for this clarification. Thank you for confirming that this is a bug. I am quite certain, that Principia is the only Mod, that changes physics in my installation, but one can never know for certain. I can try to replicate this issue in Stock+Principia and will get back to you.

Have you tried to use a smaller indicator-vessel (with distinct directions up, forward, right), that lets you estimate, if the bigger vessel can be built?

At the moment, the distance is hardcoded and can not be changed with configfiles: https://github.com/UmbraSpaceIndustries/Konstruction/blob/eecfe00077c8c9f643b55d821c15fcaa53ee26f9/Source/Konstruction/Konstructor/OrbitalKonstructorModule.cs#L15 Edit: You could try waiting until the vessel is 90° farther along in the orbit. This might rotate the built vessel by 90° relative to the shipyard.

Yes, there are logfiles. Have a look at this post, which contains a description of their location. Some of them get overridden every time you start KSP, so you might not find anything about that crash, if it happened during a previous run of KSP.

@Nicky21 I believe, that I was able to replicate your issue. Can you please check, if this is the bug, you are experiencing? https://github.com/UmbraSpaceIndustries/USI-LS/issues/314

Currently I am having troubles with my space station, because the parts are moving away from each other over time - usually after some wobbling occurred, it gets worse. This also has the negative effect, that Kerbals have trouble climbing on ladders of capsules. Uninstalling Principia and loading the game has the effect, that the parts show up in their initial positions before the diverging happened. Do I understand it correct, that Principia takes over the physics of part-movement? If so, is it possible to switch off that functionality and just keep the N-body-orbital movement active? I would appreciate ideas on how to prevent this diverging from becoming worse (reducing the station size is not a viable solution for me). This picture below shows my problem. Initially, the parts (stock + USI-mods) were all aligned to each other, but over time they diverged more and more.

@Nicky21 I also tried and failed to replicate this issue. If you would be willing to send me your savegame in a PM, I could attempt to debug this. Already located the part of the source code responsible for healing, but found no obvious explanation for your problem there.

Rapiers have the special behavior, that they can not accelerate at high altitudes, if you travel too slow: try to accelerate to 500-600m/s at altitude < 400m before raising altitude to 10km. If you want to use mods, have a look at https://forum.kerbalspaceprogram.com/index.php?/topic/177302-1123-kerbal-wind-tunnel-1311/ This mod indicates approximately, if your vessel is capable of reaching orbit. It also helps you finding approximations for the best ascent paths.

In order to answer that, we would need additional infos: How much Delta-V do you need and what TWR do you want? You would need to balance three aspects: ISP, Delta-V and TWR/thrust. Have a look at this app, which can help you to decide: https://forum.kerbalspaceprogram.com/index.php?/topic/114995-web-111-optimal-engine-charts-interactive-webapp/

One of them was the moment, I opened a massive Solar panel structure for the Kerbal Energy Crisis challenge. (Full Photo Album)

I would disagree with this statement. If you burn 100m/s at the Periapsis of A1 and A2, then the Apoapsis change of both orbits would be the same. I chose A1 and A2 specifically so that a 100m/s burn results in the same Apoapsis change.

There seems to be a misunderstanding. The A1 orbit has more energy than the A3 orbit. Lets have a look at it qualitatively: The higher the altitude, the higher the potential energy The faster the velocity, the higher the kinetic energy. For a ship in a Kepler elliptical orbit, it is valid, that kinetic energy + potential energy is always the same. That is why the formula e = ek + ep = (v2 / 2) - (μ / r) can be used to specify the energy of an orbit, since it is constant for every point in that orbit. The ship at Apoapsis in orbit A1 is faster than the ship at Apoapsis in orbit A3. Since Apoapsis is equal for both orbits (and so also the potential energy), A1 must have a higher energy than A3. This graphic shows the energy of orbits (sourcecode): x axis = orbit Apoapsis/Periapsis (Altitude above Earth surface in km, SOI of Earth is about 0.929e6km) y axis = orbit Periapsis/Apoapsis (Altitude above Earth surface in km) (Apoapsis and Periapsis get switched in the top left half of the graph, so that for the calculation Apoapsis is always larger than Periapsis) Color denotes the energy of the orbit. The more green, the higher the energy. (two adjacent threshold lines have the same energy difference) The fact that the threshold lines are farer apart, when the altitudes are higher, shows, that the energy difference becomes smaller for higher orbits. I agree with that.

Thanks @Zhetaan for the detailed explanation. I tried to put the explanation into a graphic. Have a look at this picture. (sourcecode) Each coordinate denotes an orbit with: x axis = initial Apoapsis/Periapsis (Altitude above Earth surface in km, SOI of Earth is about 0.929e6km) y axis = initial Periapsis/Apoapsis (Altitude above Earth surface in km) (Apoapsis and Periapsis get switched in the top left half of the graph, so that for the calculation Apoapsis is always larger than Periapsis) The Orbits on the diagonal from lower left over A1 to top right are the circular orbits. The color at each coordinate denotes the change of Apoapsis caused by a 100m/s burn at Periapsis (the more red, the more change) (dark red is about 0.929e6km, white is about 0km, difference between two threshold lines is about 23225km) Ignore the two white areas B1 and B2, they are caused by hyperbolic orbits which have a negative Apoapsis. Lets have a look at few datapoints: A1 (circular orbit at altitude of about 440000km) and A2 (orbit with Periapsis of about 40000km and Apoapsis of about 350000km) The threshold lines indicates that if you burn 100m/s at their respective Periapsis, you change the Apoapsis by the same amount. This means, that for highly eccentric orbits, it is easier to raise Apoapsis than it is for circular orbits. Comparing A1 to A3 (orbit with Periapsis of about 280000km and Apoapsis of about 440000km) which have both the same Apoapsis: Even though you are faster at the Periapsis of orbit A3 than at the Periapsis of orbit A1, a 100m/s burn raises the Apoapsis of orbit A3 less than the Apoapsis of orbit of A1. This shows, as stated in the preivous post, that the Oberth effect is not the only thing that affects the amount by which Apoapsis gets raised and is linked to the energy of the orbits.

I would like to suggest the following MM-cfg-file bugfix to be included into this package. @PART[ServiceModule25] { !node_stack_core_A1 = dummy !node_stack_core_A2 = dummy !node_stack_core_A3 = dummy !node_stack_core_B1 = dummy !node_stack_core_B2 = dummy !node_stack_core_B3 = dummy node_stack_coreA1 = 0.0, 1.4, 0.0, 0.0, -1.0, 0.0, 1 node_stack_coreA2 = 0.625, 1.4, 0.0, 0.0, -1.0, 0.0, 1 node_stack_coreA3 = -0.625, 1.4, 0.0, 0.0, -1.0, 0.0, 1 node_stack_coreB1 = 0.0, -1.4, 0.0, 0.0, 1.0, 0.0, 1 node_stack_coreB2 = 0.625, -1.4, 0.0, 0.0, 1.0, 0.0, 1 node_stack_coreB3 = -0.625, -1.4, 0.0, 0.0, 1.0, 0.0, 1 } Before creating a pull request, I want to evaluate, if this is a patch that you would consider including into the KSPCommunityFixes or if there is a better place for this fix. This patch fixes the stock bug that using undo (ctrl-z) in the editor can cause some nodes of the ServiceModule25 to become unusable. A video of this happening for a different part can be seen here. My detailed analysis for this fix is available here. I would appreciate feedback about this.