GigFiz

Ba-dum tsss They'll be here all night ladies and gentlemen. But you ain't wrong either

So as we close in on the release date for EA, I have been debating whether to start playing on EA day one. After all the anticipation day one is my first instinct, but I also don't want to burn myself by the time it hits 1.0. I am also waiting for them to release system requirements, since my once mighty laptop is now kind of a withered potato in need of an upgrade, which will happen soonTM, but waiting for the right deal and specs. So, I thought we might all be interested in the overall sentiment around these parts

That seems a bit selective because, if they put in rouge planets, then the people that wanted mascara, eyeshadow, or lipstick planets are going to feel left out .

I wonder if you could combine it with some kind of compression system as well. Like an airtight form that's open on the top (though still protected from raw vacuum) with a vibration system and some kind of hydraulic press type system that comes down from the top and compresses the concrete, while also letting the gas escape. Also, environmental control would help, but we already effective additives that mitigate difficult conditions. I have to suspect that down that road could be more advanced ones that could be developed to aid in these conditions. There are also some really interesting synthetic plasticized polymer products out there with similar properties to concrete, but also some nice advantages, that I have run across. They aren't used in lieu of concrete, they are generally used as coatings/cover layers but I don't know if that's a matter of expense/material availability (which wouldn't be an issue for a 'spare no expense' type moonbase), or if it's that their properties aren't as suited for heavy, large scale stuff. Though, operating in a lower gravity environment means that heaviness is less of a factor. That's one of the uses I've seen for them. As a cover coating to try and prevent/mitigate this. So I don't have anything solid behind this part, I'm just speculating/extrapolating wildly, but I wonder: if some of the synthetic polymers I mentioned could be used for building, or more advanced versions developed that could be used, or even mixed with concrete, that were lighter and more flexible than plain concrete, and if you used a reinforcing element that also had flexibility, like kevlar (though that loses strength against shear stress. was just a random thought, anyway) or something...maybe you could end up with something more suited to building in these kind of environments

Indeed. In KSP universe, the speed of light is clearly k And the gravitational constant is J (For Jebitational constant)

I Haven't made up my mind about whether I would rather it be equivalent to 1LY or 4LY in our world, but...just one little bit of food for thought: Voyager one has been out there for 45 years and is going 17k m/s, and has made it a grand total of 22 light hours. Even one light year is enough to make us feel it, I think. Even if we quasi-kerbal-scaled things by imagining it was going 10 times faster, that's still less than 10 light days That said, my purely random intuitive guess is that the closest system is going to be slightly over a light year away, to give the feeling of scale, but not feel totally unsurmountable for your first interstellar expedition, and then the others will be further, maybe (assuming 3 extraKerbolar systems at 1.0) one in the 3-5 range and one in the 7-12 range. It will be interesting to see if they will be kind of center around the Kerbin system, sending you in multiple directions, or are mostly in one direction, with the main variable being distance, or... I am also hoping that it will be possible for mods to add more systems; it would be fun to be able to fill out the stellar neighborhood

I agree there probably isn't, but they kind of could, because the amount you move is so little as to be practically nonexistent. To illustrate: Sedna has a perihelion of around 76 AU and an Aphelion of just under 1k AU, which is way out there, past the Heliopause, but also only 5.5 light days, so still waaaaayyyy less than what we are talking about, plus its orbit is highly elliptical, which decreases the orbital period a great deal, and its orbital period is still over 11,000 years. Basically, they may as well not have stuff not move outside the Kerbheliosphere, because unless you have a program going for many thousands of years, you will never even notice, even with the reduced scale. Taking that into account, I'd say if takes relatively trivial amounts of dev time and processing power for interstellar space SOI stuff, they will do it (so I would guess there will be at least a simple version in place), but if ends up being more tricky or runtime-intensive, they won't bother, because 99.99%+ of players will never run into a situation where it would matter, or notice the difference even if they did.

I mean that makes sense in the very early game, but KSP2 is going to go bigger, and then you add mods, it's gonna get a bit silly eventually. SM-M-LG works great when most stuff is 1.25-2.5-3.75, but when it gets to be .875->1.25->1.875->2.5->3.75->-5->7.5->10->? any sort of word based system (huge! giant!! massive!!! gigantonormous!!!! supercalifragilisticexpialibiggest!!!!!) is going to end up being more arbitrary and confusing than plain numbers. I think this could be a great place for tutorials to cross the gap: introduce new players with descriptives, then gently move them over to plain diameter. I don't think it would be a huge leap for people to make. Also, I really hope there is a better part sorting system in place than what we have now. Not the tabs themselves, but a better, intuitive way to sort within tabs, especially for size. Being able to go to structural parts and then just hit 2.5m would be so nice; have it so if you also hit 3.75m, it will also show adapters between the two, and have an adapter button that would show all the adapters that connect to the sizes currently selected, etc. I very much in favor of things that make less time spent playing hide and seek for parts while you are designing stuff. Oh, and for off-world VABs and such, an easy button to hide all the parts that you do not currently have the resources for.

Well this is the understatement of the forum. Seriously guys, if you want proof that this is something they are definitely thinking long and hard about and see it, and and other important issues discussed in depth, just go read Nert's old Dev thread, and the thread for his Cryo Engines; that's around 250 pages worth of relevant discussion and debate right there. We have a man on the inside, as it were, someone who has thought about all these issues and more and been here with us discussing them and making mods for years, who is now a part of actually developing KSP2. This was definitely the direction my brain went with this debate. People are talking about "the way it really was", but this isn't a replica of humanity's space program, this is us guiding our happy LGMTM through their own foray out into the galaxy; it is going to have similarities to ours, but there is no reason that it has follow the exact same path; it's not like Methalox isn't also perfectly viable fuel choice. And for jets, for one, that's not a big enough aspect to warrant a whole separate fuel. Besides, we don't make our jet fuel/avgas out of methane, but that's not because it isn't possible. Maybe Kerbin has less or harder to reach oil, but lots of easily accessible natural gas And think of it this way, in addition to the fact that they didn't pick methane arbitrarily and the cool stuff that is coming from it that they have mentioned in this thread, the fact that they made it anything specific is still a plus for mods. In KSP, the nebulous "liquid fuel" made it so fuel mods had to decide what that actually was the equivalent of (though kerosene was the popular choice, but it didn't have to be) first. This way removes all the ambiguity and makes it easier for fuel mods to be more consistent/cross-compatible, as well as makes the nomenclature more consistent, by having all the fuels identified rather than having a split between 'real life' fuels and 'video game' fuel. Heck, I'd say go one further than just labelling: I want them to actually sort them that way in the parts tab (not under different tabs, just subheadings dividing up the parts in the engine tab). Not only will this make it easier for brand new players as they design their first rockets, it would be a change in the visual language that would make it easier and faster to find the engine you are looking for, which would be a great thing for all of use, regardless of experience I love adding engines and other cool part mods, but dear lord do things get cluttered and time consuming just looking for the right parts in the VAB/SPH. Also, many of the engines are already essentially labelled it's just that it's buried offhand in the description, or even just implied rather than stated. This is information the game was already trying to give us in KSP1, it's just going to be doing a better/clearer job of it now. Besides, they aren't fundamentally changing the way the engines work; a label won't prevent any 'off-brand' use of an engine that we can do now from being possible.

