soundnfury

alpha10 released - ported to KSP 1.2.1, ripped out kappa-ray integration, and improved my build setup a little bit.

I'm hereby declaring this mod unmaintained / end-of-lifed, for the following reasons: There are some serious issues with the design, particularly around the APIs for other mods to interoperate - which require those other mods to hard reference kappa-ray. I don't know how to do this properly in C# / KSP. The raycasting is hideously expensive particularly at high time warps. Game-balancing this mod has proven to be a chrome-plated revolving pain in the posterior. I never did figure out how to handle vessels in the background. Other modders who apparently know what they are doing are now making Radiation mods (Nertea's is one, I think Kerbalism is another). I found that I didn't actually enjoy playing with radiation, at least not with the gameplay effects it has in kappa-ray (where instadeath can happen at any time if you're unlucky enough). The aforementioned other mods seem to have better ideas. I don't have enough time to give all my projects the love they deserve. Consequently, kappa-ray has been removed from the tip of the KPU repo (it didn't actually make sense for it to share a repo with KPU anyway, but never mind...); the final version of kappa-ray (for anyone wishing to steal ideas or, masochistically, take over maintenance of kappa-ray) is here.

Boosteriferous 0.2.3 released, rebuilt for KSP 1.2.0 (no other changes). See OP for links, as always.

Boosteriferous 0.2.2 released, rebuilt for KSP 1.1.3 (no other changes). I wouldn't mind at all; feel free to do so.

Please do send me a PR on github. I'll try and make an "official" release for 1.1.3 "soon", if I can find the time. And, yeah, the src/lib/ stuff should be .gitignored, that was a mistake. (But the mod download itself doesn't contain them, what are you referring to here?)

Nice update, looking forward to this! I don't think the LV-N should be an insta-kill; it's no Project Pluto. I'd say something like 30 seconds of direct exposure should cause meaningful damage. So, a little less than 0.1Sv/s on your scale.

I've improved the generator with a little bit of JS so that the form is no longer tall enough to use as a space elevator It hides the bulk of a body's options if "Reached SOI" is unchecked, and totally hides any moon whose parent planet's SOI is unreached. Hopefully that should make the Ribbonator easier to use.

Fairly sure people can still join. Some requirements are: Have a microphone, so you can join in on the mission control net. (It's possible to make do with a phone; we use Discord.) Already have some experience playing with RSS and RO. It's also helpful to have some relevant technical skills, e.g. doing calculations or writing kOS guidance code, but there are many rôles that don't require this.

I'm going to (reluctantly) sit by and watch this happen for now, and put up with occasional manual installs of 'stand-alone' mods. But. The second the new policy causes me hassle (e.g. a dependency of a mod I use (or write, for that matter) is de-listed), I plan to write my own package manager, with the (slightly) less restrictive policy I proposed (i.e. third party .ckans are fair game, but third party .netkans aren't). Because frankly, CKAN's not that great a piece of software, I've long been itching to replace it with something better written, and this issue might just be what an upstart needs to capture enough mindshare to be viable. But don't worry, it'll be a command-line tool, so the lowest-common-denominator users who are apparently the problem for Certain Modders™ will probably be too scared to use it

And you, sir, completely miss my point: that the "moral rights" mentioned in that CC license have absolutely nothing to do with the argument you are making. That doesn't mean your argument is wrong. It just means that you were factually incorrect, and I corrected you, because I am a pedant. Please try not to take my pedantry quite so personally...

Actually, the phrase "moral rights" in this context refers to a specific legal doctrine in some countries such as the right of attribution or the right of integrity. See this handy Wikipedia article. At least in the UK, these rights only obtain if they have been 'asserted'.

I realise this. I was merely pointing out that your demand that it be perfect was a little over-the-top. For instance, if we could find ways to improve the behaviour of CKAN users, then the occasional CKAN mis-install wouldn't be such a problem. IOW, you made a statement that was strictly and technically false, and I'm a terrible pedant who can't let such things pass.

A staging repo would probably fix none, or at least not enough to justify the human effort required. It can only help if someone tests it with the right combination of other mods to produce the conflict. One hopes that all submitted .ckan files have at least been install-tested by their author — if not, maybe CKAN should start blacklisting people whose (third-party) submissions fail to install on vanilla, and not take PRs from them in future. As for the NetKAN system, I have to admit I don't like it — I think automated packaging without human intervention is a pipe-dream. I think the right policy for CKAN to take here is that they should only accept NetKAN submissions from the mod author, because no-one else can know whether the metadata NetKAN sees will be accurate for its needs. Whereas, I still think it's fine to accept .ckan submissions from third parties, and I don't believe that should require the author's consent (unless the author actively maintains their own CKAN metadata, in which case they should have the option to disallow third-party interference). Regarding your third point, I don't know what you're asking for that doesn't already happen.

