Shadowmage

Weird random solutions wins again! Seriously, some of the odd stuff that goes on in KSP/Unity...

HDR = High Dynamic Range coloring. Uses floating-point buffers for rendered color data rather than byte/fixed based (very basic over-simplification of its description). I've no idea why it actually messes with KSP rendering shaders, I only know that it does and that its effect was very similar to what you had reported.

*Wishes he could do parts anywhere near that fast.... with anywhere near that quality* In case I hadn't stated it before -- very impressive work you guys are doing here, love it Wonderfully consistent in both models and textures from the previews I've seen.

My personal opinion, is, 'yes, please!'. Especially if the 'fixing scattering effects being incorrect on camera mods (raster prop, telescopes etc)' will also fix up the scattering effects on the Reflection Probe that is now used in flight-scene for the new Stock PBR'ish shader (Mapped Specular I think it is called). Though I must also say that the god-rays and volumetric shadowing effects it created could be quite enjoyable (and impressive!) in some scenarios/scenes/areas, so I would definitely miss them in the long-run.

Adding a bit of potentially relevant information -- I have noticed similar occurrences whenever I enable HDR for KSP cameras (for...reasons.....). Something in the KSP shaders doesn't play nicely with HDR, and any surfaces hit by sunlight become partially transparent. Disabling of HDR, or replacing all Stock shaders with Unity Standard shader fixes the transparency issues (but of course presents other shader related problems...). I'm not seeing your camera as being set to HDR... but perhaps that is the default behaviour of newly instantiated cameras? IDK; might not hurt to try explicitly setting it to false in the method that creates the camera object.

The last few versions - yes, or at least it is possible. (1.4, 1.5, 1.6) Further back than that... I cannot say for certain, but it is likely that it will not work due to changes in the KSP code that SSTUs custom DLLs are compiled against (method signature changes at least; some changes to resource handling). For example, the Stock-Dv meter. Required changes to the SSTU code to play nicely with it, as there were new resource-lists that needed to be manipulated when changing resources. That stock code (the resource lists) does not exist in earlier KSP versions; so I guess the furthest back the current releases will be compatible with would be the first stock release that had the Dv meter. ^^^ So there is your answer. No. Current releases of the mod will only work on current versions of KSP. Stock has changed their code, SSTU had to change to still be compatible, and those two changes entirely break any potential for backwards compatibility. TLDR: If you want KSP 1.3, you need to use the mods intended for that version. You can find a compatible SSTU release here -> https://github.com/shadowmage45/SSTULabs/releases/tag/0.7.39.149 But keep in mind I offer no support for legacy releases.

There is no such event in the stock API that fires on a per-part basis during/after prefab creation that I'm aware of. Off the top of my head, a few alternate solutions present themselves that might be of use, depending on the original intention. 1.) Stock API does offer an 'OnGameDatabaseLoaded' event. Subscribe to that and iterate the loaded parts-list, running your actions/etc on them. Its not per part, but does give an opportunity to manipulate prefabs before they are cloned anywhere. 2.) ModuleManager offers a post-configs-loaded callback where you could manipulate configs or run actions -before- the prefabs are created/loaded. 3.) Do use a PartModule. Patch/add it into the part in such a manner so as it will always be the last module, and use the PartModule's overridden life-cycle methods to manipulate the Part. More of a hack/workaround, but sometimes that's how it goes

Just thought I would drop by and say that the KSPWheel mod/API -might- be able to accommodate whatever rigging setup your part is using. It was written specifically with compatibiilty of old Unity-4 era riggings in mind (though can also handle the new riggings). It is currently used in KerbalFoundries, where many of those models have not been updated since the KSP 0.90 era, so I'm sure we could figure something out Feel free to drop by the thread and take a look, or poke me for questions.

Not possible currently, but I could imagine some potential use for it on deployable parts. Feel free to open a ticket up on the repo and I'll investigate during my next update pass. I don't imagine it would be too complicated to implement and could easily be done as an optional feature, so chances are good that it'll make it in

