CiberX15

This is probably something the devs have already thought of but I can’t help wondering if they need to move away from a real physics system for the parts of the craft. I’m very familiar with Unity, the engine KSP 2 and 1 are made in, having been working on a heavily physics based game myself for the past three years. And one thing I ended up doing on my game was moving away from physics sims in favor of scripted control when needed. Basically it’s the difference between trying to puppeteer a ragdoll vs simply animating an object. Both sides have their advantages and disadvantages, but it’s possible to milk the best out of both worlds. KSP 2 is clearly using real physics sims for all of the rocket parts connected to the rocket, and this is what causes the vast amount of bugs and performance issues in the game. Thousands of parts needing to be physically simulated while also colliding with each other, slowing the game down when they aren’t shaking the craft apart colliding with other parts of the ship. If all the parts were not individually simulated but instead all grouped into a single rigidbody (the component that tells the engine to simulate physics for a given object) then only a single calculation would need to be run per ship. Literally hundreds or thousands of times easier for the computer to process depending on the part count of the craft. This would be extremely stable, but also, perhaps a bit boring. While I tend to land on the stiffer side of the wobbly rockets debate, I do actually prefer some wobble. Not in craft that look like they should be stable, but when I build a giant noodle, I expect it to physically behave like a giant noodle. This is where you can get into faking it with scripted physics though. Instead of actually physically simulating every part, feed the forces into a script that makes them bend on their connection point based on how much force there is. For example, if the ship is turning, X amount of force is delivered in a given direction to a given part. The part would bend at its connection point. So at its base, or around a radial decoupler etc. Parts connected to that part would move with their parent and similarly bend from their connection points. Because this bend would be scripted though, it would be much easier to modify stiffness, making it completely rigid or complealty noodly as needed, without having to auto strut, which has a performance cost of its own. Since each of the components would have this script, they could be individually updated at runtime based on how big the ship is, to scale how noodly the ship is depending on how long it is. So stouter craft could be completely rigid, but noodles would flex as you might expect them too. This could even read from a setting in the options so that player’s could globally increase or decrease wobble based on their preferences. The bend could be scripted to never exceed a given angle, or break if it does exceed that angle, and that could be set on a per part level depending on how strong the part should be. Fuel tanks for example might never break but could flex to a given degree, whereas long antennas could flex then break off under too much force. The individual parts could also have their own rigidbodies but it’s set to kinematic (a mode that lets objects individually detect collisions but don’t get simulated and thus don’t eat as much performance). This would let the part detect when it’s colliding with something else and take damage on a per part level, and also pass that collision data back to the root rigidbody so it’s affected by the collision too. (Though there is a setting in unity that I believe is disabled by default that needs to be flipped on to allow child game objects to receive collision) Such a system would be a major MAJOR overhaul, but I think long term it would solve a vast number of the issues KSP 2 has been plagued with, in addition to the future problems they are already talking about running into when dealing with much larger craft.

I'd like the ability to create templates from my craft as we could in KSP 1, and optimally save them to the Favorites bar. I guess this is already possible with the merge save button but the saves system is a bit clunky to navigate right now. I just want to drag and drop a pod with a parachute and heatshield already attached instead of assembling that by hand for the hundredth time. And it's almost as tedious and time consuming to search through my saves, find the template file and merge it into my current craft as it is to just build the ship by hand again.

