PDCWolf

Panning would move the craft less than moving the navball all the way to the corner, and works both ways, not just left to right.

And you move the camera over and you can see whatever you need to see, which is even better if the navball wasn't uselessly bigger than it needs to.

That's not a navball, that's a GPS top-down map. Good try though.

Again, that is still informed by the current, uselessly big navball. It shouldn't take a third of your screen. You can pan, zoom, and even tilt the camera with the hand you already have on the mouse, there's not a single situation where the navball would leave you blind because you have the tools to fix the camera to your liking and specific to the situation you want. For me, that's way preferable to losing sight of the craft to look at the corner of my screen. Rude, probably ableist too. I thought I made it pretty clear that I'm for moving the altitude from the top of the screen in KSP1. Again, kinda rude, definitely ableist. Yo do not know how good or bad my vision is. Go forbid games go for accessibility trying to keep UIs compact and not all over the place.

Which of course is going to be an issue if they keep it as such a useless waste of space. At least I hope they make it moddable so people with real training in flight interfaces can get a crack at it, unlike KSP1. Lmao, instead of dragging down drag to the side then. You can drag the view on all axis on KSP1 with the middle mouse, no need to remember half the numpad from memory. Gotta love the cope-bashing. Which means the craft picture is further on your peripheral vision and thus less clear. A brazilian man working on an indie project after 8 hours in the office got it right after starting the wrong way:

No, I hate it because it goes against everything you learn on the cockpit of an aircraft. You center your view to see the instruments and have all the information at a glance, you look around to see outside and assess your situation. Really, just check pretty much any cockpit. Even in fighters they invented the hud and later on JCHMD so you can keep the information right in your face where it needs to be.

In KSP1: Middle mouse click, drag down. There you go, and you get to keep the navball where it should be. In KSP2 the problem is they made the navball at least twice as big as it needs to be when you include all the elements randomly thrown with huge spaces and unnecessary tapes around it. Having it at the center means the picture of the craft is closer on your peripheral vision as well. Good luck handling that on bigger resolutions.

Nothing I hate more than the external camera UI in MSFS. The whole UX of MSFS is really bad, yet it still replicates some of the lessons I mentioned: All the *tapes have useful information in them other than just a moving tape. You can also see that this UI lacks the artificial horizon, which is the object that should take the center (in place of the navball, which is almost a complete analogue). "Real life UI" on things like airliners and fighters is made to be as functional as possible whilst not cluttering the view. Game UIs don't follow that because... reasons.

Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5 3600 | GPU: XFX Radeon RX 6750 XT Ultra | RAM: 32 GB Issue: Mashing the pause screen during quickload of an in-flight scene pauses the loading process. Steps to Replicate: Create or procure a quicksave of a vessel in flight (so far testing shows it works on any save in flight). Load the save (works from main menu or hitting F9 whilst doing something else). Mash the timewarp down key (comma) during the loading process. The loading process will pause at "Applying legacy module data to vessel parts". You can press timewarp up to resume the loading process, continues as normal. What testing I have done: Two different quicksaves created during flight. This is can be reliably replicated both when the saves are loaded from the main menu and also when pressing F9 to reload the quicksave. Additional Information: Originally discovered trying to pause a bad situation before the scene was fully loaded. The scene starts playing before the loading process is shown as complete, and control is given to the player for input about halfway during the loading process. The sound of stopping the game correctly plays during the loading screen. The loading will continue until the message "Applying legacy module data to vessel parts" and then pause. Can be resumed without apparent issues. The pausing itself also seems to cause no issues. Included Attachments: .ipsImage { width: 900px !important; }

Edge case? damn does reality change. Oh wait, reality didn't change and multiport docking was the common way to build big ships in KSP1 if you didn't want to launch them all assembled [1][2][3][4][5][6][7][8][9][10][11]. It was pretty common in KSP1 before autostrut, plus this was reported month 1 (and not even by me). I will concede that people have almost no interest in making big ships, as it's either launching them through the slog or having them wobble like wet spaghetti. Ah yes, specially with the SAS wobbling your craft all over and the phantom forces from reaction wheels being huge. This is no fun if people will outright disguise reality just to have a point.

