Majiir

Realistic or not, Gilly has always had deposits in order to guarantee legacy support. The feature I'm showing off here is the grid conforming to the shape of the moon. Currently, Gilly just has a big sphere around it, and it looks terrible. [EDIT] Here's a shot of Minmus: http://i1.minus.com/i7bbJE0DHb7Ab.png

I'm not sure what you're experiencing with warp, but it could be insufficient capacity somewhere. Everything should behave the same as long as none of the individual timestep quantities exceed the capacity of an individual container. On an unrelated note, this could be useful to some:

I don't understand what you mean by cells... are you saying we'd need a large array? Yes, but likely smaller than the one required to store a texture. At this point, I don't think memory consumption is really the greatest concern, but I think it's worth mentioning what techniques exist for milking the most out of the memory we have because it opens up other possibilities. Each character actually contains data for six cells. Each grid cell has a unique index, so the scan flags are concatenated as 10,242 bits which are then Base64-encoded. My local copy uses Deflate compression to make the whole thing even smaller on disk. They're not compressed in main memory, but the entire solar system of scan masks only uses about 21 kilobytes in RAM. If I manage to get my new geodesic code working, I'll probably want to crank up the resolution to the point where partial loading will be necessary. With Kethane, I decided to be incredibly careful with what I store, and that affords me a lot of flexibility in how much of it I store. All the data on every planet remains in memory at all times because it all adds up to just a couple megabytes.

What? No, you need exactly one. C# has true multidimensional arrays (not jagged like Java) and even if it didn't (e.g. BitArray is one-dimensional) you can fake it by multiplying one coordinate by the length of the prior dimensions.

Haven't you heard of arrays (or other collections)? I don't like rectangular map formats, but if that's what you want, a rectangular array is all you need. If you're storing booleans, be sure to use something like BitArray (you'll have to add the second dimension manually) and not bool[,]. I didn't miss anything. It's a good find, and reinforces that textures should be used sparingly.

This is a long-term planned feature. I haven't done any investigation into how it might be implemented.

In the interest of keeping this thread open, let's just cool down a bit. Using textures to store any kind of data that isn't actually an image is a bad idea if you're worried about memory consumption. (I'll skip over all the ways it reduces code quality, et cetera.) At runtime, you need to have a texture that renders a map onto the screen (if you're making a 2D display), but this is completely different data than what you generate when you actually perform a scan. When you scan an area, fundamentally you're saying "I've been here, so I want access to that elevation data later" regardless of whether that's what you actually do in memory. If you need to store that elevation data (e.g. for performance reasons) you can do that, but don't store it as a texture, because a texture stores colors, not elevations. CPUs are really, really fast, and converting elevations to colors won't impact performance. Even if you don't use any kind of compression, you're making a savings of at least a factor of 24 in memory.

Please just download the latest version so I won't have to deal with your bug reports in a week. I don't put the updates out for giggles; they have important fixes. Updating from 0.7.5 to 0.7.7 is an easy affair; you won't lose any data. That's a good one. /s Planning for stock resources has never ended well. Kethane will continue as normal, albeit without the fervor of development that brought the rapid 0.5 through 0.7 releases. Just to be clear, I didn't implement multiple-resources support in 0.6 just for fun; the plan is to expand the Kethane mod so it has a full-blown resource tree. My vision is rather different than what the KSP developers have shown so far (which I frankly find boring). Consider the UI and all the versatility I've built into it, and I think Kethane will remain relevant for a long time.

No news except that designing resource generators is hard. I've been busy with other things for the last couple weeks and will remain busy until this weekend at least. Prior to that, I'd done a bit of work on completely replacing the geodesic grid code. This will only have a minor impact on Kethane, but it will pave the way for radically different features in the future and also other mods (e.g. ISA replacement). Keptin's also been busy again, but he's already completed a lot of work on the art pass, which should be ready for the next release as well. As far as 0.8 is concerned, a lot of the work on deposit generators was actually already done as of the 0.7.5 release, but the relevant changes haven't yet been packaged into a public release.

I promise you're not some kind of conceptual savant. This is a fairly common suggestion. There are mods out there (e.g. Telemachus) that put some kind of information and/or control into a second window, but I don't know if any provide full mapping capabilities. If you're really into this idea, I'd look at similar projects and see if extending one of them is viable.

First off, a few of you are being jerks and/or completely unhelpful. He asked specific questions. "Just learn C# and everything will come to you" is a terrible answer because it's both unhelpful and completely false. There are several entry points for plugin code. You can extend Part or PartModule, which is useful if you're making a part with behavior; you can extend MonoBehaviour and attach a [KSPAddon] attribute, which allows your code to start on a certain scene; and you can extend ScenarioModule, which starts your code at configured scenes but also holds data in the persistence file. Not at all. Despite the names, these two languages are rather different. C# is more similar to Java at the core, although some of the more advanced features of C# are reminiscent of C++.

All recent issues reported in this thread should be solvable by updating to the latest version of Kethane.

It's a common misconception that timewarp is "the" problem with multiplayer. It's not. I don't know why people just love to moan about how timewarp is this huge intractable problem, but they should really stop. I've often said that positional synchronization is a larger challenge, but judging from the video it at least looks like you've solved that issue better than those who've come before you (i.e. khyperia with his Kestrel project). I'm not sure what to say about state synchronization (e.g. for partmodules). I think it's possible, but you've got to get everything just right. That said, I suspect many mods would function just fine under any framework that also synchronizes stock behavior. (Mods that store data manually won't work, but that's an outdated method anyway.)

They can't use the work directly because I own the Kethane copyright. (They could, of course, ask for permission.) To answer your original question, the line gets drawn at the packaging step. Take KSPX, for example; it started as a mod, but some of those parts are now packaged with stock (with the author's permission). Whatever the user gets when they download the game is stock regardless of where the content was originally released.

