t_v

That’s very true, the interaction of thousands of exploding fuel tanks (because someone will make a rocket like that) seems tricky to simulate without freezing the game entirely, and I doubt that the shape of the explosion as gas rushes outwards will be accurately simulated. However, a rough estimate system ignoring a lot of the complexities would be easier for computers to run and would still semi-accurately portray the magnitude of an event like a rocket exploding.

I cannot dispute that hype has suffered, because everyone's experience differs and some people may be feeling less hyped, but the decision to announce the game wasn't made with the change in scope in mind. An announce late 2019, eventual release in 2021 was planned, but if you look back at those videos, a lot of polish and optimization was missing. After COVID hit, I think that the studio decided to take the extra time to change the scope of their game, adding in new content and making things look nicer and run nicer, and we have seen a lot of progress in many areas of the game. The game we will be getting is not the same game that was in progress in 2019, and it will be much closer to the game we were shown in the reveal trailer.

My hope is that not only will explosions be larger, they will also generate a simplified physical effect. I think that on the technical side, larger explosions are relatively easy to implement, by waiting a bit before creating the explosions and allowing groups of parts to explode instead of having a smaller explosion for every single part. However, with chemical fuels, we shouldn't expect immense explosions unless there are immense rockets, as standard rocket fuel can only burn so hot, and some fuels like solid fuels burn slowly by default. I'm more interested in seeing how the devs implement small craft with very explosive fuel, because the effects of explosions of that magnitude can be extreme. If an NSWR engine needs to be kept away from a base because of radiation issues, what happens when highly fissile (or fusile) fuel gets caught in a large explosion?

The oversized Puff engine is using monopropellant form the command pod

sure, a shader, but that is still easy to implement, because shaders are essentially mathematical operations applied to textures (or pixels or what have you). The point that I am trying to get across is that some systems are very hard to implement even though they might seem very similar to easy systems, and it is important to ask yourself if those systems are worth it.

the AirCar gameplay has a static texture (which they could make moving easily if they want) and a few individual particles, but that is the easy part. If you added windshield wiping, repopulating those droplets using just that big texture would take computational power, and of course, if you want to avoid Forza's weird clump of droplets that appears, you'll have to have logic to turn those droplets into a solid stream of water. The thing then would be that whether you are moving at 1 m/s or 1500m/s, the rain would slide off at the same rate, and if you slowed up down or sped it up, the wiper would wipe really slowly across the windshield and wouldn't look right. So, you cannot use a looped texture, even if Forza does.

no, I'm talking about putting the water back on the windshield. Forza does it by just adding more water particles back, but if you want to keep your GPU from going kaput, you don't want to have each water droplet as an individual texture to be applied and manipulated. It might work better with a lower density of raindrops, but there are always limitations and having that effect as opposed to just having a few larger moving textures is much more processing-intensive and not very recognizable.

The static vs. moving textures part isn't the complex part, nor is the clearing of the water. The complex part comes when you have to eventually replace that water. What Forza is doing is pretty much what I detailed, and as you can see, it isn't close to how it works in reality. If you think that the system Forza demonstrated and I talked about is over-complicated, then you are pretty much stuck with MSFS windshield wiping. edit: look at the part where the plane takes off in MSFS. The texture isn't static, and there is even logic to make the water form streams while moving. That sort of stuff is another level of realism that could be added but I wouldn't want because I wouldn't notice it, just like you didn't.

What I think you are missing here is that effects like windshield dripping that is wipeable is a very, very complex effect. In computer programming, telling a computer to draw a bird on the screen can be fine, telling it to make that bird take a step is almost impossible. Things might seem "simple" but are actually complex and very intense to program, and telling the difference is very important. Here's what you can do for liquid condensing, dripping, or freezing on a surface: make a texture that is applied as a mask onto that surface, with some logic like frosting should follow edges (we saw that in the simulation shader), or dripping (really flowing droplets) should be opposite to the direction of travel and have an animated texture. simple, albeit it would take up more RAM, but oh well. Then, you want to add windshield wiping. You now need to create logic for deforming the animated texture as the wiper crosses it, and then logic for slowly replacing the empty space with that texture as water flows down. Next, you need to create a separate flow for the mass of water that has been moved by the wiper, which is not going to follow the same path as the little droplets. You cannot just pre-generate this, as different rain and wind conditions will generate vastly different results. Even after all of these steps, you are left with a really ugly looking system that still needs a lot of fixing in edge cases and more work and more processing power to make realistic. That's where I draw my threshold because I think that the amount of effort that the devs and my computer would have to put in compared to the absolutely minuscule benefit are not enough, and I can recognize when a system is complex or simple and that system is complex. I hope this clarified a few things from earlier in the thread, where a lot of what you are suggesting could be done with a few simple shaders and easy math, but then the next logical step that you take brings the simulation into dangerously intense territory. Rivers? sure! Easy moving texture. Rain on those rivers? sure! Easy masking with the little expanding rings. Flooding due to rain? Now you have to calculate the volume of water that is passing by any given point along the river and change that value as the river increases its size, and run this recursively as each segment you do affects segments in front and behind it... And of course you can't simply raise the water level universally, because that would look completely wrong in a lot of places and generate problems. Yes, that effect exactly, but I was making an example where that effect was put on top of hot rocket parts in the atmosphere or in hot areas like deserts or molten planets.