I'm still waiting for the promised multiplayer for KSP1 as well. Also everyone who got KSP-EDU has probably died in wait as well. I wonder... who took on those obligations after purchasing the franchise? why were those never addressed again? Hmm... Btw, we're on our way to 9 months... this is still the state of docking: https://streamable.com/e31wah

I refuse to judge KSP2 based on the dreams of community members. Heck, it's finally a pretty mainstream opinion even in the forums that it is not reasonable to 100% believe the official statements either. That's 8 months of building trust right there. It'll stop being a non sequitur when people start actually playing the game for real on long term science/exploration saves. But hey, you can talk about future imagined optimizations and I can't talk about a very real issue that's currently in the game waiting to explode? (did once already, too). May I know what you call nonsensical placements? You mean the navball and vital information such as speed right in the center as it exists on almost every plane or spacecraft cockpit? Again, altitude I give to you, that's bad. I mean, if you're talking from a different timeline, might as well make it clear now, because you seem to live on a completely different reality. Probably born from not leaving the forums, which is a common problem. Normal cockpits might have a compass, altitude and speed tape, yet again, in real life they know those elements are not there to be pretty, and they should communicate information in a fast, compact and concise way: In real life, on a PFD, the speed tape exists to communicate overspeed, selected speed, current speed, and even acceleration. In KSP2 the speed tape does nothing but exist behind the one useful number it shows. The compass tape also communicates other elements, like selected heading. In KSP2 the compass tape exists as a huge useless element and the one thing it should communicate is a number which in KSP2 is sitting outside the tape, not even in it. An altitude tape shows your current altitude, selected altitude, vertical speed, and in some cases terrain altitude too. In KSP2 you need to hide one number to show the other, and the altitude tape exists only as a background element that does nothing useful. In real life, all these elements are presented in a compact way, on a single square screen that doesn't waste any space, yet shows all the useful information without overwhelming the pilot. In KSP2 it looks like someone hit the explode button, with every element taking useless space for no reason. Here's a real life PFD as an example. It sits centered in your view, so you just look down and see it, and can derive all your information from it. In the worst case, it's on one of two or more screens, but you can select on which to display it. It's the same engine, but don't worry, hating on Squad and KSP1 after getting thousands of hours on it is the only cope that has been found to justify KSP2, even though KSP2 is still the worse product of the two.

Loading times are only barely true if you keep your save clean. As part numbers and saved craft build up, KSP1 manages it so much better (on account of keeping track of less stuff, but still). Engines burning in warp is so far irrelevant, and comes at the cost of save game bloat, and a very hard limit on total parts per save before the game outright stops wanting to load, which is also why we constantly get teased "all in one" parts, like the ones on the science system. Just on that front alone, the game has shot itself in its foot, and it took the registry debacle for them to realize their "design decision" was actually a pretty firm nail on the coffin for the longevity of the game. Whilst I dislike the altitude at the top in KSP1, just moving that over would mean KSP1 has a better UI than 2 (bar the design language itself). Further than that, since before release, the complaints that the UI is bloated and over-exploded have been almost ubiquitous. Love how they listened to that, as a year later the UI is still filled with useless instrument tapes, and feels more like a 90s website with funny noises than a professional product. KSP2 is still using the same "load everything in at the start" method that KSP1 used, the only thing missing here is 80% of the game and mods. The "acceptable RAM usage" is just because of that.

You don't need to get into roadmap items. There's been feedback on the UI, playability, QOL, physics and so on since day 1. If something wasn't a very obvious bug, that feedback hasn't been addressed neither positively or negatively.

My question was more geared towards how little feedback they've taken in on what they have already out, much less on what they don't have. Adding more parts is the most basic thing. Really the biggest thing that's not a bug that I remember them taking from feedback is the public bugtracker.

