chefsbrian

I do hope it comes sooner, but odds are that if there is a scanning system akin to kerbnet coming to the game, it'll be all the way over with the resource update, scanning for deposits - stuff like anomaly detection just being a side component. I imagine the team passively considers it a feature and not a bug, encouraging people to spend more time exploring in their play while the games in EA. Even if that gameplay sucks right now, it is something to do

I've heard about FTL achieved by sidestepping this dimensions rules, but this might be the most literal take yet.

Always have. Don't remember when and where I learned the trick, but once yer in a stable orbit after launch, you can just wait for the munrise, and burn prograde - you'll get an intercept every time. Really good trick to teach friends who are new at the game, it'll let them get to the mun without having to learn how to use all the transfer tools. Again, helps hook people in to give 'em an easy cool action before moving on to the hard stuff.

Welp, full disclosure, after a few bugs slapped me on my attempted Mun landings, I resumed the cycle of going back to KSP1 while thinking about what could be. The difference I feel, this time at least, is that I went back thinking about how close it was, and whether I should try again this weekend, rather than the last times I tried KSP2 and went back to KSP1 mad about how I'd wasted my time and had an awful experience. I still don't expect KSP2 to compare to my KSP1 modded runs in so far as keeping attention and engagement, but the fact its going from being seething frustration bad to simply being lagged behind in a relatively positive light is a big win for me. The bugs still stuck, but now it feels like I played a bunch and hit some bugs, rather than fighting the game for every single thing I wanted to do. Many of the frustration points I hit were simple UI/UX issues that can be addressed (VAB Plz remember my workspace, if you want me to use workspaces then stop throwing me into a new one every time, and let me name craft in the space differently) with future updates. I see a path forward for the game to compete with the systems I have now, which is more than I could have said back in October, when it still felt like a completely worthless venture to engage with the game.

Bingo, exactly this. You want to move the player towards a 'cool' objective. Stuff like sounding rockets sounds nice when you think of the game as trying to emulate a 'real' space program, but we're not - we're trying to make space fun and accurate in equal measures. Pushing the player to quickly land on the Mun gives them that hook of "oh hell yea that was so cool" that then buoys them through figuring out the much harder steps to reach Duna, which then encourage them to do more orbital work and experimentation. But you want them to be doing that understanding why the goal on the other side is worthwhile - a Mun rush achieves that. We're mostly veterans of the game, so we get 'bored' just rushing the Mun, we're looking for excuses to do something different with a run, but we're also the oddity they expect to let loose once the Muns been conquered. We're usually finding our own path anyway :P.

Do you want to try this sentence again? I'm entirely unsure of what you're trying to say here. KSP1 never had colonies or off-planet launch capacity, so I am exceedingly confident when I say that KSP1 did not have any issues with balancing extraplanetary launches against planet based ones. You seem to be randomly jumping between talking about KSP1, potentially modded KSP1, and talking about what I think is future state assumptions of KSP2, but there's no point where it becomes clear which ones which, so I genuinely don't know what points you're trying to make about what things.

I don't really see it as a problem that needs to be solved long term - Resources are the theoretical solution to this problem, encouraging players to be frugal with parts because of resource constraints. Trying to pack in an ancillary system that also ties it into research isn't gonna help any, and would probably just punish players who try to splurge with what resources they saved, or punish players who invest heavily into basic resource production, figuring "I don't have a lotta nuclear fuel but I can produce stupid amounts of methalox on the moon, so giant rocket ships it is - oh wait part limit nevermind." Any launch part limit for gigabuilds also becomes irrelevant as soon as you have an orbital colony up - If you only let me launch 100 part vessels, I'll divide up to 100 part segments and waste 30 minutes of my time doing some orbital assembly right off the dock that put me right into a stable orbit. Again, a system that is completely unbalanced without resources, as the 'hard' part of the orbital colony is putting the stuff up there in the first place, but we get that for free at first. When it comes to early access development, I'm a strong advocate that in all things pertaining to balancing stuff who's essential elements aren't in yet should be done in the players favor - It doesn't actually help encourage exploration or engagement with game systems to find problems and issues if we add arbitrary limitations now to try and mimic the consequences, but not gameplay, of future systems.

