Delay

Granted, but given the page number, that already happened twice. Didn't seem to work out too well. I wish for no more memes in this thread.

Banned. Just. Banned.

I like it. Time to fry my GPU! By the way, I am very much aware of the fact this is all massively WIP, but these clouds are a bit too smooth right now. This is especially apparent in screenshots 1 and 3.

Banned for having a like on your post.

Separation confirmed!

This can compete against MSFS 2020! ...but at what cost? Don't tell me this amazing effect can be pulled off with no performance bottlenecks.

Today's date is either 21/12/21 or 12/21/21 So in one system you get a sequence that reverses the previous number and in the other you get the first 6* numbers in the Thue-Morse sequence. It's about the closest we'll get to a date such as 12/12/12 for, well, one hundred years! * Given that Thue-Morse can be constructed using substitutions, you can also take "21" and "12" to be the elements to give you the first three numbers.

@CheesecakeMy bad, I did not know a different log file was meant. My apologies.

The log is in the main folder of KSP, where the executable also sits. It's KSP.log.

Finally got another tetanus shot. It was already 3 years overdue.

Have you tried TUFX's TAA yet? That works fine for me. I think it's enough to create an empty profile that only has a name and the AA method set. However, TAA doesn't work well with map view, but you can make a different profile for map view and tracking station without TAA.

The kerbiloid ban.

Banned for ambiguous reason.

You know, as much as I love the Space Shuttle, aerodynamic stability is yet another reason to hate that flying brick. It's a miracle the roll axis was stable enough to be used for control!

It's already been two and a half weeks? Firstly, I decided to upgrade the tracking station. Being able to tell where you're going is kinda important! I also added the materials bay to the experiments I can run. Naturally, the first use was in LKO. I wanted to land close to KSC so that recovery could be extra cheap, but I ended up on a rather worrying trajectory... Landing in the mountains is never a lot of fun. It's easy to land on a slope and lose the valuable science on board! Oh, and Jeb. I had a lot of luck with this one. That could've gone very wrong. Right, with that little shock dealt with, it's time to finally reach orbit around the Mun! To test whether I can safely make that trip, I decided to fly without any science first. If I can't make it now, I certainly won't then. I went for the Reliant instead of the Swivel for this one, the idea being that it's lighter and provides more thrust, so I could pack more fuel into the stages. And while that did work, I probably won't do that a second time. It took over three times as long just to pitch to 45°! That kinda put the mission in jeopardy, I didn't think the Reliant would be this bad to control! I made it into orbit, but I burnt a lot more fuel than expected. I had about 1500 m/s left (I started with around 2600!). That might just be enough to reach orbit and go back? I went for it. 660 m/s at the end of the injection. 380 after capture. ... 98 m/s after escape. That was a bit too close for comfort to say the least! I got... "some" (a lot of) money from it, enough to upgrade the launch pad as well. I'm not the kind of person that could pull of a 3 t to X challenge, I need a bit of fuel and mass for these things! The launch vehicle I had was fine, it just wasn't very controllable. The solution I came up with was a Swivel for control and 2 SRBs for thrust. That would've been difficult with 18 tons. This time I could bring some science home as well! And indeed, this launch went a lot better. I had way more dV to spare through all phases of flight. I haven't built a lot of stuff with size 1 parts recently, so this actually was a small success for me! It's funny, I used to have those problems with size 2 parts! Next up is obviously a landing attempt. I should be able to do that next time, but size 1 landers never really worked too well for me...

Had a minor heart attack. That dread of landing in the mountains, it gets me every time.

Thanks, I'll try that. As for my pseudo-normal maps, they were .dds files. I tried a few options in the gimp plugin and none worked, so I assumed none of them would. Well, the code solution works as well, and that's what matters at the end of the day . (I'd still recommend at least trying that, just to be sure).

I meant via what @Electrocutor had suggested to me when I ran into this issue. textureColor = _BumpMap, 0.5, 0.5, 1.0, 0.5 It solved it for me, whereas actual placeholder bump maps did not. Speaking of bump maps, this reminds me. What format are .dds files stored in? Because right now I'm using .png just to get my textures working.

Rather easily refuted. A spacecraft is too small to completely cover the sun most of the time. Just how close do you want the camera to be? Interstellar space is an obvious one. You're not arguing that, either. Even the title of the thread excludes interstellar space from being considered. As for eclipses, I find it difficult to find any photographs of that, neither from the ISS nor the ground. I know that it's possible to observe stars behind the sun during a solar eclipse (one of the first demonstrations of general relativity), but no video or photo seems to exist that demonstrates the phenomenon. I could just not look deep enough, though. Would you like to share a photo? ...unless you were talking about lunar eclipses, which happen at night (see title) and it wouldn't be possible to observe a lot of stars with at most a 1/60s exposure time (assuming no motion blur is desired. Though star trails do look pretty...). The sky from the ISS is quite bright.

Actually, no. I was genuinely trying to correct this ambiguity. Don't worry, it's not the first time I've been misinterpreted / have presented my texts as misinterpretable like this. I mean skybox as a generalization of all possible techniques, as skyboxes are the most ubiquitous way to achieve such an effect. No perceived snark this time, hopefully. I can see how that might not be apparent. I'm not insisting on this method, I've simply chosen it as a representative of all. That is literally everything. I'd have to look exactly up in the middle of Kerbin's shadow to even try to see a few stars. Now, you could fix that by increasing the simulated exposure time, but that would necessitate the implementation of at least motion blur, and not just over 1-2 frames.

You got it the wrong way around. Stars in KSP aren't unintuitive because they don't show up in the Apollo pictures. They don't show up in the Apollo pictures because that is unintuitive, because that is something we are not used to seeing. I'm more or less actively involved in debunking that conspiracy theory, so I'd know what, how (and if) they think. Fine, "Replacing the star-filled skybox with a black one in the presence of any bright object". I can understand how under non-superficial interpretation, this statement can seem ambiguous. Most of the time stars would not be visible, unless you are located in the shadow of a planet or moon. Even in interplanetary space, the spacecraft would reflect too much light to make stars visible. Thus, we're not really talking about "stars unless object" and more about "no stars unless shadow". In that case, why bother with a skybox at all? It requires long exposure times, even in LEO.

How did you just gloss over my question? Plus, you make it sound like I'm against improving these systems purely because they are visual. I welcome every improvement in both gameplay and visuals, just to make that clear. However, unlike replacing a particle system with a mesh-based one (which, among other things, has performance benefits), removing stars is not an improvement, just a simple change that doesn't add or subtract anything.

That is because normals were broken somehow from one KSP release to another. Fixing this is a bit of a pain, but it essentially involves editing all materials without normal maps (no _BumpMap texture) to use a fixed color. Previously, the lack of a normal map simply implied that the map was blank. For some reason, that is no longer the case.

Configs are basically separate files that tell TU what to do to each part. You can make them yourself, but some are already provided by other people. I'll assume that you do not use any mods affecting stock parts? Like VenStockRevamp or ReStock? Then the Textures Unlimited Recolor Depot might be what you're looking for.

That is because you need configs. TU only provides the framework for PBR shading to work, but it doesn't affect any part by itself.