Majiir

Geschosskopf is correct about how the engine works, but it doesn't only work on Eve. It works quite well on Kerbin, though it does prove challenging on Duna. (That hasn't stopped me from flying there, though!) Some careful mounting will let you place a stage behind a single centered engine. The Kethane engine doesn't work with high-altitude screamers, but it works great if you fly low or slow. (Take it for a test flight around KSC and you'll get a feel for how it behaves when you climb; right-click the engine to see intake performance.)

Icosahedral grids are extraordinarily well-suited to this. They start as an icosahedron, which is twelve vertices and twenty faces, and then those faces are subdivided until you get the desired level of detail. You can even subdivide some faces more than others. Level of detail is essentially built into the design of the grid. Currently, the Kethane grid code isn't well-suited to varying subdivisions, but I've been working on an indexing method that more closely represents the recursive nature of the grid. This means a mapping satellite would never scan the point directly below the spacecraft; instead, it would scan a point on the grid at the current level of detail. I doubt anyone would ever notice the difference, but it means you aren't generating a constant stream of potentially redundant data like ISA. Instead, you're constantly increasing the level of detail at areas around the planet, generating a grid that reflects those levels of detail, and then sampling terrain at those grid points. It's hard to see why such a system works elegantly for mapping if you've only played with the Kethane grid, which appears to be a set of discrete same-sized cells. A subdivided grid (of any sort) affords a lot of flexibility with level of detail. Perfect example: the KSP terrain system uses subdivided quads. The geodesic grid is just a subdividing grid that works well for evenly distributing data on a sphere. I wrote earlier that you should not jump to conclusions about how such a system would work just because some of the underlying code comes from Kethane. The details of Kethane scanning have little to do with the geodesic grid. The behavior of a mapping satellite can (and if I have my way, will) be very different. On gathering PQS data: I'd suggest caching terrain data (and storing which game version the data comes from so it can be invalidated on an update), but I wouldn't ship the mod with data. There's not much benefit to be had from that. A background task (even if on the same thread) can populate terrain data for cells that the plugin expects to eventually render.

Do me a favor and confirm this issue on the bugtracker: http://bugs.kerbalspaceprogram.com/issues/821

The system GavinSac proposes is similar to what I'd do. I'd probably increment a number (representing scanned detail, more on how this might work another time) instead of changing a flag, but it's the same idea. Simply updating information in a grid structure isn't very CPU or memory intensive; you could run dozens of background satellites without impacting performance. When you view a cell, you can query PQS and progressively update the view for a smooth experience.

