Shadowmage

KSPWheel actually includes a module that will allow for removal of those colliders from the model (or any game-object/transform), as long as the game-object(s) they are attached to are not otherwise needed. One sec and I'll try and find more info on it.... Here you go -- If you add this to the part-config (replacing the transform name with the name of collider object), it should remove the collider(s) from the prefab when the part is loaded, and thus it should be removed from all 'live' parts. MODULE { name = KSPWheelTransformRemoval TRANSFORM { name = FirstTransformNameGoesHere //this line specifies to remove from the prefab part; default is '0' which means does nothing when = 1 } TRANSFORM { name = SecondTransformNameGoesHere //this line specifies to remove from the prefab part when = 1 } }

I LoL'd hard at that Sad, but so true. I love the game for what it is, but being who I am, its hard not to think of what it could have been with a slightly (or massively?) different direction taken during development of the core (career) gameplay concepts.

The blue disc is not the wheel collider. It is a proxy collider added by the API in order to prevent overcompression. Also it should not rotate. So what you are seeing is the expected and intended behavior. If you need your wheel-mesh to visibly rotate you will need to use the KSPWheelRotation submodule. If you want your wheel mesh/suspension to visibly react to changes in suspension compression you will also need the KSPWheelSuspension submodule. Examples of both of their use can be seen in the KerbalFoundries parts.

There is still some black on the underside. Well, the entire pattern generally mimics the existing textures. But I might be able to provide alternate texture sets, or even recolorable ones utilizing TU's recoloring features. For now though I'm mostly just making sure all of the models will work in my new workflow, and ensuring that I have model source files available so that I might fix any model-related issues that are uncovered in the future. On that note... some of the more recent work, in-game: Panel lines/bolts don't look too bad at all. And are pretty much invisible when you zoom out even a little bit thanks to MIP maps. Parts actually look fairly clean at this level with most of the wear being nearly invisible. Also over the weekend I reworked the Screw Drive, but was awaiting plugin fixes to the sided-model module before the textures could be used in game. Fixes done, and parts are looking (and working) nice: I also just remembered how useful the Screw-Drive is for any aquatic vehicles, as it produces thrust even when entirely submerged; actually works best that way It also still works on land. In fact, the only time it doesn't work is when it is flying. Closing in on the last of the parts now. Four tracks left to do, all of which have fairly simple geometry which should be easy to texture. Though being tracks, they still need to have some skinned-mesh rigging done to them which is a bit time consuming. Might have a testing release available late in the weekend or early next week, and aiming to have the initial releases of these updated models/textures available by next weekend if all goes as planned.

I'll second this method for learning how to do docking. Eliminating some of the translation axis' and stabilizing rotation by using the SAS on both crafts to target each-other will make learning how to do docking maneuvers much, much, much, easier. ^^ Do the above for awhile, and soon enough you'll be able to do manual docking without targeting or stabilization assistance. Once you learn the basics it all comes down to 'get in position', 'line up to target', 'apply gentle thrust', and then 'wait patiently for contact'. Unless your target is spinning off-axis.... Then you are forked.

Hmm... some investigation reveals that I might be on a usable track -- https://www.noesisengine.com/forums/ XAML based UI design with data-binding, in Unity. Unfortunately I'm not sure how compatible it will be with the 'KSP Mod' setup -- e.g. I'm not sure if its yet-another-UI that needs to be compiled with the application to be usable. Thanks for the info -- if my other endeavors don't pan out I'll definitely take a look at that. From a brief look it appears to be more of a reskin of the existing KSP/Unity UI stuff rather than its own UI framework, but I may well have glossed over something.

Having been doing a lot of WPF/XAML based development at work lately, and that is pretty much exactly what I'm looking for from an in-game UI system -- config file based UI layout with dynamic runtime databinding. Unfortunately it doesn't actually exist for Unity (WPF being a Windows only framework, AFAIK), and I'm not sure I feel up for creating an entire UI framework just to use for KSP. Would be weeks or months just to get the UI framework implemented to a point where it would be usable. Hmm.. seems like a reasonable thing though... so perhaps someone else has done something similar? I'd even be willing to pay for an asset/plugin for such a feature if it existed (and the cost was reasonable). Re-reading your post though, it seems that I responded with the wrong information/to an un-asked question; you were inquiring about the 'Preset Color Grouping', for instance, specifying in the texture-set config that the available preset colors should be taken from this list or from that list; correct? (e.g. PresetColorGroup = SSTU-PBR; or PresetColorGroup = LegacySpecular; or PresetColorGroup = SomeOtherCustomGroupOfColors; where the group-name then references list of colors built in other config files) ^^ That might be doable with the current UI. Mostly would need to find how to tell the UI which color list to pull in, and switch between these lists when different 'sections' in the UI were selected. Seem to remember that, when last I looked, there were some additional complexities with this due to how it was original coded, so it might not be a 'simple' change to make and may require a bit more effort to implement (but still far easier/faster than any new UI system).

