Xelo

I wasn't either, sorry if my words aren't clear. I also understand how light probes work, I have made my own implementations before and read the papers. This is specially for the sky scatter only (which gives the sky its color and makes the sun orange). The failure case i describe is this: A single light probe cannot handle all these cases at once. Thus multiple probes will need to be updated constantly on the ground, in the sky, local space, and etc. You don't even have to be particularly high to see this effect. This is somewhat impractical. And as you know each lightprobe needs to sample an entire separate cube-map all over for each 'value' in the light probe to generate the polynomials for the spherical harmonics (FFT doesnt help much in lower n like in light probes i think). This is why dynamic lightprobes arent discussed much, its a alot of work. Using Deferred rendering will do all these cases at once, in one pass without the need to construct and recalculate probes constantly. Only the scatterer shader knows the color of the sun lighting at any texel in the scene and thus such an approach is what I would use. I originally thought that, but I then I realized time warp exists. Such a luxury doesn't exist with that mechanic. Things have to be dynamically computed more often then not if you can make a day last fractions of a second. That's what sets deferred rendering apart, unlike forward rendering, every piece of geometry visible on the screen is known by the scatterer through a texture and the shader shades them accordingly (and with perfect specular). The water is simply included in the texture as normals & depth, the base texture and finally its material properties, and nothing extra is needed for the water to have orange reflections. (as the scatterer is a form of raymarcher in implementation you just march along the water's reflection vector from the camera and grab the color) And while yes sky occlusion still remains a problem, i don't think dynamic sky occlusion can be solved with light probes on these scales[0]. And kerbin, duna or eve are very dynamic environments. Most implementations I see go straight to raycasting approaches. You can try have a much cheaper version of dynamic sky occlusion by combining screenspace(for craft) [1]/baked(for buildings) ambient occlusion and a simple 'special ambient light' on the terrain that dims near the sunset area (would actually be part of planetshine optimally). Since this ambient lighting is generally radially symmetric across the planet, you can store it as a 2d texture, making it extremely cheap to calculate. [0] you may have one locally at your vessel only, but at that point I would just use a blurred cubemap instead o-o. Since with a light probe youd need to render the scene to a cubemap, have each texel do a 'unoptimal' gpu convolution or a slow cpu one, then pass it along to the material shader again. You may sample the sample number of pixels as with a blur, but the important thing is that each texel doesnt do alot of work individually, making it much much faster to calculate compared to the lightprobe in which each texel needs to sample the entire texture for the convolution. Unity also doesnt let you edit an existing light probe, so much as needing to replace the entire array over every time, which implies this is meant to be done rather rarely and only between existing scenes, possibly because its stored in the gpu? [1] Screenspace AO also happens to be very suited and very common to deferred rendering.

