Jump to content

Shadowmage

Members
 View Profile  See their activity

  • Posts

    4,628

  • Joined

  • Last visited

 Content Type 

Everything posted by Shadowmage

  1. Shadowmage
    Because when TU was developed DX12 had other serious issues, such that it wasn't even worth the time to include it in the API test (as in, didn't work, at all). The real question is.... does it work now?
  2. Shadowmage
    Those patches have not been maintained in... forever. Too much flux between all of the mods in the past for me to keep up with all of the changes. Perhaps now is a good time to look into cleaning them up though as I don't foresee any large changes for SSTU in the future, and Nertea is actively pushing 'final release' tags to his mods.
  3. Shadowmage
    Thanks for the link. Interestingly, that is not a patch-set or author that I'm familiar with. Do you know if they have a forum thread here somewhere? I'll take a look over the patches and see what all needs to be changed. As I'm not already familiar with it, might take a bit to sort it all out. Will let you know what I find out
  4. Shadowmage
    If you wanted to post a link to the forum thread where you got the configs, I can find them from there. Likely it is one of the two stock patches from authors I've worked closely with in the past, so I can potentially provide you a temporary solution, and provide the author with the fixes to their patches.
  5. Shadowmage
    That is an issue with an incorrect shader assignment for the meshes in that model. Whichever patch set you are using (stock configs?) needs to be updated to use the TU/TransparentMetallic shader for those meshe(s). In theory should be a very simple change/update to the patches; potentially as simple as a single-line change to a single file. If the model wasn't done with specific mesh-targets previously, or was included in a larger patch for multiple models, it might be necessary to write a patch specifically to target that model with the proper shaders, but even then it should still be a 'relatively simple' fix. Glad you are otherwise enjoying the mod and the potential enhancements it has to offer
  6. Shadowmage
    This likely has more to do with your keyboard (and N-key support) than with developers. Could also be a simple 'order-of-checking' thing in code; if 'left' do X else if 'right' do Y Would need to be restructured such as: if 'left + right' do Z else if 'left' do X else if 'right' do Y
  7. Shadowmage
    In functionality, from what a player would notice? Close to zero. Functionality, in what types of models and setups it will support -- The SSTU module is leagues beyond the stock module. You can try to swap it to use the stock module, but it won't work (nor will I offer any support). The entire reason I wrote my own (stock doesn't support multiple transforms, etc). Those other mods don't recognize SSTU panels because they have 'hard-coded' support for stock solar panels by class-name. Nothing that I can do -- the author of those mods need to 'hard-code' support for every other solar panel as well, or come up with some sort of generic method (which they should have done in the first place; no acceptable excuse for hard-coding for specific classes exists).
  8. Shadowmage
    To expand upon @sumghai's explanation -- there is little benefit for KSP (or rather Unity) to use newer .NET versions. In fact, they don't even use the .NET compiler, they use Mono (or Roselyn in recent versions of Unity). Moreso, this isn't a decision made specifically by the KSP devs, but rather is a limitation of the Unity version that KSP is built with. However, personally I found that if I use Visual Studio as a stand-alone I am able to compile .dll's using newer C# language features that are not supported by the older .NET 3.5 target (such as inline 'out' variables from C#6/7). So if your only goal is to get access to the newer language features -- you already can. You only need to target the older versions if you are letting Unity compile your .dlls. https://www.lifehacker.com.au/2016/05/a-primer-for-unity-developers-what-the-heck-is-mono/
  9. Shadowmage
    There should be an unlockable 0.625m diameter option for the fuel tanks. Don't remember offhand when/where it is unlocked, but should come with the stock 0.625m tanks.
  10. Shadowmage
    Silly suggestion -- but it sounds like you might be running the 32-bit version of KSP which has a 3.2gb ram limit? 32gb of ram should be way more than plenty for even super-highly modded installs. But, if you are launching the 32-bit client, it has a limit of ~3.2GB ram usage, which will crash even with just the stock game. If you look in the KSP folder, there should be two executables. One for 32 bit (KSP.exe) and one for 64 bit (KSP_x64.exe, or similar; not at my game machine at the moment). Run the latter one... (and then make sure your Steam or other shortcuts are configured to run the 64-bit version as well).
  11. Shadowmage
    My personal opinions on this newly announced DLC: Robotics - an excellent subject for a DLC. It is not something present in the stock game in any form, and opens up entirely new venues for craft construction. If done properly I think the robotics could be worthy of a DLC all by itself. I've personally longed for a reliable robotics package for a long time now -- one that does not suffer the caveats that IR is subject to regarding use of docking ports and 'sloppy joints' (e.g. a 'hinge' needs to act solely as a hinge, constraining movement along all axis except its specific free rotation axis, not as a ball joint attached with a spring; unfortunately I know these to all be limitations of Unity, so don't have very high hopes of the stock system working any more 'properly' than does IR). My only other concern on this is how SQUAD handles the code-side functionality -- will the code (PartModules) be limited to only being available when the expansion is installed, or will the core robotics functionality be available in the stock/core API? (either is an 'acceptable' and workable answer, though one is certainly more desirable than the other). Surface Science - Honestly should have been part of the stock career from the beginning. I appreciate that it wasn't part of the stock career mode at 'release', and so they are free to issue it through a DLC, but really feel that it should have been included in the stock game. Lack of something to 'do' on planets has been what I feel to be one of the largest 'incomplete' areas of the stock career gameplay. Deployable Science - As with the surface science, I think this one should have been part of career mode from the start and not part of an optional expansion pack. New Space Suit - Okay, sure. Not personally a fan of the look, but at least it isn't being packaged as its own micro-DLC. Cost - About right for what they are offering, esp. when compared to what you get for the same value from other games DLCs. One new major feature (robotics), two expanded science options for science/career modes, and one 'freebie' spacesuit model. I probably wasted more $ in gas warming up my car in the morning in the past month, not to mention my weekly coffee bill.... Overall - When I read the name I thought 'gee, finally some parts for surface bases!'. Sadly, I was disappointed on that, though I can't really express any disappointment towards what was actually announced as part of the expansion.
  12. Shadowmage
    https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelRepulsor.cs#L30 That is the value that is multiplied by the supported mass (or actually the instantaneous output value of the combined spring+damper calculations). It -is- a config value, though I might not have specified it in the current part configs. The actual calculations using that field/value are done here: https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelRepulsor.cs#L272-L284 Yes. That value is not used for repulsors, as they do not have any 'damage' module in the part config. See the previous answer. Additionally, the way KSPWheel functions regarding automatic suspension 'spring' value calculation, each repulsor should be able to support the full craft weight at roughly 50% compression. More replulsors will reduce the compression amount; extreme numbers of wheels/repulsors will mandate that the 'spring' value is reduced on each one so that there is at least some compression / reduce jitter.
  13. Shadowmage
    More likely that they made them use static colliders and that the deployable science packages lack any sort of spring/damper on their legs. Simpler to implement, less buggy, and better for performance; all around win.
  14. Shadowmage
    Yep. KSPWheel solves nearly all of the issues with stock landing legs/gear/wheels being wonky. Including use of automatically calculated critical damping (and setting damp ratio relative to critical, where damp = 1 = critical damp). This is however an entirely new wheel system (not just a patch/hack of the stock wheels). I wasn't about to try and polish the turd that was the Unity wheel colliders, so instead created a new wheel collider class and part-modules to manage it. Mostly used in Kerbal Foundries, though a few other mods also make use of the API:
  15. Shadowmage
    Check one page back:
  16. Shadowmage
    Perfectly stable for me, has been for many releases (1.1 / 1.2 era?). In the past, yes, there were stability issues; those were resolved when KSP updated to using the newer Unity versions that fully supported those APIs.
  17. Shadowmage
    If your computer BSOD's when enabling DX11, you have some serious issues at hand -- either driver or hardware problems exist that should be solved before continuing. I would start by updating drivers everywhere; motherboard chipset, graphics. Next, run the game while monitoring temps to check for overheating. Beyond that? RMA time.
  18. Shadowmage
    TextureReplacer has been known (at least in the past) to conflict with the TU reflection system. Might be worth investigations to remove that mod and see if the problem persists. I'm not aware of any solution to get them to play nicely, but identifying the issue is the first step in the process either way. Interesting.... I personally use '-force-d3d11' in my setups for both development and testing, but openGL should be supported and fully functional as well. For OpenGL the '-force-glcore' option is what should be used, as that activates the more modern 'OpenGL-Core' API (as opposed to the legacy APIs), and is the only option for Linux/Mac users. I would have to see more of the log (to know _which_ texture/material is generating the error), but I'm pretty sure that is a stock error/Unity error. Basically something is trying to use a normal map texture on a material/shader that doesn't support normal maps. What, why, where? Need more context from the log to know. However that specific error shouldn't cause any other issues in gameplay; only that single part/mesh/material would be impacted by the error.
  19. Shadowmage
    If for some reason you have the TU reflections disabled, and the stock 'real time' reflections disabled as well, that would be the outcome. The editor uses a stock 'prebaked' reflection map, whereas flight-scenes use real-time reflection rendering. If you post a link to a copy of your KSP.log file, that will contain some debug/output that will denote if you have the TU reflections enabled in the TU config files.
  20. Shadowmage
    They should, but entirely possible that something was broken in a recent update. I've opened an issue ticket on the subject, and will be sure to investigate the behavior and fix if needed for the next SSTU update: https://github.com/shadowmage45/SSTULabs/issues/780
  21. Shadowmage
    That file really isn't used anymore; or at least shouldn't be; its a legacy file that just kind of stuck around. Dust colors are dynamically captured from the scenery using a downward-looking camera. It renders the scenery near the ship (~10m or so I think?), samples the rendered texture, averages the color across the entire texture, and uses that averaged color. The sampling is done every X seconds or X meters, depending upon vessel speed, and then finally the colors between the last sample and the current sample are lerped/blended to smooth out transitions between different biomes/colors across the samples. Is there a specific case where this is not working? It should in theory work just fine in RSS, as well as it does on a standard scaled planet/body.
  22. Shadowmage
    Because DX9 is about 10 years past its expiration date, and should have been retired long ago. Being so old and out-of-date it does not support the modern rendering techniques needed to properly utilize PBR materials and global illumination technologies. Hence the 'requirement' to use DX11 or OpenGL-Core, as both of those APIs are much more modern and support all of the features needed. Why KSP insists on using extremely out-of-date graphics API as its default? Probably some accountant stuck in a windowless office somewhere making decisions for the business.... (read: market share / lowest-common-denominator / consoles) Certainly you can use DX9; it is functional. But I'm not going to support it or endorse it due to the artifacts and other rendering issues.
  23. Shadowmage
    Technically, its TexturesUnlimited telling you that. So, still not directly SSTU related. Not even mod related. Or even KSP related. This one is a simple 'how do I use computers' type question, with answers dating back to at least the 70's (command-line options have been around for longer than I have been alive). Here are the instructions and documentation on how to utilize the start flags, as provided by Unity, directly from the Unity website. Why I seem to be the only person who knows how to use Google to search for things, is a completely separate and probably never-to-be-answered question... https://docs.unity3d.com/Manual/CommandLineArguments.html
  24. Shadowmage
    The current releases are 'testing' releases, and may have game-breaking changes in future updates before all is done. As such, I'm not advertising their KSP compatibility or even their availability.
  25. Shadowmage
    Should work on either version, but was compiled against the KSP 1.7 libraries, so can only guarantee compatibility for that version.
×
×
  • Create New...