Majiir

The plugin uses very little; just a few megabytes. The rest is part textures, which take up about as much memory as the Kethane folder takes on disk. If there are Kethane parts you never use, you can selectively remove them.

See this thread: http://forum.kerbalspaceprogram.com/threads/47150-ISA-MapSat-Legacy-discussion

I'd like to see the ModuleGenerator Update/FixedUpdate issue fixed by 0.28.

Scan data is unaffected by the debugger. The cells already scanned will update to reflect the new deposit locations. The debugger isn't meant to be part of normal gameplay, so it's okay if it's a little cheaty. I make extensive use of it during development, and I'm sure it's handy when you just want to tinker.

The debug functions have changed in 0.8. It's a little less user-friendly, but it's functionally an improvement. There are now buttons for "Reset [body] Data" and "Reset Generator Config". The first is what you want if you're interested in moving deposits because unlike older versions, this will only regenerate deposits on the named celestial body. It also only regenerates deposits for the currently selected resource, so for example, you could regenerate Kethane on the Mun without affecting Kethane anywhere else and without affecting Ore on the Mun. The second button replaces the generator config in your persistence file with the default configuration for the selected resource. This isn't really useful at the moment, but it could come in handy with multiple resource generators. It has the side effect of resetting body data for every body, so you can use this to quickly refresh all your deposits everywhere. (It will still only reset data for the current resource, however.) There's no more "generate here" or "refill deposit" options because they don't scale well to other types of resource generators, but I might implement generator-specific debug functions at some point. [EDIT] It's worth noting that if you change the KethaneResource generator configuration, you won't see the changes reflected in existing persistence files until you use Reset Generator Config. This is because the generator configuration is loaded from the persistence file, and the configuration in KethaneResource is only used to initialize new saves.

I'm not sure why you think an EL config file is a bug in Kethane. In any case, EL has been updated for 0.22 and Kethane 0.8.

Whoops. It looks like Keptin changed the animation names without telling me. Open the part config (GameData/Kethane/Parts/kethane_heavyDrill/part.cfg) and find these lines: MODULE { name = KethaneDrillAnimator DeployAnimation = heavyDrill_deploy DrillAnimation = heavyDrill_drilling } Change the animation names so it looks like this: MODULE { name = KethaneDrillAnimator DeployAnimation = idle DrillAnimation = idle0 } I'll have this patched in the next update, but I want to wait a bit before pushing out a hotfix.

Please see the new KAS thread here: http://forum.kerbalspaceprogram.com/threads/53134-Kerbal-Attachment-System

KAS 0.4.4 has been released. The download on Spaceport (link in the first post) has been updated. This is a compatibility update for KSP 0.22. KAS does not yet integrate with the new Research and Development system. Changes in this version: The container editor will only show parts that have been unlocked when in career mode.

Outdated - New Thread Here Kerbal Attachment System (KAS) Download Kerbal Attachment System 0.4.7 Last updated April 1, 2014 (KSP 0.23.5) (release notes) License - Source code ------------------------------------------------------------------------- KAS is maintained and distributed from this thread during KospY's extended absence. The original thread can be found here. ------------------------------------------------------------------------- This mod introduce new gameplay mechanics by adding winches, hooks (magnet/grappling hook/anchor), containers, grabbable & attachable parts and constructable struts and pipes. It gives some purpose to EVA and can be used for many things: Resource transfer (winches or pipes) Towing parts (winches) Adding/removing parts on a vessel (grabbable & attachable parts) Storing parts (containers) Base/vessel interconnections (pipes) Vessel consolidation (struts & pipes) Grabbing parts (magnet) Cranes (winches) Airship anchoring (winches) Skycranes (winches) Elevators (winches) ...and more ------------------------------------------------------------------------- Useful Links KAS Wiki - See the wiki for frequently asked questions, version history, part details and more. Default keyboard shortcuts Issue tracker ------------------------------------------------------------------------- Authors KospY: Plugin development and the ugly models (hook support, grapple, anchor) Winn75: Models and textures (connector, ports, winches and magnet) zzz: Models and textures (containers, bays, strut, pipe and pylon) Majiir: Plugin maintenance a.g.: Plugin contributions