I should probably chime in here. I've been thinking about a mapping replacement for a short while, and the geodesic grid code could definitely come in handyâ€â€although not necessarily the way you'd expect. Icosahedral grid cells are roughly evenly distributed around the surface of a sphere, so they're useful for data storage. In particular, icosahedral grids don't suffer distortion at the poles. Even if you end up rendering a 2D map, storing the data using a geodesic grid has advantages; on a rectangular map, polar data will look a little more stretched, which helps latitude perception. The grid can also be used to build a spherical mesh (smooth, not with individual hexagons) that can be textured without polar distortion. Alternatively, you could use a vertex shader and crank up the subdivisions. You can easily adjust the mesh to fit the shape of the planet this way. A hex-based approach with a detailed view could also work. A big advantage here is that you don't actually have to store as much data. You can just store a level of detail for each cell, and then sample terrain levels when you want to render a detailed view. Quick myth-busting: it's not impossible for a satellite to scan while unfocused. It doesn't happen automatically, but you can pretty easily code a way around it. (It definitely has absolutely nothing at all with Unity, where did you get that idea?) I urge people to avoid comparisons with Kethane's gameplay. The underlying technology is very flexible. (To the poster who doubted my code can handle levels of detail per hex, that sort of thing is trivial. You can store any data at a hex coordinate.) There's no reason a mapping mod that uses some Kethane code has to work the exact same way. The biggest limitation is actually PQS (the game's terrain system). It's computationally expensive to query for terrain details, so it's important to be careful with storing and caching that data. For reference, on my i7-3770 system, ten thousand altitude queries takes around 200 milliseconds, so you can only perform a few hundred queries per frame before you really kill performance. (Note: given the nature of the PQS system, it may be possible to perform these queries on another thread; I haven't investigated this at length.)

You shouldn't have to do anything dramatic when the new version hits. Deposits and scans will carry over. The new deposit generator will only be used for new save files unless you manually reset it, so the only things that might change are part balancing. Your craft designs might become suboptimal, but they'll still work. The restart-every-update thing ended with 0.4.4 (or was it 0.5?) when I moved the save data to a config node.

BobCat, I was unable to find a license for either of these packs. Could you select licenses and add them to the first post? Thanks!

Silvester, I was unable to find a license for your work. Could you select one and add it to the first post? Thanks!

StarVision, I was unable to find a license for this mod. Could you select one and add it to the first post? Thanks!

Hi Devo, could you add licensing information for your parts in the first post? Cheers!

hubbazoot, I was unable to find a license for this work. Could you please select one and add it to the first post?

The DN3D mod case you linked was considered a derivative work for rather specific reasons, among them that the mods referenced the game's art library and infringed upon the game's story. I don't think you can broadly apply these precedents to KSP mods. Your use of phrases like "especially given the lack of legal rights in this case" is inappropriate; until you bring me to court over it, it's absolutely reasonable for everyone to assume I have legal rights over my work. I get that you're frustrated with abandoned projects, but this has been discussed to death and we already have a solution that has yet to be implemented. Licensing (of any sort) is mandatory, yet many popular mods are still allowed on the network. It does no good to enforce the licensing rule only after mods have been long abandoned. If we want to make progress on the abandonment issue, unlicensed mods must be prevented from using the KSP network. There's no better time to start than right now. Most mods are released under permissive licenses. If too many are released that disallow derivative works, we can talk about that then, but as far as I know such mods are in the minority.

I wish people would have a little more confidence that I know what I'm doing. Nobody ever said anything about moving around mining for long periods of time to get small quantities. I said you may have to move around (which doesn't necessarily take a lot of time) in order to get very large quantities. At this point, none of the numbers are nailed down since I'm still working on how deposits are placed; scaling is the last step. Still, we're talking hundreds of tons being the threshold for requiring a bit of movement. The smallest of cells might have 40-50 tons with some cells in the 100+ range, and with a heavier drill that means potentially unlocking 400 or so tons from a single location, which is on par with current levelsâ€â€except that with the changes, moving over a few kilometers will let you do it again. To be perfectly honest, these numbers could probably use tweaking down. In any case, give it a playthrough (or at least read the numbers I've been giving) before you start making Minecraft comparisons.

I'm approaching these changes with the philosophy that it should be easy to get a little and hard to get a lot. There are a few ways this manifests under my working changes: More of a planet's cells will contain Kethane, so it's easier to find a deposit and start mining. Cells have individual resource levels, so a more complete scan is required to get a complete picture of deposit locations and quantities. (The current system can reveal the total quantity of every deposit with very few cells revealed.) Note that deposit locations will make a certain amount of sense, hopefully (because they'll sometimes follow terrain features). You can get a lot more Kethane by driving short distances (or taking short flights) than you ever could before... ...but you'll get less from just sitting still than you could before. You'll also get more with the heavy drill, which finally gives it a non-cosmetic purpose over the radial drill. I'm also looking to give logistics a purpose. Currently, you can drill about 300K units (600 tons) from a single deposit, but then the nearest deposit might be so far away that not even planes make sense for transport. I'd like to encourage short- to medium-distance transport logistics. Note that this doesn't necessarily discourage the all-in-one designs that are common today, but such a design would have to "hop" between areas to fill up. Refilling currently means turning everything on, timewarping, and turning everything off; you never do anything to extract Kethane. Now, I haven't got a solution yet that makes the actual extraction more interesting, but at least the whole process of gathering and processing fuel will involve some more thought and interaction. I want to emphasize you'll still be able to find a lot of Kethane; a deposit on the small side could easily contain 3,000-10,000 tons of fuel, and denser deposits could hold even more ridiculous quantities. Part of the problem with the current deposits is once you mine one dry, you have to go a very long way to get more; the new system will let you get more with a short drive. (Hell, you could even build a base at the point where three cells meet.) I don't think adding a few "honey pots" would actually improve anything. The way you described them, they'd be strictly superior to any other cell except for being harder to find. That just means more scanning, which doesn't do anything interesting on the extraction end. If anything, denser deposits should be hard to use (in difficult locations, for example) but rewarding.

Quick test of a freaky polar deposit generator: I did a bit of work making the simplex generator more flexible and configurable, and as a result it's completely unintuitive to configure. This is the config for that polar generator: Generator { name = SimplexResourceGenerator SimplexOctaves = 6 SimplexPersistence = 0.7 SimplexFrequency = 2.5 TerrainBivariate { B = -0.6 F = -2 } PreBlur { B = 0.7 C = -2 } BlurRounds = 1 BlurBias = 0.5 PostBlur { B = 1 C = 0.25 } DepositCutoff = 1 ConstantCutoff = 0 Final { B = 100000 C = 0 } } Changing a couple numbers just a little bit makes the generator behave very differently, so tweakers will definitely want to read the documentation when I write it up. It's not a particularly complex system, but there's a bit of work involved in translating an idea in your head into numbers that the generator can use. I don't plan to dramatically change scanning for 0.8, but I might tweak a few numbers.

