Jump to content

TythosEternal

Members
  • Posts

    144
  • Joined

  • Last visited

Posts posted by TythosEternal

  1.  

    On 11/13/2020 at 4:39 PM, linuxgurugamer said:

    Sure.  I'm looking at it right now.  If you like, I've already cloned the repo and have done a basic pass through it, converting images to dds, fixing the categories, adjusting max temps, adding missing bulkheadProfiles, adding tags and formatting.  I will commit my changes in a little while,

    Awesome to see this kind of collaboration. A lot of GitHub projects operate under a fork-pullrequest model; you can collaborate in this way, commit directly, or even poke the old author to see if he'd accept PRs. But if it's semi-officially abandoned, your best bet might be a fork followed by subsequent collaboration. Can't wait to see what you come up with!

  2. On 12/15/2020 at 5:40 PM, BumbleBeeJBG said:

    I too am having issues, all of shaders are showing up "failed to compile"

    I was able to get compiled shaders by configuring against the PartTools downloaded under "Previous Version" (filename "PartTools_AssetBundles_02_20.zip"). I have not yet verified if this approach remains compatible with v1.11, however.

  3. I'm seeing similar issues; specifically, the "KSP > Diffuse" shader (which seems to me like it should be low-hanging fruit?) is unable to compile. Unfortunately, the downloads on the official thread don't reference historical versions, so I'm stuck with the 1.10 release.

    Here are my specific steps, from scratch (it's been a while, so I had to reinstall nearly everything anyways):

    1. Create basic part model in Blender, save as .blend and mapped texture .png

    2. Install Visual Studio 2019 with Unity Tools plugin independently (seems to fail if installed as part of Unity setup, possibly because MSVC Built Tools already exists?)

    3. Install Unity 2019.2.2f1

    4. New project (3d), open "Window > Package Manager", remove TextMesh Pro

    5. Add "TextMesh Pro v1.0.56 - Unity 2017.3" .unitypackage file to project packages

    6. Add "PartTools" .unitypackage file to project packages

    7. From "Tools > KSP Part Tools", set GameData path

    8. Add .blend and .png to assets

    9. Instantiate asset and unpack prefab

    10. Remove camera, light

    11. Attempt to add new material "KSP > Diffuse" (note: under "failed to compile")

    12. Inspect "PartTools > Shaders > Diffuse"; error message: "failed to open source file '../CustomUnityShadowLibrary.cginc'

    13. 'Compile and show code' successfully hands off solution to Visual Studio, where it is able to build without any errors or warnings

    14. ???

     

    Some of the resources I've been using as reference for the above steps:

    Some hypotheses/solutions:

    • Solution paths may not be handed off correctly depending on PartTools configuration for source  code referenced by KSP Shaders
    • Provide historical downloads of PartTools releases (e.g., 1.9, as per wasml's suggestion)
    • Successful Visual Studio solution builds not "handing off" products back to Unity entities, perhaps a callback issue?

    UPDATE:

    There is a section near the bottom of the official PartTools thread top post that references "Previous Version; For the old Unity 2017 PartTools you can use this link: Unity 2017 Part Tools". Turns out, these are TWO separate releases. The download linked under "Previous Version" provides a file named "PartTools_AssetBundles_02_20.zip"; it's not obvious, but this CAN be used to provide functioning PartTools assets (including shaders that successfully compile). Not clear from the numbering if this is for v1.9, but I'll take it.

     

  4. Indeed, that is really, really cool.

    Frida, you appear to be quite well plugged in to the NH team. I'm guessing these recent images are part of the regular transmission of data that is occurring post-flyby that are being released as they come in. Do you know how regularly we can expect these releases? 2 images/day of the resolution we've been seeing, perhaps, on average?

  5. I am very interesting by the counterexample this case poses to Rule #8 of Kelly Johnson's 14 Rules of Management:

    http://lockheedmartin.com/us/aeronautics/skunkworks/14rules.html

    Specifically,

    Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.

    I am tempted to go with Johnson over Musk here. Following every failed component with a change to your process in which you now inspect said component means that, sooner or later, you will be inspecting everything, trusting nobody, and needlessly repeating a lot of effort. It's a nasty downward spiral in which you end up spending more resources repeating verification, validation, and accreditation efforts after each stage of acquisition and integration than you do on engineering the actual systems (and if you think that's an exaggeration, you haven't worked for a big aerospace company lately).

    This is exactly the kind of balance statistical mitigation is meant to address. You don't repeat every inspection of every part until there's a zero percent chance of failure, because then you go broke. You VV&A enough to give you a failure probability within your tolerances, with the understanding that, yes, sometimes things go wrong and you should plan accordingly. The only alternative is to manufacture everything in-house, which we know has been a long-term guiding objective of Musk's anyways.

  6. Fedora is my go-to for personal use and situations where I have a say in e matter. Gentoo for when I need to go hard-core (which is less often than it used to be). At work, it's mostly Debian and (somewhat less often) Scientific Linux.

    After a certain point, you stop caring about the distro and really only think about the package manager. I prefer yum over apt-get, but mainly because I have to type three keys instead of seven. Yes, I'm a discriminating soul.

    On this and aforementioned notes, one of the most interesting info-graphics I've seen is the following illustration of Linux distro evolution. With a little luck, I'll convince our office to plot and frame a full-size version for our lab. It puts all the silly distro arguments in perspective.

    Linux_Distribution_Timeline_with_Android.svg

  7. For the 2.5 bay, I like to place an SC-9001 Science Jr. in the middle. It naturally fits well and snaps to the aligned nodes. Then, I hang all my other goodies--batteries, flight computers, Goo, thermometers, barometers, etc.--off of the Science Jr. It's not particularly efficient, but it's very straightforward.

  8. Conic sections are the exact solutions for the 2-body problem, and the two body model is what KSP is using. It has nothing to do with general relativity.

    This.

    Kepler's first law--"all orbits are conic sections"--can be directly derived from Newton's law of gravity and conservation of angular momentum. No relativity knowledge is required.

  9. Valentina flew on a 4km EVA from her ship through low Kerbin orbit to get close enough to poor stranded Strovan (spl?) to switch control and enable his own EVA, after which they both jet-packed another 4km back to the mothership for a successful rescue.

    It wasn't too extreme, but it was unusual for my missions and it definitely felt like Valentina was earning her BadS flag. Constantly switching back and forth to coax the simultaneous final approach was challenging and very satisfying.

    Isn't it funny how we credit our little Kerbals with successes we ourselves perform? It's like a comic, Kerbal-ish form of modesty

×
×
  • Create New...