Shadowmage

Interesting -- yeah, being able to reproduce it will be the #1 needed bit of info I'll even settle for specific save-files (pre- and post- issue) as long as they are using minimal mods.

Please open an issue ticket on the subject, and I'll investigate during my next update pass (probably here in a few weeks). Unfortunately I'm really not familiar enough with the stock staging code to be able to offer any interim workarounds, which also means that it will take some time to do the investigation and figure out what is going on.

That sounds like the intended behavior. The CMs all have built-in decouplers, and when staged, should decouple them from the SM (note that this decoupler is on the 'internal' lower node on the CM, and is only used when the prebuilt SM is also used). Unless I'm missing something in the description of the problem? (honestly, with staging stuff, I really have no clue. That is all 100% stock code; the most I do is play with some config values in the part/modules)

Kronal Vessel Viewer is the one I'm aware of...

For a long time I've been wanting to get more 'lander' styled legs available in KF. Yesterday I felt like working on something 'new'... so I finally did some real modeling on a landing leg that I've been trying to make for at least the last two years (I've done at least four other layouts for this same leg, but never got it fully working). Wasn't originally planning on adding anything new to KF but it seems like a good home for this part at least. 1m x 1.5m x 0.35m when closed, and retracts into a nicely sealed radial mounted case. Deploys out to give ~1m max (~0.5m nominal) of ground clearance from the bottom of the case. Foot moves upward linearly with compression, with the pistons near the foot taking the compression and the top joint of the bottom leg portion also rotating slightly to maintain alignment. Intended more for craft designs where lower ground clearance is acceptable, such as with side/radial mounted engine setups. Currently it is not 'adjustable' like the other landing legs, but I'm working on rigging it to at least allow for a few degrees of adjustment to the upper/main leg angle. Yes, it is loosely based on one of the NASA DRA Mars landers... bonus points if you know which one Model isn't done; probably about 75% though. Still some geometry to clean up and a pair of pistons/lock-braces to rework; the majority of the model is in place and the rigging is functional, just needs some minor fixes here and there. Think that I want to do perhaps one more lander-style leg after this one is done, though I have no idea what the layout/rigging would be for it (ideas/suggestions?). Going to try and sneak this one into this weekends' release. If no other issues are reported with the PBR testing version, I'll likely do some fixes for what has been reported, and start in on the balance and cleanup pass. Should likely be able to complete the balance pass in about a week, and after that will be the 'legacy texture bake/import' phase.

Possible? Yes, certainly. A metric buttload of code to write, and change for any minor changes to the UI? Also yes. And with KSPs long boot up times when modded, that would mean a 5+ minute round trip to see any changes made. I've done that route before in other mods/games/projects. It works (better for simple UIs), but it is not maintainable long term for anything beyond the simplest of UIs. The reason I'm investigating NoesisUI (or will be investigating) is because I already use XAML based UIs at my employment, I'm familiar with the technology at many different levels, and it is config-file based for defining the UIs. Also, it can be loaded and refreshed at runtime, so no need to wait 5 minutes to see simple changes. Oh... and as a bonus, it can use config-defined data-binding -- so the actual code-interaction with the UI framework is minimal if proper design patterns are followed.

Thanks for doing the investigation and letting us know the results. If the stock module works fine, I do have one additional thought on a possible point of interaction -- I added some sort of 'temperature' curve somewhere in my module, but I have no idea how that would interact with the changes AK makes (or even if it was implemented properly to begin with). Perhaps one day if I'm bored I'll have to dig into it as I'm never fond of a mystery. I've opened an issue ticket on it just to make sure it doesn't get forgotten about ( https://github.com/shadowmage45/SSTULabs/issues/768 ).

Tank steering is activated in the KSPWheelMotor module. Go ahead and patch your parts to activate it if you wish, but that feature does not fit with the intended use of those parts, so I will not be adding it to the default configuration of the parts.

Unfortunately not many. Hasn't really caught on much, and most mod authors are actively resistant to use of the shaders. Takes a bit more work to make textures even for simple stuff, and for best effect/most consistent look everything needs to use the new shaders (and thus would need new textures), so turns into much more work than most are willing to put in for already 'finished' parts. However there are a few around... This mod has patches/textures for stock parts (with recoloring) -- It might seem out of date, but the patches should still work. And my main mod has lots of semi-procedural parts that are fully recolorable -- make any color of rocket you want. Its a huge mod though with lots of parts and textures, but can be tons of fun.

Decided that the particle effects can wait for a bit. There is more work needed in order to make it a functional system than I am willing to devote to it for the initial testing releases, but I can likely finish it up over the next few nights. On that note -- the first test release is available: https://github.com/shadowmage45/KerbalFoundries2/releases/tag/2.3.7.17 Remove all old versions of KerbalFoundries entirely before installing this update. Old craft and old save games will not be compatible. You must install TexturesUnlimited (bundled in the download) in order for the models to have any textures; use of OpenGL/DX11 is highly recommended, but optional. See the link for downloads. Please note that the new and old versions can mostly co-exist, there are only a few overlapping filenames that will conflict, but this use is unsupported beyond that cautionary note. Also note that the old version will continue to function as well as it does now, and should continue to function in the future; you might need to manually keep your KSPWheel plugin up to date for newer KSP releases, but the old models and configs should still be functional and supported by the newer plugin. So, if you want to continue using the older models and textures -- go for it. They will likely not be seeing any further balance updates or changes, but they should continue to work. Even after the new PBR stuff is made the 'official' release, I'll likely still link in the OP to a release of the older models/textures for those interested in them. In the long run -- I do intend on having some sort of 'legacy' texture pack available for those who prefer the old textures/shaders. The exact format is yet to be determined, but should be available no more than a few weeks after the testing period is finished. Please report any issues you encounter with the packaging, configs, models, or textures. I'll be keeping things in a testing phase for a few weeks while issues are sorted out and a balancing pass is done on everything. I'll be posting more info on the balancing stuff once I get there (will def. need feedback). Still a few things that are WIP (wheel and track tread textures need another pass over them), and lots and lots of config work to do for balance...

It does nothing by itself -- it is purely for use of mod authors, and should be bundled with the mods that intend to use it. Edit: But when used it does make things shiny

Updated release is available: https://github.com/shadowmage45/KSPWheel/releases/tag/0.14.11.30 Adds support for some new features for Kerbal Foundries (though available to anyone).

Updated release is available: https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.3.6.20 Adds support for some texture-reloading functions for external mod integration. Will be used by the upcoming KerbalFoundries releases.

After some recent testing I can confirm that it does work to pack the particles from Unity into an AssetBundle, and read/load/import that into KSP. A bit more work from there to get them to be able to be loaded through the EFFECTS from the part configs, but certainly possible (have a working basic implementation for my own uses). I haven't encountered any surprises so far, but I'm still pretty early in my investigations. For SmokeScreen I'm sure that you will have a bit more setup work in order to interact with all the atmo curves and other supported functions, and settle upon some well defined asset bundle configurations (naming/extensions, one model-per/multi-models, etc), but seems like it will be entirely possible to support at some point if you desired. Thanks for the info, and hope the above is of some use to you

Managed to get the two major plugin issues cleaned up (well, one plugin, one model), and have one plugin related feature left to implement -- loading of particle effects from AssetBundles. KF/KSPWheel now has four different uses for particles, and none of the stock particles are suitable for those specific uses. So I am creating a method to be able to load particles created in the UnityEditor and built as AssetBundles into KSP. Initially these will just be for use by the plugin for its internal effects, but I'm laying out the framework to be able to also insert these effects into the part's EFFECTS block so they can be used generically. Hopefully I'll get it all wrapped up tonight and push out the initial testing version shortly after that. Still a few things to do between testing and full releases, but I should be able to clean it all up in time for the weekend.

@sarbian Apologies for bugging you, but I'm trying to find out a bit more detailed information on how you got the Shuriken particles working in KSP using .mu models. From reading the source-code (if I'm interpreting it correctly), the .mu models are no longer utilized actively for particles, and are instead mostly used to read in some of the old emitter values to use with the new system. https://github.com/sarbian/SmokeScreen/blob/master/ModelMultiShurikenPersistFX.cs#L558-L660 Basically I'm trying to find the 'easiest' way to get Shuriken particles out of Unity editor and into KSP (currently for some effects for use in KSPWheel / Kerbal Foundries). I tried compiling to a .mu using a PartTools, but examining of the model reveals that the particle system is not saved in the model. Other options would be trying to export/import using AssetBundles, or coming up with some purely config-based system to export from Unity and import into KSP to define the particle parameters. Does SmokeScreen allow for creation of a particle entirely from config, or is there still a model of some sort needed (and for what?/how to make them)? Any information you are willing to share would be appreciated;

