Lord Aurelius

  • Content Count

  • Joined

  • Last visited

Community Reputation

411 Excellent

About Lord Aurelius

  • Rank
    Supreme Commander

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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).
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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)?