MarcAbaddon

Me too, but we are all not native English speakers.

I am not that impacted in my interested either, but I think there's a definite risk to this approach. While it may work for really young kids, once kids are 12 or so a lot of them are trying to act all mature and cool. At that point it may turn them off more than it would an adult.

If your tank is a simple cylinder with a simple procedural texture, than yes, just making tank design procedural is simple. But if you want to add some details and stuff it becomes a lot harder, especially if you want to make it look nice. The more structure and details your part has, the more complicated it becomes. To give a simple example, you can't just procedurally scale a one-family home to get a skyscraper. Tanks are just on the border where it might make sense, while I'd say that with engines you definitely want to keep them non-procedural. EDIT: at the same time I think the laziness argument is bad, especially with fuel tanks. There's plenty of creativity in KSP 1, but little comes from sometimes having to use 2 FL-200s since you do not have the 400 unlocked yet.

After watching the latest Matt Lowne video, another thing I honestly find concerning is that KSP 2 exactly reproduces the annoying veering to the side you experience on the runway with tricycle planes during takeoff from KSP 1. Fixing and improving wheel physics was one of the most commonly mentioned wishes for KSP 2. That Matt did have to point out how to change the wheel setting to avoid it by adjusting friction doesn't really help. Seems like something the dev team should have been aware of. So I do see some nice features in KSP 2, but at the moment the physics simulations seem as wonky as always. Additionally, the way his plane spun wildly in orbit (despite integrated reaction wheel in the cockpit) wasn't great either.

All in all, it looks to have some decent features, but I am overall a bit disappointed. Not enough to be put me off the game, but I'd have expected a bit more than what we seem to be getting. The performance issue is a bit concerning - I am sure there is a good amount of optimization to be done, but at the same time the game is also supposed to handle a lot more gameplay systems and larger vessels than we have right now. So they need to optimize by more than the complexity will increase. And while I didn't expect science, resource extraction (including claw) robotics or anything similar at this point, but I *would* have expected entry heat and thermal shielding, proper RCS and much better vessel statistics in the VAB. Not calculating TWR is really weird. How are you even supposed to see whether you have enough thrust to lift-off? Admittedly, entry heat is supposed to come soon, but I would still have expected a bit more features.

Well, I for one was hoping to see at least a few more features we don't have in KSP 1. I wish the reviewers had focused a bit more on thinks like the thrust in time warp we are supposed to have. Game looks decent, but it struggling at a bit over 100 parts on that kind of machine is troubling. Looking at the example possibly it doesn't deal well with multiple engines running at the same time. That'd be a good thing, because it'd be more easily fixable than all around bad performance. Once of the most important things to test right now is whether performance degrades with engine count or part count. Loading seems snappy after the initial load screen. And there was a lot of clipping throughout. Main issue for me at the moment is that it doesn't really have any progress mechanics. It's just sandbox. Even something as simple as milestone-based part unlocking would have been nice to have in from the start. It's not just good for having to work for something, but it also helps newcomers not having to deal with that many parts at the start.

You can't, but additionally you won't be gathering money anyway. It's not a thing in KSP 2 anymore. And science isn't in the first version of early access, so we don't know yet how the science system will work. But I hope they won't simple copy the KSP 1 system and duplicate the parts. I really want science parts to be stashed away more neatly, more passive collection and definitely less biome hopping.

I'd be surprised if there are not at least degrees of how much physics get calculated in different time warps. It's hard to imagine the full physics simulation (e.g. for the forces on the joints and stuff) for the rockets running at a very high multiplier. Just allowing thrust under time warp is a lot easier, thought here are some cases to consider, e.g. thrust not properly aligned with the center of mass or thrust that would induce too much oscillation in full physics. If you are mean to the physics engine you could even build a vessel where the center of mass starts moving away from the thrust axis once you have spent 50% of your time. But just assuming thrust is properly aligned and adjusting speed, orbital parameters and weight under thrust while time warping is relatively easy in comparison.

How much of the KSP whackiness with wheels is due to homebrew KSP code vs the Unity engine anyway? There are probably good games using Unity with don't have whacky wheels, but tbh the KSP setting if fairly unique with the rugged and roadless terrain, varying gravity (!) and varying weight. In other games you'd probably just need to fine-tune the wheel parameters once. If it's Unity, do we know if they have improved their wheels since the fairly old version that KSP is using?

