starcaptain

Parts fail if they get too hot. Can they fail if they get too cold?

I too am in support of the "as long as it takes" timeline.

Still picturing that silly monorail mod idea I posited: can requests be made so that are sent or arrive in block-like increments? I know that "rate-based" means basically Flowrate and assuming the resource (say, a fluid, or even electricity or solar energy) is arriving by some kind of direct pipeline (fuel pipe, wire, line-of-sight to a star, etc.) Would it be a manner of programming to build a flowrate so that the resource "is delivered" as, say, a tank of fuel that's 5000L all at once (because the tanker arrived at the depot) instead of 50L/min ? Or is the core of the system made so that the only way fuel can be transferred is between containers with the flowrate? Meaning if I want to run a fuel delivery railroad, I still gotta discreetly transfer fuel from the depot tank to each railroad car.

Will clouds get shoved out of the way when our flaming piles of garbage that used to be rockets careen through the clouds? Praudl-glauert singularities? Double-rainbows?

I think the light source method is the most likely method that they'll do, but I suspect that it won't be something updated every frame. Unlike thermal radiation, I don't think it's going to have impacts that will hurt your spaceship as fast as reentry heating could. But I can imagine the following: You're physical-timewarping your vessel from star A to star B, and the radiation meter starts building up on some parts, over the course of weeks or months instead of seconds. It looks exactly the same as the thermal indicator, but a different color. If it "overheats", the part fails. As for crew exposure, I imagine it'd be a place where crew health bars makes sense.

You do realise that Ovin will win the vast majority of the time, right? It's like picking a fight with a wall.

understandable, have a good day sir

Inevitable

Friend of mine is sus that the blendshapes don't conform to real world maths. He sent these citations from Rocket Propulsion Elements by George P. Sutton. As usual, I expect my (or my friend's) pedantry can be solved by mods but nonetheless I'm delighted to see the game's progress nevertheless.

The video I saw on twitter looks like the thrust plume also works as a local light source, at least against the engine. However, it seemed to my eye that the lighting was very harsh and overblown. It was also emitting light through the thrusterbell, which means self-occluding shadows were not enabled, which is understandable from a debugging point. I am curious though: will things like the shock diamonds have HDRI lighting? Or is that beyond the scope of KSP2v1.0/a question for the modders? (Also, practicality doth protest to using rocket engines as area lamps around your colony.)

Here's hoping mods can also change the UI. Oh, jolly good. Can't wait to fly my ship using controllers that read out in: * Digital * Roller dials * Analogue needle mach gauge * 7-seg liquid crystal displays * Split flaps * Nixie tubes * Conway's Game of Life sims * Japanese synchro-walking * Skyrim handwritten notes * etc

Do you think that Unity could support hot-swapping the host? Picture this: you and x friends keep a server continuously online by always having overlapping sessions at some point.

I am imagining KSP2 will have multiplayer up like, maybe 8, much in the same sort of manner as Terraria, like K^2 said. Colliding vessels while in space is one of those things that's destructive but also takes effort, like making a coordinated demolition in Garry's Mod. So i don't think that's a route of problems. And the editors aren't multi in of themselves, so players can't ruin each other's building task...

We all have high hopes for the multiplayer features of KSP2 but it occurred to me: not everyone likes to play nice. Seeing as we have little to go on for how multiplayer works, it's hard to imagine what kinds of griefing or abuses may appear. But i raise this as a topic of concern, because the online culture of a multiplayer video game is greater than the sum of the many different parts that make it up: *General player attitudes within the game *Groups, cliques and common play styles *Attitudes of the developers towards the online culture *Tools made by the developers for ensuring safe, uncorrupted play These and other things will have great impact on how and when trolling might occur, and how amusing/annoying/destructive/toxic it may be. I want KSP2 to succeed, and the main thing i can do in that dimension is wanting to be a supportive, friendly, and polite player. But I don't know how core these sorts of thoughts are for the developers.

I'm curious: What if two players set up their velocity so that their orbits are very close to one another, but with inclinations nearly exactly 180° apart, so that their relative velocities are basically 2x orbital speed; I imagine the continuous collision check is happening every frame where their trajectories are similar. Wouldn't this have an impact on performance, even if the players were in opposing positions on their orbits where collisions wouldn't happen (yet)?

We're all very happy that Nate Simpson is the creative director for KSP2. Kerbonauts would want nothing less than a genuine fan beating the drum to turn a sequel into a passionate continuation of the original. But I'm curious if there's any infusion of the game with elements or design choices informed by his previous experience. This isn't his first rodeo, he's been a director before. I'm wondering what sort of things in his career are making him confident that this sort of gameplay decision or that sort of UX element are solid choices. Or is answering that kind of thing just implicit from the direction we're seeing in all the teasers? Maybe I'm just not satisfied with seeing his resume on LinkedIn. I'd like to talk about his previous games a bit.

If it's anything like earth was, it'd be a thick nitrogen/CO2 atmosphere in which oxygen-breathing bacteria have yet to evolve.

I thought you meant Chthonian planets.

Pointy mountains. I'm okay with varied terrain or even boring hills and stuff, but I always found it pretty egregious how the terrain system worked that the slope might change radically with harsh sharp angles on mountains, and driving around them was like trying to drive a shopping cart on the side of a building designed by Frank Gehry.

I still wonder if going through asteroid belts is a death zone unless your relative velocity is low.

"Thermal" and i think "Radiation" are both going to be things that appear in the engineering dialogue in the vehicle editor. If you watch closely you can notice them in some of the more recent teaser videos, beside existing highlighters (CoM, CoLift, ect.) I imagine they behave a bit like volumetric light, with different parts having different "transparency"/absorption amounts.

A lot of KSP1 is already in KSP2 so some degree of homage may be redundant. "2 is already supposed to be a modernized reconstruction of the same core experience, and we've already heard confirmed that everything you can do in the original will be present as well. Seeing some callbacks to the game's development history would be nice as long as its fun to seek out.

Multiplayer emotes. Like being able to join Kazotsky dances and high-fives in Team Fortress 2: being able to dance at orbital speed is an important part of the culture in the future. https://www.youtube.com/watch?v=Buhi-LrSUlk

Shadows moving across the windows occasionally, which shows they're inhabited.

Loving the new vehicle editor layout. A few things: TERRESTRIAL/VAB/USER tells me how the game may handle multiple users working on multiple builds at the same time, as well as different editors are arranged and named; there's also the Spaceplane Hangar (or its equivalent in KSP2), Orbital ship editor (maybe) and colony editors (which may be on the surface, or in orbit). Having collapsible tabs for different part sizes is a huge pleaser for me. On the left side we see a variety of tools. I'm going to guess they do the following, reading from the top: Radial/Horizontal symmetry (rocket mode/plane mode) Undo Redo ((4))??? Rotate Gimbal Part Picker/Context editor (similar to right click in the current VAB?) Move Gimbal Move Subassembly Gimbal/Root Part? Launch Stack Assembly? Center of Lift Indicator Thrust Vector Indicator Center of Mass Indicator Radiation Field Indicator