chaos_forge

Air is a gas, whereas rings are made of solid particles. Gasses tend to scatter light, whereas solids tend to block it: when you look at the sky during the day, you aren't seeing the atmosphere directly, but rather the effect of sunlight being scattered by the atmosphere. In physics terms, atoms in a gas tend to bounce photons around, whereas atoms in a solid tend to directly absorb the photons. A better comparison would be something like smoke, a dust cloud, or even fog (though fog is made of liquid droplets, not solid particles). A dust cloud is almost certainly less than 3% solid particles by volume, yet it blocks light quite effectively. Estimates of the thickness of Saturn's rings range from 10 to 1,000 meters. Let's take the absolute lowest bound and assume the rings are 10m thick. Let's assume we have a light ray traveling through the rings perpendicular to the plane of the rings. So a light ray traveling through the rings will have to pass through, on average, 30cm of ice. That seems more than enough to block starlight, especially considering this ice is full of impurities and much more similar in opaqueness to snow than it is to an ice cube. Planetary rings are made of solid particles, not gas. Generally, if you can see something made of solid particles, it's gonna be blocking whatever's behind it.

Principia also has a pretty janky interface though (no offense to the creators of the mod). Since the mod can't hook into the stock maneuver node interface, it has to use its own custom interface, which is way harder to use. Having used Principia, IMO the interface is *way* more annoying to deal with than the n-body effects ever are. Don't underestimate the value of a good interface. Also, that's not necessarily an argument against implementing n-body. Players who don't want to deal with n-body effects can still do the same hohmann transfers as before, and, as has been mentioned multiple times in this thread, automated station-keeping deals with the biggest (& probably only) problem patched conics players would have with n-body.

Not a man, but no problem! It's fine if you don't personally care, but many of us are opposed to DRM on principle, and for us the prospect of the KSP franchise no longer being DRM-free is very concerning, especially considering how few games have DRM-free versions these days.

That's what I was thinking, yeah. I know Principia calculates the planets' orbits using n-body too, but I feel like having the planets be "on rails" is a reasonable middle ground between realism and performance. Mostly, I just wanna be able to use Lagrange points and fancy gravity assists and stuff

If the rings are dense enough to see, they're dense enough to block starlight. Cassini for example has sent back some gorgeous shots of the shadows that Saturn's rings cast on the planet itself. Planetary rings are definitely dense enough to block light.

I am thinking of it in terms of gameplay. Maybe it's because I mostly play in Sandbox but in my experience, since SRBs have a similar TWR as liquid fuel boosters, there's no reason to use them instead of LFRBs, especially considering that LFRBs can be asparagus staged for extra delta-v. This usually leads to rockets being asparagus monstrosities that look more like a pancake than the usual tower shape you'd expect from a rocket. More powerful SRBs would allow me to build taller rockets, since once I've hit the limit of how tall I can build a liquid fuel stack, slapping SRBs on it would actually increase its TWR instead of doing almost nothing. Rockets in KSP tend to be pretty squat compared to IRL rockets. More powerful SRBs would allow taller, sleeker rockets which both look better and feel more like real life rockets. Thrust limiting can fix that. On the other hand if I need more thrust, there's nothing really (outside of mods) that I can do about that. Another factor is that SRBs are usually meant for rocket cores at least a size larger than the boosters. If you look at real life rockets that use SRBs, you'll see that the SRBs tend to have a significantly smaller radius than the liquid fuel cores. So using 1.25m SRBs for a 1.25m liquid fuel core is really overkill, since they're meant for at least 2.5m cores. If you need boosters for a 1.25m core, you should be using 0.625m SRBs , which unfortunately don't exist in stock.

Agreed; I've always felt that the SRBs are weirdly weak in the game. They're supposed to be the high-thrust low-ISP alternative to liquid engines, but they're not all that high-thrust at all. I'm not such a stickler for realism that I think every engine needs to be perfectly in line with real-world performance, but the low-thrust SRBs should be fixed at least.

That shot of the shadow over Saturn's rings shows stars shining through where they should be blocked by the rings . . . seems they disappeared the rings instead of just making them black. I'm sure it'll be fixed by release but it's pretty hilarious to see rn

N-body gravitation is more computationally expensive than patched conics, yes, but it's not that computationally expensive, especially considering that ships in time warp are treated as point masses, and the gravitational effect ships have on other bodies is ignored. All in all, simulating n-body gravitation almost certainly takes fewer computations per second than, say, flying a 100 part ship through an atmosphere. Further proof of this is the fact that, as far as I know, the Principia mod for KSP that adds n-body gravitation doesn't have a significant effect on performance. As far as difficulty, AFAIK as long as you don't try to do any weird stuff it behaves pretty similarly to patched conics. The biggest problem I see is stuff moving out of its orbit over time, but an automated station-keeping feature would be enough to deal with that, which shouldn't be too hard to add. I'd even be okay with it if there was some sort of easy mode option where station-keeping doesn't consume delta-v. All in all, I'd be pretty excited to see n-body gravitation in KSP 2. I'm not sure if it will happen, but there's a few features that make me think we might get it, such as the presence of multiple star systems, and the Rusk and Rask planets, which seem to be similarly sized and orbiting their common barycenter. Both of those scenarios are extremely difficult if not outright impossible to simulate using patched conics.

