Lord Aurelius

On the topic of making life support optional, I support this in sandbox mode and custom game modes where you fine tune the game settings to your liking even if it throws the balance off. However, like has been mentioned life support is a critical balancing mechanic for manned missions, so it (and comm networks) should be enabled by default when you pick one of the standard difficulty options. This also means the game should have some tutorial contracts/missions/whatever to show the players upfront that they need to pay attention to these things rather than giving them a nasty surprise later.

I personally think life support is as essential to the core game balance as EC is, as described at length in the OP. However I do agree that any life support implementation needs to find a way to avoid tedium or it just becomes annoying. Some good news on that front, in the recent PC Gamer article linked in another thread the devs specifically addressed this and said it would be possible to automate supply runs after you've done it at least once yourself.

The whole rush to put KSP on consoles was really strange, and resulted in a lot more problems than just a buggy console port. It also resulted in a mad rush by the devs to push an unfinished alpha out the door as 1.0, and the fallout likely resulted in a lot of dev burnout and departures. It's only fairly recently with all the work put in by the new devs that the game has started to feel like it's actually out of early access now. It's a shame too since I understand that not everyone has a decent PC and would prefer to play on consoles, but the reality is that good console ports are a LOT of work and far too many small studios make the mistake of spreading their limited dev resources too thin, resulting in not only a bad port but also hurting ongoing development of the original game. It's all water under the bridge now, but I still remember how frustrated and disappointed I was with the devs through this whole fiasco. Anyways, back on topic, I second the recommendation to just get KSP for PC. The minimum system requirements are actually surprisingly low, and I've been able to do a lot on just my ultrabook (although I strongly prefer my desktop). Not to mention how wonderful the world of KSP modding is.

So I was just playing the new update and noticed that the new magnometer boom weighs a whopping 0.5 TONS. My first impression is that this must be a typo, as that much weight on the side of a small Voyager-style probe pretty much makes it a non-starter since it completely throws off the center of mass. It's also shockingly out of place compared to the mass of the other science experiments of similar size. What do you guys thing? Is this a bug that needs to be reported?

I say yes to both. KSP1 already has multiple fuel and engine types (ion, monoprop, nuclear, solid, LF) so adding a bit more variation to liquid fuel/oxidizer combos with different strengths/weaknesses (like kerolox having engines with the best thrust and fuel density, methalox being a happy medium, hydrolox having the best ISP with poor fuel density, hypergolics with the most compact and cheapest/lightest pressure fed engines for space, etc) would give some nice variety without overly complicating things. For life support, I still argue it's a critical balance feature that is absolutely necessary for sensible game progression (something KSP1 largely lacks) and to make probes relevant. Doesn't need to overly complicated, but most definitely should be a core feature of KSP2 (with the option to disable it for sandbox or easy, unbalanced career).

I think the solution for this is a combination of a solid, story driven campaign mode (something like a series of scenarios that cover all common mission profiles) that acts as a disguised tutorial and is heavily featured on the main menu as the "correct" way to start a new game for beginners, and also a series of more explicit training scenarios (i.e. tutorials) that are easy to find and include text explaining how things work. Both these modes need to be backed up with a MechJeb like system. This is how real rockets are flown, they aren't flown by hand. I very nearly burned out on KSP's learning wall before I discovered MechJeb, and it's what actually made the game fun and enjoyable for me.

I like the overall idea, although I would probably decouple science points from research entirely and have research done entirely with funds. In terms of continuous transmission, I like the idea of long term experiments so long as the time to get credit isn't too long (minute or less with high time warp). Also really like the idea of some planet details being hidden until an appropriate experiment has been done, although I would probably start the game like KSP1 does with all the planets discovered and orbits/basic info known that could be realistically known from ground based telescope observation. Info like what the planets actually look like up close/height maps and temps/detailes gravity would require sending a probe to get. I would also like to see some science experiments be prerequisites some technologies. For example, early upper stage/vacuum engines require atmospheric pressure data on Kerbin, and crew capsules/probe cores/orbital hardware requires temperature/radiation experiments.

Like others have said, I don't see what the problem is. KSP1 has had a VERY good run and has been supported far longer than I would have expected, but it also has some fundamental flaws in its core game design that are best fixed going forwards with a new game rather than continuing to try to update KSP1 forever and maintain save compatibility. Also, it's not like KSP1 is going anywhere. People will still play it and modders will still mod it long after the devs have released the final patch. On a related topic, I generally ignore hype. It's awesome KSP2 is being developed and it's fun to watch the trailers and I hope it's an amazing game, but at the end of the day it's not worth getting worked up about something like a game, especially since it will have 0 effect on what the devs ultimately deliver.