I've been a bit absent of late, due to, well... life... and all the fun that it entails (mostly work...). But I haven't forgotten about KSP, nor do I intend on retiring from modding any time soon; I think that KSP still has a bit of life left in it, and several interesting venues still exist that I intend to explore. The good news is that I've managed to squeeze in a few hours of productive modding time over the past few weeks, concentrating on cleaning up the open tickets on the SSTU repository. Very productive time Most of the currently reported outstanding issues have been fixed in the dev code, and I believe I'll be able to get a few more done within the next few days. Also should mention that all of these fixes are available in the dev branch on the repo now if anyone is so inclined to grab them from there. Current 'plans' are to continue with the bug cleanup pass this week (time permitting), and take a few more hours over the weekend to recompile/pack/publish an official KSP 1.6.x compatible version of SSTU (at least so far as it can be with TU still being a bit out of date). At this point there really aren't any enhancements or new features in store for the release -- just a big long list of bugfixes.

I know the pain (from the dev perspective). Just get things wrapped up and ready for use? Another release drops. In the middle of a huge project that won't be ready for a few weeks/months? Of course, another release is posted. Thankfully, and I have to give them the credit where it is due, SQUAD has been very good about not breaking mods in the recent release (1.4+). Pretty sure all the mods I had compiled for 1.4 would still work on 1.6 (and likely 1.7). Still... I totally understand the frustration

Like... not at all You are correct in both the current situation, and the explanation of the problem. The TAC patches have not been updated to reflect the fact that nearly all parts use the SSTUVolumeContainer setup now. I believe some similar issues exist with the USI-LS patches.... shows how often I've been able to actually play recently... If you would like to open an issue ticket on the SSTU repository, I'll take a look about updating those patches for the next release. With the new systems in SSTU, I can probably come up with a 'blanket' patch to target all life-support-bearing parts to include a specific number of crew-days worth of supplies.

Yes. Specifically, dry mass = massOfResources + (massOfResources * tankageMassFactor * tankageMassModifier) Where 'massOfResources' is the full mass of the resources based on the tank volume, 'tankageMassFactor' is a global configuration parameter (or per-part-type?), and 'tankageMassModifier' is a per-part-instance modifier that is set by adjusting the 'tank type' in the configuration GUI. Lighter resources will generally have lighter tank dry masses. You need to provide the inflatable habs with some 'RocketParts' in order to inflate them once they are launched. They are launched in a compact form, and need further equipment in order to be brought online. If you right-click on the part, it should tell you the mass/qty of resource needed. I'm not familiar with FE, so sorry, can't offer any input there. No, there are no real gameplay differences between aerozine and LFO; SSTU doesn't use engine ignitions, nor does LFO boil-off, so the only practical differences in an otherwise stock game are the physical properties (density), and cost of the resource (more than LFO).

Yes. (helps if you read back at least the last few pages in forum threads; could have answered your own question)

Managed to find a few hours over the weekend to do some coding development, and during that time I found and fixed several of the recently reported issues. MUS Solar Layouts causing NREs -- Fixed. F1/J2 Missing Textures -- Fixed. Petal Adapter panels reappearing after jettison -- Fixed. ModularPart (StationCore) not working for 'solar panel' related contracts -- Fixed. Hoping to get a few more hours later this week/week-end to tackle more of the outstanding/reported issues. So if you've got a bug you know of that you would like to see fixed -- now is the time to report it If all goes well, hopefully I'll be able to package and publish an updated release next weekend. Of course, no guarantees about fixing any specific issue, but I feel that even the few fixed over this weekend will be enough to warrant an update. Should not be any real game-breaking changes with the upcoming release (mostly just a recompile with a few fixes). There will be some changes to the interstage petal adapter that might make it lose some persistent state.... but apparently it had issues with that to begin with, so likely nothing really of note will change there anyway.

SSTU is 100% dependent on TexturesUnlimited and the PBR shaders. I do not offer 'legacy' texture sets anymore. In theory you could go back to the old releases, rip out all of the old legacy textures, and recreate/fix all of the texture-set definitions and patches to point to the old textures.... but it would be a monumental undertaking. Might be easier to take one of the older releases and drop the new plugin into it, but I could not guarantee that all of the old part configs/etc are compatible with newer plugin code.