Kethane 0.8 has been released. The download link on the first post has been updated. This update includes an art pass, an improved map overlay and major architectural changes. This update is only compatible with versions 0.6 through 0.7.7. Important notes: This update doesn't integrate with the Research and Development system added in KSP 0.22. R&D integration will come in a later update. The KE-TM30 (1.25-meter tank) and KE-X130 (radial drill) art assets have been upgraded. Craft files from previous versions will still load the old models, but textures will be missing. The old textures may optionally be installed from the previous version. Note that the new KE-X130 drill is significantly shorter. The new deposit generator architecture has been added, but the API is not yet public and no new generators have been added. These are still works in progress and will be released with a later update. The architecture changes will perform a save format upgrade. If you're particularly attached to your deposit and scan data, make a backup of your persistence file before upgrading. The file server may still be the subject of false positives from antivirus software. I recommend temporarily disabling your AV software and manually scanning the download if you're concerned about safety. It's a good idea to erase any old versions of Kethane before installing the new one. User data is stored in persistence files so it's safe to perform a clean installation. Changes in this version: The grid overlay now conforms to terrain. Created an extensible deposit generator architecture. Added new parts with updated art assets for the KE-TM30 and KE-X130. The old parts will still load but their textures have been removed to save memory and they aren't accessible in the editor. Updated art assets for the KE-X270. Added a scanning tutorial. Open it from the Training menu. Converter info text is now more compact. Reverted an accidental change to the KE-C090 oxidizer conversion rate. KethaneConverter supports optional input and output resources. Added an AlwaysActive flag to KethaneConverter. Added an API to KethaneConverter exposing resource conversion activity. Embedded the geodesic grid shader into the plugin as an assembly resource. Fixed an issue where parts using KethaneDetectorAnimatorUnity would deploy in the ship editor. I realize this update delivers a bit less than expected. There are some exciting things still in the pipeline, so stay tuned.

Erm, no, you won't. Kethane stores data in the persistence file now. Just use the debugger. (Add "Debug = True" to GameData/Kethane/settings.cfg.)

Have you patched your KSP executable to account for the PNG issues on Linux? Kethane uses some PNG textures, in particular for particle effects. The grid appears in the tracking station and flight view, and it's the same grid (i.e. it shows you what you've scanned).

They only detect Kethane as of 0.7.7.

Yep. Maybe earlier. It won't have everything I originally planned for 0.8, but the improved grid is really nice and it might have other goodies you'll like.

That wouldn't do anything from a technical standpoint. For eliminating timewarp scaling, the simulation is difficult no matter how you expose it in gameplay. For electrical simulation, you could pretend the "server" part is somehow taking over all the electrical responsibilities of the individual satellites, but that would feel really weird.

There are two separate issues here. Tracking satellites that aren't currently controlled is easy. However, since vessels aren't simulated unless they're in physics range, flow of resources (including electric charge) isn't simulated. The scanning system would have to simulate electrical generation, capacity and consumption, and there are a number of ways this could break. Allowing high-resolution scanning at high timewarp levels is mathematically and computationally difficult. Leaving a ship in orbit and then back-calculating what cells it's passed over is not a trivial task. We had a long discussion about this on IRC, and the phrase "harder than n-body" was uttered near the end. Leaving logarithmic timewarp attenuation in place makes things significantly easier, but it leaves us with that "gaps" problem. I'll be tweaking a few scan numbers for 0.8, but improving the underlying mechanics isn't as easy as everyone seems to think. (Not without making some serious compromises in other areas, anyway.)

Hang on just a minute. There's a whole lot about the PQS system that's accessible in public members. I was explaining the other day why planet mods don't exist, and when I got to explaining that some parts were private members and locked down, someone asked "like what?" I have to admit I didn't have an answer. I've played around with the PQS meshes before, although I haven't gone and actually changed the terrain generation parameters. If we're going to have a discussion on planet modding, let's establish exactly what we aren't able to do.