I completely agree that weather on other planets would be very interesting. What differentiates Venus from Mars, both balls of rock of different colors, is the difference in the atmosphere, how it behaves, and how it looks. A rocky promontory overlooking a plain of rock is not the only way to set a visual tone for a planet, the shapes, colors, sizes, and distribution of clouds can also have a major impact, as well as weather events. I think that for each person, the threshold of what graphical effects are "worth it" compared to the work and performance impact is different. Would I want heat distortion coming off of my ship's hull and off in the distance, with mirages accurately traced out? Absolutely, and I even think it would be a great visual indicator of how hot something is. However, it could easily be replaced by a less high-fidelity and less processing intensive system, and I probably wouldn't notice it if it wasn't there, and I am not at all sure I want the devs working out the math on heat distortion like that (yes, I know you can do it with a shader on jet engine trails, I'm talking about actual distortion, where something offscreen would appear in some cases). It is the same with weather; would I like to step out onto a launchpad on Laythe, looking like that one scene in Star Wars on the water planet? (I don't know too much about that series) Absolutely! But having accurately simulated rivulets of water flowing off of the side of the pad and splashing into the ocean below is not a feature I would notice if it was never there, and I think my computer would kill me if I did that to it. However, that's just my thresholds. Everyone has different ones, and that's fine.

Left landing gear missing… I’ve had this exact experience too many times, I feel called out.

I think @Bej Kermanbrings up a really good point there - KSP is not the first to do the things it is doing, and not the best at doing them. It won’t have the amazing graphical quality and densely packed areas of starfield, it won’t have the good compromise between fidelity and scale that Space Engine manages to achieve, it won’t have the well optimized and expansive manufacturing system of a game like factorio, it wont have the accurate orbital mechanics of many old-school orbital simulators… But being on par with the best isn’t the goal for KSP 2, it is the combination of elements like these. There isn’t another pretty accurate orbital simulator in 3D which has relatively good graphics and more than one planet with avatars/characters as well as a colony system with resource management, plus modular ships… So, I think that we can look to starfield aspirationally for planetary graphics and design if you like that sort of style, or their ship building system which apparently has IVA included, but know that KSP isn’t going to be on par with many of these games because these games have focused a lot more on different aspects.

Just to loop into the discussion, there is an already defined resource that is being overlooked. Metal, in its unprocessed form, is regolith! I mean, that isn’t exactly true, but if you dug into a coal or iron vein with an industrial drill, you would get a lot of rock encompassing the metal, so it is a good approximation for regolith. You could even name the raw resource regolith and have it so when you melt it down, you get metal. A good recipe for Concrete would then be metal (processed) + metal (ore).

What? You mean metallic hydrogen? No, although now that I think of it, you could probably collect that too, in the cores of gas giants. Heavy hydrogen goes by the names of Deuterium and Tritium, they are essentially Hydrogen with extra neutrons attached, and they are great for fusion reactions, which is why a lot of far future engines need deuterium and tritium to produce thrust.

I personally think that the devs thought of the actual materials used for these engines and then abstracted them. For example, instead of having Polonium, Uranium, Cesium, there would just be a "general radioactive substance" but for common materials like water, they would have them. This is absolutely complete speculation, but here's a tentative list of the most basic materials that can be found: Methane Oxygen (O2) Hydrogen (H2) Heavy Hydrogen (I don't know if it should be split into 2H and 3H) Water Metal (metals placeholder) Uranium (radioactive placeholder) Xenon (Noble Gas placeholder) Antimatter (if it can be found) Rare Metal (Not sure how split up metals will be, do we need separate things for strong Titanium or perhaps Silicon and gold for circuits? So I just added one magic metal) Organic Matter (waste matter + seeds?) Electric Charge (energy placeholder) Intermediates: some of the items in the basic resources need to be processed before use (e.g. metals) and some can be made with tech (e.g. water) but there are some that are not in the basic materials list. This is all still completely speculative. Oh, and a lot of these processes are energy-intensive. Snacks (Organics + Water?) Oxidizer (Just O2, Ammonium Perchlorate or other stuff seems a bit specific) Fission pellets (for Orion drive, Uranium + Metal) Fusion pellets (Heavy Hydrogen + Metal, Heavy Hydrogen is the fuel for non-pulse fusion drives) Metallic Hydrogen (Hydrogen) -there's definitely a lot more here final products: just thinking about which parts would need what. Anything with electric or magnetic components would need rare metals, stuff like the MH drive could use Uranium as fuel alongside the MH (to not add a new fuel type), while most parts only need Metal and very late-game pods would also need Rare Metals. There's a lot of parts in the game and this list, long as it is, is far from complete. I think this game will end up having a complex system even with the simplifications above.

