Manwith Noname

@garyhoover Agreed. @moguy16 Yes, current downloads are for 1.8.x. Edit: Edited title to reflect that.

I can neither confirm nor deny my involvement with add on projects that may or may not be ongoing.

On repeat...

Alright, updates. Stock recolour is configured for KSP 1.8.x. Should fix the missing EXTRA_INFO header on the coupler variant. MK2 and MK3 Expansions updated to whatever release I grabbed at the time (around Oct / Nov) last year. Additions: Procedural Wings - I sort of want to revisit this at some point but it was a quick (and a little uninspired) job to mimic the existing textures and add some specular detailing. The curved surface wing kinda works but the part was never finished it seems as there are no base textures and no UV data within the model from what I can ascertain. MKIV Spaceplane Systems - This one has been brewing in the lab for well over a year. Well, maybe festering might be a better term. Colour masks were mostly done in 2018, then it sat for nearly a year before finally motivating myself to finish it. I still want to add some layers here and there but for now, it's mostly a two tone affair with smatterings of a third layer on a few parts. Thanks to @Nertea for wondeful 60's puppetry sci fi inspired nostalgia and permission to release. No pics, no clicks... As always, completely remove any existing packs and dump the new ones in place. Failure to do so will result in bad things happening. If you paint a part that doesn't use all possible colour layers then I advise making the unused layers the same colour as the primary just in case they're added one day. If anyone notices something they think might be missing, broken or can be improved (there's quite a bit in my mind), don't be shy. I don't play KSP "properly" and haven't for some years. Testing is mostly limited to "does it show in the editors and then in flight". While I make every effort to double check things when I'm setting them up for the first time, there may be changes I miss as time goes by and KSP / mod updates occur, or sometimes I break things unintentionally by rewriting the config (goodbye EXTRA_INFO). It's only really those who use them in anger a playing environment that are likely to catch them and you'll probably be reminding me of things I've long forgotten. Edit: Forgot to mention. These should be considered releases for KSP 1.8.x.

@Drew Kerman Here's a grab with it enabled. If you watch the sun set you can see the shadows "grow" towards you as it lowers behind the mountains. I can grab something with it disabled at the same UT easily enough for comparison in a bit, gotta run right now though. This is 1.9 stock. Edit: Here's a similar view, same UT with the terrain shadows disabled...

Doesn't stock do terrain shadows now? I seem to recall an entry in the settings.cfg appearing a while back something along the lines of "celestial bodies cast shadows" which people thought would be eclipse casting but I've got a vague recollection it was in fact much like the terrain shadows implemented in Scatterer.

I think I know what you are referring to and from memory of my testing when encountering this, it only affects loaded craft to the VAB / SPH. When building the craft, things functioned normally and a loaded craft would display correctly when launching. At least, I think that was what I found. Stock fairings are a bit of a pain and this isn't the only issue with them. I've been meaning to do a more thorough test on them so I can provide a more useful report in the main Textures Unlimited thread as it's not strictly a problem with the configs and textures but the way the main plugin handles them, unless I missed something in this specific module. Having said all that, last I looked at them was in 1.7.3 so it might well be different in 1.8+ versions of KSP. Edit: Oh wow. They're really broken and it appears to be linked with another issue that appeared not so long ago. Good catch. I may have already resolved this in my local files that I never got round to uploading. I certainly recall noticing some weirdness with sticky textures on some variant parts, which I suspect this would show as. Either way, if I didn't pick up on this specific case it will be fixed in the next upload. I'll get my behind in gear and pack up the updates I had done during the 1.8 era for various existing packs. Basically everything except OPT as that hasn't changed, so, stock 1.8 parts and some parts that I either missed or were added to the MK2 and MK3 expansions. Heh, might need to do a check on that some time.

@Beetlecat I appreciate the appreciation. Another pass on making it more compliant with Restock is on the cards, I just need to get round to downloading the latest release and sifting through their blacklist. There's also some improvements coming, I've redone the masking for the landing gear so it makes more sense. As in, tube parts will be one colour, other mechanical / structural parts will be different layers.

Haha, I got a bottle of that for christmas. ... It's gone.

@purpleivan I experienced something similar at KSC. I think it was after launching to the runway when the camera was at certain angles. Try disabling forward compatibility or high precision, or even both.

It's an appropriate fix. The stock cargo bays have been modelled with their animation such that the start of the animation is with the doors in an open state and the end of the animation is with them closed. The APP size 2 cargo bay is the other way around, start is closed, end is open. These parameters along with "closedPosition" in the cargo module define how the game needs to interpret those animations so the part functions correctly in game. I would say, this particular cargo bay animation is modelled more logically (the deploy limiter is mapped 1:1 this way rather than reversed, the closed position is zero...) but at the end of the day, neither approach is right or wrong as the modules have the ability to redefine the animation controller and when to occlude parts with regard to the animation state.

Hmm, I've never played with the Stock reflective shader active on parts as I replace them with shaders from Textures Unlimited. I do however run real time reflections (and they're typically active on every part, unlike stock) and don't have framerate issues. My system is 5 years old so I would expect you should get better performance. I would however note, I do get drops inside atmosphere (more accurately below the PQS switch height) when both Scatterer and E.V.E are installed. Not as bad as you are experiencing, I maybe dip to mid 40's from memory. I can use one or the other without issue but both just causes strange behaviour that I'm not entirely convinced is completely down to my system but more the way the mods interact with one another.