First off: I'm really impressed by the KAS 0.4 release. Stability issues aside, the new winch system is a lot cleaner, and pipes and part containers bring about a whole new paradigm of KSP gameplay. It's a bit like bringing the VAB to the flight view. A few notes about this! My highest priority for KAS maintenance is keeping it compatible with new KSP releases. Since KSP 0.22 is nearing arrival, the next KAS update may be synchronized with that release. (If there are major bugs in 0.4.2, I may release a hotfix before then.) My second priority is ironing out as many bugs as possible. KAS 0.4 introduced a lot of new features, so there's a lot to test and I'll be relying on your feedback. To make that go smoothly, please follow the KAS bug reporting guidelines, including using the Github issue tracker. (If you've followed Kethane development, this will look very familiar!) This makes it much easier to diagnose and resolve issues. KospY isn't disappearing completely. He'll still be guiding the development of KAS, and I'll be consulting with him on major decision points. I don't currently have plans to develop new features, but that may change in the coming months. I have no prior exposure to the KAS codebase, which is actually quite a bit larger than Kethane's. It will take some time to get acquainted, so I appreciate everyone's patience. Cheers, Majiir

Deposit quantities are random in the range 10K-500K. That was just a proposal. Those changes haven't yet been implemented.

Will the reputation "bar" thresholds be adjusted to be in line with the new level titles?

That is an interesting question. I don't think it would violate the license of the textures as long as you're not blatantly copying the visual appearance. However, it might violate the license of the 3D model, since the texture is by necessity a derivative of the model and its UV coordinates. There might be an extraordinarily clever way around that (automatic inference of UV maps?) but I don't know of any. Oh, don't be such a drama queen. If you love your users: I grant PolecatEZ permission to distribute a texture reduction pack containing derivatives of Kethane part textures. The pack may reduce the visual fidelity of parts but may not otherwise change their appearance. The pack may be released under no-derivatives terms.

I think you're overestimating the reactions of content creators. For example, Kethane is a mostly closed license in terms of derivatives, but it does allow you to create your own mods that leverage Kethane code. There's a project in the works that wants to use Kethane to replace Kethane. Am I getting mad and changing my license to stop them? No, because I knew what I was getting myself into when I added that clause. I think a few of your items miss the mark, and as someone publishing under a restrictive license, I find all of my concerns missing from your second set of lists. The choice of a mod's license doesn't impact anyone's ability to learn or start modding. Source code must accompany mods on the KSP network, and it's generally accepted that modifications for personal use are allowed; some licenses, like Kethane's, even explicitly allow it. Even if one mod's license choice did prevent someone from learning, there are a large number of mods licensed permissively. Your list assumes it's a binary choice where every mod goes one way or the other. Even then, if every mod were restrictively licensed, nothing stops an aspiring modder from reading the resources available in Addon Development or reading source code from successful mods. Open licensing doesn't provide any guarantee that people will actually use your work. (It could simply be unpopular.) It also doesn't necessarily increase quality; Kethane was restrictively licensed precisely for quality purposes. It's developed slowly as a result, but it's undeniably a high-quality mod. If Kethane were openly licensed, it'd have become bloated with lower-quality content that nobody wants to remove for fear of hurting someone's feelings. (I'm guessing on the feelings part, but I have seen content built for Kethane that I decided not to include.) Monetizing mods isn't really on the table. Spaceport was built for selling content (just take a look around the site and legal agreements) and modders overwhelmingly resist that idea. I'm not sure why you think "extensive resources" are required to enforce mod licenses. In Kethane's history, I've had to deal with fewer than ten license violations, and usually I just IM a link to the offending thread to a forum moderator. You can ask the forum staff if they find licensing to be a big drain, and I suspect they'll say policing threads like this one takes far more work than policing the actual mods. Here's why Kethane is restrictively licensed: The art assets were restrictively licensed from the get-go, and the new modeler who joined the project also wanted his works protected. You'd have to ask them why, but at the very least I'm bound to respect their wishes. I'm simply a user of their work. For a time, technical support for Kethane was a part-time job. I've been able to reduce that load through a combination of control over the codebase (restrictive license), some unusual preventative measures (incorrect install detector) and lots of bugfixing iterations (the current version is 0.7.7). There was a brief experiment where I authorized the release of a single Kethane fork, after I personally reviewed the code, and even then it was a complete disaster. Shortly after taking over the project, I made it a goal to make Kethane among the highest-quality mods available. I already had access to some of the best part assets of the time, and I could tackle the code. Open licensing is great for high-quality security software; it's not so great for game mods. I derive very little real-world value from working on Kethane. The best I can do is track download counts over time, and this is exactly why I don't allow redistribution. There are drawbacks, like slower development cycles and a lot more personal responsibility for the mod. I don't have a team of people willing to contribute patches. I choose the license terms with all of this in mind. There's really no "modding elite" in KSP. Take a look at the most popular mod threads and you have a few candidates, but among the top four, two were created by people who were/are developers at Squad, and the other two actively work to better the modding community with documentation, community building, lobbying for policy changes, et cetera. There's little standardization among KSP mods because there's just not much to standardize. The best example I can think of is the folder structure of mod downloads; you'll find some have GameData/ in the root, and others simply have the mod folder; a few bad apples will have {modname}/GameData/{modname}, which can cause quite a few problems! We've had discussions in modding channels about the best approach, and I'm personally happy it seems many have settled on the first approach. This is a decision that affects users and the choice isn't arbitrary, so it's a good candidate for standardization. There just aren't many similar opportunities. I'm interested to hear where you think the "modding elite" are resistant to standardization, and just who those elite are. There's also the problem of KSP shifting underneath us. (Note: I'm not complaining about that shifting, I love it. We're happy to patch our mods every update.) It can be harmful to settle on some kind of standard if the technique becomes obsolete in just a few months. Again, I'd have to ask just what should be standardized. PolecatEZ, you mentioned "minimal quality standards" but that sounds extraordinarily elitist. I prefer to lead by example when it comes to mod quality.

Hi there, Nice looking mod! This saves us from building unwieldy lighting mounts. However, I want to bring a few issues to your attention: Addons posted to the KSP network must be accompanied by a license. See my license selection guide for help. This mod violates the KAS license. You are allowed to distribute parts using KASModuleGrab, but use of KASModuleWinch is restricted. Additionally, your part references a KAS model, which is forbidden by the license. This isn't a takedown notice (KospY is the owner of KAS) but you should be aware that the forum moderators often enforce licenses proactively, and your mod could be removed. I advise you contact KospY, show him your part and ask if you can have permission to distribute it. Cheers, Majiir

"Inform me that you're doing it yourself" is precisely what happened in your situation. There's no problem with licensing practices here. Nobody is preventing you from doing anything; they're just asking. You sound butthurt over "unwritten rules" but those have nothing whatsoever to do with how mods can be licensed. As things are now, mods released under GPL at least made the conscious choice to allow derivatives. Shoehorning mods into GPL when they'd prefer a more restrictive license will create an explosion of "unwritten rules" on who should be allowed to distribute certain works.