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.

The problem I see with this argumentation is that you want to take the motion relative to the sun into account, while the Oberth effect is associated with the orbit of the current SOI. Lets take the example that you are within an Orbit around Kerbin with Periapsis of 75km and Apoapsis of 100km and your goal is to change the Apoapsis to 1000km. In the initial orbit, your velocity at 75km Periapsis is 2308 m/s In the final orbit, your velocity at 75km Periapsis is 2713 m/s So you need to invest 405 m/s Delta-V to change your orbit. For this orbit-change it does not matter, if the Periapsis is near the sun or away from the sun. In order to transfer to Eve or Duna, you need to leave Kerbins SOI at certain velocities. In order to reach these velocities, just as before you accelerate at Periapsis a certain amount of Delta-V. Again it does not matter, where the Periapsis in relation to the sun is located, because your burn happens within the SOI of Kerbin. If you want to dig deeper into the Oberth topic, there have been several discussions here on the forum: https://forum.kerbalspaceprogram.com/index.php?/topic/65676-oberth-effect-vs-gravity-assists/ https://forum.kerbalspaceprogram.com/index.php?/topic/122445-oberth-effect/ https://forum.kerbalspaceprogram.com/index.php?/topic/146254-how-much-dv-do-you-lose-with-a-higher-lko-really/

This sounds also like a good strategy. Yes, RSS is a different kind of beast. I play on the stock-solar-system. Did you think about a ModuleManager patch to reduce the mass of these Wolf parts to fit your requirements? They are integers. This makes it difficult to scale them to smaller numbers. It would be great to have such a simplified "Wolf Startup"-System of any kind, but to be honest, I have no idea how that could look like with the integer numbers for resources. No, that is not allowed. In order to setup a basic WOLF-base consisting of Habitation, LifeSupport, Power and Maintenance one needs a few Kerbals and: 1 Food 3 MaterialKits 1 Oxygen 5 Water So I imported these resources via a transport route Kerbin KSC -> KerbinOrbit -> MunOrbit -> MunMidlands. If these 4 WOLF-parts were too massive, one could start with Habitation+LifeSupport and go on in a second launch with Power+Maintenance. With additional launches, I extended the production capabilities of my Mun biomes and reduced the transport routes until I did no longer need to import resources from Kerbin to the Mun. The trick is to identify, which parts of a setup can be deployed without causing dependency problems. The WOLF Dashboard Planner helps with that, but one has to experiment a bit in order to find fitting combinations that do not violate dependencies. After building a few bases, I got the hang of it. The dependencies are something like Harvester -> Extractor -> Agriculture&Bioreactor&Refinery -> Fabricator. So by beginning with deploying Harvesters, one can keep the ship-size small.

No, there isn't. The reason for this is that WOLF can be seen as a everlasting infrastructure. If WOLF would depend on anti-hoppers and physical vessels, it would be necessary to check continuously, if the anti-hoppers were still working. This would contradict the WOLF-"partless"-concept. In my current playthrough, I started with WOLF-bases for resource generation and fabrication without utilizing physical MKS parts. I see them as two different paths to achieve the same goal, where WOLF has the advantage of not needing lots of physical vessels and parts. This is one strategy to make off-world WOLF bases viable. A different strategy would be to generate all required resource on site. For multiple biomes on a single planetary body you could set up the required life-support infrastructure (Oxygen, Water, MaterialKits, ...) in a single biome and transfer them to other biomes or set up production for them in each biome (in my current playthrough I use Mun-Midlands as a central hub and fabrication biome that connects to the other Mun-biomes and is the only Mun surface-biome that has a Wolf-transport-route to Mun-Orbit). There are a few basic functionalities that do not require crew points or maintenance: Harvester, Hopper, Power (low power variant). Anything else requires Crew or Maintenance. Setting up a WOLF-offworld-base requires lots of investment, but the advantage is that the generated resources are available afterwards forever. In my playthrough I got the feeling that it is easier, to start with small WOLF-bases and expand them with multiple small expansions. Once I got the hang of it, I sent larger base expansions (40-50 WOLF-parts) on single ships for the construction of a Prototypes-fabricator on the Mun. Now I think, that it is way easier to build WOLF bases than to build physical MKS bases.

I am trying to change position and rotation of parts while in-flight. My approach was to use Part part; Vector3 newPosition = XXX; Quaternion newRotation = YYY; part.transform.SetPositionAndRotation(newPosition, newRotation); This code has the effect, that the part gets set to the new position and new rotation for a single Unity-frame. Beginning with the second frame, the part is reset to its previous position and rotation. I conclude, that there is a functionality in place to reset the values, but I am unable to find information about this functionality. I also searched the forum and this thread for "part position transform", but could not find any information about this. I would appreciate it, if someone could point me in the right direction of how to change the position of parts.

Can you please be a bit more specific? Saying that something is incompatible does not help much identifying the problem. Have a look at this post for the best way you can help others to help you.

Until Meithan comes back, you can view the charts with the DLC-updates from @The-Grim-Sleeper here: https://mhoram-kerbin.github.io/engine_charts/

Are you sure, that you posted a screenshot of the right part, because this part seems to have a title and a description. I am aware that a few other parts are missing titles and descriptions.

Yes, this is the right button. It is the same for me. According to https://github.com/UmbraSpaceIndustries/Konstruction/blob/eecfe00077c8c9f643b55d821c15fcaa53ee26f9/FOR_RELEASE/GameData/UmbraSpaceIndustries/Konstruction/Parts/Konstruction_Orbital_Shipyard_250.cfg#L70-L77 you will need 4000 MaterialKits for deploying the "KS-250-O KonStructor - Orbital Shipyard".

Currently it is only possible to transfer crew into it, after it is deployed. So you need to deploy it (and switch to the KSC and back to the vessel) in order to be able to transfer crew into the KonStructor. This patch fixes this problem: https://github.com/UmbraSpaceIndustries/Konstruction/pull/97

I would venture a guess, that this is an oversight. I am not using CTT to check myself, but if you tell me, which parts should be unlocked by which research, I could offer to create a config file for you.