steveman0
-
Posts
181 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by steveman0
-
-
6 hours ago, Superluminaut said:
There are certainly still many problems with the game. Loading bugs and kraken encounters, I don't believe they fall under wobble. However I have not seen exactly what you have seen. If at all possible please share a video so that we can see if sudden, unexpected instances of wobble do occur.
I have not put a whole lot of time into KSP2, it's still too frustrating for me to relax over, so from my perspective it may be entirely possible that that it's still out there.
I don't have any video on hand for this, but it basically is a spontaneous wobble of a ship in orbit that oscillates with increasing magnitude until the craft shakes itself into pieces. At first I suspected SAS, but I've seen it on craft with SAS disabled. Time warping can suppress the effect as this halts the physics sim for this motion. Some stray calculation is causing a runaway feedback loop until the craft tears itself apart. It's most prone on large interplanetary craft. My largest had 3 instances of this effect in one game session. I'd have to see about setting up OBS again to try to record it. It's quite random when this occur so it might not be something that can be easily reproduced.
-
The new joint physics are a massive improvement. Most "traditional" rockets I build never need struts. Only some really massive asparugus staged rockets might need a strut or two to reinforce the boosters to keep them from flexing and colliding with other parts. This seems perfectly reasonable to me.
There's definitely some remaining physics instability with craft in orbits though. I too have seen craft shake themselves to oblivion spontaneously. This suggests the algorithm for the wobble is still mathematically unstable. A stable craft would have mechanical dampening from friction and bending stresses that should prevent spontaneous shaking to pieces unless a substantial input force was involved. These flexing forces should include some kind of dampening factor to ensure the runaway wobble isn't possible.
-
I don't think about ejection angle. I just ensure ejection is aligned with planetary prograde or retrograde on escape. I think that's good enough not to worry about angle to the nearest degree.
-
41 minutes ago, DonLabs said:
friction force is coefficient of friction multiplied by the normal force. (Fk=Uk M g) . So if coefficient of friction remains the same on another body (if the materials are similar like a certain type of rock), but the gravity is lower, then the normal force will be lower and hence the friction force will be lower. Normal force is gravity multiplied by mass and acts normal to the surface (perpendicular to the surface). So on a slope the normal force will be gravity multiplied by mass multiplied by the Cosine of the angle of the slope. Fk=Uk M g Cos (Theta). So smaller gravity means slippery slopes especially when the gravity is very small like some moons in Kerbin system.
This is making the rather substantial assumption that you have a simple surface to surface contact that you can continue to slide over. Realistically, if the legs of the craft were sliding on a dry, gravel surface, the legs would begin to dig into the surface/become covered in rocks increasing the friction until firmly planted. I would go so far as to say they would be designed to do this. From this point of view, the landing legs themselves should function as a kind of anchor if the craft shifts more than a short distance.
-
I think KSP2 as a game is shaping up nicely compared to KSP1. The tutorials, tech progression, and missions are great. Colonies, resources, and interstellar all are very promising to leapfrog the foundation that KSP1 laid. And of course multiplayer for those who are looking to that.
I still find it odd how they released the game in the state that it was in and how even now there are many gameplay breaking bugs that will turn off all but the most dedicated player from playing even in a sandbox context. It's kind of baffling that it remains this way as I can't imagine how frustrating all the bugs are from a development perspective and how much these would interfere with new development. Trying to troubleshooting new bugs and work on gameplay balance is surely less efficient when there are many existing bugs that can regularly impact gameplay as to interfere with basic testing.
Despite being an Early Access title, there is still an expectation that the game is playable given the publisher/studio size and price tag. The number of game breaking bugs certainly puts this status in question for a non-negligible fraction of players. It doesn't help that they maintain a relatively low turn-around on patches compared to other EA titles that many would come to expect especially from a game with the magnitude of some of the issues. There is an intrinsic expectation that large issues get resolved quickly before returning to content development. It really didn't help that they hyped up the game prior to EA announcement as being something that would be released as a 1.0 product giving the impression they were much further along than they were. The marketing team simply did a terrible job managing expectations.
-
3 hours ago, Superfluous J said:
Not if you bring them up from Kerbin and attach them in space
You could build everything but the expensive stuff, and then custom order the expensive stuff from Kerbin where it's free.
Though we don't (and won't?) have EVA construction like we had in KSP1, where you can just take any old part and slap it on your ship. So you'd have to I guess pre-build the plate with the engines on it, and then launch that from Kerbin to dock to the engineless ship at your orbital shipyard.
You're assuming they will be free on Kerbin. I don't imagine in the long run that will be the case. I also wouldn't bet that the resources to build the nuke engines will be readily available on Kerbin either.
-
These are just due to bugs though. Once the bugs are fixed, there will be no need for SAS while landed. Better to devote the effort to fixing the bugs.
-
Rearchitecting something as critical as the threaded architecture of the game is not something I would ever suggest. I would hope they planned these requirements out early on if there was going to be any migration to a new threading design. It can be a nightmare to take single-threaded code and rework it to be threadsafe and communicated across thread boundaries.
In Unity's case, the less graphical/GameObject-specific code you run on the main thread, the better. I would hope (without having looked into anything theu've done so far) that they already leverage threads for any work not intrinsically linked with GO manipulation. Simulation math is ideally offloaded to another thread only using a proxy to tie back to a rendered object. I don't know anything about how PhysX ties into this though. My only experience is with an entirely proprietary simulation engine divested of the Unity core.
-
1 hour ago, Biggen said:
Definitely not fixed. I'm experiencing it right now trying to do a rendezvous. My actually PE is 1km lower than what my PE shows on my map screen and its throwing off my nodes greatly.
That sounds like a different issue. Orbital decay is very obvious as you can watch the AP/PE drop in real time in what should be a stable orbit.
Seems like it could be a mod issue. Maybe a mixup between sea level and ground level altitudes or something of the sort.
-
1 hour ago, Biggen said:
We keep talking about “polish” but they have game breaking bugs that need tending to before new content is pushed out. I’d say docking issues, orbital decay, parachute issues, all need correction before any new content is developed. And these are only just three items. I’m Sure there are even more I havent discovered.
An engineer responsible for multiplayer net code is not likely to be as capable of figuring out orbital decay better than the one responsible for the physics sim nor better to figure out docking and parachutes than the one responsible for parts. It only makes sense that the work is distributed among the developers best suited to address each issue. To a player, it will appear as though things take longer than you think they should, but as a team it likely means much faster progress on development as a whole. I would like to see them heavily focus on the bug fixing as well and I hope the developers well suited to doing this focus more on bug fixing than polish at this time, but this still might be only a fraction of the team and they might be dealing with some of the most elusive bugs.
-
Given the pace of updates so far, I've always suspected that they are working on a lot in the background in parallel rather than full focus on immediate content and fixes. We know they have been working on all of the major milestones at least to some extent since alpha. I assume they've distributed this work among the team. I'm hopeful, as Nate himself has optimistically hinted at, that completion of individual milestones will accelerate as various team members on these pieces can devote more of their time to later milestones or bug fixing/polish.
Additionally, the scope of their plans might require some fundamental changes to how some core systems work such as rocket physics some aspects of the rendering. We might not be seeing bug fixes and performance improvements in some areas in anticipation of replacing obsolete pieces of code with major revisions once they are ready.
-
Forgive me if this turns out long, I've spent a lot time thinking about this over the last years as colonies, resources, and supply lines have been some of the most exciting features planned for the game. As I see it, there must be constraints on Kerbin in the future given the stated design plans.
So stepping back for a second, we don't know too much about the resource plans and how colonies will be managed yet. What we do know is that one of the plans is to enable players to build craft to fly between places carrying resources/kerbals and on successful completion of such a flight enable automated repeating of the flight plan to serve as a supply line of the resources transferred.
From my view of the design, this more or less forces Kerbin to have some form or resources constraint to avoid trivializing the entire gameplay mechanic of supply lines and resource extraction. Players have already demonstrated rockets that can haul payloads of hundreds of tons into LKO with no resource restrictions. If all resources remained unlimited and free on Kerbin, there would be little to no incentive to build colonies elsewhere for resource extraction if you could simply setup a supply line from Kerbin with hundreds of tons of the stuff. Kerbin is already fairly central to the Kerbolar system with pretty reasonable dV costs to fly to any other body in the system. Interstellar might be the only situation where this logic breaks down, but this is far enough in progression that I doubt they'd trivialize until that stage.
For reference purposes let's call this state of infinite resources of any type as Resource Mode 1 - the current state and as argued above, not really sensible as a solution for the future.
The next least restrictive option, Resource Mode 2, would be to allow common/low tech resources to remain infinite while applying at least a partial restriction on the rarer resources. While this would disincentivize setting up supply lines from Kerbin by limiting payloads, if the set of resources that is infinite includes everything needed to build at least a basic rocket, players will find ways to build some monstrosity that can still haul 100t+ payloads for free to orbit. Consider also that we will have orbital colonies. If you have unlimited resources on Kerbin, you can haul this to an orbital colony where a much larger shuttle could then transit these materials to other systems with the only cost being fuel (unlimited) as this shuttle would be entirely reusable. This too doesn't seem to make much sense as even low gravity Minmus becomes negligible for setting up operations unless it has some resource Kebin does not have in unlimited supply.
The last I'll group into Resource Mode 3, where all resources are at least partially constrained. It is only here that the gameplay concept really works. Limited resources will prevent unlimited launches encouraging preserving these for more important missions. If the large 100t payload launch consumes all of the resources you generate in a year, you'll be more likely to send components to Minmus to build mining operations to generate the equivalent resources there where they could be cheaply launched to a staging orbital colony for distribution. This will be especially true if it is more resource-cost effective to build up a Minmus colony than it is to upgrade the KSC colony - as I stated earlier, I could see KSC upgrades requiring returning rare materials back from other planets to benefit from the long term advantages of increased production from home.
Now going back to the root of the topic at hand: currency. Given the above, resource mode 3 makes the most sense. In this environment currency itself isn't strictly necessary and it is understandable to me why it isn't being considered by the team. I think there are more fundamental questions that would need to be answered to understand how currency would fit at all. Unlike KSP1, we don't have procedural, repeatable missions to earn currency. There has been a fair bit of criticism of these for the repetitiveness that they provided to the game. I admit that this would be alleviated in KSP2 if these missions could be completed by automated launches much like the supply lines, but then what does this accomplish?
So other than missions, how else would you get currency? Selling resources? I don't see this as a good solution as it could encourage unusual solutions like mass mining on Minmus as your only major mining operation, selling the resources and then using your effectively infinite money to buy anything else leading into a quasi resource mode 1 state. What you could buy with currency would either need to be restricted (quasi resource mode 2) or have exchange rates that made the whole process of selling resources somewhat meaningless. There's probably a balance where this could work, but I expect it would be tough to achieve this in a stock design leaving players to have to figure out where to put the difficulty slider where they find it works. I'm not a huge fan of developers pushing gameplay balance onto the player - it's great that the player have the option to adjust difficulty settings, but the default options should make for a good well-rounded experience for most players.
I think I'll stop here to keep this from getting too long. With so much still hidden behind the design curtain, there are infinite ways we could speculate everything to work. I find the team did a lot of things right from a gameplay perspective with For Science!, so I'm optimistic they have great plans for the future with resources and colonies.
-
1 hour ago, Superfluous J said:
I expect they're not planning on having the KSC be upgradeable or changeable, as the focus in KSP2 is not on Kerbin but on setting up interplanetary and then interstellar colonies.
KSC is already a colony though. Although I could certainly see it being a special exception, it seems like it would be trivial to treat it like any other with it having the same or at least similar options for upgrading. This would be a rather easy system to leverage for progression's sake.
-
I could envision a design where production rates on Kerbin are very limited early on but can be upgraded, maybe very much like any other colony, using resources only obtainable from other planets/moons. For example, maybe helium isn't available there at first, but some small production of it becomes available when you upgrade local power production using uranium and mining operations from some other exotic metal.
This might be true of other colonies where the array of resources is diverse but each place specializes in select ones unless you upgrade to enable extraction of some rarer ones.
-
I think colonies and resources will bring some more value to the labradoodle. The terrier and poodle get a lot of use for me in part because their low profile makes them great engine choices for landers. I anticipate the same from the labradoodle. We just don't have much reason to build landers of such a size that uses a large engine (although I did for Tylo). The tuba and other deep space engines make sense for interplanetary transfers, but wouldn't be very sensible to try to land.
This is where math can only optimize so far. Mission design is more than just TWR and dV. How you will be using the stages of your craft are a big factor. The poodle is great because it can serve the purpose of an orbiter stage all the way to a landing if needed. One engine for two jobs shifts favor in a way that the TWR and dV alone can't account for. It's the same with engine bulk. The NERV and SWERV offer great dV, but you can build a very easy to fly and low drag (slim) rocket that uses the deep space engines. These advantages are harder to quantify and are very dependent on your mission requirements.
-
But what are better settings? Even with just the handful of posts in this thread there are recommendations to reduce both springs and dampeners and increase springs and dampeners. I'm not sure which actually would work best without doing a complete live experimental test at touchdown using quick save/load.
Intuitively, the ideal spring setting would vary with the overall craft weight on the landing body adjusted based on how many legs you use as you only want it just strong enough to support the vehicle with full travel of the legs. This isn't something that would be obvious for me to select given a new build and new planetary body that I'm planning to land on without at least some rule of thumb. Full travel of the legs will vary depending on the dampening, which to me seems like should be something you always turn to the max as you want to absorb as much energy as possible with as few legs as you need for balancing the craft.
I might need to do a controlled experiment at some point with all variations just to understand how these work in practice.
-
6 hours ago, Emanuel01 said:
I’d enjoy if aerobrake and gravity assists were covered by missions/tutorials. I think these advanced maneuvers play an important role on the emergent gameplay features that show up once you really start to learn the game and it would be nice if they are made more digestible to the average player.
These were the first two I came here to post. For additional context, my first trip to Duna did not use aerobraking to capture as I simply didn't have a good idea what altitude to aim for to make this capture. Too high and it does no good, too low and you are burnt to a crisp. The tutorial providing guiding rules for this would have been a big confidence booster to try this rather than overbuilding for enough dV to capture without aerobraking.
Similarly, gravity assists are a hugely beneficial technique that can greatly simplify other aspects of mission planning as you can use much simpler rockets even for deep space - or just get yourself out of a bind if you spent more than your budget elsewhere.
Another major challenge for me was and still is precision landings. I hope that we will eventually be able to set the waypoints as targets eventually to be able to get access to the target icons on the navball. Having the relative velocity vector would make it immensely helpful to land on target. Seeing as the process for this is similar to the retrograde burn on final approach in rendezvous for docking, one tutorial at the end of a set to cover of this can be applied to precision landings would be great. Teaching the player how to use the retrograde burn to "push" the velocity vector to align with the target is a critical skill and would be great to have for all of the required precision landings.
-
99% of the time I am using a fairing it is to enclose a payload craft above it. It would be great if there was an optional button that made the smallest enclosure for all attached parts above the fairing to avoid the process of doing it manually.
-
1 hour ago, krbvax said:
Well shucks, there goes my plan to explore Kerbin's ocean floor...
And my backup plan when my chutes fail to open!
-
I'm sure I'm not using the 100% most optimal engine for all scenarios. For many problems "close enough" is all I need. With many small transport craft in the medium size category, the poddle is the natural fit. For more optimized landers when I need it, I've gone with engine plates with arrays or by adding an extra radial where it makes sense, but many situations don't require that degree of effort. I also do a lot of overbuilding that allows this. I put in much more effort when I'm working on a tightly designed mission.
I am really looking forward to resources in part as I expect it will encourage much more efficient mission plans and optimizing craft design such as engine selection. I'm sure I'll diversify my selection more as I refine those builds. I'm still relatively inexperienced compared to many KSP veterans with only ~250h total between both games.
-
3 hours ago, Oak7603 said:
Is that on normal science rewards? I am in Eeloo orbit right now although this was just a flyby so no surface landing possible. So far I've done high orbit crew observations, environment data, environment samples, radiation measurements, orbital survey, and orbital survey samples, as well as low orbit crew observations, environment data, environment samples, and radiation measurements and that is only 4600 science in total. I got 8000 for doing the Eeloo SOI mission. Where is there another 26000-41000 science at least?
On the surface of course. The vast majority of science comes from surface biome collections with the most coming from the largest science instrument you need to land with (radiation scanner). You're supposed to explore the planets, not just pass by for a look at them! The biggest rewards come from the biggest efforts, and there is no greater effort than to land and return at multiple biomes. Based on rough estimates I've seen for the total collectable science, there's something like 2x the amount of science to collect from all planets and biomes than is necessary to complete all the research tree without doing any missions.
-
The poodle is one of my most used engines! Good vacuum performance in a great form factor for small orbiters and landers. Even in T4 tech I find myself using it as it's just a good fit for the size of tasks it's suited for.
-
Sounds like very good reasons for docking mode to have a clear UI indication of state, as this has always been the cause of this kind of "loss of control" for me.
-
Yeah, I've noted some appear to be redundant or obsolete. There are a few with a better power per data ratio that make them worth considering if you will be power limited, but there isn't a clear pattern of progression for this. I feel like it should be pretty straightforward to design tradeoff options between size, power, weight, efficiency, and tech tier but in scrutinizing the numbers they all seem to be all over the place.
You could build everything but the expensive stuff, and then custom order the expensive stuff from Kerbin where it's free.
Docking problems i see that there is problem with docking craft on orbits, it's buggy and stowaway kerbals always try manning my Lunar or rather Munar module xD
in KSP2 Discussion
Posted
Define "buggy". Aside from craft center of mass not lining up properly resulting in instability in how the game reports the navball target vectors, I haven't found rendezvous or docking any more or less difficult than my experiences in KSP1. I've heard there can be issues with undocking, although I have not encountered this myself.