With you there. The guts of the system seem fine - In so far as it appears to be working as intended. Its just missing a lot of QoL regarding how that's communicated and presented to the player. But that's polish that can come along. Yup, I've said as much in the general thread, the effect sucks. But I'm also not really that worried about it, its just visual. Only reason I feel its worth mentioning at all is because of how much effort was put into hyping it up and showing how much work went into it, just for it to be pretty disappointing. I'm sure the art team will have plenty of time to refine it while systems level work is ongoing.

Welp, first impressions for me are in on the new update. Science system is nice, and my ships didn't randomly blow up from normal operations. Performance feels fine, but its still early in the save and I haven't launched anything with higher part counts. I'm really liking the QoL of experiments just gathering and not relying on me having to constantly monitor "can I trigger it yet". Thermals mechanically are fine, although it feels a bit overtuned with the lack of starting heat shield option. Don't like how the science point counter is permanently glued up in the top right though, it covers up part of the resource menu, and I really don't need to see that when I'm trying to fly a mission, hoping its just a UI oversight/bug. I do gotta say though, these thermal effects kind of suck. Visually they look very goopy, the sounds no good, and parts lost to thermal stress just sorta go *poof* with a tiny sound and no real flare. They're not covered in artifacts the way the KSP1 entry effects were, but I almost feel like they're too static and sloppy now - Goopy is what I used, because it looks like there's just a vague smear of 'hot' as opposed to an actual feeling of a fireball. The glow the smear gets is nice though, I'll give it that. I'll absolutely take it over nothing, but this really feels like it falls flat compared to the presentation we get with things like the engine plumes. Good first step, but needs more work - Being a visual aspect, I'm less worried about this though. All in all this does feel like I actually have some incentive to keep playing and progressing a save, so we'll see how the rest of the game stability and bugs holds up as I start to actually run the campaign.

I know what I'll be trying to do, which is the KSP1 science arc of grabbing some pad, low and high orbit kerbin science, and then unlocking whatever I can to facilitate a Mun sample return mission. If the game gets through all that without breaking at a fundamental level, I'll be pleased.

Yea, this is probably as close to a like for like comparison as we'll have anytime soon. ISRU resource harvesting is the only directly ship related mechanic that's missing for an apples to apples comparison, and assuming it arrives at the same time as the general resource system, we'll have colonies and interstellar parts making a like to like near impossible. Alongside the general content depth comparison. For what its worth, I don't see depth as a problem - I'd much rather 5 science parts in a science system that works, than 50 in one that's broken. Because if the system works, adding more parts to it later is a relative breeze, and if I don't want to wait, modding can take advantage of a system that actually works already. Meanwhile if the system just doesn't exist or doesn't work right, then it doesn't matter what you add to it, its still too scuffed to actually use. I imagine Colonies and orbital construction will single handedly put KSP2 well outside of easy comparison to KSP1, just from what that opens up. Right now, the game chugs trying to launch massive nightmare ships through atmosphere, and we lack a variety of heavy lifting tools to really put stuff into the stars. Orbital assembly neatly sidesteps that entire ball of yarn and puts your NERVA stack into space wholesale, no docking ports or launch reinforcement required. Trying to draw design comparisons at that point is gonna be moot, as the possibility space changes so radically.

Welp, as an active critic of the state of the project over the last year, I will say that I hope this works out well. I can't honestly say I'm excited, as the last year has moderated my expectations into the floor, but I do hope this succeeds. I'll be playing around patch launch, and we'll see if I feel that the games actually worth my time, rather than wasting it by spontaneously disassembling all my missions. But if its actually good, I won't be shy about saying so either.

We know that some content creators have gotten early access to the content. But the post informing us of that also said they are releasing their early previews on the 19th. Considering how Intercept usually interacts with community creators1, its probably Embargoed until the update goes live on steam, but its possible within that wording for the videos to come out in the morning hours before the update. 1. This isn't a jab at the team, just making it clear they prefer gated content over more open early access periods to updates as some other developers tend to do. Both approaches are valid, especially for a game that wants to promote player discovery, no fun to see it all in a tuber update before you find it yourself