What's the exact complaint here? That the program recalculates it at all (wasting a neglible amount of CPU time) or that the recalculation gives different results each time? I could understand the second one would be an issue. Given that I usually run a pretty heavily modded setup and rely on engineer redux for this, I had to check in an unmodded KSP 1 instance if the Stage 1 values really change if you add something in Stage 6. They don't - at least in simple straightforward serial staging scenario. So I don't really see KSP 1 doing what you say it does?

Agree that something like rover ruts easily can be done, e.g. by Shaders, especially if they are not persistent. Making it persistent would be more difficult but still possible, but you would probably get some weird results if you stack too many crossing and overlapping ruts. I am not sure I really want them to affect physics though (which is possible, see e.g. what the parallax mod does). Wheel physics was buggy enough in KSP 1 without it. And I think it is still Unity handling it, so while it is likely much improved I would not be surprised if it is not still weird in places. Large scale deformation is computationally feasible (hell Magic Carpet did it back in 95, to just give a random example. But it's the kind of feature you need to pretty much built the rest of the engine around, so highly doubt we are going to get it - that's the kind of feature you brag about and also the kind of feature you can't really easily add at a later stage.

What's important is that there is no split in the community, multiple sites can lead to all of them failing. Worst thing would be if Fextralife puts up something. They have a history of pushing it when a game launch , getting to the top of the search results and then abandoning it fairly soon afterwards. That's the main reason why Wrath of the Righteous has no decent wiki, despite being more popular than Kingmaker, which has a fairly good wiki. I think adding to the KSP wiki is the best way to avoid that. There's a lot of wiki's that cover multiple games well, e.g. UESP wiki for Elderscrolls.

Theoretically general relativity also allows for naked singularities, though there is the cosmic censorship hypothesis, which says this should not happen. But that's mainly because it would break causality. With a naked (rotating) singularity you would still have the ring-shape singularity, the time travel aspect and ability to get as close as you want to the singularity, but there would be event horizon meaning you can escape.

The reason it doesn't work is not rocket equation, which simply doesn't hold in certain situations, like if your rocket gets refueled in flight. The real problem is conservation of mass. Each g of mass you emit is lost to you. Though it is worth noticing that a rocket is actually not a totally closed system. You can easily pick up some energy (mostly in the forms of photons) and less easily some mass.

That's true when going for interstellar travel, and I am fine with it myself. But it's still true that the new engines intended for interstellar travel will push KSP a lot further into the speculative part than was the case for KSP 1 and I can respect that some people don't like it. I don't even think KSP 1 was that speculative - the reason you could do things we have trouble with in RL is mainly the smaller scale and not simulating things like part reliability or life support requirements plus in some cases unrealistic performances as with ion engines and reaction wheels. The engines, tanks and power systems are within the current envelope and similar to existing engines, excepting NERVs and RAPIER which at least have proof of concept analogues. All those new KSP 2 engines are based on some sort of theoretical consideration, so they are not completely made up, but let's face it: likely many of those concepts will turn out to not be practical or clearly inferior to another option in the real world.

Oh, come on, as if metallic hydrogen engines are anything but a theory at the moment. We don't even know if it could be a realistic technology. Same thing with fusion drives and other technology for interstellar travel - we know just enough to think that certain avenues might be worth pursuing, but not enough to know which will turn out to be realistic and useful technology. OK - maybe that's reproducible or not - I'll need to try. But it's not at all the "first thing" someone reasonably new to the game would try. In fact, I doubt even 1% of the player base tried something like. So congratulations on your creativity, but please don't pretend this is normal (as in somewhat common) gameplay. It also relies heavily on Unity physics, which means it is the sort of engine bug we might have in KSP 2 as well.

Well, I only started playing KSP around 1.1 or so, but while I noticed some physics bugs I don't really think it is that bad. One thing it definitely doesn't do to me is crash on a regular basis. It's one of the more stable games for me. I had both modded and unmodded career playthroughs with 100+ hours in, without a single crash in that time. What I did have happen is a craft suddenly flying apart when you try to add parts from inventory while EVAing or landed vessels having issues when transition in again later. But game crashing? Not really. Bethesda games crash to desktop more often to me (though their latest games are better in this regard). It's even relatively forgiving with adding and in some cases removing mods in the same game - mainly, due to how little is persistent. It also was maintained for a long time. I do think people are a bit over optimistic with the new code base. A lot of the stuff that caused trouble in the past still seems like it is being handled by Unity. And I have seen a lot of expensive AAA games handled by professional teams being a buggy mess. KSP 2 does get rid of a lot of limitation of KSP 1 (such as non-persistent rotation, not being able to time warp while burning, etc.) - even if the programming team is more professional that's all additional complexity which may well introduce brand new bugs.

That would be neat though technically difficult, especially if there is an atmosphere. It depends on your entry angle, the drag of your vessel and how and when you activate your engines (especially if you rely on both parachutes and engines). Even in vacuum if the delta-V indicator assumes a suicide burn you'd need to also have a timer for when to start the burn.

I haven't really played enough FAR to have a really founded suggestion. I do know that atmospheric flight is important to me, but secondary to the orbital mechanics part of the game. So I would not really appreciate an aerodynamic model that makes getting through out of the atmosphere or landing a shuttle type vessel much harder than it is in KSP 1. This being said, however it will be implemented, I would like to see obvious weaknesses with the KSP 1 model eliminated, most importantly that hidden or shielded parts can still add drag or that some parts that should produce a little bit of lift are missing it. Speaking of the topic, in terms of simplifications, I would also not mind having some 'nicer' thrust curves as well. Especially with RAPIERs where currently it is hard to get above MACH 1 and then they suddenly kick-in like crazy.

In order of your pictures: 1) the vacuum toggle is about the engine properties, not gravity. This is because gravity isn't less just because you are in a vacuum - it is just that for a planet with an atmosphere you need to get some distance from the planet to go into vacuum and this decreases gravity. But the Mun wouldn't suddenly have more gravity just because it has an atmosphere (assuming same mass). 2) TWR as an indicator is interesting in order to know if you are able to lift-off and land on a body. For this to works you need to calculate it using surface gravity, which is what KSP does. For orbital maneuvers maximum acceleration is more useful. 3) KPS definitely calculates single-body gravity according to Newton correctly. Both the stock gravity meter and Kerbal Engineer Redux shows you the correct gravity. All the orbits would look very different as well if it was just a constant. In short: your starting assumption is wrong. For other people reading this and wondering how orbits would actually look like if gravity did not decrease with distance, I found this discussion which seems interesting, but I have not checked in any detail yet myself: https://math.stackexchange.com/questions/1345571/what-would-a-planetary-orbit-look-like-if-gravity-had-constant-magnitude

