Shadowmage

Yep, that is correct (though that 'update' mode will cause errors unless used very carefully, but should acceptably for model-data style patches; more problematic in runtime texture switching). The trick to enable the stock-specular equivalent decoding is the third line 'keyword = TU_STOCK_SPEC '.

Its not that I removed anything... its that the current code is entirely new compared to the original KerbalFoundries plugin. Certain small portions were based on the original functions, but everything was written entirely from scratch for KSPWheel. I did eventually include a 'wheel group' setting that works as you describe, but what I'm looking for in the potential new UI is a few steps beyond that -- allow each feature on a part to be grouped separately. So you can have a group that controls max torque for -all- wheels, a separate group for steering limits on the front wheels only, a group for motor inverts for the left wheels, and another group for motor inverts on the right wheels. I really should try and mock something up, as it would probably make more sense that way...

@AlphaKerman IDK what this 'RealPlume-Stock' folder is all about. Here is what I use, which I know works: Smokescreen ( https://ksp.sarbian.com/jenkins/job/SmokeScreen/86/artifact/SmokeScreen-2.8.13.0.zip ) + Realplume ( https://github.com/KSP-RO/RealPlume/releases/download/v13.1.0/RealPlume_v13.1.0.zip ) Could it be that the RealPlume-Stock also needs the base RealPlume installed? (isn't the 'RealPlume-Stock' setup just configs for stock parts?) Looks like it is changeable through the in-game settings menus:

Certainly possible, and could be enabled as an auto-safety feature. Something simple like "if accelerator is not pressed, and above max safe speed, apply brakes momentarily". Would have to be set on a per-part toggle, through the parts right-click menu. Will give it some thought, see if there are any as-yet unforeseen issues that pop up. Likely it could be implemented for the next release.

Sure; max motor RPM and max safe speed are tunable separately. I generally tried to place the max motor speed 2-3 m/s above the max safe speed, knowing that the max motor-speed is an asymptote that would never be reached under normal conditions. Max safe speed probably could be bumped up a bit, but I would prefer to leave the max motor RPM unchanged. The motor/power sim is actually based on large electric motors, but torque is torque... so yes, that would be one way to do it.

Good to hear from ya Yeah, we're still around, keeping things rolling. I'm just coming back from a bit of a work-induced break myself, having spent the last ~year working up the corporate ladder and getting myself into an... interesting... job role. Mostly the wheel simulation works well; it is definitely a simplified model, and it has a few quirks/edge-cases that I've never quite closed out... but they'll get you where you need to go with a minimum of fuss. Can't say that the code is 'pretty' (my naming conventions have definitely evolved over time), but I tried to keep it free from hacks and workarounds, and it is organized and structured such that it is fairly easy to add new features through new submodules when desired. The one thing that could still be really useful to implement would be a per-vessel wheel-controller system, allowing to group together specific functionalities of the wheels on the vessel in a new UI, so the player can both see what all the wheels are doing, and organize/control/adjust them without going to each individual part. Never figured out how to do a good layout for this feature, but it is still something I would like to look into at some point.

Indeed, I too tried to enable HDR on KSPs terrain/scenery/buildings back in the 1.6.x/1.7.x era, and found that their shaders did....strange things... when HDR was enabled (simply turning it on in the KSP cameras...). Stuff like the buildings gaining partial transparency whenever they were under direct sunlight (terrain was fine, as were faces on buildings not directly receiving sunlight). Some of this very well may have changed with the updates to using Unity 2019, but I haven't had the time to look into it personally yet. Likely going to look into it before too long, as getting HDR working is almost required to enable bloom post-processing (it works without it, but not nearly as well). I personally don't see as either of these belong in Scatterer, being general rendering changes rather than anything specifically environmental related (which is Scatterer's focus from my viewpoint). Much better would be to see the issues with KS3P fixed up, and then simply use that mod for what it is and the features it provides. I realize that the author for that mod hasn't been around in some time, but there were some discussions in the thread of it possibly being picked up by others.

Someone has a config still using the legacy 'SSTU/PBR/XXX' shaders, which I doubt I'll be updating (so yes, they will still have problems with OpenGL and some DX11 hardware). Those have been 'legacy' for at least a year now, possibly longer.

No worries, I started it off anyway by bringing up the subject, so its not entirely off-topic. I haven't personally played with the implementation of CoreHeat myself, so not entirely sure if it is the mechanic that would accomplish what I'm looking for, or if I'll have to come up with some customized system. On a semi-related note, I made some modifications to KSPWheel that should clean up the display of 'max speed' and 'max load', only displaying those values if the KSPWheelDamage module is present (and in fact, the values have been moved into those modules and should be specified in that modules config; values will still load from the KSPWheelBase module if present for backwards compatibility). This change reworks how the modules do their startup/initialization, forcing the modules to do full initialization during prefab loading -- which allows for module-specific data to be loaded, parsed, and displayed in the GetInfo() call (and thus, to display in the editor-part-list tooltips / 'more info' widget). With this change in place, a ton of info that was previously not visible should now be added to the module-info for the parts -- all of the config values from all of the submodules; motor torque, max EC, steering deflection, etc. Mostly minor stuff, but certainly useful. Along with this change I've also added module-specific 'max speed' settings to KSPWheelSteering (for steering curve calcs), KSPWheelAnimation (for animation speed calc), and KSPWheelSounds (for motor/running effect max speed). If these modules do not have values specified, they will load the value from the KSPWheelDamage module (if present), or will fallback to use the existing default-max-speed calculation function (which uses 400rpm as the max). Fun stuff.... Edit: Little preview of the updated part-tooltips, showing the additional info being displayed: Still a bit of cleanup to do in some of the formatting (including the units symbols), but still better than it was

Unfortunately for PartVariants, I cannot offer any support. I've stayed as far away from that stock kludge as possible. Although, I can tell you that the '_Color' parameter is not how to specify a texture, that needs to go under something like _MainTex or similar (_Color is a shader parameter that expects a color input and not a texture; you need to find the name of the shader parameter for the main texture, often _MainTex, and also however the stock PartVariant system references that texture). If you have problems with any parts which simply use the MODEL node setup, I can likely assist with those if needed (that is just doing calculations on model scales and node positions).

Hmm... there could be I've been poking at the back-end code for the editor parts-list, and fairly certain someone could come up with a mod to color-code the background color of the tiles. Perhaps if I get bored.... Certainly some viable feedback there. If it doesn't use max-load rating, it shouldn't show it. Have opened an issue ticket, and will attempt to have that change made for the next release - https://github.com/shadowmage45/KSPWheel/issues/72 Possibly. The range of the slider would certainly have to be limited by the current part-size (as super-tiny engines shouldn't have the same max possible as larger engines), but I'm really thinking a 'heat' based mechanic would work well for damage on these. Something like: Max thrust/load/output output determined by part-size (and based on config value) Any thrust output generates heat, with heat load increasing with output (use part core-heat mechanics) Part-temp decreases efficiency of the emitters. At max temp they output close to nothing. If a sustained high temp is seen for a duration, parts may break due to 'melting' of internal components It should be possible to induce this failure state in 'normal operation' of a poorly designed craft E.G. 'too hot' might be only 70% of 'theoretical max heat' (where thrust output is zero) If it is in the 'too hot' range for too long, it breaks Best operation is when the parts are kept in the nominal range; above or below reduces efficiency Can use stock radiators to manage temps / uses stock heat mechanics This should provide some interesting mechanics, where the design factors include trying to keep the loading even across the devices/ensuring proper scaling for the load, ensuring that they are loaded within their nominal range, and ensuring that there is sufficient cooling for the heat output for the load. The heat mechanics should allow for temporary over-loading without damage, sustained marginally overloading (with sufficient cooling), and could add a bit of depth to the design consideration for use of these parts. Now, this is all speculative / material for discussion at this point. Before I would consider beginning any implementation, would need to have all of the details laid out and a clear idea on how it will work, what complexities will be involved, and most importantly I would need the free time to actually work on it. Probably not in the immediate future, but I will keep it in mind for sometime in the coming weeks/months. Hehe, was just writing exactly that. Heat seems like the perfect mechanic for these parts.

Something else of note -- the ALG parts will only steer when their main strut is straight, as the models only accommodate steering when in that specific orientation.

@Delbrutis I've recompiled the TU shader packs using the same Unity version as KSP, which should resolve the issues with OpenGL. You can find these updated files here: https://github.com/shadowmage45/TexturesUnlimited/tree/dev/GameData/000_TexturesUnlimited/Shaders Download the .ssf files, and replace the existing ones in your 'GameData/000_TexturesUnlimited/Shaders' directory, and you should be good-to-go. Please let me know if you needed any further assistance with this, or if the updated shader packs do not resolve your issues.

IIRC, they don't utilize the load-rating, because they don't have a KSPWheelDamage part-module (which was intended to simulate physical breakage scenarios, from over-stressing of suspension components). As these don't have traditional suspension mechanics, there is nothing to break. Rather, they'll continue to draw ever-increasing amounts of power with larger loads and stresses, until eventually, you simply can't supply enough power fast enough (for some designs anyway); they'll then shut-down from power-loss, and the craft will hit the ground shortly after. I've never quite known what to do with those parts. They aren't wheels, treads, landing gear, or landing legs of the traditional mechanical variety. Working purely in the land of unicorns and pixie dust... who knows what a 'realistic' failure state for them might be? Can such a thing even be stated (e.g. the 'realistic' portion of it)? Could possibly come up with a specialized damage module/functionality that is more in-line with their far-future sci-fi setting and operation; e.g. they put out ever-increasing amounts of heat, or have a specific limitation of power output for specific sizes of part, which if exceeded will 'overload' the 'emitters' or whatever. IDK, hard to balance sci-fi stuff against stuff that is based in real physics.

That is always what remove duplicates did, as far as I'm aware; there was even a configurable merge distance on the tool (though IIRC, it didn't show up until after you had run the tool; you could then adjust the distance and it would recompute the changes). I'll keep that in mind though when I look for the remove-dupes function; that it has been renamed/moved a bit.

