Shadowmage

Good news is that at least the ALG-Large looks like it will be able to keep its original UV map. This means that I can provide PBR textures, as well as utilize the existing stock-compatible textures. I have not yet looked at the other ALG parts, but instead took a moment to play around with some concepts for this series of parts in general. Hmm... PBR semi-stock texture? The doors are only half done, but upper body is otherwise complete. Tried to mimic the stock smudgy stuff around the panel edges a bit, though its certainly less visible than the original/actual stock parts. I'm not sure what it is supposed to be, so its hard to replicate in PBR.... is it dirt? scuffed paint? idk... so black smudgy stuff it is After removal of the 'stock' details, and instead using a 'scuffed paint' effect in combination with standard edge damage effects along the paneling lines, it ends up more like: Just playing with concepts at the moment (and refining some 'hand painting' skills), haven't settled on anything for these parts yet, and indeed don't even know if I'll be able to do all of them yet.

Pretty much, at least on the Windows side. Neither do they support DX11/DX12 though. I could even dig up some official comments from SQUAD staff on the subject, basically stating that DX9 is the only supported graphics API on Windows. With that said, I've had generally good results using DX11 with TexturesUnlimited. There were some part-icon issues (blue models in part list), but I believe TU is patching those parts now to fix the problems. Aside from that I can't think of any issues I've encountered.

As a fellow Substance user, feel free to hit me up with questions/etc. I've been using it off-and-on for ~1 year now (more off, unfortunately), and find the methods that it provides for texturing to be so far beyond the normal standards (PS/Gimp), that there is no way I could ever go back. I love the ability to slap a texture stack onto a model, tweak some layer masks, and have a nearly fully textured part with only ~10 minutes of work. Granted, I'm using a 'Smart Material' setup (a preset group of regular Material layers/folders/etc) rather than going down the full Substance Designer Procedural Material route, but in the end the goal and use is very similar. If interested in PBR textures/materials/shaders (e.g. Unity Standard shader), I would also urge you to check out Textures Unlimited (see signature for link), so as to unlock and take advantage of the full potential of Substance Painter, and Unity-PBR materials and shaders.