Despite protestations to the contrary, you clearly place non-zero value on your mods being used by others, else you wouldn't share them at all. Moreover, the "SNR" argument implies that 'real' bug reports have value to you. Thus, a fairer criterion for acceptability would be that CKAN provides you with more benefit in terms of CKAN users finding non-CKAN-caused bugs than cost in terms of CKAN users reporting CKAN-caused breakage. Given how low the SNR is without CKAN problems, the ratio for CKAN users doesn't need to be raised all that high before it becomes a net improvement. Therefore, the "CKAN needs to be perfect else I hate it" position is unreasonable.

QFT. Getting rid of CKAN won't solve the "dumb users can't read" problem. It will, however, cause plenty of new problems, so at least the original problem will have lots of friends.

Wow, am I the only modder who likes CKAN? "Whine whine whine users are dumb whine whine my support channel has too low a SNR whine whine I'm trying to use a forum thread as a bug tracker and it's not working." (paraphrased) Seeing people blame a package manager for misdirected bug reports like this really makes my blood boil. Watching this discussion has caused me to lose a lot of the respect I had for certain modders, and that makes me sad. And if I think those modders are acting like spoilt little brats, I'm not surprised the people who actually run CKAN don't want to bend the knee to them. If I'm reading rightly, for instance, @ferram4 effectively said at one point that something like CKAN was only acceptable if it never made a mistake. Not "strives to minimise mistakes", not "fixes mistakes when they're spotted / reported"; no, apparently it's unacceptable to have "issues that allow inaccurate metadata to be added and for any kinds of install errors to occur". In other words, CKAN is required to somehow guarantee that it will never have a bug and will catch any and all typos, thinkos, and other errors in metadata. Suppose, for instance, that you have a proper bug tracker, but many bug reports go to the forum thread, and get lost under CKANspam. Then, just don't follow the thread, state in the OP that bug reports should go to your tracker (and that bugs should not be reported against CKAN installations). Anyone who has enough brain cells to find the bug tracker will have also understood that CKAN bugs shouldn't go there. Fun fact, @ferram4 mentioned how hard it was to get users to use his bug tracker... which isn't actually linked in his OP! (Not meaning to specifically hate on @ferram4, btw; I'm disappointed in several of you, it's just that the examples that came to mind both involved him.)

I'm both a mod author and a CKAN user, and from both sides I've found the CKAN process to be well-designed. Obviously some other people in this thread have had rather different experiences, but that brings me on to the second point... I've only seen one substantive complaint about CKAN, which is "CKAN users pester me about CKAN even if I don't touch it". Frankly, I don't see how that's CKAN's fault - rather it's caused by some members of the community being excessively entitled, and we've seen that in plenty of other contexts that have nothing to do with CKAN. (The phrase "64 bit" comes to mind, I can't think why.) Getting rid of CKAN, or changing its submission rules to forbid third-party metadata submissions, wouldn't change that in the slightest. I have seen this claimed a number of times in this thread, but my understanding is that it's not true. Certainly the metadata can specify versions with dependencies - see https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md#relationships - and I'm fairly sure the client respects them.

They're all there on the Videos tab, just for whatever reason the channel's front page is blank...

alpha9 released - ported to KSP 1.1.x, improved the Library's determination of used inputs, other small fixes. Updated download link in the OP.

Yeah, we got Agathorned. All part of the fun

Uh, there's no DMP (I'm not sure why you think there is). Though we may need it in the future for some missions, we're not using it yet. Just lots and lots of telemetry, and a Discord server for the chatter. I've attempted to compile a modlist here; note that it's missing various eye-candy mods (RVE etc). Probably we should have a list in the repo, but I'll let @NathanKell do that as he has the canonical install.

There is a fork of Telemachus by @tcannonfodder at https://github.com/tcannonfodder/Telemachus/releases, which is updated for 1.1. I've tested my Telemachus frontend KONRAD (which afaik we're planning to use) with it, and it mostly seems to work. Unfortunately staging ({'run': ['f.stage']}) seems to be broken for some reason. But apart from having to switch back to the KSP window to whack spacebar a couple of times, flying a launch from mission control is definitely possible

Boosteriferous 0.2.1 released - adds a wider variety of thrust profiles, with technology unlock requirements. Also fixes the Thrust Termination Ports which were broken in 0.2.0.

Yeah, I saw those. Unfortunately, like I said, I can't allow arbitrary FloatCurves, because I have to be able to integrate the burn times. And I don't fancy writing code for algebraic integration of the reciprocals of arbitrary Hermite polynomial splines bozhe moi. So I'm limiting to piecewise linear functions. Much easier to integrate

I am planning to add more profile types in the next version (this release was just a quick 'get something out the door for 1.1'). As well as the current 'step' profile, there will probably be 'linear' that ramps down smoothly from start to end, and then some two-part profiles that allow you to throttle back up after max Q. However, there won't be anything quite as complex and customisable as the old version of this mod had, let alone the 'draw a graph' in the concept you linked. Part of that is for UI simplicity reasons (I'm not great at writing GUIs), and part because of burn time calculations (I have to be able to integrate the reciprocal of the thrust curve so I can put an appropriate number in maxThrust). There will be gameplay integration of this new system, the more complex profiles will cost more and possibly require tech unlock.