Definitely. and I don't recall seeing about it one way or the other, but this seems like the kind thing that they would get rid of, anyway. But yes, saying " you can't add another booster because you don't have enough resources/production capacity to fabricate/fuel one" = good. Saying "you can't add another booster because you have hit an arbitrary max number of parts, but you could if you removed that backup antenna" = bad. Also, forcing players to keep part counts low and ships more streamlined could kinda make sense in ksp1 when those are major vectors for kraken and performance issues. If those issues are fixed, then those limits stop making any sense they may have made

If you have to do that already, why not just cut the whole issue out, stick with 2-body and save the dev-hours and computational power? I get that Lagrange points and better gravity assists (apparently. I've seen it mentioned that they are easier with principia, at least) are cool, but at that point cost/benefit doesn't seem to really make sense. In one of the dev diaries, they noted that, at the scales they are working at and the precision they need, you blow way past the limits of 64-bit calculation (and moving to double precision brings its own set of issues at large numbers), so it has to calculate things as a section within a section in order to reach the precision necessary. If, in order to keep framerates and performance high, you are doing only one section at a time like that, you need something to keep things stable and accurate everywhere else in the meantime with the minimum amount of resources, which sure sounds like you've circled back around to rails again. Plus, as I saw someone here point out some time ago (and assuming their statement is accurate), NASA uses 2-body math to plan their missions, and that's worked out pretty well for them (we aren't exactly running planet formation simulations here. Even if our space programs go for hundreds, or even thousands of years, that's just a drop in the bucket); so hey, good enough for the space goose...

I think you and I are saying similar things, I just don't think I illustrated it very well. When I say limitations on procedural tanks, I also had preserving the (lego, as you called it) building style in mind. My thought is something along the lines of: instead of the Rockomax 8, 16, 32, and 64 tanks, you just have a single 2.5m tank that can be resized lengthwise, but it only snaps to sizes corresponding to the 8, 16, 32, 64 (and more sizes if they want), and cannot just be freely adjusted. At that point they have condensed 4+ parts into 1, but kept the building limitations, making it more of a clutter-reducing QoL feature. Then, if they went that route, I would think that making a mod to go in and remove those mandatory snap points, making things freely adjustable, would be a relatively simple affair. I do think tanks that you can adjust the radius of are less likely to be included, but that just means a bit more work to mod them in. If things do go that route though, I would be rather surprised if the procedural fuel filled wings were fully adjustable (or at least would expect some kind of separate set of limitations around how it does fuel, even if the wing shape is fully procedural), since I can see far more issues with those than with the good old fashioned cylinders. I'm not one to go the "oh just make it a toggled option" route, but some amount unlocked procedural tanks is actually something I could almost see as an included switchable option, maybe just for sandbox mode or something. Though the balancing issues if you have procedural engines, and the sizing issues if you don't, means there will always be some hard limits without mods, I think.

That made me think of on along those lines: a better autopilot for aircraft, and for rovers. Because even if you had a plane that could make it there and back, it still took ages, but you couldn't just walk away, cuz the trim ends up a hair off and you might come back to a crater. Similarly with rovers. if you want to do any actually real roving in them; I like the idea of ground exploration, but bloody hell is it tedious and slow. And you can try just going faster but that backfires rather often. Of course you can just go slow and use physics warp and that....usually doesn't go great either.

That's right, I remember discussing this with you in some detail, earlier this year. I quite liked your ideas, and they definitely match up well with what I am hoping for. And now that we know that they are making science the primary 'currency', there is at least a chance that the system could end up looking like what we are wanting. No guarantees, obviously; there are plenty of other ways it could go, so...fingers crossed. I don't remember if it came up at the time (or if you had already accounted for it), but the other thing interesting thing that could be spun out of your ideas is a better mission system. As we all know, the current one is...pretty boring and superfluous, and doesn't really feel connected to the rest of the game for the most part. But in a system where science and progression are linked that way, missions could operate more as a way to point you in helpful directions, and maybe give you some bonus tasks and rewards to do while you are at it...or something like that, but the point is that it seems like an opportune setup for making missions feel actually tied to the rest of the game, rather than tacked on. At the moment, it seems unclear what we are going to get for missions, though I feel like they did at one point acknowledge the benefit of that sort of element of structured gameplay, and that it appeals to plenty of people (I am one of them). Hopefully, whatever they end up doing, there is at least a more robust framework for missions in such a way that mission packs become an actual interesting avenue for modding. PS: Good point about that being able to make those penalties feel meaningful. Especially since this hopefully means that, this time, the tech tree won't just be trivial to blow through.

This is very true, but the trick here is that there is very much a line where it crosses over from 'cool challenge to overcome' to 'miserable, punishing slog'. And the problem for life support specifically, which always seems to be among the more heated topics, is that, not only is it a extremely fine line, the line is in very different places for a lot of people. Expanding on that, I think a big reason there is so much disagreement on this topic is that a lot of systems have, by and large, a gradient of difficulty, which leaves a lot of room for different, but similar enough opinions; life support, on the other hand, pretty much goes straight from 'overly punitive to the point that for many/most people it will not be at all fun' to 'ignorable to the level of why even bother' (for ships at least; colonies are actually fairly easy because you can just have them go on strike, essentially (which looks to be the form it will take if they have it)). In-flight missions, though, are whole other kettle of monkeys. It could be made fatal, but time warp alone creates too much potential for mishaps that are not the players fault (other stuff too, but not going to rehash everything). They could refuse to operate or pilot the ship, but you have just made rescue missions impossible, or would have if it didn't mean you just always have a backup probe core. You could just have a life support part that is required to launch, but all you've done is added another random thing to put on your ships (people batteries, as it were)...better than nothing, but not super interesting (I say that but, while I don't run life support mods, I do have one that has hydroponics bays and I make them a self-imposed requirement on all crewed interplanetary missions) and even then, something has to happen if the part breaks or gets destroyed and you are back at square one. The best I can think of for a penalty that doesn't seem either overly punitive or ignorable is something like: no collecting science, no fixing parts, and pilots can still pilot, but they lose all SAS ability and have to pilot fully manually (that part could still be ignored by including a control core, unless you also are out of electricity, but it's something at least). I suppose if there was an easy answer we wouldn't all keep arguing about it.

Well, this will certainly make it so that something that counts as a large ship now will have fewer parts, but it has also been shown that it will be possible to make massively bigger ships (much bigger VAB, orbital shipyards, etc). Interstellar ships are indicated to be on a scale far beyond anything we could make now. So that kinda puts things back right where they were, all things being equal. However, all things are not equal: the issue is very much exacerbated by janky stuff in the KSP backend, which KSP2 will likely/hopefully be doing differently (and maybe being on a newer version of Unity will help? I can't answer that one). I actually had the same question on a different thread, and got a great reply from K^2: "KSP handles fuel cross-feed in a very stupid way. To the point where it can be the main reason for abysmal performance of ships with very high part count. I haven't heard anything, but we're hoping Intercept fixed that in KSP2." And presumably there will be other things that they are doing differently/more optimally as well, so it seems the likely ceiling for size and complexity we can go to before running into that level of lag will be drastically higher. Of course, this is KSP, and no matter how much higher the limit is, it will be immediately pushed to. If the limit ended up exponentially higher, that just means someone will try and build a megastructure or something (awesome, if it could be done (still probably not)).

Oh, I know. I was just snarking that if they put they put combat in, it would technically be Kerbal warfare (being simulated by humans). I'm on the same page though, I like the complete absence of any content about, or indication of, aggression or interest in warlike behavior in Kerbalkind. There are a bazillion games about violence/warfare/aggression already, let us keep our happy little space exploration (and space disaster) sim.

Well, Kerbal aggression sim, but yes, exactly; it is fundamentally different from the whole purpose and design of KSP as a whole. Absolutely zero consideration or dev time would ever go into anything like that, or any sort of framework that would (non-coincidentally) help support it. Besides, this is KSP, if you want a ship to explode, you launch one and do it yourself, dammit.

Huh, I hadn't really considered the implications of modding + multiplayer much. Seems like there could be some potential for asymmetry (though that is mitigated by KSP as a game concept doesn't really lend itself to explicitly competitive game types); I wonder if there will be explicit limitations for mods, or if it will just be determined by the host. K^2 explained how using LUA limits/eliminates the malicious abuse potential, so that would solve that, but there still is the performance question: stuff like people with lower end systems that are trying to limit how many mods they are using, mods (such as ones that add lots of parts) that take up a non trivial amount of space, as well as the ones that heavily alter an aspect of gameplay (stuff like planet packs, or MKS type stuff). I guess that, to some degree, the answer could just be "don't join those games", but I imagine the situation arising for someone, somewhere, of friends wanting a multiplayer game, but also enjoying really wanting different mod setups I guess, logically, everyone would have to be running the same mods (except maybe ones that don't affect gameplay and can just be ignored by the multiplayer code (ie, visual stuff like scatterer, etc.)), which also eliminates the asymmetry questions; I'm definitely not an expert, but I would imagine that the game having to handle things differently for multiple players at the same time has to be problematic (if not impossible, in some situations). So I guess it comes back around to not joining games using mods you can't/don't want to use, or reaching a consensus with the other players about it beforehand. So I guess I sort of answered my own questions...maybe. On a completely unrelated note, all my saves have different mod setups, so I end up having a number of different, sorted copies of the GameData folder saved somewhere, to swap out if I want to play a different save. I know mods load at startup, so that's just how it is, but I do wish KSP2 would have a better, built in way to track what mods each save has and load them accordingly. PS: if mods load at startup, wouldn't that create some issues if you have to incorporate new mods from the host when you join a game?

Well, one nice thing about early access is that they will get to test things on way more machines, over a greater spectrum of performance, than they could ever do in house, which is useful data. It's early access, issues are to be expected, that's part of the point; you should only get worried if the issues don't get acknowledged and worked on. If we get a few phases into early access with no improvements in performance whatsoever, and no comments about it from the dev team, then I'll get worried, but until then...eh. The initial finish line for optimization is release, anyway (at least theoretically...tell that to some AAA publishers though); obviously, the closer we get to 1.0, the better picture we will have, but until they decide Early Access is complete...concerns are fine, but death knells are likely premature.

As far as resources limitations in the early game on Kerbin go, that could easily be explained as, since it is a brand new, untested, space program, it has a more limited budget to work with, and as successes and accomplishments accumulate, the resources/money/manpower at their disposal is being increased accordingly. Also, even if launches are free from Kerbin, that still doesn't necessarily make it the best option beyond the really early game. Yes, you could use it to cheese things a bit, but the huge increase in fuel expenditure versus getting something from, say, Minimus, will make it take way more time and launches, and honestly, if you are that determined to abuse the system, just use cheats and be done with it. Not to mention time: yes, you can ship everything you need on Duna from Kerbin, if you really want to, but do you really want to wait several years for a launch window and travel time every time you need something? 'Currency' wise, switching to the system they are describing largely makes sense to me. As people have said, money was done in a...not very compelling way in KSP anyway. You could generally ignore it completely (though, yes, there were sliders to make it more relevant), and the half baked mission system made it so that you either got more than enough without ever thinking about it, or had to farm random missions that, the majority of the time, weren't fun. Resources were also half-baked, being useful-ish, but kinda boring and usually not worth the time setting up, outside of RP reasons, or just for fun. Using money makes no sense at the scope KSP2 is at anyway; like the post above me said, having to pay money from the same pool for building stuff on Kerbin, a random moonbase with minimal infrastructure, and a whole other planet around a distant star just screams 'arbitrary video game thing'. Meanwhile, wherever you are, building a ship requires building materials and fuel, and all that good stuff; even in a simplified form, it feels much more natural. Otherwise, I personally would like a mission system of some kind (A good one. If it would just be another boring, half-baked thing, may as well skip it). As others have said, I like have specific goals, at least some of the time. Even without money in the game, there are other rewards that could be used, even just science. I could see this very much being a YMMV love it or hate it thing, but having missions/mission chains that unlock parts or building upgrades (as long as it was relatively logical and not arbitrary or annoying) could be interesting And as far as multiplayer goes, I think it makes sense to wait until later, like they are doing; it adds another huge moving piece, and would be much easier to balance/test and debug if they are already pretty confident with the stability and quality of the base experience. There is a reason a lot of games wait until pretty late in the development cycle to implement multiplayer.

The one I've wondered about is how it is going to handle super high part counts. Because on the one hand, they've all seen how that goes in KSP currently, so that is something that has to be a major concern/performance focus, but on the other hand, with the ability to make waaaaaayyy bigger ships (and in fact, the need to for interstellar ships), we will have the ability to, and very likely will be, building stuff with astronomically higher part counts. Now, this is KSP, so people are going immediately seek out how far they can push things before the game blows a gasket (as is proper), so the question becomes how far that is before performance issues start to arise, what the bottlenecks are going to be, and how it's going to look like on high end vs low end setups. I am not a programmer, so, while I have read that KSP does some behind the scenes stuff in stupid or just weird ways, I don't know how much of the issue arises from that vs programming/computational power challenges inherent to the nature of a program such as KSP, and I am definitely curious to know

We know procedural wings are going to be in game, so I could definitely see it showing up for other part types, especially since using it for other major structural stuff opens up, or makes easier, more design possibilities, while helping keep part counts lower and reducing part list clutter. Even if not, having that capability already built in to the game will make it easier for it other procedural parts to be added in, I would think. Now I could see something like fuel tanks having limitations to what you can do with them, rather than having totally free adjustment, but that seems like something that would be pretty easy for a mod to override. For me, it's hard to say until I see the finished game, but I'm looking forward to seeing what kind of cool part mods people create. Interstellar travel being a part of the game opens up a whole other level of design space for part mods (as of now, it's quite easy for stuff to get overpowered unless you also mod the stock system extensively), and that should be fun to see. I'm also hoping (I gotta imagine this is going to be possible) that it will be possible for people to add even more planetary systems and such, which, unlike now where you can only get limited mileage adding new planets, opens up a pretty unlimited frontier for exploration.

A very important thing to keep in mind too is that Nate has said explicitly that when they are designing systems, if something ends up as a slog or just flatly not fun, they are not going to keep it that way just for the sake of realism. Verisimilitude is all well and good, and largely desirable, but not if it just makes things miserable. This, to my estimation, points strongly in the direction of any life support system being something that is not going to be aggressively punitive, especially to the tune of killing crews and destroying missions; if I had to guess, I would suspect it will definitely be there, but probably not excessively complicated, with a small number of factors to plan around. I could also conceivably see it being something that is fairly minimal for active flights, but much more robust for colonies (in the sense of more resources/moving pieces to manage, still not in the punitive sense). It is much harder for a colony to get lost in the shuffle or forgotten than some small, barely manned exploration mission you sent out years and years ago, and you are never going to have nearly as many colonies as in flight missions (for most people I would guess), so the game auto-stopping to bring your attention over to fix something, would be much less obtrusive overall. Plus the colony system looks like it will be fairly extensive, so it would be a reasonable way to do that. That said, even if it stays relatively basic, I do hope there ends up being a really robust framework for it behind the scenes, in such a way that makes it easy for modders who want more hardcore stuff, or just to tweak it/build it out more. Edit: also, looking at the roadmap again, even if not mentioned explicitly, Life support could easily be there as an unmentioned subsection of almost any of those, especially exploration and colonies. They aren't going to spell out every single thing they are going to put in, especially with early access still months away, this is just a rough guide for us to get a feel for the overall shape of things Edit 2: also, from the faq on the ksp website: "The core pillar of KSP2 is building and flying cool rockets. While we have additional features planned like colonies, interstellar travel, and multiplayer, we first want to hear back from players about the core fundamental experience". There are also multiple mentions of stuff like, 'not yet revealed features', 'not wanting to spoil everything yet', 'more to come'... So there is 100% still plenty they aren't showing/telling us yet, whether incidentally, on purpose, or because it's not to that point yet. So something not being mentioned yet, especially a less major system that isn't part of the core gameplay loop, should not really be a cause for panic. I don't think it would be something they would be telling us about yet, regardless. Plus, life support is a system that is perfect for early access: it is something where the line between fun and compelling and miserable and unfun, is extremely fine. It would be extremely logical to introduce it fairly early (probably in the colonies or science part of the roadmap) in a fairly basic form, and then iterate on it a bunch throughout early access, in small steps, but lots of them, to get it to a good, and fun, place.

Decades of travel time will be plenty to separate colonies. Sure you can just warp through it, but you can say the exact thing about comm lag. I don't buy the 'teaching people wrong stuff' argument in the slightest for this; anyone who has the slightest knowledge of space (or even just relativity, or even just that light speed exists) knows that communication has a lag time, and KSP isn't going to magically make everyone think we have/will easily ftl communication. Besides, 6 months is a while, but not even remotely insurmountable. Age of sail empires had colonies that could take months to travel to (England to India was 4-5 months by boat, for example). And seriously, half a light year? if you think that, there is a greater problem already. The closest star system to us is 4 light years away, and there aren't all that many under 10. So an interstellar colony, even with truly light speed communication that's four years bare minimum (which is still totally doable for keeping contact, if a bit tough for keeping a group truly unified), and from there you rapidly get to the prospect of colonies having a lag time of a decade/decades (increasingly less doable, obviously). But yes, this is just going to go in circles, or degenerate (or both). I disagree with you, though that one way or the other is fundamentally incorrect way to do it. I certainly have a side I am on, but they are both valid design choices, with arguments that can be made for both and their respective pros and cons. It will be what it is, and if we hate it, this is ksp, someone will mod it to something we like.