Wow, this discussion got heated in the last few days since I last checked. Personally, here's how I would like to see game options handled in KSP2: -All game modes should use a common base game mode with minimal code branching (prefer using 0 multipliers to turn features off for example) -There should be quick buttons to start at least a new default career and sandbox game (with default options of no LS or commnet unless chosen) without messing with sliders, and a custom game mode that exposes sliders and the ability to toggle features like LS, commnet, reentry heating, etc (even if the "toggle" is just zeroing a slider). -Slider presets and world states should be able to be saved and shared to create new game modes -Default Career mode should be what the game is balanced around to provide a cohesive experience and is the recommended way to play without messing with sliders, LS and commnet should be enabled by default (with reasonably forgiving settings) with an easy way to turn them off if they're not wanted

I don't agree with this petition. The devs need to focus on doing KSP2 right, not rushing out an early access version which will end up hobbling future development.

Although early access has enabled the development of many games that otherwise wouldn't have been made, it's also a pretty poor way to make a coherent game. It incentivizes short-sighted changes to attract new customers at the expense of long-term game coherence, and because devs have to keep players happy throughout development it strongly discourages big, game-breaking changes (i.e. balancing, removing some placeholders or game systems that aren't working as intended) that could potentially affect save games, but at the expense of making the final product worse. I'm very glad KSP1 exists, and wouldn't have been made without early access, but it has some unfortunate baggage from it as well that KSP2 would be best to avoid. That said, an open beta of KSP2 would be very much appreciated prior to launch.

Kerbals definitely need to have a greater role in KSP2, we need to care more about them, and we should be able to fully customize our Kerbals. For greater roles, obviously more ground science experiments make sense, along with KAS style interactions. Also maybe have large colony parts like rocket factories and hydroponics facilities that require a certain number of Kerbals to operate. Maybe even some skill trees for Kerbals that give bonuses to science returned, parts that can be fixed, and piloting skill. Or maybe they're a showman and generate additional reputation for everything they do. For customizability, have a Kerbal creator on the main menu where you can create your "hero" Kerbals that can be used for a career, or even show up randomly in the list of available Kerbals to hire. This creator would allow appearance, personality and possibly even skills/other bonuses to be customized. These both lead directly into caring more about them. If you've got an experienced, high level Kerbal you'll want to keep them alive. Also maybe have reputation penalties for killing Kerbals (just like RL), providing further incentive to give those little guys extra TLC, and maybe send an unmanned mission first to verify they're not being sent to their doom.

It doesn't really matter how sandbox is implemented behind the scenes, there just needs to be a simple way to enable it. If there's a one-click button to start sandbox mode which applies the appropriate world state and settings automatically without users having to manually set things up, then that works just as well as a fully separate game mode. The mission simulator isn't quite the same thing as a sandbox though. Sure, there's definitely overlap (lots of players use sandbox to test missions), but the mission simulator doesn't keep a persistent save for doing something like a sandbox career. Forced LS and CommNet could also definitely be an issue with sandbox/mission sim. When you're in the early stages of planning a manned mission and still hashing out the flight path and craft design, or experimenting with space station/colony designs it's nice to not have to worry about life support. Same thing for CommNet, and relying on the community to create world states to spawn in a bunch of relay constellations just to test a single deep space probe sounds like an overly complex solution to a problem that could be solved much more simply by just temporarily ignoring comm network connections for determining probe control (which is a debug feature that will need to be developed anyways) . Plus, that also means the game is now dependent on the community for what many would consider to be a critical feature (ability to test probes).

While I agree that too many options can be problematic for both development complexity and potentially confusing players, I also respectfully disagree with the assertion that options are universally bad. I can get behind the idea of one "canon" game mode with settings and enabled features that most closely matches the dev's vision of the game and receives the most balacing focus and is clearly labeled as the way the game is intended to be played. However, I also understand that some features like life support and comm networks which I would want in the game for the full career experience would be annoying to deal with if you're just wanting to casually mess around in something like sandbox (which is a core part of KSP and will return) and would need a way to be disabled for sandbox if nothing else. If the devs are already enabling these features to be turned off for sandbox, then it's not really adding dev complexity to allow players to turn these off for a custom career, and by putting these options under a custom mode instead of the standard career the devs can make it obvious that it's not the "recommended" way to play and maybe even have a disclaimer to that effect if balance is a bit wonky due to the particular combination of settings. On a tangent, I also agree with earlier posts in that KSP's balance/gameplay problems are a result of the way the game was developed without a coherent plan and with placeholder being tacked on placeholder that resulted in the poorly balanced options we have now, and the options issues are a symptom of these development problems and not the cause.

Haven't looked at KSP for awhile, but I have fond memories of SETI and am very glad to see someone picking up the torch for an overhaul mod like this. Kudos for picking a permissive license that will allow the mod to live instead of dying like SETI did. Just one little thing, on the thread title this mod is indicated as being 1.8.x compatible, but the spacedock download link hasn't been updated to reflect this so I want to make sure I'm getting the newest version of the mod and not an older version.

I don't see an in-game programming system as replacing action groups, but rather complementing them. For example, action groups can run code snippets, and code could toggle an action group. If you don't want to use the coding system, the action groups would still work the same way they always have. On the topic of a stock programming system, yes please. A drag and drop code block interface would fit the game perfectly, and would enable a ton more functionality and automation. As long as your vehicle has some sort of guidance computer onboard (anything with a probe core or crew capsule, external seats don't count) it could execute the programs.

Did you use any life support recyclers when you tried those mods? How long of missions were you trying to do? All LS mods I tried (mostly TAC life support and UFI Life Support) had pretty good balance IMHO where the crew capsules had enough LS for early LKO missions, for Mun/Minmus missions you had to add a little bit, but the weight only really became a big concern for interplanetary if you weren't using recyclers. Same thing would happen if you wanted to do an interplanetary mission with just batteries/fuel cells without bringing along solar panels or RTGs (hmm, now that sounds like an interesting challenge). Sure, you're going to need a lot more than a MK1 capsule to get a Kerbal across the solar system alive, but isn't that the point of playing with life support, to eliminate the realism break of being able to do that? Your second point is valid for LS, but is also a problem in stock KSP for dV since unless you're using a dV map/calculator the game gives you zero info on how much dV you actually need and you're pretty much guessing on that front as well. Definitely an issue worth addressing if some sort of stock LS is added, but not a new issue for the base game either. I've long thought that KSP could greatly benefit from a mission planner that would let you place a bunch of maneuver nodes and get an idea of the launch windows, dV requirements and mission duration, and it would nicely solve both issues. Would be even better if you could see the mission plan during your flight and have the maneuver nodes prepopulated.

That's what the blast shield is for.

Orion drives sound like the perfect solution to less than ideal landing sites. Nothing like dropping a few nukes on the way down to flatten out pesky slopes and leave a nice, level glass-lined crater to land in.

Another random point on this topic: throttling isn't inherently a bad thing. Running CPUs/GPUs beyond their cooling capacity for short periods of time has been one of the big reasons laptop/smartphones (and many SFF desktops) have the performance they do. It allows them to have the performance of a much more powerful processor for a short period of time without the corresponding increase in cooling weight/bulk/cost, and for many workloads (web browsing, application loading, etc) there's plenty of downtime between tasks that the end user sees their machine performing much better than it would if the CPU were limited to what the cooling system could actually cool at steady state. Same goes for a beefy custom cooling solution, it's great that you can run max boost constantly, but how much more performance could you get in tasks that don't 100% load your hardware (i.e. most games that aren't KSP) if you allowed it to boost beyond even what your crazy cooling system can handle (in other words, what overclocking does)?

For custom desktops that may be true, in OEM systems the manufacturers have a lot of tuning parameters to play with to adjust the thermal behavior of the CPU to fit whatever cooling solution they've built into their design. End users can also tweak these with appropriate software utilities (had to do that on an ultrabook that insisted on bouncing the CPU between 100% and thermal slowdown mode under load without settling on a steady state in between). But yes, the best way to get the thermal load is to actually measure it (or in the case of end users like ourselves, read CPU reviews where they measured it and tested with various coolers).

Fair enough, if you've got a custom/botique gaming desktop with appropriate cooling then the clocks will always be at max boost even under load. However, for the vast majority of PCs (including most desktops) the CPU and GPU will only run at max boost in lighter workloads, hit them them hard and they will heat up faster than the cooling can remove the heat and they will throttle. An average desktop CPU tops out at around 90W (lower TDP parts will potentially boost into this range as well briefly and throttle sooner, the TDP is a measure of average power), anything less than a high end air cooler/liquid cooling will have trouble keeping up with this rate of heat production under sustained load.

Ugh, not another one of these "realistic" space movies that's anything but to join the likes of Gravity and Interstellar. If you're going to make a realistic, hard sci-fi movie, then stick to real science. If you want to do crazy stuff, then either make a space fantasy like Star Wars, or do a comedy like Rocket Man.

For laptops (or any PC really) that lives on poorly implemented thermal throttling, possibly. ALL PCs now (even giant DTR laptops and desktops) live on thermal throttling, which is why there's separate base and boost clocks for CPUs and GPUs. If well implemented, that throttling will maximize performance for a given TDP in intermittent load scenarios (i.e. normal everyday PC use with opening web pages and programs). During heavy sustained loads, ideally the parts will slow down to achieve an acceptable steady state temperature that won't result in overheating. In a machine with poor cooling design that puts temperature sensitive components next to hotspots like the CPU/GPU with a potentially inadequate cooling system and throttling algorithm on top, then yes, reduced lifespan could be a real possibility.

Unless there's something already wrong with your PC, the only real concern on that list would be lag or running out of battery if you're not plugged in. Overheating in modern machines generally manifests itself as lag since the chips slow down to reduce heat. Crashing/freezing could potentially happen due to driver issues. Fire is so unlikely that it's not even worth considering, your machine will hit thermal shutdown and turn off long before it gets hot enough to ignite anything. At the end of the day, KSP is just a particularly demanding piece of software on the CPU side due to the physics, you could generate a more demanding load on the CPU/GPU using benchmark software.