DRM is basically any kind of software that restricts when/how you can use it. For example, most game store clients such as Steam are a form of DRM because you can only launch the game if Steam allows you to. The purpose of DRM is ostensibly to prevent piracy, but many people are opposed to it because the presence of DRM means you can't have control over a game you bought & paid for running on your own computer. Also, given how easily most DRM schemes get cracked by pirates, there's little to no evidence it actually does anything to stop piracy. All it does is screw over legit users. Red Shell is spyware that 2K tried to slip into KSP. It runs in the background of your PC and collects all sorts of data unrelated to the game, including stuff such as web browser activity. They removed it after there was a massive community backlash, but it's still worrying that they even tried.

As a DRM-free player, this is pretty important to me. Additionally, the presence of DRM has a very high possibility of interfering with people who have multiple installs to test out different mod lists. I hope KSP 2 continues the tradition of the original game in being released DRM-free.

Will the game be released DRM-free (either as a downloadable exe or on a DRM-free storefront like GOG)? As a long-time DRM-free player, I hope the franchise continues to support DRM-free play.

Hey man, first off thanks so much for the amazing mod! I just have one quick problem/suggestion: when I use the snacks life support mod, the inflatable crew habitats don't seem to have any snack storage capacity. Would it be possible to add snacks to the inflatable crew modules as well as the fixed ones? Thanks!

The soil converters seem to be misconfigured. I'm running Snacks version 1.10 installed via CKAN, configured for kerbals eating 1 snack/day and soil converters to work at 100% efficiency. I'm currently looking at the Snacks\ModuleManagerPatches\MM_Stock.cfg file. In the comments, it says "Given the dynamic nature, the input/output ratio is ALWAYS set to 0.00004630, which gives a daily input/output of 1.00008 per day. The recycler will then adjust the input/output ratio based upon RecyclerCapacity and recycler efficiency." However, I have noticed two problems with this: Firstly, the input/output ratio seems to actually be set to 0.000034723, which gives a daily input/output of only 0.75 per day. Secondly, it seems like the soil converter input/output is never actually multiplied by the crew capacity. I tested this in-game by slapping a few solar panels on a Hitchhiker and timewarping for long amounts of time. When 4 kerbals are on board, the soil converter cannot keep up with the amount of soil being produced, even with a max level scientist on board. In fact, with a max-level scientist on board (260% efficiency), the soil converter can only just barely support 2 kerbals. This means that the "baseline" production of the soil converter is 2 / 2.6 = 0.75 snacks/day. So despite the advertised capacity, a hitchhiker soil converter can in fact only support 0.75 kerbals at 100% efficiency!

[ignore this post, I had a massive brain fart]

I also think that the new mk1 cockpit looks like it wants to be a 2-seater cockpit. I think a tweak as simple as changing the 3 panes of glass to all be a single pane would make it look more like a cockpit meant to house only one kerbal. I like to put a mk1 cockpit with a mk1 inline directly following that to make mk1 planes that seat 2 kerbals, and I'm afraid the new cockpits will look weird in that configuration.

Wouldn't this be more of a bug than a suggestion?

You made a mod that makes binary work in KSP? I would certainly be interested in hearing about it . And while I certainly still think many of the ideas expressed in this thread are good ones, I haven't been as involved in the KSP community lately as I was a year or two ago . . . I also just realized that I have no clue how the KSP forums handle necro-posting. Should I start a new thread, or is talking in this one okay?

Another thing that has been suggested often is an orbit direction indicator.

I like the suggestion of making parts that are about to overhead produce a fizzing sound and start smoking/sparking/spewing flames, just like DRE does. The sound very quickly alerts you to the fact that something is overheating, and the effects show you what is overheating without cluttering the UI. I would be fine with overheat gauges on the staging menu in addition to this.

I would like to see dedicated radiator parts as well. EDIT: a cool feature would be if open cargo/service bay doors acted as heat radiators, just like the space shuttle cargo bay doors do in real life.

While I fully support the idea of adding dedicated radiator parts, another thing that I think would go a long way towards making the new heat system seem less rough around the edges is some kind of indicator that a part is overheating before it explodes. Right now, we have no easy way to tell that any part that is not an engine is overheating. Players should be able to figure out why a part is exploding without having to use the debug menu. The new heat mechanic is fantastice, but right now it can be very frustrating to have parts overheating/exploding but you can't figure out why.

Not sure if anyone's mentioned this, but we should have some way of knowing that parts are overheating, instead of just having them explode without warning.

It's not realistic, because we still have high density LF tanks, and even big LF-only tanks due to the MK3 parts. What we don't have is a variety of high-density LF tanks. So what'll end up happening is you'll be forced to use spaceplane parts if you want to have an LV-N rocket with a halfway decent payload fraction. This is inconsistent, not realistic.

The problem with this is that it will make the ratio of wet to dry mass of your tanks even worse, which defeats the purpose of having efficient engines.