You're not wrong (the UI has always been a mess). Indeed, it took me at least three different attempts to learn Blender, over about a 5 year period, before it finally 'stuck' and I could start using it productively. It wasn't until I started into KSP part modding/modeling that I finally started figuring it all out, and even then it took about a year to become comfortable with it. So, yeah, I would imagine that I'll come to grips with the new UI eventually; just going to take a few months of googling previously-known functions, and likely more than a few expletives being shouted.

Nope. Nothing user configurable will change any process from GPU to CPU or vise-versa. The things that are calculated on CPU in KSP will continue to be so, likewise with the GPU-bound calculations. Physics are entirely CPU (collision detection, thrust/impulse/force mechanics). Game system updates are entirely CPU (thermal system, resource system, comm-net). Procedural terrain system is CPU (PQS system, creating planetary meshes from input data) Rendering dispatch is entirely CPU (animating meshes, updating object positions). Rendering rasterization is purely GPU (drawing triangles from mesh data). Post Processing effects are (mostly) GPU (mostly seen in mods, e.g. Scatterer) 'Optimizing for max performance' in KSP is much more a matter of ensuring the maximum possible single-threaded CPU performance, and providing an adequate GPU for the little bit that it is used. Overclocking your CPU by ~10% will likely offer far larger (and more tangible) benefits than any change in the KSP game settings/options. (note: I only recommend overclocking if it is something you are 'in to'; it is, by itself, not a solution for anything)