Not yet; still working on cleaning up backlogged WIP projects. Currently nearing completion of the KerbalFoundries PBR texture reworking (1-2 weeks left maybe?), and then on to the next project. Likely next up will be another set of bugfixes for all of my published mods that need it (another week perhaps). Beyond that? Nothing planned currently, so might be a good time to start onto something new. The main issue standing in the way of creating any new UI related functionality for TU is actually the UI portion of it. My last series of investigations was into how to use the 'standard' Unity UI system from within KSP, which concluded with 'best case scenario is its going to be a massive PITA'. Can't compile the UIs with the application as is the intended method, because its not my application. Can't export the UI's through asset-bundles, as there is going to be a ton of plugin code that would need to be used by and linked with the UI, and you can't export plugin code with asset-bundles. Which is about where my investigations stopped; the last option to look at is creating the UIs entirely from plugin code and compile that code into the TU plugin, but I'm very hesitant to go down that route as I know how painful it is to try and create UIs from code that were meant to be setup with an interactive designer (extremely inefficient, at best). On that note -- if you have any idea of what a functional UI layout might look like for the feature, I'm open to suggestions/ideas. I didn't get around to any design prototypes or any layout work previously, but that is something that will need to be worked out before any real work can be done towards implementing it.

Speaking of ALG parts -- they are next up for retexturing, starting with the -Large that I had already done prep work on. Not sure on some of the details (all the tiny bolts on the panels), but trying new things out on these parts. I'll likely tweak the edge damage and dust a bit, but otherwise fairly happy with the results so far.

No, not without completely redoing the models, which is not currently scheduled. The problem is that the models are not created in such a way so as to allow for steering to be adjusted when the strut is angled; to do so would require an additional set of transforms and meshes that allow independent rotation from the main strut of just the wheel and its braces. These models are not mine, and I had no hand in their original creation; I only updated them to work in recent KSP versions. If/when I redo those models it is a feature that I will certainly include; however no such rework is currently scheduled or planned in any form.

Unfortunately, not with the current model. It is not modeled or rigged properly for any sort of deployment animation, and at this time I'm only doing texture reworks (and minimal model UV updates to facilitate those). Not a bad idea for the future though...

Not for anything I've created or used. No, that is the intended scale. 3.75m is the closest stock diameter that would allow for the engine to fit; its way too big for 2.5m. The RS-68 is one of the only oddly scaled engines, being closer to ~72% real-world scale compared to the ~64% used on everything else. In theory should be easy enough for you to rescale to 3.125 (as the engine cluster module supports rescaling functions), though I can't offhand remember exactly what would be needed. The same stuff that is used to rescale SSTU engines for RO/RSS would be used for this, so I'de check the RO patches (if they were ever updated for recent SSTU versions?).

Slightly reworked the APU model to clean up the geometry (okay, its an entirely new model, built after the original). Not sure if it will get the external case back or not; kind of like it bare like this. Also, finished a rework on the last landing leg (config WIP, need to fix foot orientation), and managed to sneak in time to do the Skid as well (at least basic first pass on textures). Work is still progressing nicely, might have an initial testing release available in a week or so. Still have the ALG parts, four tracks (could be time consuming), and the Screw-Drive left to rework.

KSP is primarily single threaded, and CPU bound. Therefore you want the highest single-core speed (and IPC) that you can get; more cores/hyperthreading doesn't help much. It doesn't really touch graphics resources that much, though visual enhancement mods can change that. Basically KSP will always be limited by its (mostly) single-threaded physics calculations, which is why you only see a small portion of your 'system' in use; it is only using 1 or 2 out of your 4 cores. Now if you can bump that 3.3ghz up to 4.x+, you will see a major improvement in performance (given the same IPC); given that you have a -K series processor, overclocking is (potentially) as easy as bumping up some multipliers and ensuring sufficient cooling.

One more nearly done, at least for this initial pass. I'll likely go back over all of these textures a second time to make sure all the colors and settings are consistent, but it will be relatively fast compared to the initial setup work. This is another of the landing legs modeled by @TiktaalikDreaming, with a slight change in color scheme to better line up with the rest of the re-textured parts. Not entirely sure about the red text or ring on it, but giving it a try for now; easy enough to change this stuff around later. This landing leg will also be getting the adjustable-deployment feature, where the vertical and horizontal extensions (black sections) will be independently controllable.

Glad you got it figured out. Always fun trying to diagnose issues like that. Good work

