nathan1

The bug tracker does not yet have the new console patch version listed, but I've posted two new bugs that I've found there.

I've been using the Simplified control scheme, and it took me a bit of time, but after getting used to it I like it for the most part. I have encountered a few issues, which I've logged to the bug tracker: Controls become unresponsive using Simplified control scheme Camera resets position/zoom in Simplified control scheme Inconsistent navigation in Simplified control scheme "Look around" doesn't always work in Simplified control scheme Missing controls in Simplified control scheme Cannot open radial menu when part action window is open in Simplified control scheme Also, a bit of feedback that is not specific to the Simplified control scheme: Separate axis-inversion

Maneuver Node Splitter

Hey, sorry I didn't see your question sooner. Can you provide before+after screenshots showing how much the predicted trajectory has changed? Also, is this a stock solar system or are you using Kopernicus? A few possibilities that may be causing your problem: You may have an encounter with the Mun or Minmus that throws your final trajectory way off. Be careful to check for that. The final trajectory can sometimes be very dependent on ejection timing (depending on where your destination is and how precisely you want to preserve your planned trajectory), and even if you've planned the original maneuver node well in advance of the final ejection the split can move your final ejection by 10 to 20 minutes. When you make the split there will be a green text alert that says how much time difference there is between the original maneuver and the final ejection maneuver. When I have trouble with the final ejection not lining up correctly I'll use an iterative process of adjusting the final split (i.e. the last maneuver prior to the ejection maneuver) by a tiny amount until the final ejection happens within 1 minute of when it was originally planned. Something like the following: Set up the split how I want and apply it. Take note of how much time difference there is for the final ejection, and see how good the trajectory looks. Undo the split. Adjust the final split by a tiny amount (usually 1m/s) and re-apply. Check whether the time difference is smaller than before, and how good the trajectory looks. If the time difference is more than a minute go back to step 3.

The Earth, Moon, and the Sun all orbit the center of the milky way, so really the moon is in orbit of the milky way, not the sun. I mean, over galactic timescales the orbit of the Moon around the center of the galaxy is nearly indistinguishable from the Sun's orbit.

Yes. Probably, but I've never tried. Monophonic's idea of creating a translation would work, at least. I'm trying to understand what you're getting at... are you asking to unify construction through VAB/SPH and construction through EPL/GC? If that's the case I would think altering EPL/GC so construction time/resource costs are tied directly to the funds cost of parts (and then possibly adjusting the funds costs of parts) would accomplish that. Assuming you are talking about a replacement for KCT (relating to your "simpler alternative to KCT" comment), if you don't require construction to actually take time then I think an important point of KCT is missing. For example, if you have KCT and a life support mod installed then you have to consider what your options for rescue missions are before you launch, but if construction is instant then you don't. I think severely limiting funds from contracts combined with a "drip funds" mod to force you to not just launch all your missions within the first month of your career is a good way to play, but I don't think it really replaces what KCT does. Regarding AltFunding, it currently allows scaling of funds received by time or by reputation. Scaling by building upgrade progress seems like an interesting idea. I still need to check whether AltFunding is working or has any bugs in 1.3 anyway...

I found another Juno picture of Jupiter (this one of the north pole) that includes two different color-enhancements side-by-side: https://images.nasa.gov/#/details-PIA21031.html. It looks like a good example of the kind of difference color enhancement can make. From the description there:

I'm not sure if this is related, but it appears that physics timewarp is too fast with lossless physics enabled. Using a wall clock to compare I'm seeing game-time progress at the square of the warp rate compared to real-time (e.g. at 2x physics warp 4 in-game seconds pass per 1 real-world second instead of 2 per 1, at 5x physics warp 25 in-game seconds pass per 1 real-world second instead of 5 per 1, etc). To test I noted the time in KAC and on my wall clock when I enabled time warp, then waited for 30 seconds (real time), then exited time warp and noted the time again in KAC.

It depends on what you mean by "rebalance." The thread started with a simple question about the amount of fuel in tanks based on volume, and to my knowledge there is not a single-download easy-to-use MM patch that makes the stock parts have consistent balance in a stock-like way (SETI-redesign does not do that. It re-arranges the entire tech tree, among other things).

@TriggerAu I've made a pull request on github to make the length of time a tooltip is visible configurable (there was already a variable for it, but it wasn't exposed in the UI or persisted before).

What I want is a visual-only version of this mod. In other words: All vessels can still talk to each other (as in stock). Only lines between vessels on the same network are shown (to de-clutter the view). Each network has its own color for the displayed lines. The active vessel (or selected vessel in the tracking station) is the one exception: the whole path to the KSC is shown for that one vessel regardless of networks.

@Alshain The patches that duplicate stock structural parts for other sizes (e.g. duplicating the 1.25m 6-way hub to 2.5m, etc) don't update the bulkheadProfiles for the parts, so the parts don't show up correctly when filtering by cross-section.