Definitely should be using interstellar drives in-system, and I can actually defend that mechanically and via gameplay. We know that resources and resource gathering is going to be exceedingly important to expanding the footprint of what you can build and fuel in the game. We also know that Interstellar drives that are anywhere near as capable as their predicted IRL counterparts make travel vastly easier - A metallic hydrogen drive or fusion/torch drive turns an IRL mars mission into weeks rather than months. It stands to reason that these drives are going to be extremely expensive as a result - Aside from accurately requiring a lot of valuable, rare materials manufactured to exacting standards IRL, it just makes sense as a balance and progression model. Which means, in my opinion, you'd be wasting it to use your first handful of drives to yeet yourself out of the kerbol system. These drives trivialize moving around the home system, but you probably want to be doing a lot of that now as you will want to scale resource extraction and production with your colonies. Using a torchship to ferry materials or goods sounds wasteful initially, but it'll let you move more goods, faster, creating much more responsive supply chains. Using such a beast of a ship to deploy a mining operation would let you bring way more equipment for every setup trip you do, vastly increasing the rate that you'll grow your available resources. And the player will be doing all of this with a ship that makes launch windows far less of a concern, and with a Delta-V thats sufficiently generous so that even the more relaxed, "Make it look cool" engineer can be confident of making all their destinations, even oblique and off-plane ones they might have struggled with. These engines would provide an easy option for players to scale up and widely engage with the other mechanics of the game in the kerbol system, which I see as an obvious reward for having set up all the infrastructure to build that first engine. Players will still have to play with conventional gear up to that point, and players who want to scale up on the conventional stuff can still absolutely do so - You'll be flying more missions, and they'll be a little harder, but that sort of self-restriction is already the realm of the 'serious' players anyway so I doubt it'll be a big deal breaker. To me, it just seems like a system that automatically provides a bunch of different options on how to have fun, without requiring you to take a specific path - for in system, anyway, I'm sure interstellar drives will be the kings of actual interstellar. I think it'd be naïve to try and force them to only be good at that though. As for stuff like Epstein drives (Fusion torches with incredibly high efficiency and thrust) I wouldn't blame them if there was one or two at the end of the technology tree, maybe using alien system resources. But I'd prefer if it was left to mods, gotta have something worthwhile to add to the near-future Intergalactic mod

I'm betting against any significant reschedule for sure. Outside of "We're having troubles with holiday steam and need a few hours", rescheduling this is basically "Push it into 2024" which, considering the chase to squeeze this out at the end of the year, I believe is simply not an acceptable option to the team. Whether it be internal or external pressures, it seems they don't want the narrative to be "KSP2 saw no roadmap updates at all in its entire first year of early access". Besides, per the claims of how they're working heavily in parallel on all these roadmap updates, they should have had the better part of a year to get this done

That's not really how this works, your testers aren't the people determining release schedules and planning.

I'm actually on the side that its a bit weird they don't have a date out yet. December is an interesting one because while it has 21 paper working days, in practice you're lucky to get much of that in effective man hours on projects between people taking vacation time, which also knocks onto people being reluctant to release major things late into the month - If there's issues, half the teams out and you've only got a few days before christmas to fix it. It doesn't mean the month can't have launches at all, quite the contrary, but that you want to know well before december rolls around that the launch is ready to go. December working hours tends to turn into cleanup, maintenance and pet projects as a result. If this was just some minor patch or content update to existing core mechanics, I wouldn't be too concerned, but this is major net new functionality that's unproven in so far as stability goes. If they were going to launch in the first working half of the month, that date shoulda been locked down and ready to communicate by now - Its only two weeks away. If they're not done and its not working to satisfaction yet, then alarm bells should be going off, because your likely release window is pushing into the latter part of the week of the 11th, giving you very little time before christmas when you're liable to have the least staff to fix inevitable post launch issues. I wouldn't be so bold as to say "If we don't hear about it by X, its definitely delayed" but I will say that going into a december release window without a december release date is not a reassuring sign. Every project I've ever been in that tried to pull something like that off either got burned, got heavily 'last minute MVP' cut down to size, or got pushed into late January when most of the hands were back and able to fix it. Its entirely possible the team is just being super conservative about announcing dates for fear of missing it, but then their lack of confidence in those dates is not confidence inspiring to me either.