The look of TexturesUnlimited is the mod. Its entire purpose of existence is to provide access to shaders that stock KSP does not provide; shaders that can dramatically alter the visual aspects of the game. What specific mods are you inquiring about? There are a few mods that use TU's model-loading capability but do not leverage the shaders. However, in those cases, if the authors aren't using the shaders, then there should be zero visual changes. If the specific mod is using TU's shaders (and doesn't provide stock fallback options) then there is likely nothing you can do; the stock shaders simply cannot work properly with PBR texture assets. If the mod author did provide fallbacks, then you should only need to remove the config files as @Beetlecat suggests.

Wow... good finds I would suggest filing a bug on the Squad bug-tracker, to make sure the devs see this issue.

Changing gears works with the wheel-group functions as well. Set the wheel groups, and then change the gear on a single wheel will see it propagate to the rest of the wheels in the group. This is all done through the part right-click menu; I don't remember if action-groups are supported in that functionality, or what specific functions have action groups that trigger them.

As in, adjusting the ride-height / spring values for multiple wheels at the same time? For most wheel functions, if you set each part the same 'Wheel Group', any actions triggered on one wheel in the group will propagate to the rest of the group; adjust spring on -one- wheel, and it gets set for all of them. (might not be exactly what you are looking for; if not, let me know with perhaps a bit more detail, and I'll see what I can put together)

Nope, when in the water, the wheels always sit fully drooped (nothing for the spring to press against). You can get more force by mounting the wheels higher, so that when in the water only ~50% of the wheel is submerged (the point of greatest force output). Yeah, the scaling balance is a bit... strange... in places. As long as the power draw (and mass) of the part make sense for their new scale, I wouldn't worry too much about cross-part-(im)balancing, esp comparing parts at different scales.

Not by default. You can try the unsupported stock-parts patches, which can be found here (download the .cfg files, put them in a folder in your GameData) -- https://github.com/shadowmage45/KerbalFoundries2/tree/master/KerbalFoundries-Patches/Stock But please keep in mind they are currently unsupported for a reason -- I haven't had time to review or fix issues with them in quite some time. As far as I know they work, but I could not tell the extent of any issues that might be present.

Most of the KF wheels (and tracks) have water propulsion. As long as some of the wheel is visibly above the water surface, but still in contact, you'll get some movement ability. One of those neat little hidden features that almost nobody finds or uses

TU does not already have such functionality, though what you are looking for has been brought up a few other times in regards to custom texture packs / recoloring, and it is a feature I would like to have. The problems arise in that it is such a huge difference from the existing methods that neither the existing UI nor the plugin code could properly accomodate it (with the UI being perhaps the more difficult of the problems to solve). With that said -- I will certainly give it some consideration during the upcoming UI redesign (whenever that actually happens...). There are a few other features and changes coming regarding the recoloring and customization end of the mod, and I think the end result will be... well.. something different at least. If you were up for some custom plugin coding... it might be possible to do what you are looking for by leveraging some of the existing TU infrastructure... but I make no guarantees. I've been out of the loop for a bit, and would have to re familiarize myself with the code base before I could say for certain, or give any more pointed tips on where to start. At the end of the day though, the shaders and reflection updates are the important parts provided by TU -- all else is provided only for convenience for the most common use-cases (or what was seen as the most common at the original time of development); it is fully possible to leverage the shaders with fully custom plugin code that doesn't touch any of the other TU TextureSet stuff.

Judging by the slight environment reflections in this picture -- at least some of the new assets appear as if they are using PBR shaders of one sort or another? (is this the stock Specular Mapped shader in use here?) Work looks awesome (and very much of the quality that I'd expect given the source ), just curious on some of the technical bits, for personal reasons (I have long dreamed of a day when all of the stock parts were using modern shading techniques). Looking forward to seeing this develop into maturity; I could likely actually use these stock parts without cringing