Majiir

Not in the case of the KSP community. I know because I've accidentally released DLLs which don't match the public source code, and nobody complained. I suppose someone might've complained if the discrepancy was malicious, but I find it far more likely nobody compares the compiled assemblies with source. It's nice that the build-it-yourself option is there for the truly paranoid, but let's not get distracted with the security excuse.

Yes. This should be standard procedure. I was referring to a mandatory set of licensing terms. I'd also consider a scheme where new unlicensed mods get "automatically" licensed to be in poor form and possibly downright illegal. An option with a convenient default has its own problems, which I'll detail in my answer to KasperVld's question. Threads variously pop up here or in The Forum Forum (like this one). Squad have gone on record saying they do not lay claim to the intellectual property of mods and don't consider them to be derivative works. Many games have modding ecosystems where it's common to reference or copy elements from the base game, but this is rare (or even illegal) in the case of KSP. I agree with it because this is effectively the situation anyway (unlicensed mods are under full copyright). However, I think enforcement is a touchy subject, and you (the forum mods) ought to be very careful about what policies you choose in implementing this rule. Faark asked what I'd have against a dropdown with a set of license choices. My main concern is this: licenses are permanent, so mod developers should not be pushed into a decision. If you have a dropdown with a license selected by default, that's a problem. If you make a list (like my stickied thread) of licenses and one's at the top, that's a problem. That's precisely why I put "All Rights Reserved" first; I wanted any lazy reader to have the option to change their mind later if they want to make a more informed decision. I really, really, really didn't want to see someone license their mod under something like GPL only to regret it as soon as they understood what it's all about. That's exactly what happened with KospY (KAS), and it was only by a technicality that he was able to back out of it. Users can afford to wait a few weeks for the developer to choose (or write) the license they want, but if a developer hastily releases a mod with a license they're not happy with or don't fully understand, that's irrevocable. Just nitpicking: in general, we've misinterpreted what this means. Generally, screenshots or other similarly derivative media of a piece of software are considered to be property of whoever owns the software unless they explicitly license otherwise. All Rights Reserved doesn't grant you those rights so, for example, we're technically in violation by distributing screenshots of ISA Mapsat. This is really shaky because in the same way, we're not granted the right to actually play the mod, but... yeah, we all take that as an assumed privilege. I'm not arguing that we crack down on such cases, but I wanted to point out that even the simplest of terms can have complex consequences. If we're on that note, I disagree with the source code requirement on principle, although I do see clearly how it benefits the community.

