dmsilev

The point is that the current game really is three presets with the same underlying game. Sure, it calls it three different modes, but that’s really just semantics; 'science' and 'sandbox' are two endpoints on the 'amount of science points available at start' axis. 'Career' adds in a separate axis, 'funds available' which for the first two is implicitly set to Really Big. I think you have a stronger argument for 'no options' with the variables you started with such as the communication system, or for that matter the 'hidden' option of AutoStrut, as those have the potential to change how craft are built and flown in deep ways that sticking to a funds budget simply doesn’t.

While I like the basic structure of what you outline, how is it "fewer options" than the current setup? You've replaced three discrete points with a broad 2-D continuum of "start-up funds/science", which is a vastly larger set of values for the player to choose from. Sure, you can add a few presets, but that then is exactly equivalent to what we have now so you haven't changed anything. (also, one thing Career mode has that is not addressable by adding startup science/funds is Kerbal experience. The only way to get a Pilot who can do a hold-orientation-to-manuever-node in Career is to actually fly them around to a bunch of places. That's a minor point, and one could certainly imagine allowing Kerbals to "buy" experience in a training facility, with a cost in funds and/or science)

In the interview that was aired yesterday from PAX, the devs said that (a) they were planning to release "several" videos showcasing various parts of the game and that (b) those videos would be coming out "every month or two". Folding those together, the most optimistic timeline for release would be 4-5 months from now, so late summer/early fall, and quite possibly next winter. Still within FY21, but not "April".

So, let's take "no options" beyond reentry heat and comms and ask the following question: Does every player have to play in sandbox or in career mode?

Thanks! I tried this with Parallels and a W10 VM. I put the CKAN executable in the KSP directory (in my Steam folder on the Mac volume), navigated to it in Windows Explorer, ran it, and everything Just Worked (tm). KSP itself was installed as a Mac app, so I'm sure trying to run that through the VM would have failed miserably, but that's no big deal.

If I wanted to run the Windows version of CKAN inside a VM, giving it file-share access to the Mac volume with the KSP & CKAN install, is there a straightforward way to do that? What I mean is do I just have to copy some config files from somewhere on the Mac to some location on the Windows volume, or can I point the Windows CKAN instance to the appropriate files on the Mac volume directly?

Can confirm that this works. Now I just need to go through my mod list and figure out which one is blocking me from clicking on anything on the main menu. Sigh. Edit: Updating ContractConfigurator to the 1.8-appropriate version did the trick.

I have this problem as well (2016 MacBook Pro, Catalina). Reverting to 1.7.3, everything is fine, reinstalling 1.8.0 it's back. As noted, putting the screenshot utility in the foreground causes the effect to go away...

Same here. One ~3 hour time warp yielded roughly 2400 messages coming from several Goo and Seismograph experiments. I couldn't even open the message window to delete them (got a busy cursor icon for several seconds, and then the window didn't open); had to edit the save file directly. Basically, until it's fixed the game is unplayable for me.

As an alternative to copy/paste, can you tie multiple actuators to one timeline track?

You mean something like this? *------====== | =======------ *====== | =======------ *====== | ======= where the load is the *, and the cylinder of piston 1 attaches to the base of 2. That allows the load to reach anywhere along 2's length, but it has the limitation that the total length of the construct changes depending on where you want the load.

You could fake it with two opposed pistons: one expands while the other contracts, with the load in between. A sliding rail does let you translate pretty much end to end, whereas a piston has a lot of dead length, so a true rail would still be better for a lot of applications.

Thanks! That got me most of the way there. It's now sort-of functional. I say 'sort of' because all of the buttons along the top row (Launch KSP, Refresh, etc.) are grayed out. The list of mods is present and I can interact with that just fine, and if I select something for installing or updating,, I can switch to the changeset tab and apply the changes, so it is functional. Just annoying not to be able to change the display filter mainly.

I'm having an issue with the latest version of CKAN on a Mac and was wondering if anyone had any pearls of wisdom to offer. When starting it up (via either the CKAN.app bundle or by running Mono in a terminal window), it starts up, and then immediately freezes in the 'updating repositories' stage (see screenshot inside the spoiler block). It stays there indefinitely, without even the progress bar thingy moving, until I kill the process. I've tried a couple of different versions of Mono (5.4.x, as linked from the 'install CKAN on OSX wiki page, and the latest 5.6.x stable version) without any difference. During the startup, the first tab (with the installed mods) flashes briefly, and then it switches over to the updating tab, so it at least is doing something. Any thoughts or things to try would be greatly appreciated. CKAN 1.25.4, OSX Mojave.

Wonderful, thank you. I don’t usually mess with the dev builds, but I think I’ll make an exception here.

Thanks for the response. With regards to the UX problem, perhaps expose only a few options by default (for the transfer maneuver, that could just lock the time choice to 'optimum' plus the create/execute buttons), and then a "advanced mode" button which is deselected by default but when clicked enables the full menu of possibilities. An automatically-growing window (similar to how the Utilities window grows when the Autostage checkbox is selected) might be the way to present that. In that advanced mode, a checkbox (deselected by default) for "prograde/retrograde only" would recover the old behavior. The mid-course correction burn can be done quite easily already (via the fine-tune closest approach maneuver type), so if you wanted to offer a simple three-burn trajectory, you could have the code offer to chain the two nodes together. Honestly though, I wouldn't bother; my experience has been that the second burn usually is a combination of a plane change plus some minor tweaks to the trajectory due to the initial burn being a tiny bit off, so you don't want to calculate the second burn until after the first one has completed and you know how the actual trajectory compares to the nominal one.

I've been playing around a bit with the new bi-impulse transfer function, and it would be nice if there was an option for the old Hohmann transfer functionality as well. Sometimes, a three-burn solution is just better. To give a concrete example, I tried a fairly standard Kerbin->Minmus transfer just now. With the 3-burn system, you do a ~920 m/s initial burn, then a plane change somewhere along the way (usually about 10 or so m/s, though it varies) and then the capture burn. With the bi-impulse, it was giving me a transfer burn of ~11-1200 m/s (using the "optimum time" setting). It was also picking a decidedly higher-energy transfer, taking maybe 6 days to reach Minmus, and hence needing a bigger capture burn as well. In all, I'd estimate it was giving a solution that was maybe 300 m/s less efficient than the previous setup, so call it 25% more dV. I assume that it's a combination of the higher dv cost of low-altitude plane changes (even when combined with the big prograde burn) and more importantly the solver getting stuck in a local minimum in parameter space. The latter is a Hard Problem to solve (I deal with nonlinear optimizers from time to time in my day job, so I'm very sympathetic to the difficulty), so being able to fall back to a numerically-simpler algorithm might not be a bad idea.