nathan1

I'm sure I'm not the first to think of this, but since the rocket is an F9 they need to name one of their barges "F5 for safety."

Part of the complication isn't just calculating the values but making sure that the information is displayed in a way that's understood by new players. Specifically vacuum dv vs atmospheric dv is a complication I haven't seen mentioned yet in this thread. If a new player is told their rocket has 3400m/s dv because their rocket has 3400m/s vacuum dv, but they fail to make orbit around Kerbin then they might conclude something's wrong with the game (especially if they're not the kind of player who frequents forums or downloads mods). Including a dv readout in stock is an entirely different beast from including it in a mod: you know someone who downloads a mod is the kind of player who will look outside the game for more info to at least some extent (because they downloaded the mod in the first place), but some players who play stock wouldn't even think to look on a forum or download a mod if something isn't working. Mod-downloading forum-goers are not hurt by having to download a dv-readout mod, but a half-hearted dv implementation in stock could be misleading and confusing to new players. Note that I am not arguing that Squad shouldn't add a dv readout. I'm only pointing out yet another complexity that Squad will have to take into consideration for implementing it. I agree that it should get added at some point, but I have no problem with Squad prioritizing other things.

I've re-tested with the latest 1.1 KSP pre-release and it's still working for me. One thing I didn't think to mention before: the button only shows up on the map view.

The 1.1 version will use the stock toolbar. Make sure that you've installed it to the correct location and check the logs to see if there's anything wrong there. I haven't downloaded the newest 1.1 pre-release build yet, so it's possible that something changed in KSP that broke the mod. I'll test it out again, but probably won't have time until Sunday.

Version 1.5.0 is now available: -Updated for the KSP 1.1 pre-release. Note: do not use this version with KSP 1.0.5. It is only for the KSP 1.1 pre-release.

Aha, I see that part now. I had scanned the post, then searched for "vector3d" and didn't see it before... I should read more carefully.

Looks like some of the KSP code has moved to a different DLL. The Vector3d struct is in KSPUtil now.

The launch failure in this Kottabos video. His reaction is priceless.

The problem is as Val has described: if you perform two 700m/s prograde burns at Kerbin then you are no longer orbiting Kerbin and there's no way to wait another Kerbin-orbit and perform a third burn (you are escaping Kerbin and you're going to be orbiting the sun). There are multiple ways to deal with this: -Use the "undo" button and keep trying different numbers until you get something that works for you. -Specify the maneuver-splitting by apoapsis instead of by delta-v. -Use the "repeat" option instead of specifying multiple numbers manually (the mod will figure out how many times you can split the maneuver with that amount of delta-v and add the remaining delta-v to the last maneuver). Personally I prefer to keep my apoapsis below the Mun before the final ejection burn so that I don't get any encounters with the Mun throwing everything off. Also, if you raise your apoapsis a lot before your ejection burn then your orbital period can get really long, and your final ejection can be way later than your transfer window if you didn't plan and split the maneuver far enough ahead of time (with an apoapsis way above the Mun "far enough" could be a month ahead of time or more). The 1.4.0 update now includes an error message when the input values cause an ejection from the body you're orbiting prior to finishing all the apoapsis-raising maneuvers. In this case it will add the remaining delta-v to the burn that causes ejection so that you will get an ejection that actually brings you out to your destination.

Version 1.4.0 is now available: -Added error messages when the input values cause early ejection from the original SOI or an encounter with another SOI.

Transfers work fine with the mod: that's the use case I used when making it. You just have to make sure you set up your orbit far enough ahead of time. If you set up the maneuver far enough ahead of time (i.e. days ahead of time, not just 30 minutes) then it will automatically adjust the maneuvers so that your final ejection is around the same time as the original. It also handles inclination changes. What is less efficient is when you do a prograde burn to change your orbit and then a separate normal burn for inclination, but there is no efficiency lost from splitting a combined prograde/normal burn into multiple burns. I've used the maneuver splitter to convert a direct-transfer from Kerbin to Moho (which included a large inclination change). Performing the burn in multiple orbits after splitting the maneuver had almost the exact same periapsis around Moho as the original single-burn maneuver and did not cost more dV.

This is probably possible with a PatchedConicSolver and an OrbitDriver (without needing a proto vessel), but I'm not sure whether the orbits would be displayed on the map. You could always just display the orbital parameters manually if needed.