I mean I guess that’s partially fair. For science released on the 4th so it will be coming up on two weeks now tomorrow (Jan 18th). I admit that’s tight even for a hotfix. I agree 1-2 months is a reasonable turnaround time for non-critical bug fixes. HOWEVER, I think the reason the community has been so harsh, (I know it’s why I have been) is because of all of the “how did they miss this” bugs that they keep releasing with. I spent seven years as a professional quality assurance tester for a videogame company, and now I’m a software engineer myself. Whenever my company would push a major release we would always do a “playthrough test”. Have at least one QA tester play through the game like a normal player, if only for an hour or two. That always caught a massive amount of “how did they miss this bugs” because it’s easy to miss things like “The Science Indicator keeps blinking even when the science collected will be zero bug” when you are just testing the feature in isolation. I can almost guarantee the QA team read the spec, tested to make sure the icon blinked when it was supposed to, then called it completed. I’m not calling them out on that, that’s exactly what I would have done too. However, if they had gone back and played the game like a player, they would have hit the bug on their second launch, and asked, hey wait, I didn’t get any science for this, why did the indicator go off. Which makes me feel like they aren’t spending enough time testing the game like normal players. And the For Science release was pretty tame in terms of “how did they miss this” bugs. Previous releases were much worse, so of course the community is on edge. Maybe I’m wrong. Maybe they DID know about bugs like the science indicator bug, or the fact that lights don’t work until you quick load, or that staging doesn’t always work if you visit the map view, and either thought they weren’t severe enough to delay the release, or I’m mistaken about how difficult they are to fix. It’s just frustrating because there seems to always be a LOT of seemingly straightforward bugs along the core gameplay path. I do love the game. And I complain because I care. I will try to be patient.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 4.00 GHz | GPU: NVIDIA GeForce RTX 2070 | RAM: 32 GB I did a flight past duna with a probe core. No parachutes, no means of returning it to kerbin. Honestly didn't think it would survive. But it did. In fact not only did it survive, it ended up with enough fuel to make it all the way back to Kerbin orbit, which I decided to do since it had a little over 300 science worth of samples that I couldn't transmit. So once it was in orbit I flew a "rescue" mission up to the ship, eva'd a kerbal and got right up to the core only to realize, there is no interface for transferring science from the probe to the kerbal. So that science is perpetually locked inside the core with no means of being retrieved, since it can't be landed and it can't be transmitted, and it can't be manually transferred to another craft. I'd expect there to be a "collect science" button, either on the probe core or on the experiments themselves that would allow me to manually collect the samples on EVA, so they can be brought back in another craft. Included Attachments: .ipsImage { width: 900px !important; }

Reported Version: v0.2.0 (latest) | Mods: Flight Plan and K2D2 | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 4.00 GHz | GPU: NVIDIA GeForce RTX 2070 | RAM: 32 GB If I move my camera then use right click to rotate the camera, the camera moves. This makes it almost impossible to work on larger crafts or crafts that are not centered, as middle clicking will correctly let me focus on the part I want to rotate around, but right clicking instantly moves the camera away from the part I was trying to look at. Repro: Make a big ship Move it off the center position of the VAB Middle mouse click a part to focus on it Right click to attempt to rotate around the part Observe camera snaps to a new position. Included Attachments: .ipsImage { width: 900px !important; }

So I very frequently keep finding folders in the parts menu closed, presumably because I clicked the banner, but I don't actually want to close them. Being able to close them is a useful feature but I'd recommend making it so you have to actually click the arrow, not just anywhere on the banner.

The problem I'm trying to solve is I want to use a probe core to turn a staged launch boster around and fly it back into a suborbital trajectory. But the probe cores are almost always too small to do that. Unless I'm missing something, the probe cores aren't actually any better the bigger they get, and if you can build a 1m wide computer that can fly a ship, its weird that it takes an exponential amount of research to do that with an even larger computer? So my request would be for the probes to either unlock all at once (minus maybe the stayputnik which is kind of a tutorial probe and presumably intentionally unwieldy), or in tandem with the larger parts so you can always build probes to scale with the size of your rockets.

I'm personally not fond of how when going up and down time warp settings, it slowly ramps up or down to the target time warp. I find that makes it difficult to judge just how fast it's going to be going and by the time I've realized it's way too fast, I've already gone too far. Vs if it just snapped to full speed right away, I could see what that speed looks like and quickly hotkey it back. I'm sure this is a personal preference thing, but I'd really like an options setting to disable that ramp and just make it snap.

Ok so I understand that for a live production game the devs don't want to be constantly releasing bug fixes since you never know if one fix is going to break something else. I also totally understand wanting to go a few months between releases so the devs can go heads down and knock out new features. However, I think one of the stressors on the community is waiting so long between the little bug fixes. Stuff like engines staying locked after time warp, or spacebar not actually staging. Unless I'm missing my mark, these aren't bugs that take months to fix, but because of the update schedule and not wanting to make things worse by posting constant untested bug fixes, or burn time on repeated QA passes on tiny releases, these bugs just hang around for months, fixed on paper but still broken and causing headaches so far as the community is concerned. So my suggestion is this: Depending on how the dev team is branching the game, there is presumably a "main" branch, and a bunch of feature branches, and branches for various bug fixes. In between major build releases, keep a branch that includes the main branch and all the bug fixes, and release that as a Beta. Players would only download this version if they manually went into the steam Betas system and opted in to using the "experimental" branch, and thus would be accepting the risk that it could implode at any time because it hasn't been properly tested. Or create a similar option on the KSP Launcher. This has two major advantages. For the community, we get bug fixes faster, and the developers get eyes on the fixes sooner, and maybe shave off some of the rough edges before rolling everything into a full release. Obviously this could also be extended into experimental builds that contain unreleased features, such as base building... but I'll try not to get greedy here.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 4.00 GHz | GPU: NVIDIA GeForce RTX 2070 | RAM: 32 GB On multiple occasions I've pressed the spacebar to move to the next stage only for nothing to happen. Pressing it a second time usually correctly stages, but also sometimes stages twice, ejecting the engine I was trying to activate. Other times pressing the spacebar does nothing, most often when I'm on my last stage trying to open my parachutes, forcing me to manually open them one by one. Included Attachments: .ipsImage { width: 900px !important; }

