mhoram

Great info. Thanks for making me see what I did wrong. This basically means that in the following picture on the orbit the duration for the path through the green area is shorter than the duration for the path through the red area. (Edit: see post below) And since you asked, yes I would like to get my hands on the script you used.

@jbakes: If you know the specific orbit (meaning you know Apoapsis and Periapsis) then you can calculate the orbital period. (See https://en.wikipedia.org/wiki/Orbital_period) @paul23: The longest possible time the ship spends in the shadow is when the apoapsis of the ships orbit is in the shadow. The calculation for this shadow-duration is explained in http://wiki.kerbalspaceprogram.com/wiki/Orbit_darkness_time or you might have a look in chapter 9.2 of my physics of KSP documentation.

In the Dev branch there is only a single small PR from me. Just thought that since you do all PR via the Dev branch, I put it also here.

May I ask you to merge snjo/DEVELOP to snjo/master for the final release.

As a reference: a while back it was also experimentally established that the position does not matter. http://forum.kerbalspaceprogram.com/threads/75916-If-something-has-an-SAS-torque-of-20-what-does-that-actually-mean

Here is a comparison of the different LS mods: http://forum.kerbalspaceprogram.com/threads/108160-Life-Support-Discussion-and-Comparison-%28updated-9-29-2015%29 I prefer USI-LS to TAC-LS, because it does not clutter the resource panel that much.

@Starslinger999: Sounds like an installation issue. From a few pages back:

@rose4100: Here are the numbers: https://github.com/BobPalmer/MKS/wiki/One-Kerbal

Updating the readme would be beneficial for others who try this. Thanks for your insight about PartModule and vessel reloading.

Now I was able to get a clean, new project working in Visual Studio 2013 Community. The thing I had to do was to manually increment the version number in the file Properties/AssemblyInfo.cs from [assembly: AssemblyVersion("1.0.0.0")] to [assembly: AssemblyVersion("1.0.0.1")] and for each compilation after that. Or as I just found out how this can be accomplished more easily: Replace in the file Properties/AssemblyInfo.cs [assembly: AssemblyVersion("1.0.0.0")] [assembly: AssemblyFileVersion("1.0.0.0")] by [assembly: AssemblyVersion("1.0.*")] and get it incremented automatically. Now I have another question: From what you have learned during your implementation, do you think it is feasible to implement a "ReloadablePartModule" for the PartModule class in the same way as "ReloadableMonoBehaviour" works for MonoBehaviour?

It is good to know, that you came to similar results. I did not stop the graph below 100km ... It is just that below that altitude a two-burn strategy (with an 80km altitude Periapsis) makes ÃŽâ€V-wise almost no sense, so the graph points up to indicate a preference for single burn.

Try the addon RCS Build Aid.

Here are my results about when to use a single-burn vs two-burns. (More details on original post)

Thanks for letting me know that I am on the right track. There are other classes in my project - maybe they interfere. I will report back after digging deeper into this.

A while back there was a similar discussion. For reference it was this post and the ones afterwards: http://forum.kerbalspaceprogram.com/threads/75542?p=1072850&viewfull=1#post1072850 It was also discussed when two burns ("lower Peri to LKO" & "ejection burn at Peri") are more efficient than a single burn.

I am not sure if I understand the mechanic of this mod correctly. I try to get a simple mod (display debug info) working [KSPAddon(KSPAddon.Startup.SpaceCentre, false)] public class MyTestDebug : ReloadableMonoBehaviour { public void Start() { Debug.Log("MyTestDebug: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"); } } When I change the contents of the log-message, recompile, reload plugin then still the initial debug message appears. According to the log-messages, the new plugin is reloaded [Log]: KramaxPluginReload.PluginClass.CreateInstance create object MyTestDebug_2_. Is it essential for this to work, to use "AddComponent" or is there something else I am missing?

The wiki contains information about that topic: http://wiki.kerbalspaceprogram.com/wiki/Experience

@RyanW1019: There is no need to actively generate Mulch, since Kerbals only require Supplies to stay alive and they produce Mulch. Fertilizer is another method for generating supplies from Mulch, but I assume that this was left out, since via Dirt->Orcanics->Supplies you already can produce an unlimited amount of Supplies.

Having four tanks T1, T2, T3, T4 and connecting them in this configuration - Fuel line from T1 to T2 - Fuel line from T2 to T4 - Fuel line from T1 to T3 - Fuel line from T3 to T4 creates problems.

The simplified mechanic looks nicely balanced and streamlined. Good job on picking this abstraction level. But I will stick with UKS, since I enjoy the complexity.

Do you have any tanks of the following configuration: T1 -> T2 | | v v T3 -> T4 The two different lines from T1 to T4 are problematic. Best way for us to check would be if you could provide the .craft file. Here is a thread explaining all fuel flow rules: http://forum.kerbalspaceprogram.com/threads/64362-Fuel-Flow-Rules-%280-23%29

Looks very promising. Have to try it.

Regarding the placement of the refueling station, this thread contains a lot of information: http://forum.kerbalspaceprogram.com/threads/75542

I just tested this and the minimal requirements to run USI-LS is ModuleManager. Probably this issue did not come up before, because most people who use USI-LS also use UKS which comes with MM. @RoverDude: It would probably be best to aviod future confusion if you mention the dependancy on MM in the OP and on your download site, since this is nowhere documented.

Until now I always misspelled the Oberth-effect as Orbeth-effect. Why did nobody tell me? ;-)