I think discovery can be an exciting element but for it to work optimally it needs to be a discovery for the player as well. If you know everything about Duna (rough orbit, atmosphere, temperature, etc) but still need to have the Kerbals discover it in-game than that is alot less fun than knowing nothing about Duna and learning those things when it gets discovered in game. It might even feel like a chore if you do it for the n-th time, unless the discovery gameplay is very compelling. Observatories probably wouldn't be, satellites might work since they tie in the core gameplay loop. If we ever get in a place where KSP X can generate interesting systems and planets procedurally then discovery could become a central part of the game. And discussing this I wonder if it would be a good idea for me to stay away from info about the new systems as much as possible...

Most games made by experienced game devs have lots of bugs too, and when relying heavily on physics simulations it is really difficult to avoid them completely. I am expecting it to have a lot less bugs, but it'll still have bugs. And if anything it is easier to introduce new bugs when not relying on a pre-made engine, the advantage is just that you can fix them more easily yourself.

That still seems wildly optimistic. There'll still be parts deep in the code that may have new bugs and maybe more importantly they still use Unity, so we'll likely still have bugs caused by the underlying engine instead of the game code added on top. A lot of the unfixable KSP 1 bugs are downstream bugs from Unity.

I don't really see people calling the game "unprofessional" if there are only N stars, all with systems. Just assume it's in a very isolated corner and everything else is really out of range. Either way I would probably stay away from star types which need general relativity to understand and model, such as Black Holes.

With currency being out I think another important question is what stops the player from just shipping almost everything from Kerbin, where it is likely in unlimited quantity (excluding really rare materials). It doesn't seem like there would be a natural cap on expendable chemical rockets being produced Kerbin side.