Ah, good spot. I can imagine how this occurs but I'm not sure if the game actually works that way. If a lookup table is being generated for redirected textures like these parts do, then the last path definition for "placeholder" will point to the incorrect path for the cones texture. I hadn't noticed this because I've patched them all anyway. For the Size 2 Cargo bay, some of the animation entries want to be flipped, so false instead of true and vice versa. You can test this module manager patch if you want... I made manual edits directly to the file in this instance so I haven't personally tested that patch. OK, so as noted by @Tankman101, other parts need to have their placeholder texture pointed to the right path then everything should be fine. You can either find the part configs and make sure the path for the cone texture is correct or you can try this module manager patch... Not personally tested this one either, my own patches are more extensive and won't work without other files. If you don't know how to make this patch work, simply make a text file inside your GameData folder. Name it "APP_Cone_Patch.cfg" or something that helps you identify it. Copy and paste the above code in to it and save. When you run the game it will alter this entry in the part config. Patches are written off the top of my head but they're fairly simple. Though that doesn't mean I haven't forgotten to do something obvious

When did you download the mod? This particular part did have an issue due to it reusing Squad textures that have been moved to a new folder. This does appear to be fixed for the latest release looking at the configs on GitHub though.

It might be worth mentioning, KSP automatically converts textures to DDS during load and should be dumping the unconverted information from RAM /VRAM, though I don't know for sure if it does but I suspect it is otherwise it's just consuming even more resources nullifying half of its purpose. The benefits of having the textures already in an appropriate DXT format (packed in DDS) are: You'll reduce a bit of load time as it doesn't need to run the converter. This is the main one, you can control the quality to some extent. I've never used the auto DDS converter but I have made plenty of DDS textures manually in GIMP, BMP2DXT and with the command line tool from nVidia. They all gave similar results with one exception, the DDS plugin for GIMP has a toggle for perceptual error checking which reduces the 4x4 block effect in certain scenarios. This may exist in the command line tool from nVidia but I only run it for comparison with quick arguments I found. I suspect the DDS4KSP tool is built around these nVidia tools but I don't know for sure. At least, it's what the GIMP and Photoshop plugins are built from. So, personally, I'd try a few things and see if you can spot the difference. It really depends on the input texture as to how noticeable some artefacts are. For sure, batch converting is the easiest route but without using that tool myself and comparing the results with other methods, I couldn't say whether I would recommend it for anything beyond convenience. I'm also unsure if auto conversion just simply converts everything to DXT5 when DXT1 might be adequate, which would mean half the file size again.

I should try and remember that exists. It will probably make removing all the asteroid entries a doddle.

On the subject of asteroids, they should eventually despawn if they are not being tracked. It takes a while but in theory, the save will clean itself up in time. If you can't wait, open up your save file (make a manual back up just to be safe) and look for entries such as this... You can safely delete these, just make sure you don't leave loose brackets or remove extras. It should be fairly straight forward though, if a little time consuming. Back when asteroids were first added to the game, I made a save that was basically a test to track everything that appeared. I got to somewhere around 6-700 being tracked (from memory) before the game choked and became almost impossible to use. This was on an old laptop so numbers will vary I imagine based on CPU, plus there has been numerous updates since then. For me, there were very few actual vessels in flight so the majority of the asteroids were clumped together in the save. Haven't checked in recent versions but that's something else you want to be sure of, don't want to accidentally remove an important craft while mass pruning. Fortunately one of the first entries is the name of the craft so you should be able to just keep highlighting down after finding the first one until you see a craft that isn't identified by the typical asteroid monikers.

I suspect many players can attest to plotting a node for intercept only to find they've missed on arrival if they have not been monitoring it en route. This could potentially have some explanation for why that occurs. Squad's math isn't necessarily wrong though, rounding can cause such errors even with the "right" math.

Kerbal Object Inspector will render the mesh of an inspected object in wireframe. Typically, this is shown like an overlay of the model so you see it in place. This occured because I had previously been inspecting meshes inside the cabin from IVA, when I jumped back to the external view, presumably due to positional data changing with reference to the camera, or perhaps something like the reference for that part of the model disappearing, the wireframe appeared in the heavens.

Do you want a list? Granted most of them are from decades old TV and B movies where over the top hammy acting was par for the course.

I did this a while ago but I was just browsing some screenshots. I call it "The great landercan in the sky". Technically, only the rover part is present as a "constellation".

Mark Zuckerberg says "Today we reveal the next revolution in social media, Spacebook".

So, I haven't played the game properly in a long time but I have just encountered something similar. I decided I wanted to try and make a SSTO plane capable of lifting a reasonable amount of tonnage. The plane works fine until I add some docking ports and the intended cargo in to the cargo bay, then, it just spins when loaded to the runway. It's a very slow rotation, no reaction wheels enabled (I disable them on all plane type craft and rely on ailerons). I fiddled with spring, damper and friction values and that seems to have "fixed" it, though I'm not convinced there isn't something weird going on underneath that this simply hides. Mostly, it was increasing the friction that prevented it, I just adjusted spring and damper to make sure it wasn't on the verge of doing the old kangaroo thing when they bottom / top out. I also suspect the MK3 cargo bays are not shielding correctly but that's another story.

I don't have a Mac but I've seen this problem and a potential solution on the Steam forums. Find the KSP.app file of your install, "right click" (might be command and click if you have a single button mouse, or whatever combo it is. I know one exists but, I haven't used a Mac in years) and choose get info, then tick the "start in low res" box. Original post here.