TythosEternal

What happens when you attempt to activate the component? Would you be willing to upload your part mod to something like GitHub where we could test it out and give you feedback?

I've been looking over a lot of tutorials and API references in the wiki lately. It's great to have regularly-updated Doxygen now adays, which is simultaneously more accurate/detailed but less easy to augment/comment. It seems like a good time to just strip the attempts at API documentation from the wiki, and use it instead to augment the Doxygen pages with guidance and examples.

Darn, that's always disappointing. Sorry to hear that.

Do we need to update this for IMGUI migration? That seems to be a sticking point for keeping a lot of UI mods up-to-date.

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!

Grats, Squad! I can't tell you how happy it makes me to see you continuing to develop quality content. This is a great milestone of an expansion, too! Many thanks.

The wiki has a decent set of tutorials. There are also some solid YouTube playlists and walkthroughs. That having been said, a number of the above are little out of date (API references, etc.). I plan on putting some time into update some of those wiki pages, in particular, in the near future.

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.

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): Create basic part model in Blender, save as .blend and mapped texture .png 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?) Install Unity 2019.2.2f1 New project (3d), open "Window > Package Manager", remove TextMesh Pro Add "TextMesh Pro v1.0.56 - Unity 2017.3" .unitypackage file to project packages Add "PartTools" .unitypackage file to project packages From "Tools > KSP Part Tools", set GameData path Add .blend and .png to assets Instantiate asset and unpack prefab Remove camera, light Attempt to add new material "KSP > Diffuse" (note: under "failed to compile") Inspect "PartTools > Shaders > Diffuse"; error message: "failed to open source file '../CustomUnityShadowLibrary.cginc' 'Compile and show code' successfully hands off solution to Visual Studio, where it is able to build without any errors or warnings ??? Some of the resources I've been using as reference for the above steps: https://forum.kerbalspaceprogram.com/index.php?/topic/160487-parttools-updated/ https://forum.kerbalspaceprogram.com/index.php?/topic/192258-part-tools-problem/ https://forum.kerbalspaceprogram.com/index.php?/topic/197990-trouble-with-parttools/ https://wiki.kerbalspaceprogram.com/wiki/Tutorial:Making_an_asset_from_start_to_finish 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.

I love the Spacecraft Thursdays idea!

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?

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, 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.

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.

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.

GAH! I want to stay up, but it's 3:40 AM here in California and I really need to be coherent at work tomorrow... Go, go, New Horizons! May the Spirit of the Hype live on for many bytes to come.