For now, you're meant to run out. I'm not necessarily against regeneration schemes, but I think if you mine Minmus dry, it's about time you started mining somewhere else. Add "Debug=True" to the Kethane settings.cfg file and start the game. The Kethane window in the map view will have options for regenerating deposits. (These will be getting a makeover in 0.8, but for now they just regenerate all the deposits for all resources at every planet.) ...then maybe you shouldn't accuse a mod developer of deliberately distributing malware.

You'll have to talk to Avast (or possibly your ISP) about that. Kethane's source is available, and you're welcome to verify that the packaged DLL is built from the same source. Kethane code doesn't do anything even remotely suspicious. Make sure you're running the latest version of Kethane; this sounds a lot like an issue that was fixed recently.

I wrote up some notes last night on a rewrite of the grid code. I've worked out some of the cell enumeration algorithms, but I've not yet tackled indexing. If someone wants to write code, they could come up with a few coloring routines, but I think it's a bit early to be writing much code.

Glad to hear it!

Yeah, this is what I had in mind with the recursively subdivided geodesic. I'll need to modify the grid code to at least support translation between different subdivision levels, and I might even need to come up with a completely new coordinate system. I don't really think the PQS queries will be a problem. If anything, I'd defer queries until the data is actually needed rather than preemptively querying.

I'm still not sure what you're confused about. You can write your own part configs, but you cannot use mine. This isn't contradictory, and it's all spelled out in the license. What is less clear is that sometimes copy/pasting from the packaged configs is acceptable because it's indistinguishable from creating your own work; how am I going to know if there's only one value in the config that can even change? That said, it'll be really obvious if you create a particle emitter that has all the same values as mine that you copied it. Still, the letter of the license is clear. I wouldn't have an abandonment clause re-license the mod because it's essentially unrecoverable at that point. I might accept a clause that allows me to re-license any user-distributed modifications, but it's honestly not high on my priorities list.

The license permits you to use (by reference) portions of the Kethane plugin, and it disallows modification of the plugin or use of any other assets. I'm still not sure what's causing confusion here. (I'm happy to clarify the license, but I'd like to understand what the issue is.) If you're making a custom detector part and copy/paste a KethaneDetector config node from one of the packaged parts, that's not a problem; there's really no intellectual property in that config. If you copy/paste an entire part config (e.g. for a rescale) or copy/paste a particle emitter config (which arguably contains some creative content) that's getting into iffy territory. What's an example of something you're concerned the license allows in one place but disallows in another? I've considered an abandonment clause, but it's not a simple thing. I'm not sure who I'd transfer the project to if not the general public, and I'm not sure what conditions would be best. There's also the part where if I'm in a coma, what happens to my KSP mod is the least of my worries. (Maybe everyone will pitch in for my medical expenses so I can return..?) Yes; the fix is now built-in. I'm not a big fan of it. The parts were designed for specific sizes. Like anything, you can rescale parts for your own use, but I'm probably not going to grant an exemption for a rescale pack.

