steveman0
-
Posts
182 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by steveman0
-
-
On 4/12/2024 at 2:55 PM, herbal space program said:
If they have decided that any capability for resource extraction and ISRU will require a full-on colony/factory setup rather than just the the handful of parts used for that purpose in KSP1, then I agree there is no point to implementing any resource extraction before they have the colony parts. But OTOH building factories and resource extraction systems without any actual resources to use them on also seems kind of pointless to me in terms of gameplay
I don't see these as being incompatible. Just because we don't have resources yet doesn't mean a colony fuel factory can't produce fuel from EC alone when built in the correct location. They could implement the full requirements for colony construction, power generation, thermal management, and the installation of end fuel production facilities with the caveat that you can only produce the fuel(s) available to your local body with the precursor resource assumed available in an unlimited quantity if only at a limited rate.
The resource update then expands on the system only to the extent that fuel production now requires the precursor resource supplied as an input from extraction operations but with the benefit now that these don't need to be colocated. The colonies as a system need to change very little for this integration.
This all would have notable gameplay impact as the future updates may enable centralized colonies that process many materials supplied through automated deliveries from small branch extraction colonies. The first implementation may require each to be fully developed for production. This might be fine since it isn't clear if there are notable tangible benefits from consolidating production at a single colony or if it would be better to produce on site at the extraction colony anyway and only ship the fuel product to a central staging colony for say interstellar journeys.
-
8 hours ago, NH4Cl Enthusiast said:
I don't disagree with the facts you're saying but I do disagree with their interpretation. I think they have ground to a very slow pace because that's the only pace they can produce relatively bug free code. This in itself would not be a bad thing, but the problem here is that in addition to being slow, the content they do produce is not really that complicated or difficult.
There's a phrase I picked up in another field that is applicable here. Move slow to go fast. Taking time with testing to make bug free code is a very reliable way to keep the project maintainable into the future. This is a smart move for what might be a decade long development cycle. A slow pace is good if it saves them rewriting substantial parts of the code in the future as it appears they need to do with a lot of the early alpha dev work.
I'll also point out that content that is complicated or difficult does not necessarily make for a better game. There is elegance in simplicity. Some of the best games is history rely on simple systems. In order to reach a wider audience, simple systems are a better approach. This does not stop them from still making a very compelling game from this.
8 hours ago, NH4Cl Enthusiast said:but I can say with confidence that their game design skills as a team are on the level of cash-grab mobile game developers.
This makes it clear that your own subjective take on the direction of the game is clouding your views of the objective reality. For Science! was an incredibly well received patch that got many, myself included, to play much further into the game than KSP1 ever did. The science, tech progression, and missions were all substantially responsible for this. I did a 40k+ science mission to Dres, collected all the atmospheric samples of Jool in an epic single-probe mission, and I landed a rover on Eeloo all because of the science and mission systems they designed for the game.
I can't take anything else you say seriously in light of this clearly biased perspective.
18 hours ago, Scarecrow71 said:I'm curious as to what you think is a small, underfunded organization. Because the team developing KSP2 is 50+ people strong and is backed by one of the largest game companies in the world.
The entire studio is only 40 employees by their own website of which only a fraction are going to be developers. Obviously, if you falsely assume their development team is much larger than reality than it can seem like they accomplish much less thn they should. You need to keep reality in check for any expectations you are going to hold.
-
1 hour ago, Scarecrow71 said:
Ah, but I DO have a developer background. I'm the point person for automating file loads through SSIS/Alteryx into SQL Server/Snowflake for a pretty darned large team in a pretty darned large organization. I'm fluent in several programming languages,
It's surprising then that you can't grasp the situation. Maybe spoiled by being in only large well-funded organizations? In a small understaffed and/or underfunded environment you can't always tackle everything in a few weeks. Something has to give. Sometimes that means a bug sits on the list for weeks or months until you can spare resources for it. This is especially true when there is a particular focus on some new feature rather than fixes. Without knowing the details of the current development plans and focus (again the reason for this thread) the rate of development can't be reasonably estimated yet the quality that we've actually seen turned out lately has been positive.
-
54 minutes ago, Scarecrow71 said:
Every patch has introduced new bugs. And while they keep saying they are knocking out bugs, the worst ones that have been around since launch day haven't gone anywhere. In fact, missing orbital lines returned after the last 2 patches dropped.
You seemed to have missed the point that solving serious bugs properly requires a lot of work. It's not surprising to me, having worked with test-driven development, that identifying the issue, developing the tests for fixing the issue, and developing tests to ensure the issue remains fixed can take time.
Even the orbital lines bug, as I understand it is actually several bugs and not so much as entirely fixed but rather partially in the cases that were identified as contributing.
1 hour ago, Scarecrow71 said:How nice of him to share it here too. Oh, wait - he didn't. Thanks to the organization for continuing to ignore the forums unless it's to delete threads/posts they don't want to see.
This was the kind of off-the-cuff statement that just happened to come up as a one-line in conversation. Nothing to go marching on all the media platforms to broadcast. He did however express a positive response to writing up a dev blog post on their testing process, so we might get the full story that you're wanting.
1 hour ago, Scarecrow71 said:Again, we have bugs that have been present since launch day. The core gameplay loop is not entirely fixed, the game is still unplayable for some (and for others it's playable but buggy), and we've seen new content once (no, I'm not counting grid-fins) in the last 14 months. They hired 2 of the best from the KSP1 modding community, and they can't even give us information on colonies. They are certainly, and at a minimum, doing a poor job at the technical level
I understand why someone without a developer background would think this way. I understand the specific approach they are taking and recognize that it will make for much more consistent results going forward and that we've seen evidence of this recently. I also understand the effort it takes for this approach and the massive commitment of time required to propagate the benefits throughout the codebase - it won't happen overnight. If you want some optimism, read up on test-driven development and its value to long-running projects.
-
1 hour ago, Meecrob said:
Unfortunately not. In regular play, you may not encounter many bugs, but I made an 11 minute cinematic and about 1/4 of the time or 50 hours was spent dealing with bugs. This game cannot load the same save more than like 5 times before the craft comes out all krakened. Its clear this game has not been playtested to any reasonable standard. I have a hunch the QA team is a revolving door, since it must be demoralizing to be forced to put out a product that does not meet your personal standards.
I think you need to go back and reread my original post. I didn't say there are no bugs left to fix. They are, objectively, moving in the right direction and are taking a technical approach that should ensure they will continue to do so. Part of the point of the post was to highlight this appears to be due to a rather dramatic shift in how they are doing things now versus the past suggesting significant improvement in the technical team. It's dishonest to use the past mistakes as a judgement of current performance.
-
4 hours ago, NH4Cl Enthusiast said:
Honestly while this is often true, in this case I would not put too much blame on the publisher or even corporate greed. I mean if you look at all the things this studio has promised, failed to deliver and straight up lied about, in this one instance I think the people paying literal millions for it are equally liquided as we are. Sometimes the developers are just for whatever reason very bad and this is one of those times and I think unless they are called out for it, there will never be a good KSP2.
Someone on Reddit put it well by saying something along the lines that KSP2 is not a do-over of KSP1, it's more like a do-under of KSP1. Almost everything is just copied and almost everything they changed was for the worse.
What the publisher could and should do is scrap the game as it is, get a new studio to re-develop a new game with a planned EA launch in about 3-4 years from now. This way they could still salvage the IP and if done well could have a profitable game. But sadly the safer option is just to milk whatever value is left and move on.
I don't think this is a fair representation of the situation. From a technical standpoint, the team appears to be doing exceptionally well, albeit moving a bit slowly. The For Science update was incredibly well-executed and very well received. While there have been some noted complaints of missing or incomplete gameplay aspects, the technical execution was nearly flawless with only a few minor issues refined in 0.2.1. They nailed a lot of the core gameplay aspects, improved performance yet again, and knocked out more bugs in the process while introducing virtually none.
What you are describing sounds more like what may have happened with Star Theory and led to the current situation the team is in currently where they are having to devote a lot of time and effort to cleanup past mistakes to get the code base into a good state... but that does appear to be happening.
Darren shared on discord some of what they do for testing and it is the full suite of best practices for the industry and likely a major contributing factor to both the smooth release of For Science and part of why development seems slow. It's because it is by some view of it. Given the long-term development plans for the game, heavy focus on testing is a very smart move as it ensures the work they are doing now will continue to work through the long development life of the title. I suspect a lot of effort is still needed to clean up past mistakes and is why many of the older standing bugs have not been resolved yet... because they are doing it right to ensure unit and regression testing will prevent reemergence through future updates. I suspect this all comes from a change approach in the development process, likely when moving from Star Theory to IG.
The problem does not appear to me that they are doing a poor job at the technical level, the opposite in that regard. The root problem is as this whole thread has been created for is that they, for whatever reason, don't want to speak to any of this and are keeping everyone in the dark about just about all work that is actually happening.
-
Wooo boy... I try to give the devs slack because, while they may be slow and quiet about what they do, they seemed to be putting in effort to do things carefully from a technical point of view. But this whole situation... is pretty much a prime example of how not to do things taking an already bad community situation and cranking it up to 11. I don't understand how anyone in the position responsible for this could have the slightest idea it was a good move. Shameful really. I'm not mad because I'm not as invested as many here, but it is very disappointing to see the direction of the whole EA phase turning worse.
-
10 hours ago, PDCWolf said:
It is not fixed, in the sense that the "fix" only accounts for a single configuration. In a game where you build land vehicles, aircraft, spacecraft, space stations, land bases, interstellar ships, and so much more, a solution that only ever works for vertically stacked tanks on the same central axis of the root part is useless. That's not even going into the performance tradeoff (huge) when you build big stuff with autostruts on.
Maybe you need to clarify what actually isn't fixed about it. My experiences with it are that craft now much more realistically respond with an appropriate magnitude of bending forces to be realistic to materials that would be used in real life rockets. I believe the only notable issue that even relates is as @mattihase has pointed out - that there aren't appropriate dampening forces in all situations that can allow a phantom force to sometimes feedback on itself in increasing magnitude to the extent that it can cause craft to rip themselves apart. This is not fundamentally the same issue as wobbly rockets, it's fundamental to the modeling of the physics forces and not the joint stiffness. This issue would overwhelm the rocket regardless of how stiff it is because it results in runaway forces.
Long thin metal craft with metric tons of mass at either end subjected to metric tons of forces are going to experience some degree of bending. It isn't realistic to expect to build toothpick craft that don't bend under extreme load. When you push the physical parts to the limits of the geometric construction, you should expect a craft to bend and fail catastrophically. It's a fundamental failure mode for a craft of a given shape. Where we are at in terms of the magnitude of craft design where this failure point is reached is just perfect in my view. The noodly rockets we had were silly and making some of the things I've seen some people try to fly more rigid would be equally so.
-
1 hour ago, cocoscacao said:
Exactly... currently. When you set out to do something more bigger and ambitious, than KSP 1 in this context, you have to plan ahead.
Are you of the opinion that if you build some thousand part momstrosity that also shouldn't wobble under extreme load? If so, reality might want to have a word with you.
Reality is that even single stack rockets must be carefully designed to account for bending forces under load in real life. As a KSP rocket designer, the realistic implementation is one where you must consider the potential bending forces when your design becomes extreme either by moving to a more structurally sound core design or by structural reinforcement, i.e. struts.
The wobbly rocket fix is about as close to perfect as I could ask. Realistic looking rockets don't need struts. Move to asparugus staging and add boosters and you might need a few. Move to 1000 part launch craft and you might need to question your design choices. Or just add more struts. There can be no more Kerbal solution.
-
14 hours ago, Icegrx said:
From my understanding CommNet is omitted in KSP2 as a decision to make the game more approachable.
I think a simple option to enable commNet or disable it would solve the approachable issue, but they say it’s not a current priority.
it very well could be a performance thing buried under the veil of “easier for new players” but I don’t think we will ever know the answer to that unless they change their mind on the priority thing.
I wish I could recall where I saw the discussion from Nate on this topic, but I think there was a very important element of it that most overlooked or didn't understand was being said between the lines. The aspect of approachability as I understood it had a lot to do with the fact the game does not provide a good user interface rendering of the range of current communications.
You can't even tell where in the system is not currently covered by the existing simplistic model of comms by fixed unoccluded distance from antennas. If your craft wanders outside of that range and you can lose control, it can be reasonably inferred that you don't have a satellite in range, but even this is only reactionary to potentially losing a craft to a disasterous loss of control. Without a way to see your communications coverage, it's not a great player experience to have craft lost to communications loss.
Adding occlusion to the mix would only make it that much harder to plan a probe mission or risk an unplanned catastrophic loss. Once we have a good way to visualize safe regions of space where we can communicate and perhaps a great tutorial teaching of the dangers of communications black out, there will be a great opportunity not just to restore the gameplay elements this provides, but also teach new players about this aspect of space travel.
My impression from the discussion is that doing this all well will require enough work that they just don't have time to devote to it now.
TLDR: approachable != easy. Not including commnet yet seems less about making the game easier than it is about first providing the tools necessary to tackle the challenges presented.
-
I hope when you add full occlusion during the eclipse that you'll also add to a future built-in alarm clock a means of tracking when these occur. I'd enjoy planning landings to see all of the eclipses. I don't have a good sense of how to go about that without knowing the time of these events or where they even can occur.
-
36 minutes ago, Meecrob said:
Yes they are. Straight from Dakota/Shana:
You're misinterpretting the quote...
-
48 minutes ago, PDCWolf said:
They've actively, literally, contradicted this by saying work was continued between the restructuring. Plus it's literally the same upper management minus Paul Furio who got fired early on, so it's either them practicing corporate diplomacy (with themselves?) or development really wasn't interrupted. Hope one day we get a proper post mortem and a case for devs and publishers to look at and learn from.
At a minimum, studios changed by my understanding. Even with the same staff, we can't know what legal copyright/licensing grounds required them to rewrite substantial pieces of the codebase. Even if "work continued", there was likely significant, costly disruption and we won't know until KSP 2 goes on to be a huge success and we get a documentary on the early chaos
-
Really awesome designs here. I've struggled with the landing plan. What's the preferred strategy here? Parachutes and/or powered touchdown? I don't see any landing legs. Landing on the heat shields? Decoupled legs?
Oh, I just noticed the parachutes on the aero tail for orientation!
-
2 hours ago, mc04 said:
they had six+ years to do 'core engineering work' and came out with a sim that at best functions about the same as the original. it is what it is at this point. if they really wanted to bring it to a wider audience they would've done far better as an expansion or remaster.
As I understand the history, it isn't safe to assume they do have 6 years worth of usable development work. In how the project changed hands, a portion, perhaps even a significant portion, of the codebase may have needed to be redone. We don't know and likely never will. We just know that more engineering work is clearly required and they continue to work on it.
1 hour ago, Scarecrow71 said:As far as this community goes, I wholly disagree. We ARE interested in the engineering and core loop fixes that they should be working on. Heck, we've been asking for this exact kind of communication for more than a year. We want to hear exactly what bugs are being worked on (KERB reports), where they are at with working on them, and what troubles they are facing with getting them fixed. At the same time, I'd also like to know why they exist in KSP2 but not in KSP1, and why they haven't chosen to look at the code for KSP1 and figure out how to reverse-engineer that as far as fixing these bugs goes.
Yes, I suppose many here would find it interesting, but still no one takes much pleasure in spending time talking about how they are further behind than they want to be. I can't blame them for wanting to keep focused on getting the work done so that when they have something good to share that can be the focus. It isn't good for anyone's morale either to have another post with minimal updates. Even in this thread some of the complaints that have come up have been that npt enough of the Kerb changed between weeks. Is it really that useful to make a post that is just "no significant news this week"?
-
I don't get the perspective that the goals for KSP2 are unclear. The design/creative direction for KSP2 are abundantly clear to me. They aim to bring the challenge and wonder of spaceflight introduced in KSP1 to a wider audience by providing better tutorials and inspiring goals through the mission system towards the notions of interstellar travel and collonization.
I don't know what people are expecting them to do with more interviews or explanations on the front of these core aspects. They've already communicated those plans. There's only so much they can say before they just rehash existing interviews that everyone here already watched or read long ago.
The specific functionality and nuanced mechanics within these systems can't be presented until they have something developed to present. This all takes time. I agree it would be nice if they shared more looks behind the curtain, but that's just not how they operate. At best I expect you'd get a "we're working on it / it's not done". It's hopeless to demand communication on functionality that doesn't exist.
Why it is taking that long and what delays they are facing are perfectly reasonable questions to ask though. They do seem slow and I suspect because much of the focus is on core engineering work that generally doesn't attract as much interest to publicize those efforts. It's in their best interests in damage control to communicate these delays. It's strange to me they decided to enter Early Access but to insist on keeping significant project challenges under wraps especially when charging a price that is likely very near release price despite an apparent multi-year additional development roadmap to finish.
-
So if I'm reading this right, the dart in some kind of multi-engine/asparagus staging appears to be the best. This matches what I found emperically when I experimented with a sample return build in the VAB.
-
I'm not sure I agree with the conclusions here. Is there anything that really isn't being built up above and beyond KSP1? In my reading of the plans, it definitely sounds like we are getting more of the former. I don't think it's accurate to claim the latter just because the game isn't done yet.
The only things I know appears to be changing relates to career mode with the removal of currency since it is redundant/obsolete by migration to reliance on resources. Contracts as a source of currency go with it since players will have their own goal-driven tasks for resource gathering.
-
I think the wacky physics simulator space is a lot more overcrowded than the somewhat realistic space agency simulation space. Colonies, interstellar, and multiplayers will do far more for the game's reach than robotic parts, IMO. Maybe after 1.0 as they suggested.
-
We're already getting rotating station parts. They appear like they will be largely cosmetic rather than for attaching parts to them for some functional reason. I thought I saw suggestion that we might get prop motors but not arbitrary rotating parts for custom building them.
I wouldn't count on any parts added just for the sake of wacky builds. There is still far too much game to focus on that dev time won't likely be spent on more toy-like elements.
KSP is still mostly a space simulation game, not so much an arbitrary physics sandbox.
-
Honest question: like what? I have 150 hours or so in game now and have not found the need for them. I managed to deploy a rover by just tipping my carrier vehicle over. Robotics seems like a low return per invested hour of development time in my estimation making it sensible that they aren't prioritizing it.
-
2 hours ago, Scarecrow71 said:
Mankind has been to the moon. Once. We don't have any real life experience in this area.
Uh what? Maybe I'm missing a point here since this statement is wrong, but we've landed several mobile craft on multiple bodied. None that I know of using tracks. I asked because given the number of rover missions, I though there might have been one, perhaps not by USA/NASA that did use them.
-
Are there any examples of tracked vehicles used in real space missions? I feel their complexity/reliability wouldn't be justified for their potential benefits. I don't see them as a necessity if they make wheel controls work well. Something more suitable as a mod I think.
-
I continue to hope that the silence and apparent slow progress is due to them recognizing these limitations and being hard at work at substantial infrstructural redesign of some of the core systems to accommodate the performance needs.
I see potential for batching parts for combined simulation, offloading background sim to other threads, and surely other opportunities to address performance needs while working around some existing bugs by essentially writing the systems responsible for the bugs in the first place.
I would have hoped that this kind of work would be precisely the kind of fundamental effort they would publically highlight to show why it is difficult, takes time, and is resulting in otherwise slow progress in areas that are of immediate attention for players.
The Comprehensive Colony Communications Archive
in KSP2 Discussion
Posted
If it makes sense for the long term, sure why not allow conversions. I wouldn't ask for any more than is absoluately necessary of the interim solution. The goal should be to release colonies in a state that is fun new content that players can experiment and feedback on knowing there will be changes for the future final version refined by the resources update. If this will include conversion options then including those now gives the chance to benefit from the feedback on this as a gameplay option.