As a person whos dabbled alot in graphics programming (and unity), light probes are only for static lights! :O. Wouldn't you have to recalculate and re-position (quite expensive bc of fourier decompositions) the light probes many times every second or so if you intend to use it with the sun? I also dont see light probes also used in scales such as kerbin either. They seem very much more suited for indoor or semi-open spaces with alot of indirect lighting and many (or complex) GI light sources, in order to maintain lighting consistency with moving objects. The L2 spherical harmonics resolution unity uses also makes the the probe's lighting very diffuse, making it ill suited to 'sharper' lighting like the sun i think. If they were using such an approach I think they would just forgo probes altogether, skip the expensive Fourier part and use a cubemap directly for lighting in a custom pbr shader. However the light probe (and similar) format is very very very ill suited for say: being in space over a sunset, the ship doesn't have orange lighting, but specific portions of the ground below do because its inside the atmosphere being scattered, you would have to recalculate all light probes in view many times and lag your device to death computing fourier transforms... (not to mention it would look bad, the lighting would be seen as very patchy with each patch corresponding to a light probe) therefore a different approach is typically used: I'm speculating the reason behind the sunlight not being scattered is a minor disconnect between the implementations of the scatterer and the pbr shading, which doesnt natively accept the results of the atmospheric scatter. The pbr stuff expects standard types of direct illumination and/or light probes, light maps. The scatterer is a post processing effect. Thus in order to have the scatter influence lighting everywhere you would have to use deferred rendering, and use the scatter on everything at once: that is rendering everything as encoded information concerning normals, depth, base color, etc baked into multiple textures, which afterwards running all the lighting passes, in which the sun itself is part of the scatterer pass as opposed to a separate light source. This means the scattering shader would also have to compute the pbr material effect as only it knows the specific color of sunlight as it strikes geometry. Quite a challenge! Currently to me it seems the scatterer is rendered first, and there is a 'placeholder' direct lighting sun applied on the materials and placeholder area light for the blue sky light. This then leads to all the weird effects like the water not reflecting the daytime sky (it turns black at sunsets rather then say, reflect the sky's orange color) and the incorrectly white sunset lighting.

Im not that worried, they already have these graphics features somewhere. Id imagine bringing it all together to be part of this beta phase. If not then, my 50$ aint going anywhere while the game works to reach expectations over EA, after which i will purchase.

Yeah I would definitely like to see a shot where they added the shadows and scattered lighting/distance fog back in! Sadly the sunrises and sunsets didnt get its best look in the stream since these polish features were omitted in the build they were using.

I would probably allow rocket or propeller engines, but add a rule saying 90% of the trip has to be the rover contacting the ground so you cant just go into orbit. That way there is a interesting dynamic between having an uncontrollable heavy rover that is fast and a slower, lighter rover that is easy to maneuver around the big rocks on the surface and avoid crashes.

Id imagine there would be alot of rule sharking of what exactly a 'rover' is and how close a rover can be to an icbm to avoid the race taking literally 20 irl hours to complete xD

New episode! Yeyyy

While those lack of constraints is true, for a mod to be generally 'sucessful', it typically has to be stylistically consistent or superior, maintained for a long duration, and performant and stable enough for most to run it. (And a feature that is determined to be lacking in the base game but thats probably a given) Those that compare ksp 1 modding with ksp 2 arent comparing kiddies first mods with ksp2, they are comparing cream of the crop stuff. Thats why I omitted those constraints. I feel these well recieved mods typically satisfy (or have the ability to satisfy) most or all of these constraints anyway. Leaving typically the narrow expertises and wisdom of the crowd kinda deals where out of everyone who plays ksp theres going to be someone who wants a feature and knows how to make it well. I do however understand that the beaucracy of a real dev environment makes these constraints considerably more stringent, but its not that uncommon for modded features to be outside the techincal scope for the main dev team so I dont think it should be dismissed as a possibility either, even if the core team is very talented.

I dunno about the rest of you guys, but I'm pretty interested in the relative ease of making a EVE-styled cloud system for ksp2 vs crawling your way from scratch in ksp 1 as EVE has done. I agree with the notion that comparing a mod from ksp 1 and ksp2 itself is disingenuous. Mod authors sometimes have very specific expertises that are difficult to look for in a regionalised job posting, allowing for more advanced systems then what the core dev team can produce. What matters more is the ease of modding, which is promised and also remains to be seen.

That is until you've seen the circus that is steam community discussions on ksp2 o-o I have fears this forum is incredibly tame compared to a more general sample of prospective KSP 2 buyers.

I dunno how new this is, but KSP 2's steam page now has beta screenshots! https://store.steampowered.com/app/954850/Kerbal_Space_Program_2 (theres alot more then this)

I wonder, Is solid fuel going to have a 'real-chemical' name as well? :O

Well isnt Duna typically the first planet you go to? From a gameplay perspective it would make sense for the early game planets to source early game fuels like methalox. And later, most distant planets rich in water ice to fuel hydrolox/ nuclear thermal engines.

Wut, didnt the graph say they have a high ISP at sea level but bad TWR? Id also image the trend with nuclear engines continues somewhat into the higher isps not shown in the graph too.

Whats preventing this in KSP2 then? :p Surely once the mod ecosystem has steam behind it you will be able to play your desired realistic KSP 2 with less 'streamlining' and enjoy the feeling of hard progression. KSP means different things for everyone, the base game isn't the final experience. The devs thought the original game was too exclusionary and that's quite valid, but you don't have to take their advice when it comes to modding haha.

If a hypothetical god ran a space program on earth would we be able to tell if they are moving in a slower time-frame? As a kerbal, to know the current 'time warp' you would have to measure god (the player) themselves as a reference. So can they measure the player? If yes then they can tell. If no then they would not even know there was a difference. :0 Though as a kerbal employee, it would be a weird sight to see new vessels created instantly. They might really suspect something was wrong with time at least. xD

Felt it was appropriate to mark the occasion :p

It can be a deterministic finite automation if you consider pages to be states and clicking links to be their transitions. I guess it just boils down to whether you think a programming language has to be Turing complete, or not (like considering SQL a programming language)

*glances sideways* I believe you may have mistaken this subforum to be about the original ksp instead of ksp 2? :3

Maybe some hidden achievements: Eco-(Vall)rior - Use no polluting fuels (e.g. carbon-based liquid fuel, open-cycle nuclear, etc), and leave nothing behind in a trip to Vall and back. Kessler's day off - Miss a spacecraft with <15 m of clearance travelling at least 1000m/s relative Express shipping - Complete an interplanetary supply route in 1-2 days or less YOU NEED MOAR BOOSTER! - Try to launch vertically with a TWR > 1 You need less boosters - Burn up and explode in the atmosphere from going upwards too fast A large beep for robotkind - Land on every celestial body without manned missions. Orbital veteran - Reach a stable orbit from the surface without looking at the map view or using SAS Phew - Dock in orbit with less then 2m/s of dV remaining (incl. rcs). Marathon - Walk 40km as a kerbal Rovert to launch - Drive a rover from minmus (or mun) to the ksc launchpad by ramping off a hill, surviving reentry and then driving the rest of the way. Making Ancient History - Crash a max-size asteroid into kerbin's giant crater. Cant beat the weather - Start a colony within 500km of Kerbol

What an honor :0! Hmm, how about @whatsEJstandfor, I like his cat photo :3

There's also the really interesting notion of cooperative workspaces that Nate mentions, and being able to merge designs together and send designs to your friend's workspaces. :0

Apparently gurdamma has a second moon that briefly flashes its name in one of the episodes called Gop. :0

International dispute: Crash a vessel on the other side of the planet from the KSC

Of course! But looking to realism does help for balance, as physical limitations already are 'balanced' in a sense? So having artifical limits (like supply route limits) inspired off of physical ones seems like a good place to start. I believe the original argument was along the lines of whats stopping you from just making a basic colony and clicking duplicate supply route indefinitely with a wheel attached to a mining drill and a chair. Since we know population is based off some kind of milestone, it can be a way to limit supply routes based off progression. Another way would be the facilities to support supply routes like ports and storage and fuel production, forcing you to improve your colony and thus making tiny supply ships redundant in the process. The barriers don't have to be from emergent gameplay, otherwise the only real limitation would be cpu power