I think "only 7 science parts" is a symptom of a bigger problem, in the same way science is still going to place with parts loaded, and right clicking. Sure, it takes time now and it is done with a single button, but that's just basic QOL. They've copied the flawed science system from 1, and merged it with the flawed contract systems from 1. This means they need pretty much a miracle bundle of good design choices to extract some fun back from what were two very bad things in the prequel. Further on I ask, will they keep developing FS! after it's launched? will the science aspect of the game get updates as the game moves forward or whatever we get on december plus a couple fixes is what stays? As always, my angle is whether KSP2 is justified in its existence (if it's not gonna fix the problems from 1), and its price, which "feature parity" is not a justification for me, it should be better, it should be bigger.

Which is exactly why later on I wrote "there's little hint so far that any more care has been put in KSP2s planets other than disjointed discoverables/easter eggs." I was talking about KSP1 indeed on that paragraph.

What happens in NMS happens in KSP as well. Moho is the desaturated red ball, eve is the purple ball with metal oceans, Kerbin is the one with the most variety because it has a desert and poles but that's it, Duna is the red ball and the only variation is the frozen poles. Dres is so boring that most people meme it doesn't even exist, Jool is a gas giant so you can't land on it, and so far the cloud layers aren't anything to write home about, vall is the ice ball, laythe is the sand and water ball, tylo is a big mun, bop and pol are just asteroids like Gilly, and Eeloo is the mun but ice. Every planet is just one biome, with 2 or 3 bodies including frozen poles. Every planet has no more than 1 or 2 memorable spots. After you go past one or two hills it's just more barren wasteland of the same color and there's little hint so far that any more care has been put in KSP2s planet other than disjointed discoverables/easter eggs. You should try the latest versions of Space Engine, the surface looks decent now, whilst still being completely procedural, and Vova is implementing weather systems for data like winds and temperature to make sense.

Lots of people lying to themselves here. ED has planet sized planetary bodies, for example (Horizons launched 2015): No Man's Sky launched 2016, has Kerbal-sized planets: Space Engine launched 2013, has planet-sized planets: That the game looks dated is an objective observation. Whether you take the cartoony style into account or not.

Nitpick, but 10th-of-a-planet sized bodies Still, even through procgen you can create beautiful stuff, like on Space Engine, which is now 13 years old.

Unrelated to the report at hand, but in Spanish the standard is qwerty, and in Latin America we use a Standard for the whole region that includes ç and ñ as physical keys, and changes the disposition of []{}¨Ç^*´ç`+ which are between P, Ñ and Enter and Shift. (Red circles aren't mine, some symbols may vary)

Okay let me rephrase. First off, I don't think they coded in such a problem willfully, wanted to clear that up. My point is: You have the system already coded (fuel logic from KSP1), and you have unfettered access to the bugtracker both public and private to see which problems it ran into. So you know making the fuel logic behave a certain way is gonna make the game chug when you spam engines. It's no longer crashing against a new issue, it's repeating a well known and probably even well documented one in a system that's supposed to not be the same as the last. I don't believe in "we're organically finding the same issues" without also having to take into account that they are either ignoring that the issues were there, or worse.

But you know the problems KSP1 had, why program them in again?

"it is my understanding there's no holdover code on that [fuel flow] system at all, that we're organically encountering the same challenges that KSP1 is facing, because we're attempting to simulate fuel flow across in some cases some very complicated trees." How is a listener supposed to take this? You have the first game, you can look at the code of the first game, yet you develop an allegedly new solution that has the same problem, even though you know that barrier is still there? There's no good way to take this. "I can not make a categorical statement that nobody has copypasted any code between KSP1 and KSP2. My understanding not being a person who can look at code myself is that there's little to no reuse. Perhaps if other people are performing a forensic examination of the codebase and determine there's significant code reuse I'd be very curious to hear about that". Nate, you know it breaches EULA to look at the code, and it's even illegal in some countries... "If a feature could be replicated at relatively low cost by duplicating it from KSP1, I'd be eager to do that. That's one of the things that's made KSP2 complicated is that this is very rarely possible to even theoretically do that, because the underlying systems are so different". And then ShadowZone reveals they're using the same middleware as in KSP1. Lmao. That's probably another reason they decided to stick with unity, having to depend on third parties' software that might not be available anywhere else, much less if they went custom.