For some reason I thought you were talking about the FTL kind of warp and then realized you meant time warp. I don't think the problem is difficult to solve from a coding standpoint; in fact, I think your solution of getting two different mods and mashing them together would be harder than the actual solution. The problem is preference. Every other solution that was proposed is a matter of preference in how people play, and people have strong preferences. Some people prefer having what is essentially a single player experience with the builds of your friends popping up over time, some people want everyone playing to interact in real time, and there are different ways that it has been proposed, there are some who don't prioritize IRL time spent and have a Civilization-like system, etc. All of these preferences are the reason why this discussion has gone on for so long, because people really stick to them, because people want multiplayer KSP to be "good."

You are entirely correct that it would be unbalanced and the devs should not be expected to make it balanced. But do you mean that the experience would have to have meaningful progression, therefore it would have to be balanced which the devs are not expected to do? I was thinking to just leave it unbalanced, and if the system that the player starts in has absolutely nothing that can make oxidizer, the the player can’t launch anything that needs oxidizer from colonies because there is no oxidizer to put in it. I guess some late-game resource puzzles will not be “solvable” with early game tech though, so you probably shouldn’t start on those celestial bodies.

That too - I talked about delta - v and landing/ orbiting puzzles as two examples but meant “gameplay differences” in the more general sense. I’m just hoping that not every starting planet is an oxygen-rich rocky planet with two moons which have roughly the same resources as the Kerbin system. And I agree with the balancing aspect, making things work on Kerbin is important to have good balance for the default game, and starting on other planets can be much easier or harder depending on the planet.

I would like to see different starting planets as a nice quality of life feature, but I’d be happy to have it as a mod. One thing I’d like to add is that I don’t want it to be like Gael from GPP, because ideally each starting planet brings with it a new experience and not a retextured old one. Yes, inclinations and all that, but I’d like delta-v numbers to be different and for there to be different challenges wherever you start. A ringed planet would make your options for where to place your ships limited, or a planet very close to a star could be easy to get into orbit around but require a lot of delta-v to get to the next planet. I haven’t gotten to the point of being sick of the Kerbol system (and I don’t think I ever will, because it is a nice system in my opinion) but I understand the desire for a different experience once in a while. I just don’t think that it should be similar to the Kerbol system. Another reason I think that each starting planet should be different is because they have to be developed, and the easiest way I see this being implemented is by having the planets already in the game become options to start with. Similar to the arguments for RSS, having a starting system that isn’t in the default game would mean maintaining a whole system that many players wouldn’t interact with. So, the alternative starting planets should be in the game, and each planet should be unique enough to pose its own gameplay differences, not just visual differences. Starting on Ovin would be a fun challenge for experienced players, and Ovin is very distinct from Kerbin visually and gameplay-wise, and the DebDeb system is too.

It’s very true that the weight of snow would barely compare to the weight of metal and it would take really bad construction to make a hurricane topple a metal structure affixed to the ground, but I was pointing out the merits of the idea in those edge cases. For example, in the trailer, there is a pier held up by super long, thin pillars with no horizontal supports, which would fall down in very high winds. That sort of stuff. Overall, the only thing I’d really like to see is wind on ships and planes, because that would make the most difference to gameplay; having it act on colonies would just let you find out your colony has fallen off camera.

