WarriorSabe

They're mostly various homeworlds from the projects of many of the creators. I don't think they're all released yet, but of the ones I know that are, - The big vacuum one on the left and the topmost world in front are Mesbin and Kerbmun from Whirligig World - To the left of Duna is Asite Par from the last one, Week World Planet Jam - Between Duna and Kerbin is, well, also Kerbin, from Alternis Kerbol Rekerjiggered (I'm not 100% sure if this works in the latest version) - To the top right of the big desert one is Haven, from Edge of Eternity (which is still well in development, like 60% of the worlds still have placeholder assets) - To the left of the one in the bottom right corner is Echo, from SLIPPIST-1 (which like AKR I'm not sure if it works in the latest version or not) I also feel like at least one one (maybe more idk) of the rest of those is released but off the top of my head I can't pin down which

Having Unity versions is definitely a good thing to have for all those compatibility reasons you mentioned, but also, Scatterer flares are generally overall more capable (unless you want a very large number of ghosts), so perhaps having both options would be a good idea? It's not just the being compatible with the atmospheric extinction, but also the fact that every component can have independent scale curves as well as intensity curves. For an example from Edge of Eternity, while I chose something which probably doesn't have the same overall design direction in its particular assets, For context, the first picture is out at Esker, the next planet away from the homeworld, while the second picture is Calefact, the innermost planet 6 orbits down where the sunlight is so intense the kerbal standing there has less than a minute before needing to go back in the ship to avoid overheating and getting poofed. Obviously EoE's flares are a lot simpler than yours, but that just means that you could benefit a lot more greatly from those features than I am here.

While I've yet to personally play 2, from everything I've seen from those who have, this all makes a whole lot of sense. Modding after all works best when there's 1) actual direct support for it and 2) a game that actually functions properly, so those should definitely be priorities (and even just from modding KSP1 I've been running into issues caused by the shortcomings with both, I'm looking at you infinite-distance directional sunlight)

I think those ended up becoming a part of a separate mod under her own direct authorship, iirc

Actually, I can run EVE volumetrics just fine on low settings but am far below the minimum spec for KSP 2 with my MX-150

While I am currently out of town and don't have access to my computer to properly check and cross-reference the logs, I do know that when originally uploading the last update the files were incorrectly uploaded and I had to immediately upload a patch with the correct files (twice, actually), which brings me to two questions: did you make sure you downloaded the latest version, and if so, does redownloading a version before the last major one work?

They do, however, include biome names and occasionally notes in comments, which in some cases could be spoilery

Generally yes, those are the files you want, but I do have some experience with using that tool, and it's very particular about how it expects the configs are internally formatted, and I fully expect it to not understand the PJ2 configs - specifically, the masses, reference bodies, and semimajor axes of the planets. That meaning, they will upload, but the distances and some masses will be wrong, and a lot won't be able to find the object they're supposed to orbit and not show up on the map (they'll go to into their own holding area at the bottom of the list until they have a valid reference body) The reason why being, for the planet smas and for a number of their masses, instead of directly setting them these configs take a base value and multiplies them, mostly as a result of how the jam was structured. For the reference bodies, the reason is because they're keyed to identifier rather than name. So if you want to upload the configs, you'll need to manually set all those to the correct values after uploading, which would also mean reading the configs and very easily accidentally exposing yourself to spoilers (as well as also just being a lot of work). For that reason, I might recommend trying KSPTOT - while it's overall a less convenient tool to use and doesn't always get as efficient of trajectories, it works by using a small mod that links to it and reads the planets directly rom how they're loaded in the game, therefore bypassing any potential confusing configs. It does need to be downloaded and run separately from the game and requires external libraries (MATLAB) to be installed, however. You could also always try doing it manually, but if you're new to gravity assists PJ2 isn't exactly the easiest place to learn how to do them manually (though they are incredibly powerful).

Yeah, as far as I know the mx150 is fairly comparable to the 1030 (it might be somewhat worse due to being optimized for a laptop). And yeah that was about what I got, 15-25, no parallax and all at default settings (so it may have been better with lower settings, but possibly worse with also parallax) - but I would add, those of us on cards like that are likely to kinda be used to framerates like that already (and the motion artifacts do go away when paused or simply not moving too fast so you can at least still get decent screenshots), and that test may have been further slowed down by external factors since the framerate was slightly lower in space far away from the volumetrics too. Basically the final "what it came down to" of that test is on my laptop with a 2gb MX150 (also GDDR5) it was about a 30-40% reduction to framerate compared to the basic EVE redux, depending on whether you consider the high space fps reduction to have been evidence of an external factor to the slowdown or not.

Best I can think of would be removing the layer2D, but that would also remove them in-flight from orbit