Thanks for the report, and self investigation I'm actually a bit curious if you manage to find a solution to this issue, as I'm seemingly impacted by something similar. When starting KSP in OpenGL, about half the time it will crash when going from main menu->load game to the space center view, with what appears to be an access violation / low level crash (no crash reporter/etc, KSP window just disappears). Would not surprise me at all to learn there is something up with the Nvidia drivers (as I'm also using Nvidia at the moment), or even something specific in recent versions of KSP.

Welcome to the forums Glad to hear you are enjoying the mod; being the only full-time developer, it certainly has taken some time to put together and get to its current state. Work is ongoing though, and there is still more fun stuff planned for the future Excellent question; unfortunately the best answer I can give at this time is 'I'm not sure, it should be working as well as the stock solar panels, as they share similar code where energy output is based on body heat and solar flux'. Now, the After Kerbin Planet Pack may well be patching the stock solar panel parts to change how they function (higher EC generation rates), in which case the obvious solution would be to also patch the SSTU solar panels in a similar fashion. As this is not a mod/pack that I use, I cannot supply these patches, and they would have to come from someone more familiar with the planet pack and its setup. Anyone else familiar with After Kerbin Planet Pack, and how it affects changes to solar panels?

Up to 35/66 tasks completed in the tracker for the model/texture updates. Just a bit over 50% done... One more part re-UV'd and with initial textures applied -- this is one of the landing legs originally modeled and textured by @TiktaalikDreaming, with some minor changes to geometry (made it a bit shorter): It will also be receiving a bit of a functional update, where the middle piston (black) will have its extension controlled via user-selection. Will be fixing up the deploy-angle specification/use as well. Both will end up being linked to an otherwise empty animation so the leg will still be fully retractable/deployable, only now the extends of the deployment will be easily changeable from in the editor (and flight?). Next up I'll be testing out some updates to the ALG parts. I'm unsure if they will need new UV maps... if they do, I might skip updating them -- keeping the existing textures available to match the stock parts for these particular pieces is kind of important.

Updated release is available -- just a repack to fix issues with missing OpenGL shaders in TexturesUnlimited: https://github.com/shadowmage45/SSTULabs/releases/tag/0.10.46.158 See link for downloads...

Thanks for the confirmation, and glad it is working for you now/again. I'll try and get a repack done tonight that fixes the published release up (likely a new version#).

That would be my guess -- the animation needs to be set to the looping type from within Unity, prior to exporting the .mu.

Thanks for the report, will definitely take a look and see what I can see. In the meantime, you might try updating TexturesUnlimited from the releases on the Repo ( https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.3.5.19 ). Apparently the one that I bundled with the last SSTU release was missing some shader targets (notably, OpenGL on Windows; should have still been present for OSX though). Will let you know what my investigations reveal...

LoL, ooops those are WIP/testing mods, that get compiled with TU (but that I forgot to remove from the package). Fixing the package now, and will re-upload shortly. So if you have 'bloom' enabled in your game, please remove TU/TUFX and redownload/re-install.

Couple more parts done, and some interesting changes/additions... Tiny Wheel: Nothing too complex or surprising there. Its a wheel Finished up the standard Repulsor texture... And gave it a new particle effect for when it is enabled (effect varies with repulsor height setting).... So far it is always enabled, but I'll likely have a config/toggle somewhere to turn it off. Fairly lightweight though, single emitter using the new Unity ParticleSystem (Shuriken). Now that I've got the effect and texture done, the surface-attach repulsor will likely be finished up in short order as well. Edit: Because, well, why not...

They all have issues at timewarp > 2 (meaning KSPWheel in general); its a physics thing that I'm unlikely able to be able to solve. Don't put it past me in the long run... the shaders/materials don't support it currently, but I was investigating a similar possibility not too long ago regarding mixing in secondary detail maps; these secondary maps could well be a 'damage/wear' texture. The alternate would be to somehow expose my entire Substance material stack to Unity (its supposedly possible?), and tweak the parameters in-game & rebake textures occasionally to increase the dust/wear effects. This would be the 'better looking' solution, but I'm entirely unsure as to its possibility or impact on performance.

Updated release is available: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.3.5.19 Fixes shader bundle OpenGL compatibility on Windows. Should be no other changes.

Few more parts finished up yesterday, as well as adding a few more wheel tread options (not shown). Small Wheel + Medium Wheel: Truck Wheel (Single + Dual): These went quite fast, as I already had considerable work done on them, including all of the UV mapping and most of the rigging. Mostly they just needed various texture or model related issues 'fixed' before they could be finalized. Well, they've been fixed up, and things are coming together nicely now.

Update/recompile OTW with fixes to the missing OpenGL Compatibility on Windows. Apparently my instance of Unity Editor had somehow reset its 'Player Settings' and removed my customized shader/graphics API target lists. Recompiling the bundles now (with proper target lists), and will repack and upload as soon as I can verify they are all working. Few hours perhaps.

Created an easily changeable set of of wheel tread textures that I'll be using for as many of the wheels as possible, will be an option in the VAB to select the specific tread texture, likely with an additional option to reverse the tread direction on a per-wheel basis (for directional treads...). Will be quite a few tread patterns available to choose from. Most of the existing tread patterns will still be available, as well as some old concepts that never made it in or were retired, and a few new ones as well. Undecided as to the exact number, but as they will be re-usable across all the wheels, I don't feel bad about including a decent selection. The tread patterns do not change any of the wheel properties(friction/grip/?); it is a purely visual/texture change, and will remain so for a few versions. Also, one more part with the retexture/re-rig/config update 'done' Nearing about 30% completion on the PBR/model reworking update in total, with ~9/30 parts being done.

Thanks for the confirmation that it does work with DX11 at least; thought perhaps I was going crazy... I'll def. do some testing on OpenGL though, and will update with info when I find out. ....Was wondering why my shader bundles were so much smaller...

Did you try DirectX-11 by chance? Is what I have been using myself personally, as for some reason OpenGL mode wasn't loading consistently for me. Thanks for the report though; I'll do some checking with OpenGL, as it should still be supported and usable.

While going through some of my old assets, I ran across some of my first 'Base Core' concepts, which also happened to be some of the first modeling work I did (perhaps even the very first stuff I worked on?). I don't think any of it has ever been shown before, and certainly nothing was ever published as far as usable parts go. I think I did have some part configs written up, and the parts were generally usable, but ran into issues with lacking terrain that was flat enough to built out a base comprised of the modules. There were 5m/10m/20m domes for various functions -- hab, lab, storage, factory/processing/production. Though I think I only got the storage and perhaps ag domes had any real work done on them before I shelved the concept. Last change date on these is... 05-12-2015 This is the '10m storage dome' concept, in its nearly finished state (props/textures/etc) -- 10m 'ag' dome (far earlier in the dev stage) And the set of 'tubes' to connect the various domes together -- Anyway.... the reason that I'm showing these is that I've recently run into the lack of any sort of base-related parts when I was trying to put together a mission profile to use for regular testing and screenshot/promotional purposes. Got a few of the craft built out, got to the 'design the surface base' stage, and got immediately stuck on the abysmal selection of stock/SSTU parts that are intended for surface bases. I do believe a concept such as these could be made to work and be quite usable with the addition of some sort of support mechanisms for the modules that allowed for height-adjustment and use on varied terrains. Likely in the form of multiple animated (but rigid) support struts that extend from the modules and include some sort of self-leveling function, with height adjustment. While the BaseCore development might still be quite a ways out, its not too early to start discussion of potential options and figuring out design requirements, especially when those requirements involve solving problems such as 'how to deal with lack of flat terrain'....

Updated release is available: https://github.com/shadowmage45/SSTULabs/releases/tag/0.10.45.157 Tons of fixes, but otherwise nothing new. Recompiled for KSP 1.6, updated all bundled dependencies. See the above link for full change log and downloads.

Updated release is available: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.3.4.18 Mostly just a recompile and version file update, but does include some fixes to recoloring shader mixing functions.

The #1 need for post-stall maneuvering is some form of thrust vectoring (or differential thrust to a lesser extent and on specific axes). The second would be that your COG is very near your COM/COP, that way the aircraft will not have undue aero or mass related forces trying to make it 'fly the way it wants to'; you want it to fly where you tell it. The third would be a TWR sufficient for the maneuvers you are attempting; your vectored thrust needs to not only support the aircraft during stall, but also affect changes to orientation -- therefore, more thrust = more maneuverability. This aircraft can easily be controlled in all post-stall conditions. Using thrust vectoring (and I guess the reaction wheel contributes some..) I can actually get it to fly backwards, controllably (flat spin, cut thrust, glide backwards). Keep it small, keep it light, keep it balanced, give it lots of control surface to get into the stall, and then give it lots of thrust and vectoring for maneuvering during stall. 'Supermanueverability' is far less about 'good' aerodynamics, and far more about being able to put out the physical forces to force the craft to do the maneuvers. The more 'aerodynamically stable' your craft, the more force you are going to have exert in order to break into the stall regime. Edit: The above is all taken in a 'stock' context for KSP. But the basic theory is the same in FAR, and even in real life. I have personally designed and built many RC (radio control) aircraft that were designed specifically for high-alpha/post-stall flight, and they all relied on the same basic premises for their control post-stall control -- neutral balance and strong thrust-vectoring.

Not from in-game that I'm aware of. Probably should be added to the part descriptions at some point. Even looking in the part config might not help much, as those configs merely link to a model definition. The model definition, however, does state the EC output for the panels; but it is not 'simple' to find those files, esp. for something that should be visible in-game.

Please include a link to a KSP.log file, and I can take a further look at what is going on. Likely that some dependency is missing. In development news, I think I'll finally be able to get back to the PBR updates in the upcoming weeks. Here is one that I was nearly finished with when things got derailed, that I spent a few moments today to clean up a bit further: As this is one of the RBI parts, it is sticking with the 'stealth black' color scheme. Still unsure on how much of the 'dust effect' I want to have present in the final products, but it is a very easy parameter to tweak in the setup I have in place for texturing these parts.