Nertea

Restock already replaces most of the MH parts, with the exception of the parts we don't consider to 'work' gameplay-wise (service modules, the MEM). There are some discussions about doing the BG parts, but it's low value. RestockPBR is currently scoped to also replace the mk1/mk2 plane parts (mk3 is probable but honestly this has been a ton more work than anticipated). We're at about 345 done and about 60 in progress with the mk3 set parts being another 30 on top of that. And yeah, will convert all my mods in due time and this will be the new visual 'baseline'. It'll take a while though, literally a thousand parts. I have made sure that the base look of parts is quite similar to the Deferred baseline though, see this post in the NFT thread:

Yeah, fair. I can't really disagree with you feeling frustrated, you feel that work you've done is wasted. Can't change that I'm afraid. I will say that I am incredibly familiar with TU as a concept, I have been around this community for a long time and watched TUs inception, and sat through several attempts to apply recoloring to my mods that frankly ticked me off as an artist. At at least 3 different times, I did evaluations, one of them with shadowmage in the loop, of how I might utilize TU for its various capabilities. In every case it has fallen flat for a scattering of different reasons, and it's only recently that I would say the mod ecosystem has become capable of delivering a unified product for visuals that matches what I want. Maybe if I were to qualify the original statement I'd say there is no coherent tech art approach to delivering recoloring that involves the original artists Like I mentioned to another poster, I did a strong evaluation of the available options for this conversion both in UI and tech art terms and I found that they did not align with my goals and the user needs that I saw when I evaluated actual player use of the tools. Features like swatch editing and authoring are just not MVP as part of this project. Looking at how people used things, I didn't see a desire to choose rgb=254,124,126 with metalness 0.2 vs 'shiny metal'. If you feel like it is less flexible, you're right. Maybe I'm wrong. I'm ok to be wrong, we'll just roll and adapt. However saying that I think you should modify your perspective a bit. This piece of work is a PBR conversion with recoloring as an additional feature. I want to use modern shader features to improve the look of parts and learn new art skills. Recoloring is separate and additional - my perspective has always been that I won't do recoloring until I do PBR, as I'm not reauthoring things twice. In the restock context, I am acting as an artist and taking it on in this way lets me develop the approaches and tools that let me realize the artistic vision that I have for this. The TU mask work for Restock you have done wouldn't have delivered a Restock PBR conversion, because that's not what you're doing. In that context, I feel that the various approaches to applying recoloring to my work fall short because they don't match my vision (yes, I have been aware of its existence). That's not to say they're bad, they just aren't what I would do. If I'd joined your project I'd have made a mess of your own vision and compromised my own, to the detriment of all. So, my apologies.

You should probably ask in the snacks thread. This mod only provides some configs, the actual stuff that does stuff isn't managed by me.

Yes, repaintable, yes, optional tiles.

A considerable amount of work is being done on the plane parts right now. A few in-progress images...

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.

Sigh. This isn't up for debate. It's not punishing people for politics, it's just that I do not want to have this stuff in my mods. Here's a thing I wrote for a different community, which strips all the politics out so it's less loaded that may communicate understanding. Also, see this note in the NF thread for an important service annoncement:

So, there's something that will probably be happening in the next set of NF updates. I will likely be moving all parts to a PBR workflow, which results in a far higher fidelity than the currently existing parts. This will introduce a hard dependency on Resurfaced, and a soft dependency on Deferred (because it won't look quite as good without that). This update would not be backwards compatible, as it requires reauthoring new textures and using new shaders that will not work in the older shading model. This wouldn't break crafts, but would not work well without the new dependencies. The existing mods in their current versions would still exist but any new development will only happen in the new workflow. Thoughts welcome. Here's some examples of how parts look in that context.

I have a pair of fairly solid concepts for the capsules right now. I'm working on a different, extremely large project at the moment so it's not a priority, plus I guess more time for people to be offended is good. New versions of NF Spacecraft will have the 2 new capsules, a replacement engine, as well as likely the 5-6 aerodynamic landing legs I've been working on for 3 years on and off. New versions of NFLV will have the 2 new engines, as well as a couple other incentives to upgrade. Likely both new updates of the mods will include compatability to the new project, which in itself should be a large reason to upgrade When this happens the deprecated assets will remain, but I'll do things to them to discourage use.

You can safely delete the file. It should probably be removed. I wouldn't count on them being maintained. Once they are replaced, they're going to be at risk. I might do something weird like massively decimate the textures to keep things safer but degraded for longer. The issue with this is that with those engine technologies, switching to a lighter propellant significantly cuts the thrust. As I want to have fairly clear role categories for each engine tech here, I don't want to make the MPDTs suddenly jump into low thrust high ISP roles. I wouldn't use the electric RCS lineup as a good comp, I'm really not happy with it overall and now that FFT has some more options in that space it might get reworked in the future. The current thinking for the NFLV engine replacement is to use the the Welkin engine in both a standard and vacuum versions (Otter, Sphinx), as it's neat and has a nice visual vibe as well as fitting the rough size envelope. For the CryoEngines one it'll be either the Aeon-R or Archimedes, again with a vacuum variant (Deinonychus/Eagle). Not sure which at the moment, leaning towards the RocketLab one because I like Neutron.

I've kept this one around for vague(?) reasons - I can just swap the raptors out, the outer frame there wasn't based on anything in particular. So once the Raptor replacement comes in (trying to decide between a couple options) it's a drop in replacement. But if people prefer I'll cut that one out, easy enough. I've got stuff in flight already.