• Content count

  • Joined

  • Last visited

Community Reputation

4,948 Excellent

About Shadowmage

  • Rank
    Sr. Spacecraft Engineer
  1. Updated release is available: Fixes the missing/broken color and float property inheritance. Really not any other changes.
  2. Updated release is available: Updates the included versions of KSPWheel and ModuleManager, both for KSP 141 compatibility.
  3. Updated release is available: Disables dust-effects at the plugin level (no more NRE logspam), and basic recompile for KSP 141.
  4. Updated release is available: Just a recompile for KSP 141
  5. No. Just as ModuleManager doesn't ship anyone's personal patch configs, neither will TU ship anyone's personal texture-set configs. It is not my place to decide how the parts should look in someone's personal game, just as it is not ModuleManager's place to decide what ISP an engine should use, or how much fuel a tank should hold. Another example of a neutral API would be KSPWheel -- if added to a game by itself, it does absolutely nothing; and the same reasoning is why it doesn't ship with patches to KSPWheel-ize the stock parts. (not trying to say that TU is on the same level of utility, usefulness, or stability as ModuleManager, merely pointing out that both are intended as neutral APIs that by themselves should not effect anything; they exist to allow others to do things) Please don't take this statement as me saying that I don't appreciate the work put into those patches, or that I disagree with the outcomes -- neither is true. I fully appreciate the patches they have put together, and in fact use (some of) them in my own personal games. I fully support and endorse their work; I just don't think it would be proper to distribute it with the base TU releases. I don't even have any objections to distributing those patches from the TU repository as separate (optional) downloads, so that might be an option in the future. There -might- also be an option for a 'TU-Deluxe' release that included configs at some point in the future -- but I don't really have time to look into it for awhile, and it would of course still depend on the willingness of the authors to have their work distributed with TU.
  6. Still up for debate... all of the various loopholes are a veritable minefield. Emphasis added on the last sentence is mine. A KSP plugin is (al)most certainly a 'separate work'. Definition of a 'combined program' is also a bit debatable: In the case of KSP addons -- I would say that it is not the main program that is establishing 'intimate communications', but rather it is the plugin itself that does the (majority of) communication. Of course, most of that covers how KSP would be effected by GPL'd plugins. In the end though; I don't really care. I release my source code under GPL license, and will continue to do so. This is to allow others to use, modify, and redistribute the source-code, under the terms of the license, and really doesn't have any impact on what I do with my own source.
  7. Will be posting an updated release this evening to fix the dust-effects NRE log-spam -- will be disabling dust-effects entirely until I can rewrite the system. Will also have 'official' KSP1.4.1 compatibility with tonights release, so anyone needing proper .version files for CKAN dependencies will have them. Dust-effects will be returning. But as they (or lack of them) don't interfere with the base functions of the mod (wheel physics), I'll be holding off on fixing them until I can get all of my other mods into at least 1.4.1 dev-testing state. Have considered adding support for generic 'collision' based dust effects (e.g. spray some dust whenever things collide; either parts->terrain, or parts->parts). Any interest? (there was another mod that did something like this, but I've not tried it, and no idea if it has been/will be updated for 1.4+)
  8. Just a quick heads up -- Will be pushing out an updated release tonight that fixes the float and color property inheritance features. Shouldn't have any other changes (though I'm considering adding capability to load the old config-node naming, just for compatibility sake). If anyone is aware of any other new issues that need fixing -- now is the time to speak up
  9. Its much simpler than that -- go into the in-game difficulty options, find the mod settings, go to the KSPWheel entry, and you can disable or adjust the wheel damage stuff globally there. If you are looking to adjust only a specific part (as per your example patch), I can probably help you figure that out as well, but will need time to look into what values actually need to be patched.
  10. Work... lots and lots of work Have been spending my days the last few weeks learning a new development environment/language/system as part of my new position at work (its a rapid application development framework, more than an actual language), as well as studying up on a few specific database systems that I'll be working with. So far I'm finding that I'm really not fond of using such limited tools to create programs - being so far removed from the actual code is frustrating - but I can see the intent of it, and can probably learn to use it well in the long run. Databases are, well... databases. Gotta have them, gotta know how to use them (or rather, setup and administer them). Ohh.. you probably meant news on SSTU? Scroll up a few posts to see the latest (recap: still working on fixing dependencies; at least a few weeks out for an SSTU update). KSPWheel is mostly working; dust-effects are broken by the update, but the actual wheel bits still work. Likely 'good enough' for now, can fix up the particle effects later. TexturesUnlimited is still WIP on the update, but will likely be in a stable state later this week. After all of that, I can hopefully start to focus more specifically on the SSTU update. I've made some progress in the last week, but most of my focus has been on getting KSPWheel and TU back to being functional (both because I need them and because other mods rely upon them).
  11. @Electrocutor is the author of the one that I personally use.
  12. @Electrocutor is the author of the one that I personally use. @Manwith Noname Also has a few configs for various mods. They can be found here: And a link to the KSP 1.3.1 stock conversion patch is here: A couple previews of parts using the stock-conversion patch: Edit: Wonderful forum software....
  13. You can disable the dust system entirely in the in-game difficulty menu. As this is a particle-effect problem -- going to take awhile to sort out. I have exactly zero information on this new particle system; so not only do I need to learn how to use it, but then I also have to bash it all around to make it work in KSP.
  14. Hmm.. that would be problematic, but probably not compatible with any texture switching mods. I should probably add to the OP that 'uniquely named transforms' are necessary for proper per-transform/per-mesh texture handling. Yes, for a given MATERIAL, it will use the first texture found for all other uses of that MATERIAL. Yes. If you need different textures to be used/inherited, you need different MATERIAL blocks that target different meshes. This change was a direct result of a fix for the exact loophole that these types of property-only 'texture sets' were (ab)using (property values carrying across textures sets). The MATERIAL definitions now work kind of like an actual Material instance in Unity -- a single Material can be applied to multiple meshes, but they all will share textures/etc (and that is what they directly map to in the code). I think if it all works out, you should be able to switch your dependency from TRR to TU. TU will have all of the shaders and reflection-probe handling code, so you should be able to use those as needed. Have you checked out the TU 'stock conversion' patches that have been floating around? They pretty much already do all of the window-reflection related stuff, with just a simple config/MM patch (if you already had existing additional texture maps for the stock parts, can likely make use of those too for even better effects)
  15. In addition to my previous post, apparently I forgot to write a couple of code blocks for inheriting standard float and color properties (the actual functional bits of the code), so the above config/example won't fully work until I push out an updated TU version. As it is a fairly large omission, I'll try to get an updated release available within the next couple of days. Apologies for the omission, has been a bit crazy trying to clean up all of the KSP 1.4 breakage across all of my mods.