Nertea

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.

I've absolutely nuked dozens, if not hundreds of hours of my own work before, generally to everyone's benefit. I'll replace the parts removed by different, better versions, as usual. There's no shortage of interesting command pod concepts out there to work on, and a new monoprop engine will indeed be developed to fit the gap created. It'll just take a little longer - I'd initially intended to wait until I had the replacements ready to do this, but us in Canada have been a little stressed for the last 24 hours, and this is part of my own response to things. To be clear, I pass no judgement on people making SpaceX mods or using SpaceX mods, and I respect the work the engineers have been doing there. Unfortunately, to me it's kinda like a band - I personally cannot reconcile the frontman's statements (this ain't any one thing) with distributing things that are tributes to the band. Any further details or discussion fall definitely under the no-politics rulesets. If you want to share information on how to restore the removed parts, you may of course do that, but please respect my wishes and don't do it in my thread.

CryoEngines 2.0.8 Removed Deinonychus and Eagle engines They are soft-deprecated so crafts in flight will not be affected. The reasons for doing this should be evident. They may be replaced in the future by different models.

Near Future Spacecraft 1.4.6 Removed the Nereid and Tethys command pods and the Chickadee engines. They are soft-deprecated so crafts in flight will not be affected. The reasons for doing this should be evident. They may be replaced in the future by different designs Near Future Launch Vehicles 2.2.2 Fixed VABOrganizer subcategory assignments for RCS parts Removed the Otter and Sphinx engines They are soft-deprecated so crafts in flight will not be affected. The reasons for doing this should be evident. They may be replaced in the future

These screenshots don't work with me. The new reactors also work fine with this mod for myself (and this is the first I've heard of it as well). I recommend you make sure you have the latest version, or take a reinstall if necessary. Edit: reviewing your log - KSP-Recall and associated plugins are known to cause issues - You have several outdated mods from my suite installed. Consider ensuring they're all updated.

I've been cooking something with Beale and a few others to add to Resurfaced. https://imgur.com/LzRkaGI https://imgur.com/tNx6hLc This is a lightweight, low friction team colour implementation that builds off the shader work that has been done. Excuse the garish colours, just for demonstration

Systems Monitor 2.3.4 Stability updates: breaking the mod will now break it less Performance updates: cut frame time cost of DBS on a 200 part vessel by something like 75% Fixed issues with edtor reverts and reloads failing to reset the UI until you made a change to the vessel Code cleanup Reworking of layout of handler code for ease of use Remove old thermal handling code now that nobody has missed it

System Heat 0.8.0 Updates to zn-ch localization Corrected an issue where the heat simulation would not be reset when using the Hangar mod to launch ships. Note that if you are experiencing this you will need to re-save the ship in the editor Additional performance improvements and code cleanup Added the ability for radiators to have their output scaled by atmosphere depth and/or acceleration Fixed a fission reactor related logging incident