and your point is? Frankly, this is totally (IMHO) unnecessary. We don't build the buildings, they already exist. And if you look at the Kennedy Space Center as an example, the VAB has stood for more than 50 years, with minimal damage from weather. Why waste time implementing something that rarely, if ever, happens? I think in this case @Vl3d means colony buildings, which, depending on how poorly you do your architecture, could be very vulnerable to sideways forces or in the case of snow, heavier than normal downwards force. In a previous thread, there was a lot of contention over making this fair, which for me boiled down to showing people a preview of extreme conditions to identify failure points, with a toggle able overlay showing "structural integrity." Thinking back on this, it could also be applied to spacecraft design, sort of like how center of lift is shown, you could also change the angle that you define the wind as coming from and see the "lift" vector change. Not commenting on the intensity of the simulation because that really depends on specific implementation and how many systems are included, but I think from the player perspective this could work.

To be more direct, I’m asking to turn the conversation away from realism, because ultimately, while I am certain the devs will mostly implement realistic things, the gameplay takes priority over realism. I’m sorry if I made it personal to you. You made a good point that since wind is realistic, there is no impediment to adding it to the game (unlike magic drives or hollow planets with black holes in the middle), but talking about it being realistic as a reason to include that feature will lead nowhere, as we have seen in that thread I mentioned. Sorry everyone else for temporarily disrupting this thread, but I didn’t want it to devolve. One more thing I will add that contributes to the discussion is that wind conditions across multiple planets could differ greatly - offering a new aspect to discover about planets that will render them unique. I would love to look at Merbel’s super-flat oceans, which don’t have much wind on them. (Ok, that doesn’t necessarily mean that wind needs to be simulated in that case, but in any case, different wind conditions could bring a lot of variety to the game) What do you think? Does wind add enough variation to make it a worthwhile addition?

Wind is just a hindrance that makes the player resort to a host of annoying solutions instead of being able to do a clean gravity turn. Pitch blackness between the stars is a challenge that can be overcome by clever planning. If I can reverse your argument and it still makes sense, then there isn’t enough of a difference.

This, for one example. The point being, it doesn't matter whether a feature or non-feature is realistic or not. At its core, KSP's design will be based on whether it promotes good gameplay (gameplay over graphics was your main line in that thread) and not whether it is realistic or not. It is fine to want this feature, but remember, it does not have to be realistic. Ideally, the devs implement realistic features that also aid gameplay, but I would be dismayed if they did not include any quality of life features that are unrealistic simply because they were unrealistic. That sounds like too much to me as well, but luckily nothing here is concrete. I think that having slowly changing wind speed and direction would be helpful, such that during an ascent, you wouldn't suddenly be constantly in changing conditions. But of course, as you move around the planet in the atmosphere, you could easily experience different wind speeds and directions. As for higher winds in higher parts of the atmosphere, those are problematic for players who really want to get absolutely perfect ascents, but unless there is a hurricane only 10 degrees away from the launchpad, I don't think that wind would pose much of a danger to launching. In the end, I'd be happy as long as there are some situations in which wind plays a significant factor in moving through the atmosphere

No, it's a simulation with a game on top of it and having wind effects would go a long way to making routine rocket trajectories and aircraft physics not feel so sterile. Ok, on this I have to disagree, and admonish you for using this particular argument because in previous threads, you were adamant that a realistic feature should not be implemented if it did not fit gameplay. KSP is a simulator in the same way that Goat Simulator is a simulator, because they are both games which use simulation (orbital mechanics, ragdoll mechanics, etc.) to enhance their gameplay. What’s worse, I agree that wind would benefit gameplay a lot, just do not use the argument that it is a simulator to justify that. @DeadJohn thinks that this feature would hurt gameplay, and included that remark so that people wouldn’t try justifying the feature by saying that it would be realistic. It also needs to be fun. That aside, I think that you wouldn’t even need a UI element to show wind direction. We have clouds already, and we’ve seen that they shift, why not tie that to wind direction? Lots of the visual system already lends itself towards having weather patterns, however simplistic, and I think it would go a long way towards enjoyment if you could catch a jet-stream and save some time flying around. And lastly, before people wonder about the computational impact of a weather system, @Nazalassa’s system can be run as a low-resolution shader, putting less load on the system than the reflection of the light from one celestial body off of the ship.