taniwha

@schlosrat I know the window can be moved off-screen manually, but not completely, though I suppose it can be hard to find (especially if you don't notice moving it). I will, however, look at getting window movement limits into EL's UI. On a separate note, I have found that click-through blocker doesn't really work all that well, and can negatively impact user experience (in particular, blocking vessel controls just because the cursor is over a window). However, EL's new UI (when I get it done) removes the need for click-through blocker (with the new UI, the only time input locks are needed is when entering text into an input field).

@schlosrat It would be quite helpful if you could investigate the cause of the window going off screen. It has never happened for me, so there's currently no way for me to reproduce the problem and thus do proper testing.

@ayothepizza There is a rather comprehensive section on configuring parts for EL in the manual.

I have no idea how STL export works. However, one thing to try is exporting your imported craft as a mu, then importing that mu and exporting the result.

Edit KSPIE's module manager patches.

Totally agree (on both points). No quibbles about girders and tanks, but things like that certainly should be passable.

Windows or Mac, no idea. Liniux: ~/.config/blender/<version>/scripts/addons

That you're having fun again is the best news. Do let me know if anything else comes up (just don't mention in-flight part selection, because... reasons ).

While I think the problem manifests itself only when you build the recycling bin then immediately use it, that's still good to hear, thank you

I've got the svg->png export sorted out so my backgrounds are transparent again, but I'll hold off on releasing a fix for them as it's a very minor (purely aesthetic) issue. My hope is I'll be able to release an update with juicy new features soon. The problem is I got burned out on the work (lots and lots of UI stuff), so moved over to doing some work for KK... more UI stuff... oops (and getting burned out on that again). However, EL's dev work is getting close to the point where I can look at implementing the above mentioned difficulty settings and CommNet usage.

Oh, actually, it looks like Inkscape updated yet again

OK, I've got it working with no code modifications: First, don't know if it's neccessary, but simply delete the ShipInfo node from ELSettings (this is what I did). Second, it seems you cannot have the window up when first entering the VAB/SPH or after hitting New until you place a part. After just deleting all parts, you can still toggle the window, though. Oh, and yeah, the button appearance is my fault (sort of: Inkscape changed its command line syntax and I've got something wrong with them for those files).

@schlosrat I have no clue what's going on (yet), but I have reproduced it. I agree that it's likely something to do with the button being weird. Unfortunately, I didn't notice it while testing the recycling bin (I was in the VAB to add a bin to my test vessel). Hmm, button is black in flight, too, but it works. Button looks to be an SVG export issue, so unrelated.

I have released version 6.8.3 of Extraplanetary Launchpads. This is a quick-fix release for the actual bugs found by @Snoman314 (a very big thank you!) Changes from 6.8.2: Ensure probability of non-leaf parts being recycled is never 1 Make recycling bins part of the work-net so they never lose track of the network. The other discussed changes (using CommNet, difficulty, etc) are still planned, but will be part of the next feature release.

Yeah, that was the intention. My thinking was that by the time people were recycling, they'd have several engineers on board and thus have more than enough productivity (like you), and thus most wouldn't notice for larger vessels (but would for more maneuverable units). Going by the very low amount of comments I've received on the behavior, I'd say that assumption wasn't too far off the mark. This is already doable, my proposed changes would drastically reduce the occurrence of mini Kessler syndromes. Already testing the actual fixes. Came up with a better solution that what I was talking about in my post.

@Snoman314 Update. Yup, bug in recycling bin handling of the work-net. commit 8631f12061cde58ee77a2e93414a94f95098911f (tag: v6.3.1) Author: Bill Currie <[email protected]> Date: Tue Nov 13 17:01:03 2018 +0900 Ensure sources and sinks know the worknet. As part of the spawn process, especially when using the micro-pad, the worknet for some or all parts may be lost. Since the vessel worknet rebuilds the network after any vessel modification, simply update each source and sink with the current worknet while building the network. Fixes the erroneous 0 productivity in the build window. Recycling bins are NOT part of the work-net, and so they don't get updated when the work-net updates, and I suspect the above describes your situation. I'll need to poke at the work-net code a little to ensure it does the right thing with non-consuming work-sinks, but I'll add recycling bins to the network. Again, thank you.

First, I just want to clear up that this feature was meant to make the recycling bins a little more interesting than just part-at-a-time recycling, and the fairly low (0.75) productivity requirement was supposed to make it pretty easy to get 100% reliable recycling. It was never meant to be punishing in any way. Really, I have to thank you: not only have you found some bugs in the recycling code (this post is written in a back-and-forth manner), this is the first actual constructive criticism I've received regarding the behavior of recyclers. If your station has a productivity of 24, then the probability of a non-leaf part being recycled should be 0. That it was not is a very deep concern. Looking at the code, a little above the while loop you posted, it looks like workNet is null (which is a bug in itself, I wonder if something has changed in KSP because I was pretty certain I tested recycling bins after the switch to VesselModule for the work-net). However, another bug is that the default productivity (prod = 0) should have been passed through HyperCurve (which would result in a probability of 0.5 for a non-leaf part to be recycled. To save you some effort, HyperCurve passes the value through (sqrt(1+x^2) + x)/2 (core of asinh, actually), so -inf -> 0, 0-> 0.5, 0.75->1 and asymptotically +x -> +x for x >> 1. Anyway, I'll fix the glaring bug (not using HyperCurve in the right place) and investigate the apparently incorrect workNet reference. Also, I'll add a note to add a difficulty setting for this, and I've come up with some ideas to make recycling tugs more usable: tie the effective productivity to highest of the local vessel, and a single-hop to a probe control point (or KSC if Kerbin itself is single-hop, where KSC has an assumed very high productivity (0.75 is plenty, so single-hop to KSC would mean no scattered parts)). I might add signal strength in there.

Bwahahahaaaaaaaa }:> No, it's not dead. It's just not free. As a bit of a hint, recycling bins are dumb, they have no idea how to take apart a ship: they just much on the most convenient part. They need intelligent direction. Less subtle: the recycler code goes through the vessel part tree, and at every part that has children it makes a random decision as to whether to move on to a random child recycle that part. When it gets to a part that has no children, that part is unconditionally recycled. Now, the probability of that decision is a direct translation (ie, no scaling) of a very specific vessel-wide statistic.

hmm, it looks like it might be a problem with massless efficiency keys. For now, it might be best to remove the 0 keys and the efficiency lines from the 1 keys. However, what it even more looks like is I need to rig up a test harness for the converter so I can test it outside of KSP.

@Li0n In my experience, mod compatibility issues with KIS are more often in the mod itself. I'm not saying it's not KIS, just that you should ping on the B9 thread as well.

I have updated the manual and zip download links to use https. The ssl certificate is self-signed, so it may cause some problems, thus the old http links are provided as well.

Thanks. BTW, you should be able to fix your issue by either adding a second efficiency key, or having no keys.

Though it looks like it could take some time for the fixes to come into effect for everyone.

Yeah, I noticed. It should be good now. I had fixed the name server addresses a few hours ago, but forgot to update my nameserver's database (oops)

While AdjustableModPanel and kOS are decidedly unhappy about something (might be good to send this log file to those authors), I don't think they're related to your crash. RecoveryController is decided unhappy about the vessel being built by EL, so certainly worth contacting that author. InterstellarFuelSwitch is very unhappy, but it looks to be due to module mismatch (did you install or remove mods after creating the craft file?) However, real trouble began with KspiFoldingRadMed and DeployableMicrowaveInfraredRectenna complaining about Infinity or NaN values (probably due to one of the earlier issues).