Thanks, that was the information I was looking for. The icon issues are to be expected, as there were some changes and fixes in those areas in both KSP and TU; it was more the base shaders and saturation issue that I was inquiring towards. Could be, but seems strange, as none of the other shaders have needed recompiling. There aren't any errors listed in the logs when loading the shaders; they all seem to work from a basic technical perspective. Took a few minutes to test on OpenGL on windows, and can confirm the same over-saturation while in the editor: Have also noted a lack of reflections in the flight-scene, even with the stock reflection settings enabled (though there is no over-exposure in flight-scene): So, now that I have a way to reproduce the problem, I have a chance of figuring out the cause and possible solutions. Going to try some recompiling of the shader packs this evening and see if that clears anything up; I can't really think of anything else that could be causing it, as I have changed literally nothing in the shader code itself, and it does work fine on DX11 (and in previous KSP versions). I was honestly quite surprised that the shader packs even continued to load under KSP 1.8+ -- was the first Unity version upgrade that did not specifically require a full recompile of all of the packs. Could very well be that the DX11 shader pipeline was unchanged, but that there were some internal changes to the OpenGL pipeline that require the shaders to be recompiled. Edit: Took a couple minutes of my lunch to recompile the shader packs, and it looks like that is all that should be needed: Both the in-editor saturation is fixed, as well as the in-flight reflections now appearing as they should. Will confirm this evening, and recompile the shader packs in their entirety. Also looks like I might need to adjust the OpenGL Icon-shader clipping space code to no longer invert the Y coords (At least on windows?), as it looks like KSP is feeding the correct coords directly to the shader now.

Thanks for the confirmation and info. If this is a problem that just started manifesting with KSP 1.8 and KSP 1.9, then it is almost undoubtedly related to the update to the Unity version. Can you check if the older TU versions still manifest the problem? The KSP 1.7 versions should still be capable of loading with 1.8+, and if the older versions still have issues, it would confirm that the issue was the Unity version upgrade. ( https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.5.8.23 )