The default license issue has been beaten to death in other threads. The current rule, if enforced, solves a lot of problems. It also creates a few. (e.g. KospY was given a scary notice that he had to pick a license, so he did so hastily without understanding the consequences and it seems the forum mod who gave him the notice didn't link him to any resources about choosing. Not a good practice.) Mods that go unlicensed and abandoned are often considered a problem of the community or Squad. They're not. Blame rests with the mod developer. I'm strongly against any kind of default licensing scheme, and at the very least Kethane will disappear from the KSP network if Squad decides to go down that roadâ€â€but every indication from Squad has been exactly the opposite, so I think we're in good hands.

Gene Kerman comes from the stock training missions. That screenshot is from the Kethane scanning tutorial (which as of a little while ago is finished). I may also get to mining and converting tutorials.

http://en.wikipedia.org/wiki/No-communication_theorem

Greys is right on with the reading comprehension. ModuleManager is licensed CC-BY-SA, so we can tweak it for our purposes. I'm mainly interested in the more internal config-replacing components. ModuleManager-like syntax could be very useful for specifying which pieces of a config need to be mapped to language keys, but for language strings themselves I suggest using a different format. Config nodes have issues with escaping values (and since this has been on their bugtracker for a long time, I don't imagine it'll be fixed any time soon).

I'll check it out on my Linux VM. It's still possible to work around if we're willing to lose culture-specific number formatting. Resource files are commonly used as asmi described, though there may be commonly used libraries. Let's start with the part where you completely misunderstood what I wrote. I was referring to natural language values in config files. For example, the KethaneWetMassIndicator module has a Label property which changes the info panel string from "Wet Mass" to whatever's specified. Extraplanetary Launchpads uses this because "wet mass" is an odd term to use for a container of rocket parts. Whenever a natural language string is in a config file, it'll need to be replaced. A whole lot can be done (with varying degrees of difficulty). Obviously we can't modify everything, but we can certainly tackle some important parts of the UI. This has a cascading effect in some cases: if I can't change how the UI displays resource names, then I can't translate "Kethane" into other languages without causing confusion. A few key spots in the UI can make a big difference. I agree. What I wrote was that resources should be shareable between components in the same mod, so e.g. I can translate "Kethane" once and use that string in both my plugin and part configs. Cross-mod references aren't a horrible thing if they're namespaced, but that seems like complexity with little benefit. Indeed. I'm eying ModuleManager as a good candidate for modification as a component of this system. Support for textures, sounds and binary files should be sufficient, and that can come in a more polished version. In a worst-case scenario, those assets can be swapped out directly in GameDatabase.

Translations will be manual. (I am taking a course in computational linguistics, but I'm not that good. Machine translation is hard.) Egh, I think this is a crappy excuse. Squad doesn't have to actually perform any translations because the community can create language packs. The issue is that Squad has shown no interest in adding even primitive support for localization. Repeating what I said in my first post, getting text translated is the easy part; having a way to get that text into the game is hard, and it's what requires our attention. Only a small handful of things (like part descriptions) can be changed. I tried earlier today to build a system for localizing resource names (e.g. Kethane -> 케테ì¸) and found that it is possible, even if arduous, to replace some stringsâ€â€but EZGUI won't render other character sets. There's no easy way forward here, so we'll have to hack our way to language support.

Yes, and this may be useful for some plugins, but I argue it's not the best solution for a few reasons: Someone has to build the assemblies, and this substantially raises the barrier to entry for anyone who wants to provide localized content. (They could hand off their resources to someone else to build them, but that potentially introduces a bottleneck and it's a pain in the butt for everyone involved.) It only provides resources for plugins. This is acceptable for plugin-only mods, but if you also want to localize config files, you're now distributing multiple files in a language pack and distributing those resources in two different formats. Localized content can't be shared between plugins and config files, leading to duplicate entries (which is never good). Moreover, there are larger problems with KSP i18n than simply loading the strings. I welcome discussion here, but my inclination is to say resource files aren't the way to go. Here's loosely what I have in mind at this point, obviously subject to modification: Plugin API for retrieving localized content by key Config file syntax for injecting values by key, and a plugin to perform the injection Language files mapping keys to resource values The advantage here is that all localized content is in the same format, and that data can be shared between both mechanisms (and even a third if it becomes necessary). It's a little indirect, but that indirection is intentional and will prove helpful in some cases.

Internationalization is the process of making some software support multiple languages and cultures. Localization is making that software support one specific language. In this case, my main concern is internationalization so that localization becomes accessible to anyone.

I see no obvious culprit as long as you've defined Hydrogen somewhere. Note that HeatProduction=0 is unnecessary since there isn't actually a HeatSinkAnimator module on the part; you can just omit the config property.

No, because KSP is built for DX9 and thus doesn't support geometry shaders.

Not currently, but the new deposit generator architecture (coming in 0.8) supports that.

I've been thinking for a couple weeks about supporting internationalization (language packs and more) for mods. It's not an area in which I have much expertise, so I'd like to open this as a community project. I have a few goals in mind: Enable mods to support other languages and cultures. (Duh.) Whether you know it or not, your mod is probably used by a lot of people whose primary language is not English. Once I started looking, I was pleasantly surprised at how many international KSP communities use Kethane and discuss it in their native language. Put the fire under Squad to internationalize KSP. If mods can achieve this through the more restrictive KSP API, surely the game itself can do it too. In principle, large parts of the stock game can be internationalized like a mod, but some things are hard-coded. Get modders thinking about internationalization concerns. Some programmers are already thinking ahead, but many hardcode strings or turn off culture-specific number formatting without understanding or caring about the consequences. To those ends, I'd like to build a system for modders that abstracts away the difficulties of internationalization. Here are some problem areas: Natural language in config files. Part names and descriptions are clearly in this category, but there are also cases that can't as easily be handled like module-specific parameters. Modders will require a flexible system for replacing language strings in a variety of configuration files. Natural language in plugins. Some kind of API needs to be available for substituting language strings in plugins, which often generate graphical interfaces or other text. Selecting a language (and other user concerns). Users need to install language packs and select their language of choice with as little difficulty as possible. Since users are by definition people who can benefit from using a language other than English, it's critical that these processes be intuitively understood. Displaying alternate character sets. Not all parts of KSP support rendering characters for other languages, but in some cases we can build workarounds. This will involve a lot of diving into the UI and building replacements. Luckily, the same component (EZGUI) that seems to lack support for alternate characters is also easy to manipulate from plugin code. Internationalization of stock game systems. This is a more general description of the previous problem. The game and many of its components were not built with internationalization in mind, but support might be added by manipulating or replacing things like part modules, UI elements, et cetera. Translating language strings. In my opinion, this is the easy part. There are large number of multilingual players, and translation tasks can easily be distributed to many people and improved over time. I'll be working on this as time and other projects allow. In the meantime, I'm interested in your feedback on the above, your thoughts on how to proceed, and ultimately your participation in making this project a reality. Thanks!

Gene Kerman doesn't really look like me, but it'll have to do unless someone can build a better prefab:

KospY, in your new license, I think you may have misunderstood one clause in the original Kethane license. Under "YOU MAY" you have a section "Distribute KAS parts using the following part modules:" In the Kethane license, this part reads "Distribute non-Kethane parts using the following part modules:" The license is saying you can't take Kethane parts (like the compact scanner) and distribute configs for them, but you can make your own parts that use some Kethane code. It's designed to support the Kethane API. This is a common point of confusion in the Kethane license, so I should perhaps clarify this (and design the Kethane license to be used for other projects more easily). Dude, have some patience. I don't really understand your title, (if you want to make something, just go do it) but I can tell you as an addon dev that this sort of behavior is really obnoxious.

Erm... by this logic, humans can only count to 9. (Unless you know hexadecimal, in which case you can count all the way to F!) The biggest objection I have to this thread is the title (emphasis is mine): "there must be something ..." Why must there be? Why is consciousness special? Even if there is some fundamental component of nature dedicated to consciousness (and I think we have a large body of evidence suggesting the opposite) you're still wrong right off the bat for insisting without evidence that it must exist.

Realtime mesh manipulation is possible, but it would have to be done on the CPU because KSP is built for DX9 (which doesn't support geometry shaders). It may be possible to sidestep a lot of the performance issues by offloading the triangle/vertex computations and only assigning them on the main thread. To be clear, this isn't an easier method than particle effects, but it would look a whole lot better.

I experimented with this a while back (compressing immediately as they're loaded instead of at the main menu) and didn't find any textures compressed at all. Can you dump a list of textures that don't throw an exception, i.e. what kind of textures are loaded as readable? I still think the solution here (other than Squad fixing their system) is to write a custom .mbm loader, but if .png works then we might see a major shift in what mods use.

Make sure you're at 1x timewarp. KSP disables context menus at warp.

The Kethane license isn't very well-written. I just made it up, and I'm not a lawyer. That said, it works well enough for KSP purposes, and you're welcome to copy and modify it if you really want.

You can definitely release 0.4 under a different license, since you haven't yet released 0.4 under GPL. I think you can revert the GPL on 0.3.1, too, because you didn't actually include it in your source files as the GPL requires. (In other words, you didn't really license it under GPL yet so it doesn't have legal force, and I think the forum moderators will understand that you were pressured.)

I'm unlikely to be in Minneapolis any time soon. I'll redeem this if you ever come east. The grid distance is configurable, but it can't be too close because the grid polygons can clip into the surface. Since they follow the terrain surface now, the skin can be quite close, and I'll be tweaking those numbers. Before then, I want to do some performance profiling and test some optimization techniques. Currently, the terrain height is queried for every vertex (there are 61,452 of them) and the results aren't cached. I think I can reduce the query count by a factor of two or three, and caching the results would be fairly easy and use little memory. Still, as it is, there's not a noticeable delay when switching planets.

I wrote a short guide (link in my signature) on choosing a license if you haven't seen it. Since you've GPL'd your code, anyone can fork the current version, but since you are the copyright holder, you're allowed to violate your own GPL, so you could release your own version of KAS (with new features) under a more restrictive license. Just a fun fact in case you were feeling regretful. I can't promise much in the way of feature development since things are a little busy for me right now, but I can definitely work on fixes and other maintenance. [EDIT] I should mention that as with Kethane, I'm willing to do a bit of personnel management if that's desired. There are some good plugin developers out there, but it might help to have someone dedicated to organizing the project and managing code quality (be it me or someone else).

I strongly advise against moving mods out of the folder they were meant to be placed in. Some mods tolerate relocation, but many don't, especially those taking advantage of newer features of the KSP API.