Wrong game This is the KSP2 Modding section, this won't work.

I'm not really bothered. My focus for any early access is systems, not specifically content, as systems are the hard part of the equation. Its comparatively easy for them to do a later update that adds more once the systems are in place. And if I'm really hungering for more, I'm sure some modders will jump on making fun stuff once its out.

My understanding was that it wasn't the lack of EC that prevented deploying panels, but the fact that being out of EC means the probes turned off, so the "deploy" order is never received. I've deployed solars on manned capsules that ran outta EC, so unless a mod of mine cheekily changed it in the background, it already works as mentioned.

Kinda feel like things are do or die - Not for the project team, but for the community. They really need a content and feature win to moderate community dissatisfaction with the EA release, just as much as they need stability and bugfixes to deal with the community sentiment on that front. In their position, I'd be desperate for a content update too - While our specific community and its disappointments do matter, the casual observer opinion waiting to buy the game matters too, and "Its been a year since Early Access and it hasn't gotten a single roadmap update" is a bad look, the kind that causes a lotta people to just remove the game from wishlists with a "I'll check it out later then" sentiment that often ends with the game being forgotten. Perhaps releasing science isn't the 'Best' idea with the bug state of the game, but its probably the most realistic idea, and heads off a lot of other budding problems. Sometimes its not even a matter of 'Good enough' so much as it is a matter of 'Survivable' in early access development.

Sorry, I'll elaborate then. Its all about the various ways a user can try and bring attention to a problem. Forcing users to submit new reports rather than resurrecting old reports themselves ensures that your having users go through the whole process, and ensuring that you leave behind any potentially irrelevant and stale information from the old report that could merely muddy the waters of an issue. Allowing reopens also opens avenues for misuse, via users finding old items 'easier' to reply to as the requirements are not as strict to just say "its happening again", when it very well may be entirely different. This leads to you having one way to handle one report, and one completely different way to handle another report, just based on how the user decided to submit it, hence multiple paths and multiple processes. This problem gets worse as you open more avenues for people to submit issues - Such as a stripped down report to just present a seeming UI only issue, and so forth. The people managing and triaging the queue have to keep up with all these different avenues and the appropriate way to treat them, and the User has to somehow be educated on how to use the right one in the right situation - Which frankly, isn't their job and is just asking for mistakes, that waste everyones time and confuse the whole system. So at the end of the day, the best way to go is one user, one issue, one report, full reporting expectations, and if its determined to be a duplicate by the team, then they can merge it in. Opening any way for someone to bypass that just adds confusion, difficulty to maintain, and a risk of things just being straight up wrong due to assumptions made on either side of the equation.

The problem with offering multiple potential paths for submission is that users tend to take the path of least resistance, even if its not correct. Again, I get that in your situation its an unneeded PITA, but multiple processes is a much greater PITA on the rest of the team, I've been there and it sucks lol.

its a catch-22 sorta deal: players may think they're the exact same bug report because the symptom is the same, but from the developer perspective it could be an entirely different bug report for tracking purposes because the root cause is the same. Having everything submit separately and be merged after review if determined to be indeed duplicates is the best way to handle it, usually. Your experience shows the other side - users aren't workers, and are entirely capable of saying "not worth it" and just not bothering with a report. Ease of report submission alongside quality of report submission are two metrics that are forever at odds, especially since ease of reporting influences quantity of reports as well. For what its worth @Dakota, The way you do it now is probably the best way. The number of hours I've wasted as a developer hunting down a bug in a completely wrong avenue because the bug that "returned" only happens in entirely different reproduction circumstances that were never documented because the user just reopened the last incident instead of a new one have probably cost my company a fortune.

Glad to see Waffle Irons being included as a sneak peak into the science experimentation modules, should add some diversity to my usual Mun Lander Pancakes.