Kethane's license is fantastic for rookie modders who are interested in actually creating something. Suppose you have a cool idea for a mod that allows you to collect and process resources, but you have no idea how to code plugins and only basic modeling skills. You whip up a few models quickly, add Kethane modules to the part configs, and suddenly your parts are powered with the full weight of the Kethane plugin. You might be the worst modeler out there, but you could still come up with a great idea, and it's incredibly easy to get up and running since you can make use of the Kethane code without ever having to worry about the programming yourself. People can get interested in your mod, and pretty soon you've got more talented artists lining up to help you. I'd argue that in this respect, Kethane is more friendly to other modders than any other mod out there. (What other mods actually provide a third-party API? Hell, my license doesn't even ask for attribution!) Technically yes, but if you retexture some parts for yourself and want to share a rocket design, go right ahead. Remember that the license is only enforced if I specifically ask for something to be removed. This sort of thing only gets activated if someone starts acting like a real jerk and posts a thread showing retextures along with step-by-step instructions on how to accomplish the same retexture.

No, it's a good observation about the KSP community. It's in vogue to complain that unlicensed, out-of-date mods can't be forked and then insist on mandatory abandonment terms, a common license, or some equally silly measure. The truth is that unlicensed mods already violate the addon posting rules for the KSP network, so more rules won't really change anything, and it's ultimately the creator's fault if their mod ends up unlicensed and abandoned. I am always willing to have a healthy discussion about the Kethane license, but be aware that I've put a lot of thought into this. Also be aware that I've been steadily making the license more open, but this is largely because it's become more specific; the most dramatic change came with version 0.6 when I opened up the Kethane module API for use. (Previously, you couldn't make something like a custom converter without my permission; now, if you want to make your own part that uses my module code, I can't stop you.) Lastly, be aware that I'm a nice guy and I do grant exceptions, but there are certain cases that the license was specifically crafted to forbid. (Retexturing a part and releasing it as another pack is one of these cases.) Skykooler's Extraplanetary Launchpads started with an exemption to the Kethane license. Others have contacted me about building third-party mods, and I've told them I'll be happy to grant them exemptions since they're doing things that don't necessarily fit within the license. Fundamentally, I'm happy for people to use my work if it helps them to create their own work, as in Extraplanetary Launchpads. (That mod really is skykooler's brainchild, and the fact that it uses Kethane is a technical detail.) Reskinning a part, on the other hand, isn't creating anything new; it's lazily reusing someone else's work.

A few things on licensing: When I took over the Kethane project, the copyrights were transferred to me, not licensed. That said, if Dani-Sang were to release updated versions of the parts, he'd own those copyrightsâ€â€and frankly, it doesn't much matter, because Dani-Sang and I have very similar ideas about how assets should be used. (The current Kethane license was designed around the original MMI license.) Keptin retains the copyrights for his works, and he's allowed me to use them. That said, we've discussed licensing and he's in agreement with the current terms. You're certainly free to ask him for an exemption, but don't be surprised if he just directs you to me. [EDIT] To elaborate on this: I don't own the copyrights, but I've been authorized (by Keptin) to use and relicense those assets, which is exactly what I've done in the case of Kethane. The license allows you to play the mod, share media of the mod in action, and modify it for personal use, but that's all it grants for these assets. So, if you wanted to retexture Kethane parts for fun, go ahead; that's allowed under my license, which has been allowed by Keptin; but you cannot distribute those retextured parts, and you cannot distribute derivative works thereof (e.g. screenshots and videos). Either Keptin or I can allow use of those assets; in practice, the only rights you're granted come from the Kethane license. What parts of the Kethane license are contradictory? It's fairly clear that the license enumerates rights that are granted and then declares all other rights as reserved; the "you may not" list is provided for clarity. The license can be summarized in simple terms thusly: Kethane has an API that you may use, and you can share changes to source code since that's useful for submitting patches, but you can't use the mod in other ways and you can't reupload it somewhere. I've written at length (several times) on the reasoning behind the Kethane license. I realize it's unconventional, but Kethane also isn't an ordinary mod. Search through this thread and my Reddit history (be prepared for lots of k-pop) if you're interested. In the case of part assets, one of the reasons modification and use is disallowed is because they're high-quality parts meant to be used in a high-quality mod. Maintaining and building upon that standard of quality is important to everyone involved in the Kethane project. You may not agree with our philosophy, and you're free to produce your own high-quality parts and license them however you like.

You can make your own parts as allowed by the Kethane license; for example, you can create your own scanner that uses the KethaneDetector module. You cannot use the Kethane models for such a part, and you can't release modified configs of parts that come with Kethane. If you're making a scanner that works with Extraplanetary Launchpads, you don't need to define a KethaneResource; just add the KethaneDetector module to your part config. I'd be happy to "proofread" your mod if you're concerned about the license. I wouldn't worry about it; it sounds like what you're doing is well within what the license allows.