I did find the buttons in the escape menu. For some reason I still find the buttons in the Mission Control window far more pleasant to interact with. I don't know if it's that they are bigger and easier to read, or if it's that it's one less button click to get there, but even having trained myself to use the esc button, my first thought when I want to change windows is to look if there's a button for it in mission control.

When planning a maneuver node, it would be nice if there were some shortcuts for common options. For example, a hotkey or button for "Circularize orbit" that automatically creates a maneuver to circularize the orbit at the altitude of the maneuver nodes start location. And similarly a "Match Plane With Target" button that automatically creates a maneuver node to match plane with the given target at the most efficient point in the orbit.

Ah well this might alleviate some of my concerns. I guess I always considered the delivery routes to be part of the OABs, but I guess there's no reason to assume that. Then I could at least build automated refueling stations in orbit. So my counter argument to this is that building the factory once / getting to a given orbit once is fun. Having to build that same factory or make that same trip more than 3 times stops being fun quickly. At least for me. Factorio solves this problem with templates and drones that can build the templates, so after a certain point, once you've built an optimal factory layout, you never have to build it again, you just stamp down a template where you want it and the drones build it for you. So to me the OABs would serve that same role. I have to get an OAB to a given orbit, then get an automated delivery set up to it, but once that work is done I don't have to make that flight again. I use that base as the beachhead to launch the next mission to even further reaches of the system. Building each OAB in a new orbit would be like designing the optimal factory, and once in place it would act like the template, never requiring me to do that same task again because I put in the work to solve it with automation. Our argument is really over _where_ in the game loop that tech unlocks though. Even in factorio the ability to build and deploy templates is kind of mid game content. However, in Factorio, the templates unlock right about the same time the factories you need to build start getting tedious to build. How much time does it take to place 3 buildings vs 30 etc. To me the basic launch to orbit in KSP starts out already taking a lot of time, and there doesn't seem to be a great way to speed that up that isn't unrealistic or un fun (You can use bigger engines and go faster but that's inefficient and also risks burning up your craft if you get going fast enough, so the mechanics basically reward you for going slower not faster), so to compensate I'm recommending moving the automation closer to the beginning of the game to compensate.

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz 4.00 GHz | GPU: NVIDIA GeForce RTX 2070 | RAM: 32 GB Ok so if I have three stages, Parachute at the top, Engine in the middle, and Decoupler at the bottom, I want to drag the stage containing the Decoupler in between the Engine and Parachute stages. However if I begin dragging and release with my mouse in the gap between those two stages, it won't work. Instead I have to drag it to just a pixel or so above the Engine stage. This makes it a bit finicky to move stages where I want them. I would expect the stage to move if I release it with the mouse anywhere in between two stages.

Kind of but being able to dock with an orbital fuel depot doesn't solve the tedium problem if I have to make constant manual flights up to refuel the the fuel depot. Which is where I think the core difference is between us. I find manual launches from kerbin extremely tedious. It's a gameplay loop I've completed a thousand times and don't want to have to do a thousand more times to unlock the privilege of not having to do it anymore. To me the whole draw of KSP 2 over KSP 1 is the promise of being able to automate away tedium. The game Factorio does this the best. Introduce an extremely tedious gameplay loop, then give the player automation that takes all of that tedium away. But if that automation is withheld until late game, then it's just an extremely tedious game. Look maybe this is a case of having my cake and eating it too, but I don't want to just play sandbox. I find sandbox boring because there's no goals or progression. So I'm not saying I want progression mode to have less progression. What I'm saying is I think having OAB's earlier in progression makes for a more fun progression arc.