A new bug is introduced with this version: supplies consumption scales up with the Unity physics time-step (instead of consuming supplies once every second it's consuming supplies every FixedUpdate - so supply consumption appears to be about 25x higher in this version on my machine, consuming more than 1 supply every minute). The check referred to in this comment in the source appears to have been moved after supply consumption and needs to happen before instead (as it was before this version).

I had based it on the dev branch, but the dev branch has moved on. I'll rebase it so it's up-to-date. Unfortunately there's a pretty big bug with my changes currently: if you run out of supplies during catch-up then the negative effects will not get applied. I know the exact line of the code that's the problem, but the root of the problem is subtle differences for detecting that catch-up is in progress (so that it doesn't kill your kerbals during catch-up if your vessel/base is in the middle of creating resources at the same time as they're being consumed) between what the code used to do and my changes. For now I'm mulling over what I can do to fix it... A suite of tests is a good idea. Were you thinking something automated, or a list on the wiki? I'd recommend keeping it as concise as possible; if it's short and to the point then it's a convenient check-list for testing, but if it's long and verbose then people will avoid it and it will quickly become out of date.

I've made a change to have life support consumption calculated from the values stored per-kerbal instead of by values stored per-vessel. It's a pretty straight-forward change, but I'm still testing it (although it seems to work fine so far). See the branch here and the commit here. Feel free to compile it and help me test it out (just remember to back-up your save). If I don't find any issues I'll put it into a pull request to see if RoverDude wants to incorporate it. For those interested in implementation details: RoverDude already stores a "LastMeal" (timestamp) per-kerbal, but also stores a "lastUpdateTime" on each part with a life-support module. Actual consumption is currently keyed solely on the lastUpdateTime, so when vessels dock, kerbals are transferred, etc, there's room for weirdness. I changed the consumption to be calculated from the kerbals' LastMeal values.

The docking ports from this mod are not working for me in KSP 1.0.5. They will not attract or connect with each other or with stock docking ports. I can also confirm what others have reported about the cargo bays: the "deploy limit" is not limiting how far the bay doors will open but is limiting how much they will close instead.

The mod is designed to split a maneuver node so that you can perform part of the burn on each of multiple orbits. You can use it for any maneuver node--you don't have to use it for transfers--but I'm not sure what kinds of maneuvers other than transfers you'd actually want to split in this way. Did you set up your original node very far in the future? If you split your maneuver into multiple nodes then you have to make a full orbit between each burn. If your original maneuver node isn't far enough in the future then the mod can't put the prior burns far enough ahead of time for your final ejection burn to be around the same time, so that will have a big impact on your transfer. For example, if your orbital period is 30 minutes and after splitting your first burn gives you a 1 hour period, your second burn gives you a 6 hour period, and your third burn is the ejection burn then the mod has to place the first burn and the ejection 7 hours apart. If your original node is 30 minutes in the future then the split nodes will be moved multiple hours, but if your original node was 8 hours in the future then when the mod splits the nodes it can put the first one about 1 hour in the future and have your final ejection be around the same time as it was originally. If your maneuver node is far enough in the future you can also play with the values to get the timing of the final ejection as close to your original maneuver node as possible (the first maneuver the mod creates has to be an integer multiple of your orbital period away from your original maneuver node in order for it to be in the correct location. From there the remaining maneuver nodes are constrained by the orbital periods resulting from each of the burns). Re-using my example from above: the mod can put a new node 14 orbits (7 hours) ahead of your original node, then the next node on the next orbit (6 hours ahead of your original node), and the final ejection will be right around the time of your original node. But if your second burn gives you an orbital period of 6 hours and 15 minutes then the mod can't place the first node anywhere that leaves your ejection anything less than 15 minutes away from your original maneuver node.

Since the new maneuver nodes get shifted to be earlier than the original maneuver node you can end up with a new maneuver node only minutes or seconds in the future. If you're not paying close enough attention to how much earlier the new nodes are you could easily fly past the new nodes without burning at all. There's no reason for me to prevent the user from undoing the maneuver node changes and re-applying. Can you provide the kOS script that does that?

I'm glad to have been able to introduce it to you. Precise Node is one of my top download priorities when a new KSP version comes out. Thanks for the suggestions; I think I can implement something like that. As for the undo, I thought I already checked if the nodes were in the past, but I guess not. I could at least make the undo button remember what the state was immediately prior to clicking it, so you can undo your undo.

Awesome, thanks! I also just released version 1.2.0: -Maneuver splitting can now be specified by deltaV, orbital period, burn time, or apoapsis (splitting by burn time requires that you have installed KER).

Version 1.1.0 has been released. This version adds support for using either the KSP skin or the Unity skin (the new default). To change the skin you can modify the settings.cfg file in the NodeSplitter directory, or you can add a Module Manager patch in the root of your GameData directory so that your settings aren't affected by updating the mod again later: @MANEUVER_NODE_SPLITTER { @SETTINGS { @skin = ksp } }

Hm, I had some ideas for improvements, but I hadn't thought about providing other ways of specifying the split... I like the ideas. I'll have to look into what I can do there.

I think Mod Actions will do what you want through action groups.

Yeah, I was kind of bored and perusing the forums when I saw someone ask about it and thought "hey, I've done that manually in game with Precise Node... I bet I could make a mod to automate the process!" I've never heard of Precise Maneuver before now; I'll have to look into that one.

I created a mod that behaves similarly to how you suggested available here. You can enter how many burns you want and how much delta-V you want for each burn and it will split your single maneuver node into multiple (handling non-prograde burns as well).