What's a mod?

Depending on the nature of the patch, this can be considered a derivative work. A tool that upgrades part configs for 0.20+ by wrapping configs in a PART{} node isn't a derivative work, but other patches can be. This is incorrect. The Spaceport TOS grants Squad a lot of rights, but notably the intellectual property still belongs to the uploader. Squad does NOT have any legal ownership over mods. I'm not sure where this myth keeps coming from.

Note that the terms Greys quotes are from Spaceport and don't apply to mods hosted elsewhere. Neither the KSP TOS nor EULA mention addons.

File a full report on the Kethane issue tracker. Include your persistence (SFS) file and kethane.cfg file in addition to the debug file specified in the bug reporting guidelines. There's no easy way to do this with the current Kethane API. The 0.8 update will allow you to define your own deposit generators, so making a certain resource available everywhere will become possible. In the meantime, I recommend writing a plugin to get the job done.

I highly recommend not using mod managers. Unlike many other games, KSP mods don't need to overwrite any common set of files, so there are no conflicts to resolve. Installing KSP mods is easy and mod managers have a history of screwing things up. It's long been convention to package plugins such that the root of the zip archive gets merged with the game root. When 0.20 came out with the GameData feature, a lot of people switched to packaging their mods where the root of the zip goes into the GameData folder. This caused a lot of confusion because many players would try to unzip the contents of the GameData subfolder into the game root. The convention Kethane uses is the same as the old one: the root of the zip merges with the game root. It has the added benefit that it's blindingly obvious what you're supposed to do; it makes no sense to have a path like KSP/GameData/GameData/Kethane. If there's a GameData folder in the root of the zip, it's obvious that it needs to be merged with the GameData folder in the game root. Unfortunately, a large number of players seem to miss things that are blindingly obvious. (There's really no excuse.) I ended up adding a checker that warns the user at the main menu screen if they install Kethane in the wrong place, and this has dramatically cut down on support requests, but it seems that's still not enough. In short, it's not just personal preference, it's a damaging bad practice. Mods should package such that the zip root merges with the game root; this works for any mod, and it doesn't suffer any problems that other packaging schemes wouldn't. ...what? I really, really hope you aren't removing the Grid.cfg file.

ISA is unlicensed and the creator is inactive, so it cannot be updated. It'd be a good idea for someone to create a new mod to replace it.

These statements contradict. By releasing this under CC-BY-SA, you're allowing anyone to use your work, including for commercial purposes, as long as they give you credit and don't relicense it. If you want different terms for the configs and the models, you need to specifically give them different licenses.

It's well worth asking Ialdabaoth to implement things on his end. I asked him how to make Kethane work and he very quickly had a release out with support.

You'll be able to get more from one "deposit" (blob on the map) but less from one landing zone. In order to get large quantities, you'll need to move around a bit, but that movement is over much shorter distances than currently.

I'll explain the proposed changes in more detail. Currently, when you drill a deposit, you extract Kethane from the entire deposit as a single unit. It doesn't matter what hex you're in; as long as you're inside the deposit, you'll be able to suck it dry. The new deposit generator architecture affords a lot more flexibility, so the new deposits will have a different quantity in each individual cell. The small drill will only be able to extract Kethane from the hex immediately under it, but the heavy drill will be able to also draw from surrounding cells. My current thinking is that for every unit drilled from the main cell, half a unit (total) is drilled from the surrounding cells. Once the main cell is depleted, surrounding cells can no longer be accessed, so landing on the highest-density cell in a cluster is important for unlocking large quantities without relocating the drill. This is why a detailed scan of a deposit will be handy; if you know all the cell levels, you can plan out where to land to best satisfy your mission requirements. Of course, if you only need to refuel a small ship, a small drill landed anywhere on a deposit will do just fine. ------------------------------------------------------------------------- On a completely different note, HAPPY BIRTHDAY, KETHANE! On this day last year, MMI released Kethane 0.1 to the public. I loved the industrial nature of the mod and spent many hours building fuel depots around Minmus. During that time, I made myself a few fixes and improvements which I eventually released, and shortly after I took over the Kethane project in earnest. Kethane now gets a thousand or more downloads each day, even as KSP had changed dramatically. For my part, it's been a fun ride!