When I made the map, the way I handled the ascent was to treat gravity losses as cosine losses (which works for a horizontal ascent profile), and integrate them over the decreasing effective gravity as orbital velocity is approached, using some ballparks for typical TWR values. For drag losses on atmospheric worlds, I have a more empirical polytropic fit based on what seemed to be typical values for various reference worlds (as well a similarly empirically determined factor that increases gravity losses to account for less horizontal profiles), and calibrated to return values similar to those on the stock map, since I figured players would most likely already be familiar with adjusting those values to their own rockets and profiles. For transfers, you are right in that I used higher orbits, typically 5-10km above obstacles or atmosphere, except for the very smallest worlds. I also modeled the orbits as circular, with the exception of Esker, for which I used Transfer Window Planner (and I plan on ultimately using such empirical values for the remaining irregular orbits). And, on the subject of Esker, that's the one case where your low-end value will likely not be quite achievable - it's in a 2:3 resonance with Haven, which means it always is in the same alignments, and will never allow you to transfer towards periapsis. It also turns out, according to TWP, that despite having only a single point of conjunction, there are actually two alternating transfer windows per synodic period pretty with similar costs, one of which is quite unusual (it happens around conjunction, with the ejection from Haven being approximately radial out from Terminus). All the other eccentric resonances are higher order, though, so they should allow decently close to a periapsis-aligned transfer at the least. And I guess if you're willing to wait taking several orbits to get there you could try launching to its periapsis, you just might be sitting around Terminus for quite a while before things finally line up. That said, good work on the table, it's something I had thought about making but ultimately ended up not. I'm surprised you even went so far as to include all the Cerberan moonlets, that's a lot of extra transfers to calculate considering their less significant role.

Wait, that's a potato? Then what is my 8 gigs, I5 CPU, and 1030-equivalent considered? (which with nothing else on default settings gets a pretty solid 15-20 fps with the new volumetrics, yet to test with a bunch of mods)

Something like 60-70% of the framerate, on average. That's with the included configs and default settings, I'm sure better could be achieved by lowering the settings or using less intensive cloud configs

I'm not sure what kind of performance that has, but they work relatively fine on my laptop's MX 150. Framerate's kinda low with default settings but it was already kinda low so it's not a ton worse

Sometimes we like keeping those old monuments to the past. I remember doing a crewed landing on an asteroid moon I had visited 24 ingame years ago, and touching down within a kilometer or so of an old probe and paying it a visit on EVA, which was fun

Oh wow that's cool, a lot more than I was expecting

Are we thinking of the same movie here? I don't remember there being planes or toxic jungles in that Oh that sounds like fun - are you talking actual bolts of lightning or like flickering lights inside the volumetrics? Either way that'd be cool. And as for the particles, what would be different about them to the current ones? Locked orientation for more natural precipitation or something?

Second hotfix, should work properly this time. I should probably not do releases right as I'm going to bed

Where's the apparent vorticity come from then? It looked like they were actually twisted a bit not just columns

Just released a hotfix for the game not properly loading, some files didn't copy right and a bracket was missing

0.21.1 is out! The ring revamp is mostly finished, using the new backlit ring shaders (requires a fully up to date Kopernicus) and the addition of the moonlets. A few more system tweaks were also done, finishing up the big system update started in 0.21.0 The github changelog has the full details, as usual

The way that descended through the clouds, I half-expected it to freeze midair and spontaneously disassemble while the crew floated bewildered in the middle. Awesome work with the Eve EVE, and I can't wait to figure out how you did those cyclones to make Cerberan hypercanes

I believe that's because the clouds are a) much higher fidelity than the surface of Laythe itself, and b) it interacts with Scatterer differently. With the latter effect, my guess it's because Scatterer is configured to provide a really hazy type of appearance, but this isn't a true volumetric haze, rather it seems a filter applied to the ground appearance, and that's not applying to the clouds (or at least, not in the same way) - it's particularly evident where the plume meets the terrain, since you can see the lighting on it is the same neutral effect all the way from top to bottom but then suddenly the ground has this haze effect. This seems to be working in the ground shots, though, so perhaps it's a scaledspace-only effect

Awesome, I was hoping something like that would be possible

My descent profile (at least, for larger things, haven't done a proper career) is typically: Ballute slows to 1-1.5 km/s, engine burn to slow to ~900 m/s (costs less than that difference due to the aid from the ballutes), deploy drogue chutes, then engine burn again for final 50 -100m/s or so. Costs approximately 6-700 m/s for landing my high-TWR SSTO/1.5STO (has multiple launch configurations) rocket. Successfully landing on the high elevation areas, with the snow and all that, is a lot harder though; I usually have to start braking earlier, and with 800 m/s budgeted it often costs all of that just to get to a safe parachute deployment speed, meaning it sacrifices a bit of the crumple zone without fuel for a final landing burn. Would probably work reliably with a km/s of remaining dV, but I typically just try to avoid such landings