Shadowmage

@Delay Managed to sneak a few minutes to take a look at Blender 2.8. My initial thoughts are (after years of using 2.7.x): what an absolute and abysmal mess they've made of the UI. Nothing is where it was, many previously very accessible tools are hidden behind submenus or only available through shortcuts, and it will undoubtedly be a very frustrating and bad-word inducing time (re)learning the interface. But... one feature that I can be excited about, is that in 2.8 when you do boolean cuts into a smooth-shaded object, it actually (and properly) calculates the vertex normals for the newly created vertices/edges. So this means you can get decent shading on, for example, cylinder command pods with window cutouts, without having to resort to hacks or buggy plugins. Note the pink 'normal' lines shown on the corners of the cutout in the cylinder, showing proper interpolation between the normal direction of the edges of the original face; the smooth-shading that was maintained on the cylinder even with the cutouts, with zero extra manipulation needed. Wonder if it also works for knife-cuts and other means? Seems like such a tiny thing, but wow, the time this could save me if it all works out. Used to spend so...much...time... fixing up these terrible normals and shading errors, calculating and editing them by hand or using hacky workarounds. I haven't even started on any of the viewport / shading related changes yet, but frustrating UI-changes aside, it seems like this version of Blender is a good technical step forward.

Agreed. From my testing yesterday, it looks like the only mods that should be broken by this update are those that interacted with the main game-cameras; such as Scatterer and EVE (and any other that might interact with those systems). I didn't notice any other API-level mod-breaking changes during testing of my mods, and they poke around in a very large number of the KSP code subsystems. Overall seems to be a pretty 'gentle' update as far as most mods should be concerned. If you right-click the game in the games list, select 'properties', and then go to the 'betas' tab in the popup window, it should allow you to select previous versions under the 'Select the beta you would like to opt into:'. Note, it isn't just betas, but actual full stable previous versions of the game. Mine is already showing 1.8.1 as an available previous version.

Thanks for the information and reply; my comment regarding de-listing was intended mostly as a joke/expression of frustration. Will keep the info in mind though if I ever decide to go crazy on it in the future (not likely).

Sure, sounds plausible. That would explain the how and the why. Edit: Thinking more on it, I do remember some discussions with LGG on this a few months (years?) back; and yes, permission was granted, so nothing is really amiss there; was such a brief conversation I had completely forgotten about it. Still not something I'm going to personally support though. If someone can't be bothered to take the time to manage their mods themselves, I'm not going to bother to take the time to help them. (not meant negatively towards CKAN or their dev team; this is intended towards end-users who can't even read basic error messages in log files to try and fix the problem themselves before bugging me about it)

I don't see that as my problem; I've never requested that my mods were added to CKAN, not sure how they got there or why, and as such I offer zero support for CKAN related issues. I would have a different view on it if it was a system integrated into KSP; but as a completely optional third-party system? Not my problem to support or deal with any issues it may cause.

Thanks for the testing and craft/log files; much appreciated, should be very helpful in my initial investigation. I've opened an issue ticket on this to keep the information from being lost in the forum shuffle, and will be posting further updates to the problem there: https://github.com/shadowmage45/SSTULabs/issues/820

Strange, as I know I updated the OP when I was posting the 'update available' message. I specifically remember fixing the 'includes module manger' line to actually be compliant with requirements... Odd, it must have dumped it/discarded changes when I posted the update msg (was working on them in the same browser tab, yuck). As long as the -package- contains the dependency -- why would someone not install it? Oh, nvm. Just CKAN doing its usual thing to make me hate life. Nothing to see here. Is there a way to de-list all of my stuff from CKAN? Glad that sorted it out for you

Nah, just the KSP.log file should be sufficient. ModuleManager shouldn't be involved in the SSTU parachutes much, and certainly not the staging portions of it.

Not that I've personally noticed, but it may well could have if SQUAD did some changes to module staging mechanics. I'll add it to the list to investigate for a 1.9 release...

You are missing the TexturesUnlimited dependency. Should have been included in the installation package.

Yep, I had missed that implication; and that could be useful as a stock feature, esp. in regards to VTOL landers. Those things are always a nightmare to balance/fly if not built perfectly symmetrical w/fuel on the COM. Good point Entirely different set of math and module interaction code though, but might be a useful feature to request/keep in mind for the future.

