Nertea

Somebody else could, but it won't be me :). Easy enough to change default bindings when a true release is closer :).

It's you know, an incredible amount of work, but yes. Yeah I can't effectively support non-stock scales. Yes. First priority after RestockPBR.

Well... I have almost zero interest in picking up other peoples' work and giving it a fresh coat of paint (I am vaguely interested in knowing what mods you're thinking about). Benjee needs no help updating endurance stuff and I really try to avoid working on replica mods at all. Just painting up other peoples' stuff is not really rewarding and I'm usually chasing some kind of unified gameplay with my things. If I were to start taking legacy mods, ripping them apart and making them fit my visions, I expect people wouldn't be happy.

It would be great. but that definitely needs a better software dev than me (I'd ask @JonnyOThan if he has ideas) . I honestly didn't know about Stapler until now. I had thought that TS was the only mod that was brave enough to go in there lol. Happy to support whatever could be sorted.

RationalResources has in the past created issues with my mods. I don't know what it does competely to be honest, but it would be something best discussed with that mod's owner. "Rational" as a term implies that it has a specific conceptual agenda, which may be different than mine .

lol barely, I hate this industry. Yeah I looked at all the existing recolor 'products' as part of starting this out. I think there's some things that work quite well with your mod (focusing on swatches is nice obvs, also there's some good work in the subarea selection stuff). I think you're in a good place - there's a bunch of alternate approaches one could take with recoloring that many games have experimented with. If you want to dig into that, I'd recommend a quick browse through customizers for various games. Focus on RTSses, MOBAs, things that aren't first person or RPGs for good examples. The thing I've done is for example highly inspired by Dawn of War's 2's army painter, which I love. tbh I think you're a little hamstrung by TU and its conventions, and the way people have used them over the years- you have to work against that. That's partially the reason I've taken such a clean-sheet approach, I have a fairly specific goal for what I want players to be able to do and what level of customization I want to supply. I can design the art, assets, UI and UX to cater to that exact vision (and it's intentionally less complex and arguably less capable than TU), which ets me take shortcuts and not deal with some of the stuff that you've had to. I also had a goal to integrate this seamlessly as a 'construction tool' so I put a lot of work into that. That's a stretch goal. Eventually I'd like people to be able to define a custom swatch and assign it, but doing investigation of how people used texture painting, both in KSP2 and the KSP1 mods, the far more common use pattern is to pick one or two common colours and use them throughout a switch. A (config-defined) swatch-based approach is much faster to develop, has cleaner consistency and seems to cover most use cases.

Yes.

Something I've been working on for a little while. With the advent of Deferred which makes major improvements to the overall lighting quality of KSP, the framework around using shader that use paramaetrically based rendering (PBR) has gotten a lot more relevant, so after some significant prototyping and testing I've decided to commit to a complete rework of Restock/Restock+ to use PBR shaders. For the layperson, that means more realistic lighting and materials parts, including reflective metals, better foils, translucent solar panels, etc. Here's a few randomly selected examples: This video is a nice example of some of the dynamicism on display, and here's a vignette of what things look like in different lighting environments This is an incredible amount of work so of course we need to add more. One thing that's currently missing from KSP1 is a unified, coherent part recolor system that has a passable UX. So with the help of a few people such as @Beale and @Al2Me6 I've been extending the Resurfaced mod to include a custom recoloring solution. This is my own personalized vision of how recolorability should work in KSP so is pretty dialled in to what I want. Effectively, RestockPBR will not only include reworked part art, but will also include a full-fledged team color implementation. Here's a few videos of how this works: The basics More basics Multiple material recolor zones with variants With tweakscale there's some amazing customizability of parts A couple core notes Often this will be replacing various Part Variants with recolorable zones. This means that perfect seamless compatibility with base Restock and stock will not be as good as restock. Some of your selected Part Variants will reset to defaults The QA level on this project is lower because it's just me :P. Work is slow. There's hundreds of parts and textures to convert. I'm up to 240 so far. This will probably include updates to parts Restock doesn't cover, notably aircraft parts. There are currently no official downloads, but they will probably come in alpha form soon, once I pass a certain part completion threshold.

Well, that depends what you mean. The kinda whole point of PBR is to increase the contribution of the local environment to the object, so e.g. the sky adds blueness to things facing the sky, green grass could tint something greenish. That manifests itself broadly by reflections and ambient contribution, which very much depends on the material's properties, which are an artist/author's defined parameters. So when you say that you want to reduce the shininess, that means that in this workflow you want to change what the artist decided on. So you can't, not easily. You could probably hack some stuff into the lighting setup to decrease the strength of the light probes (things that create the reflections/lighting contribution to the objects) but then you're kinda just removing the whole point of the conversion. So I'm questioning why you would do that at all and what the goal is. If you don't want reflectivity, just stay on older versions of the mod.

I won't upgrade any soft deprecated parts. I might reduce their texture resolutions to save on RAM.

I have a defence contractor now.

Both those engines can fully cool themselves when they are running. They just hook into the nuclear engine handling to do things like consume uranium and have some effects on throttle up and down.

Yeah I definitely won't do both. Every asset needing to authored in 2 different workflows is a killer and just won't happen. I can't disagree with some of that. I'd throw a couple notes on this. Older mod versions would always continue to be fine. I don't actually make a lot of new content these days so by staying on those you're just... staying on those. In some cases, by doing this I'm actually decreasing RAM usage, by reducing the number of variant textures for different colours and finishes. For example, if this stuff was applied to SSPX we would delete a whole set of texture variants (probably a couple hundred MBs) as you wouldn't need one set anymore. That should help offset additional teamcolor/metalness maps. Otherwise, mod memory consumption directly scales to the number of parts (in a part mod context). If you want more content there, you get more memory use, sadly, regardless of the assset pipeline Anyone who can match my textures in blinn-phong can match them in PBR no trouble :D. My somewhat radical opinion about KSP stability these days is that it's driven by planet mods and the somewhat chaotic framework around those. There's so many planet mods that have different compatability needs with the collection of scatterer, EVE, EVEFancyPantsClouds, Kopernicus, Parallax1/2/3, ultra-high res texture packs, that I honestly can't keep it straight. This isn't a knock against all those mods, just there hasn't been a stable framework baseline for the planet content to work against. I'd love to get a community project together to build up and stabilize all that but it won't really work until the core authors actually stop delivering key new content TUFX is not required at all in this set, by the way.

I'm not really interested in making new stuff right now, if there's something in the optimization or balancing landscape that needs to be changed please let me know so I can look at it. I don't notice much if any performance impact from the new things on the garbage laptop (6+ years old now) I do all development on, at least not compared to scatterer, vol clouds, parallax, etc. The different finishes are an issue for sure, but I'm being quite careful to make sure the color balances are tuned so that most untouched parts with default settings are similar. Hers's an example.