If you're looking for an example of an atmo curve with tangents, the aerospike has the most complicated one that I know of: atmosphereCurve { key = 0 340 -50 -73.71224 key = 1 290 -21.23404 -21.23404 key = 5 230 -10.54119 -10.54119 key = 10 170 -13.59091 -13.59091 key = 20 0.001 }

Version 1.7.0 is now available: -Compiled for KSP 1.2.2. -Fix for splitting maneuvers that include a normal component. The fix is for a bug I didn't notice before that looks like it showed up with KSP 1.2.0. Splitting maneuvers that only include a prograde component are not impacted, but in 1.2.x prior to this fix splitting a maneuver that includes any delta-v in the normal/anti-normal direction will not work correctly (the inaccuracy increased with the proportion of the burn that was included in the normal component in the original maneuver node). This build fixes that problem.

Jebediah Announces Munar Contest In celebration of almost successfully launching a rocket, Jebediah Kerman has announced a contest to send two lucky kerbals to the Mun. The winners will be launched on top of a Kerbal X for a one-way trip including in-flight snacks. Initial reactions are mixed, as some kerbals are overheard complaining that they "were really hoping it would have been Minmus." Unnamed sources say they are "extremely disappointed" that Jebediah is only using stock parts for the contest rocket: "I've got a really good parts pack, and I'm just not sure why [Jebediah] won't use it." Spirited discussion has also ensued regarding the impact an additional attempted launch will have. One kerbal distressed at the introduction of another launch commented that "if the flight [attempt] numbers get past 5 I'll have to start counting with my other hand, too!" It is unclear how Jebediah plans to proceed if eventual flight numbers exceed the fingers on both hands. Kerbals have only a few weeks to enter the contest, and some confusion has arisen regarding the contest details, but some enterprising individuals have already submitted entries. Allegedly Valentina has submitted a picture of Bob's face for the "comedy" category, which Jebediah has ruled is "not in the spirit of the competition."

I personally don't like Python, but it's pretty widely used in various domains, so it's a good choice of language to learn if you're looking for a job. But the most important part isn't which language you choose or how technical your book is; the most important thing is whether it keeps your interest. You can always switch languages more easily than learning how to program in the first place.

What about "ShowAs:Toggle" and "ShowAs:Plain" or something similar?

Version 0.3.0 is now available: -Updated for KSP 1.2 -New UI -You can now change the configuration from within the game. -Historical payments and the next ten upcoming payments are shown in the budget window. Note that the new UI is not finished (I'm especially not happy with the UI for changing the settings), but I wanted to get a release out. Everything is functional, and the new UI is still better than the old one. I'm not sure exactly what changes I want to make to the UI, so feedback is welcome.

Looks like Z-Key may not have updated his wrapper code for blizzy's Toolbar. There's a conflict that happens with Contract Configurator. See: And:

I'll have an update for 1.2 with a new UI up this week. You will be able to see a list of how much money it's given you historically (not just the most recent payment).

Version 1.6.0 is now available: -Updated for KSP 1.2 -Includes a version file for KSP-AVC (thanks Henry Bauer!)

Is the button also available in flight? It would probably be useful there, too.

I use multiple maneuver nodes more often for figuring out what I can do with the delta-v I've got rather than to actually burn them as planned. Having an idea what the upcoming parts of the mission are going to cost helps with deciding whether or not to try to squeeze in some extra encounters/landings on an in-progress mission. Edit: looking at the way you've got things grouped into sections you should be able to create a section for each intercept to add the buttons. So after the "orbit" section you might have a "Mun Flyby" and then a "Minmus Flyby" section if the current trajectory flies you past both.

Some suggestions for features: The ability to add a maneuver node after an existing maneuver node (e.g. if I have one maneuver node that raises my apoapsis then I just click a button to add a maneuver node where the new apoapsis will be). The ability to add a maneuver node at the periapsis after an SoI change (e.g. I'm on my way around the sun towards a Duna encounter; I click a button to put a maneuver at my Duna periapsis). The combination of the two above (e.g. I'm still in orbit of Kerbin with a maneuver to send me to a Duna intercept; I click a button to put a maneuver at my Duna periapsis). For the second you'll probably need to iterate through the list of encounters to build out the menu dynamically (for when there are multiple encounters). Also, I've done support for Blizzy's Toolbar before, so I can put together a pull request for you once 1.2 is out.

If the original maneuver node isn't far enough in the future then it will just plot the new maneuver nodes in the future (making the final departure date later), so that shouldn't be an issue. Regardless of whether it should be an issue, I tried to reproduce the freeze by splitting a maneuver node in the near future (and also by splitting a maneuver node that was already in the past), and it's not freezing for me. Is the freeze happening for you every time you try to split nodes or only sometimes? What are the specific values you're using for the split? It's possibly input validation... if you entered something I didn't anticipate maybe it's causing the mod to go into an infinite loop. If that's the case then I can fix the input validation once I know what kinds of input are causing it.