Partially at least. Logarithmic buffers appear to have been implemented in Unity 5.x versions. The 'magic' that is being implemented now isn't something 'new', but is rather the default for DX11 that was previously unable to be taken advantage of because of the DX9 support. Reversed z-ordering is the bit of magic implemented here that allows for a single camera. Found more information on it, and very good explanations, here: https://developer.nvidia.com/content/depth-precision-visualized It also explains why this technique doesn't work with OpenGL. Bit of a read, but a good one.

As this feature is simulating collective pitch, as utilized by helicopters and other rotorcraft, I'm not sure how it could be applied (conceptually) to combustion based engines. Those engines can't really put out more thrust on one side of the engine than the other; there is only one nozzle, which determines the direction of thrust. Rocket engines/etc can already do vectored thrust with the use of the gimbal module; different concept and applications, but is how thrust is controlled on those types of engines IRL. Many thanks for the info, seems to be exactly what I was looking for

I too would like a bit of additional info on that. Missed it during my brief peruse of the patch notes. Knowing a bit about the internals of how KSP renders things, I would imagine that this means they are no longer compositing the final viewed image from multiple cameras (near/local, and far/scenery/celestial objects). If true, this would go a long ways towards cleaning up rendering issues regarding reflections and other post-processing effects (e.g. scatterer). Single camera, single transform matrix, single render texture/render-target. The improvements to performance likely won't be anything crazy, but it is a great step towards simplifying the rendering. Wondering what in the recent Unity versions allows them to do this, or if it was other changes to the rendering code? I've spent some time myself trying to solve that issue for personal game-dev projects, and the dual-camera setup is the only solution that I could reliably get working while keeping things 'simple'. Perhaps they've gone from a 16/24-bit z-buffer to 32 and implemented logarithmic depth calculation? Those changes combined might be enough to give good enough precision for only a single camera (though I thought logarithmic depth buffers had been in use for many years as a standard).

Huh, figures that 1.9 would hit literally hours after I finally update my mods to 1.8. Really looking forward to the cyclic/collective changes to rotor blades. Trying to implement a functional swashplate system without massive part-count was... not going well (rather, it went nowhere). Minimum mass/minimum cost definitions in config files and validating the mass and cost values to not be negative is a fairly useful (but bug-hiding) feature. IN theory it shouldn't be needed if parts and mod code works properly, but at least now when it isn't working, things won't start flying off into space on their own (negative mass on a craft does weird things). ^^ Is simply a wonderful addition to the stock debug tools, that has been missing ever since they added the object relocation functions.

Yes, pretty much exactly that. Currently no, and nothing planned. That module was written specifically for those parts. Everything that currently uses KSPWHeelAdjustableGear PartModule will have some form of deployment sequence. I should note (though not likely important for your inquiry), that the KSPWheelAdjustableGear module doesn't actually use a Unity Animation, but rather drives all of the transforms procedurally from the module code based on the current user configured values.

Got a chance to investigate for a bit, and can confirm the odd steering that you reported. The cause is that some of the motors on the right side have been inverted, and others disabled, thus there is more thrust from the left side, and it pulls to the right. Change this: To this (which should have been the default configuration): (fixed .craft file: https://www.dropbox.com/s/vj3d670nyiq8qz0/Mun Rover Tester-fixed.craft?dl=0 ) And it will drive as straight as KSP physics will allow Note: the position of the Kerbal will also effect traction to some small degree; if there is only a Kerbal in the left-hand seat, you'll get more traction on the left wheels, though not nearly to the degree noted above. 2nd Note: I did notice a bug with these wheels regarding the symmetry-part updating on the motor invert toggles, likely due to having multiple motor modules in the same part; regardless of which motor was inverted, only the upper motor on the symmetry part would be updated.

QFT; this man knows what he is talking about. You really don't (and can't) appreciate the impact, until you try it yourself. Adding variants (esp. geometry variants) can take a simple '3-hour part', and turn into into a two-week long slog of tweaking and re-exporting models and re-baking AO textures. And that is just the art/model asset side of things; there is additional work required to get it all working in KSP as well. And if going for optimal texture packing/re-use, the entire thing has to be planned to include variants from the very start, or else you will end up redoing work or having sub-optimal use of textures.

