Alastair412

Didn't you already deprecate the core in the continuation package you released for 23.5? It wasn't bundled with that one (and I don't think it was missed either )

The AES cockpit is adorable, and exactly the thing I was looking for to replace the probe core with a live kerbal in an ion glider: Flies like a charm. A slow charm, a relatively ugly charm, but a charm nonetheless. Stock ion engine, lifts off slightly below 40 m/s with NEAR (and barely makes 45 m/s peak speed).

I've started playing around with this, and I had a very odd thing happen using the LFO VTOL engines set up using the tri-connector thingamajing (central structure with cargo hub and LFO tanks, external structure with 4x LFO VTOL engines) - the engines on the right side had their fuel supply depleted within a few seconds, while the left side engines and central tanks were untouched - as if there were fuel connectors from left to right. On an unrelated note, your sig doesn't list this mod at all I second the person who said there needed to be a sort of index of all your awesome mods somewhere

Just a thought from a simple user - a closed license also means that the moment the author moves on to other things, or focuses on other parts of his life, the vision he so much desired to protect with a restrictive license also dies. I cannot express how indebted I am to the modders for expanding KSP to make, out of a decent thing, a great one. I share very little back, but possibly a tiny bit of feedback, and mostly silent appreciation. At the same time, a closed license acts as a reminder that the mod it contains is not shared, it is lent. And that's perfectly fine, I am not entitled to anything. But the distinction is worth making. For us users, getting over-reliant on mods that are lent is a road to disappointment and resentment. It shouldn't, but that's human nature. I sometimes do minor part tweaks for my own convenience - extremely simple changes that are within my grasp, cloning parts and retexturing, adding other modules to .cfg. Extremely derivative stuff for my own use. The thing is, even if suddenly something were worth sharing back, a closed license would provide a barrier to entry that I would probably not seek to overcome. Wikipedia kinda trundles on after nearly a decade and a half because the barrier to entry for contributing and expanding on other people's work is extremely low (and it also comes with its own share of problems). All closed license alternatives haven't ever thrived. TLDR: mod authors owe us nothing. However, if the prospect of becoming the giant on whose shoulders others are standing is appealing, I urge those of you modders who are thinking of restricting your licenses further, in part because of this thread, to reconsider. There will always be a few obnoxious types around who will tend to ruin everyone else's experience, but just because they PM you won't make them less obnoxious, only, perhaps, more courteous until the moment you tell them no.

I played around with 0.1 a couple of weeks back (already under 0.24.x) and even in that state, it was a blast. Looking forward to test the new version. Tiny consistency thing: This thread is called Asteroidal Resources, your sig calls the mod Asteroidal Cities (which could also cause confusion with Klockheed Martian's Asteroid Cities). In the Karbonite release thread, you mention "Resources" in reply to a query from an user.

I've been using Kethane for a good month and love it. One thing I've noted that's missing since at least 0.4.3: the 2m converter tends to fall off very easily. Looking at the part.cfg, I noticed that there's two parameters missing, breakingForce and breakingTorque. The default values for these are apparently really low. For reference, they're set at 50 on the medium converter, and 200 seems a typical value for 2.5m parts.

Yep, and that's how I do it, but I was thinking of both automating the process end-to-end and having the output add the PART{} wrapper in my stead Love the tool BTW.

Well, one possibility could be to prompt for the GameData folder when saving and simply store everything in there under GameData\Partgen\Parts\(subfolder based on tool selection). Or (your time permitting), adding an option to replace GameData in this example with a user-defined folder. It's just convenience of course.

What happens when more than one add-on makers post bundles using the same plugin? In particular, in the following scenario: Add-on X ships with plugin x.dll (under Gamedata\X\Plugins\x.dll). Author of X later updates the plugin but the player doesn't notice or update. Player then downloads add-on Y, which relies on the plugin from X, and bundles it with the latest version of the plugin. The game now has: x.dll v1 under Gamedata\X\Plugins\x.dll x.dll v2 under Gamedata\Y\Plugins\x.dll How does KSP load the plugin(s) under that version? What happens when parts from either invoke properties that are defined differently in each version? And what is the recommended best practice for curating the plugins folders? Should both X and Y bundle as above, or should Y bundle x.dll under a X hierarchy, even if nothing else from X is present than the plugin?

In your steam library, right-click Kerbal Space Program, click properties in the pop-up menu, and on the updates tab, set automatic updates to "do not automatically update this game". Problem solved