While I appreciate what you are trying to do with that patch, all it will ever accomplish is to relatively adjust the existing balance, rather than specify it. Better would be to specify an exact value for each, so you know exactly what you are changing. As a bonus, you won't have to adjust your patch if the balance in the base mod changes; your patch will specify exactly what you want for your personal balance. In the long run, and far more useful to everyone, would be suggestions on how much each part should support at its default scale? I've tried asking for this feedback a few times in the past, but nobody seemed interested in providing a comprehensive set of values. Lots of suggestions on one or two parts, but I cannot balance one or two parts in isolation. TLDR: I don't remember making any specific balance changes, especially to those parts, but if you are unhappy with the current balance, feel free to make suggestions. In fact, I can do one better than relying on memory.... Github keeps a log of changes to these files, and the last change to any of the ALG configs was Feb 25th, 2017. So no, there were no balance changes to these part configs, intentional or otherwise. ( https://github.com/shadowmage45/KerbalFoundries2/commits/master/GameData/KerbalFoundries/Parts/ALG-Small.cfg ) Are you sure you hadn't previously patched these, and didn't migrate your patch to the new install?

I thought this was an error, but it might be intentional. TU adds a reflection probe to the editor, so that the in-editor reflections more closely match those from the flight scene. The default environment map provided by SQUAD was not convoluted properly, so offers incorrect reflections compared to the flight scene (which uses proper convolution). You can double check if this is what is occurring by going into the in-game options menu, finding the Textures Unlimited options, and de-selecting the 'Custom Editor Reflections' option. This however is a bit more worrisome. Almost like it is using the icon shaders, which do exactly that. Not seeing anything in the logs though. No exceptions or unexpected error messages, nothing alarming. I have a nearly identical hardware setup as yours, so I couldn't see it being a hardware/support issue. Only difference is the OS and graphics API being used. Did you see these problems on older versions of KSP? I'll find some time to do some testing on OpenGL on windows, and see if I run into anything similar.

If you are looking for an event-driven architecture... start with the GameEvents class and see what it offers. Might well be an easy event you can subscribe to, that will call an event-handler/callback whenever the orbit changes. If you are looking for a polling-driven architecture -- simply cache the current values into your partmodule, and examine the values from the vessel every frame/update. When they no longer match, you know the orbit has changed. There are 6 or 7 parameters you'll need to cache, as every one is used to determine the unique orbit: https://en.wikipedia.org/wiki/Orbital_elements (might be named slightly different in KSP)

Thanks, your efforts are appreciated; and no worries on the timing, I know all about work responsibilities Already has. Might be fixable, but it is going to require some additional work out of the devs, as now they need completely separate code-paths and setups; one dealing with a single camera, and one dealing with the multi-camera setup. Thankfully, the old multi-camera code should be portable to the new versions and stuck behind some OpenGL-only conditions, and it is actually the single-camera setup that will require new work and changes. The real problem is going to be that the possibilities/capabilities between the two are going to be vastly different. There are going to be things possible with DX11 that simply aren't available for OpenGL. It could be either, but I suspect and expect it to be a widespread OpenGL problem.

Screenshots of the issues, and log files, would go a long way towards having the information to even address this (let alone investigate, or solve). And yes, this much more belongs in the TU thread, as it isn't directly SSTU related. If everything is working, TU should not touch stock parts at all; zero changes, as it doesn't do anything to them, nor to any of the stock rendering. If you migrated older TU configs forward (merged new version into the old), there may well be some config-level issues from duplicate files/etc. Part of the problem is I have zero access to Linux or Mac desktops, so I can only ever 'guess' that the releases will continue to work, and can never do any sort of hands-on testing. I have no doubts that there may be issues; unfortunately, I cannot confirm them, and any attempts at fixes will be 'guesses'. I believe they can likely be resolved, but I will need the cooperation of a willing test-case who has time to try out a couple of the attempts at fixes.

It has to be addressed on a part-by-part basis. Due to the completely random assortment of scales and scaling factors used in the stock models (mostly the older ones; newer ones are better), each part must be recalculated based on the scaling values listed in the config file. You need to know: The default scale/units the model was created in. This is where it is faster to import the model into blender, but with some math you can calculate backwards from the config-specified values and measurements from within KSP. What sort of scaling is being used in the current config. This is both 'scale=' and 'rescaleFactor=', which get applied in different methods (one of them also scales attach nodes I think?), but both impact the model scaling. How to fix legacy particle effects if/when they are in use, as they also interacted with the scaling, and will be incorrect when the model is scaled through the MODEL node setup. If you had a specific example of where the direct/simple conversion is failing, I could possibly walk you through the calculation process to determine what 'scale = X,X,X' to put into the MODEL node, and how to fix the attach-nodes.