One step closer to being ready for a testing version; all parts have textures and working configs. Shown at 100% / default scale, with two-view for most parts. Have a few things to clean up in the plugin, so probably nothing today, but soon.

Decided to go with a more stock-alike 'white' paint color. The parts tend to blend in with stock stuff much better now...which was the whole point of the change I've also changed out the yellow/black stripe scheme for white/red where applicable, and added red or white/red trim to a few new parts. Only partway through the texture pass. Basically ALG, repulsors, legs, and skid done at the moment.... Yes, at least it should. There will be a new version in the next week that will not be backwards compatible, so if you are thinking of adding it to your games it might be best to wait until then.

As requested, more information would be needed in order to determine the cause or even what is going on. Screenshots, log files, etc. (but no, that doesn't sound normal; and yes, entirely possible there are mod conflicts, or even just bugs)

Last two parts done for initial pass -- Surface Track and Tiny Track: Next I'll be taking some time to go over config parameters and clean stuff up a bit, making sure at least the functional portion of the configs is done (not touching balance yet). After that I'll be doing a cleanup pass over the texture sets, mostly cleaning up AO or other baking issues. Next pass will be doing color and consistency checks on everything and determining the base texture resolution for each part, re-exporting the 'final' textures, and converting them all to DDS. And then I'll be able to make a testing release available.

Good news is that the folks from NoesisUI got back to me, stating that it should be perfectly usable from within KSP. So now I have exactly one potentially usable UI framework to investigate (I don't consider the built in Unity UI system to be usable for KSP mods due to its necessity to compile the UIs into the application). Not sure at this point if I'll have to purchase a license for it... but I'm willing to if I must -- whatever it takes to get a functional and usable UI framework. Hard to believe that Unity has come this far and not addressed their terrible UIs...

You are likely correct -- I don't think they exist -- more specifically I was looking for some method to replicate the issue in stock via changing of game-settings / patching globals files, or even poking at stuff via a simple custom plugin. I'll gladly fix any issues in this area, as long as I know what to fix So if you guys run into something, please let me know.

Nope, not currently, it is just for 'cleaning up old models that include weird stuff'. Specifically I built it to remove the 'Arrow' meshes from the KF parts that were intended as editor placement aids. Curious what you are trying to accomplish? Have some pics/images of the part/model you are trying to work on? (knowing what the visible layout is, and what the hierarchy is, I might be able to offer better suggestions).

Two more parts down; two left. Apparently I had both of these already unwrapped and rigged, so they just needed some minor cleanup to configs/etc. Apparently the arrows/details are backwards on this one... but should be easy enough to fix up.

Indeed -- my thoughts were that, if I've coded my plugin properly, and the solar flux properties of the sun(s) were specified properly, that it should all just work. The fact that it apparently doesn't work, would to me indicate that one of the two above premises is false -- either my plugin code is not working for adjusted solar bodies (entirely possible, I've not tested it with changes to the solar system), or the solar flux for the adjusted star is incorrect. Or possibly both, good luck figuring that one out If anyone can provide me with MINIMAL test case scenarios that reproduce this issue (without downloading ~500mb planet packs), preferably a test case that does not use Kopernicus, I will gladly do some testing, verification, and issue any fixes necessary to make sure it works. But I will not be downloading some random giant planet pack just for testing -- I don't use them, and have no personal interest in them given the issues I've had with Kopernicus in the past.