You might be able to effect this with a simple MM patch, by setting the scale on the X axis of the model to a negative value (e.g. scale = -1,1,1). That is traditionally how things are 'mirrored' in 3d modeling, but I cannot guarantee that KSP will handle it all properly, especially if the part in question involves animations or other complicated modules.

I believe that can all be found here: Basically, the only real requirements are that you include -a- license, and that you document any dependencies or bundled redestributables. Doesn't really matter which license you choose for the most part; just needs to be stated publicly on the page, so that others know how they can treat the works. I'm personally fond of the open-source licenses (MIT, CC, L/GPL), various and sundry, but you could even go down the 'all-rights-reserved' road if you desired. As far as the 'document dependencies' clause, as this work utilizes TexturesUnlimited, a quick link to the TU forum page and stating the license for that mod should be sufficient, and is all that is done on most mods' pages. Basic attribution type stuff, making sure it doesn't appear like you are trying to take credit for others work, and that you are complying with any license(s) for those works.

@Delay Have you given any thoughts to releasing the texture sets that you have been working on? (or have you already, and I've not noticed?) I would be more than happy to include a link in the OP if/when the time comes. I was doing some testing with KF the past few days, and though -- 'Gee, wouldn't it be nice if these stock parts I was using didn't look like mud?', and then though of the very nice looking previews you've been posting, and realized that I don't think I've seen any links anywhere...

Apologies as I must have completely missed this post when it was made. Not sure how, as I thought I was keeping an eye on it specifically... Going back through things -- I'm not sure what I'm looking for is even possible without changes to other portions of the loading code. The end goal is to allow for custom shaders to be used on parts (non- KSP/ shaders; e.g. the PBR-Metallic shaders from TexturesUnlimited). These custom shaders will generally also require a customized icon-shader to maintain equivalent functionality. The first problem is that you cannot export parts using custom shaders through PartTools; the PartLoader code will throw an exception during KSP loading due to an unrecognized shader (the list of supported shaders appears to be hard-coded somewhere?). The second issue (and the reason for the original post) is that it appears that the current mapping of shader -> icon-shader is hard-coded somewhere in the part-loading routines; I cannot find any publicly accessible dictionaries/maps/registry methods that would allow for me to add a mapping. However, the second issue cannot be addressed until the first is made possible (i.e. loading of Parts with non KSP/ shaders). This, by itself, doesn't seem to hard; add in a method to load the shaders from AssetBundles, add into the internal shader reference stores, and anywhere that Shader.Find() is currently used, replace with a method that first looks in the loaded shader cache (as shaders loaded from AssetBundles will never be visible to the Shader.FInd() method; that method only finds shaders that were compiled with the project at build-time). I don't have access to the PartTools/PartExporter code, but might be some minor modifications needed there depending upon how the shader is stored in the .mu file (is it written as an int, is the name written as a string, etc). In the meantime I've worked around this much as you propose above -- manually going through the game database, brute-force iterating through all transforms/renderers for all loaded parts, finding those that use one of the 'to be replaced' part shaders, and then manually replacing the icon-shaders in the materials for that part's icon prefab based on some config provided mappings. Its ugly, its hacky, but it seems to (mostly) work.

Thanks for the link; I didn't have any further time last night for testing, but will attempt to give it a go this evening. More than likely it is a craft setup/configuration issue where one of the wheels is not set up to be inverted properly when it was built. Will let you know what I find out.

Actually, those images all show things looking exactly as they should. The reflections you see are exactly what you should be seeing. Yes, the icon-previews look different than the parts do in the editor, or in flight (because they are using different reflection maps for each). That is exactly how those parts were intended (the lander cans). The windows are of course very reflective, but the metal hull was intended to be more of a brushed-metal style of shiny (so not truly 'reflective', but will still show some environmental lighting effects). If all of those are fine; I wonder what the problem was with the engines in your previous screenshots? Perhaps the issues you were having with SmokeScreen were preventing the stock system from working. I feel I have to put this out there -- in KSP 1.7/1.8, TU does not mess with, adjust, or manipulate the reflections in any way; that is entirely a stock system, and any issues you may be encountering are stock problems, and not something that I can fix. If the shaders are loaded, and the textures applied, that means TexturesUnlimited is working properly (as that is all that the mod does; load shaders, and update materials on models).

What version of KSP and TexturesUnlimited are you using? Just have to make sure we are all talking about the same stuff here...(major differences in setup between the newer and older stuff)