Thanks for doing the investigation, and please let me know what you find out either way (having debugged my share of these types of problems, I'm always curious what they end up being caused by)

Question: I had previously intended to retire the existing part-textures for this next update (due to changes in the models/UVs that make them unusable), but I have recently realized that there might be an alternative. Blender has the capability to bake textures from one mesh to another, across different UV layouts, essentially allowing for converting of an existing texture between one UV mapping and another. This process however is not loss-less; the textures are basically sampled and rendered back onto the geometry as if they were being rendered at very high resolution, and any differences in UV layout/rotation/scaling can result in differences in the output compared to the original. It also takes time to do the baking as it is a wholly manual process, lacking any sort of batched automation. The question is -- how many of you would like to see the existing textures continue to be available in future releases? Is this a step that I should plan and schedule for prior to the next releases? If I don't bring in the original textures, the new PBR textures will be the only ones available for most parts. While I personally think the new textures are a vast improvement and more compatible with my personal mods, I can understand others' desires to keep the original stock-compatible textures around.

Hi; the issue you are describing sounds like a hardware or driver issue to me. If the game is actually loading properly into the main screen, then TU is more than likely functioning as it should. But, it will also utilize far more of the GFX resources than stock KSP, so may well be triggering an existing hardware/driver issue that stock KSP doesn't. You an try uploading/linking a copy of your KSP.log file (found in the main KSP directory with the executables), but if it is actually crashing your computer, that log file does not likely contain much. Probably a good place to start though, so as to verify that there are no errors with your mods/setup. Past that, I would start by updating graphics drivers, and checking on hardware temps during runtime (CPU, GPU, Main RAM, GPU-RAM, chipsets, voltage converters, even hard-drives). What you describe sounds very much like a temperature/overheating related failure; things get too hot, and the OS/hardware shuts down as a failsafe.

New features for user-controllable transform manipulation are in-place and working nicely... Allows for one set of landing legs to function both for short and compact setups: While still being configurable for a bit more clearance when the situation demands:

With a text editor (just had to...) Documentation is available on the TU wiki -- https://github.com/shadowmage45/TexturesUnlimited/wiki/Config-Documentation You can also see some examples of the system in active use in SSTU's configs (though this is also including several other layers of SSTU setup) -- https://github.com/shadowmage45/SSTULabs/tree/master/GameData/SSTU/Data/TextureSets/updated Good examples can also be found at both of the previously linked threads...

Unfortunately, the PartTools used to build the .mu models does not support the new ParticleSystem used by Unity. I recently hit upon this problem myself when trying to create and add new effects for one of my mods (Kerbal Foundries)... The solutions that I devised all require custom plugin code, and none that I've envisioned would allow for the effect to be usable by any stock KSP PartModules (e.g. they could not be added to the EFFECTS block in the part config) Create script in UnityEditor to export the ParticleSystem parameters to a text/.cfg file. Use custom plugin code in KSP to parse this config file and create a prefab of the particle-emitter. Yet more custom plugin code to add this emitter onto the models, and still more to enable activate/deactivate it. OR In UnityeEditor, export the ParticleSystem prefab to an AssetBundle, use custom plugin code to load that asset bundle in KSP, and more custom plugin code to add the emitter to a part/model and control its state. OR My 'chosen' solution was to create the ParticleSystem and set it up entirely from plugin code. As I was already using a custom PartModule to manipulate stuff on the part, it was easy enough to add this loading code to the module. An alternate solution, that I've not yet investigated, would be to use SmokeScreen to create the particles for you. While I don't think it can load any sort of prefabs/precompiled objects, I do believe that it will allow you to define your particles via config files, AND will let you link those particles into the EFFECTS blocks to allow them to be used by engines/etc. I'm honestly curious as on this myself as to what solutions others may have come up with. I implemented the 'quick-and-dirty' loading through code, but would love to be able to create the particle in UnityEditor and export it somehow to be able to use in KSP (especially if it can be used in EFFECTS blocks and by stock KSP code).

I believe the mod you are referring to is: AFAIK it is still 'alive', though hasn't had any comprehensive updates in quite some time. For more up-to-date information, I'd post into that thread (or at least read the last few pages).

This mod is only an API -- it provides a framework that others can make use of. Basically the mod does nothing on its own. I do not provide configs for -anything-, as nobody else seems to like the same aesthetics as I do (I strongly dislike 'stock-alike' texturing), so I've not bothered to spend my time on a publishing a bunch of configs that would only increase my support burden. So yes, you can write your own, or find one of the other config packs that are floating around. I think that both @Manwith Noname and @Electrocutor have config sets, both with their own thread (I'll try to dig up links...). In order, No, No, No, Yes (with caveats, see below). As this mod facilitates its own texture switching... using other texture-switch mods will generally result in conflicts. TU can be setup to handle most/any of the other texture-switching mods' functions, at least as far as actual texture switching is concerned (TU does not touch part resources or anything beyond visual textures). TU can play alongside those other mods as long as they don't target the same parts/textures/materials (or should be able to, in theory, not sure anyone has tested it much). Those other texture switch mods' are more than welcome to integrate with the code-side of TU to allow use of the PBR shaders, but I cannot force such compatibility upon them; I have offered and made available the functionality, which is all that I can do. TU does have some WIP integration with the stock part-variant module (again, by writing configs). But due to bugs in stock code there are some minor edge cases that are not accounted for in regards to part-icons. Aside from that, it is possible to use the stock part-variant setup for UI control only, and relegate all actual texture switching to TU code, or nearly any other combination (e.g. set only some textures/properties from TU, and the rest the default stock handling).

The cab portion of that craft consists of one stock Mk2 lander can, in square form, two stock rover bodies, the stock claw, and the wheels are from KF. All stock aside from the wheels (and the SSTU fuel tank in the trailer segment).