Kethane Pack 0.9.2 - New cinematic trailer! - 1.0 compatibility update

[KvickFlygarn87]

Hi im looking for kethane space craft can someone help ?

Thanks.

Uh, yeah, hit the big building at KSC, choose the parts you want in the right, enter the name of your craft, save it, hit launch ;-)

[Thourion]

Hey Majiir, dunno what you did with this update, but yeah its as smooth as silk. The map change speed is day and night compated to the previus release.

I also have the idea of a more smooth operation. Dunno if its my imagination, or if its the new grid code, or other fixes you may did.

Anyway cheers.

[KerbMav]

Can I simply delete the old folder and copy over the new without loosing my Kethane deposits as they are?

They are saved in the save file, yes?

Just to be sure.

[Nori]

Please note that donations go to Majiir and not any other participant in the Kethane project.

I will buy things that make me personally happy, like good coffee beans and k-pop socks.

Remember: a programmer is a tool for converting caffeine into code.

Mmmm good coffee beans... What kind of beans do you like getting?

Thanks for the great mod, it really adds a lot to the game for me and I love that you are continuing to add and expand it.

[Thourion]

Can I simply delete the old folder and copy over the new without loosing my Kethane deposits as they are?

They are saved in the save file, yes?

Just to be sure.

Yeah, they are saved in the persistence, Go ahead.

[LORDPrometheus]

you have to add it to the settings.cfg your self

Debug = True

Ok how do I run the in game GUI then?

[Majiir]

In future releases can you include settings.cfg in the package with default values? It's needlessly esoteric to have to look up what the filename is, that it even exists, and what the values are before customizing?

Sure thing.

Nice! What sort of possibilities does the new grid open up?

I can see a shroud of mystery... what kind of treasures do you have in mind for us? Can we get a hint?

This is the subject of my blog series in the works, so I'll try to summarize:

The old grid was represented internally as five rectangular grids that get stitched together. Neighbors on the rectangular grid are also neighbors on the geodesic, which makes neighbor lists easy to compute, but things get weird near the edges and a whole mess of code was required to handle that. (Neighbor lists are essential for constructing the vertices of the grid cells.) Each cell was indexed by three numbers: two for the location on the rectangle and one to identify the rectangle itself. The two polar cells aren't actually in any rectangle, so they get these weird negative indices which, you guessed it, require more special-case code.

Inflexibility is the main problem with this structure. In order to store data, those three-dimensional indices are converted into a one-dimensional array index, but if you increase the level of detail on a grid, those indices will be all shuffled around. The structure of the grid dictates that you're locked in to a single level of detail. It also makes some important algorithms difficult to implement. For Kethane, a common query asks for the cell underneath a given position. With the old grid, the best technique was a hill-climbing approach which ran in exponential time with respect to the number of grid subdivisions. More complex search methods (which I'll describe in a minute) simply weren't possible.

Icosahedral geodesic grids are inherently recursive structures, so the new grid code was built to reflect that. (It uses a tree structure internally.) Indexing starts at the twelve "level 0" cells which form the grid with the lowest possible level of detail. (This is just an icosahedron.) From there on, each level of detail fully populates the index space after the previous level. In other words, a cell in a given position will never change its index. This means you can change the level of detail of a grid as much as you want, and you can even do it asymmetrically. So, for example, you could have a level 5 grid (like the current Kethane map) and then pick a few cells to draw at level 8.

Searching for neighbors is now much, much more complicated, and an additional layer of caching was needed to solve some performance issues. That said, searching for neighbors is also more powerful on the new grid. Whereas previously there was only one set of neighbors for a given cell, the new grid lets you get a cell's neighbors at any level of detail. For example, cell #0 is the north pole, and we might want to get its level-0 neighbors, which are also pentagons; we might want its level-1 neighbors for performing a search algorithm; or we might want its level-5 neighbors for building the Kethane grid mesh. Although the code is more complex, it's a more elegant system structurally speaking, and it's much easier to reason about the new grid mathematically. The recursive structure makes searching for a cell (given a line) much faster (asymptotically speaking) because we can start at the lowest level of detail and progressively increase it as we search. This is the "obvious" way to perform search, but it wasn't possible with the old system.

This last update takes advantage of the new grid to solve a performance issue. To make mouseover work in the map view, the plugin casts a ray from the screen to the mouse position, and if that ray intersects a grid cell, we show the tooltip. When I added the terrain-conforming grid, I used a MeshCollider to identify the cell hit by the ray, and I took extra care to ensure the raycast operations wouldn't hurt performance. What I didn't realize at the time is that mesh colliders take a long time to initialize, and this was happening every time you switch planets in the map view. To solve this, I created a raycasting algorithm specifically for the geodesic grid. At each step, the algorithm tests a group of cells, and for the ones it hits, it generates more cells at a higher level of detail. When casting straight at the grid, about 50 cell tests are required, and for complicated areas with valleys and peaks near a horizon, up to 250 tests are needed. Modern CPUs are fast, so several thousand full raycasts can be done per second. There's still an initialization routine, but this is okay for a few reasons: (1) it's a lot faster than before, (2) the data set is small and could potentially be cached, and (3) it's all my own code, so I can control when it runs.

So, on the future of Kethane: The raycasting algorithm is essentially a generalization of the cell-from-line search algorithm, so it could be used for things like scanning at an angle to the surface. Raycasting is efficient, so something like a ground-based pulse which reveals visible cells is now easy to implement. The recursive grid could allow for progressively refined scans, or individual cells could be broken down into "subcells" to get very detailed information about the surface. A few months ago, I suggested that this grid (which was still a work-in-progress at the time) could be useful for generating detailed altitude maps, and I still think it has applications there.

"When all you have is a hammer, everything looks like a nail" and I have a really, really nice hammer.

Hey Majiir, dunno what you did with this update, but yeah its as smooth as silk. The map change speed is day and night compated to the previus release.

I also have the idea of a more smooth operation. Dunno if its my imagination, or if its the new grid code, or other fixes you may did.

I did a lot of performance testing, and it definitely loads faster, although there's still a substantial delay which could be removed with aggressive caching. I left it out for now because it would have increased memory consumption by up to 15-20MB, and I want to make sure there's some kind of option to disable that. I also wanted to get some feedback on the changes as they exist currently.

Mmmm good coffee beans... What kind of beans do you like getting?

I just finished a can of Nicaraguan Maragogype. I cold brew my coffee, and I've found darker roasts come out well. With so much less acidity, they sometimes come out more like chocolate than coffee. I've only been paying attention to the coffee I buy for about a year, so I'm open to suggestions. Some have generously donated this last week, so I'll be sure to share what I'm drinking!

[KhaosCorp]

I just finished a can of Nicaraguan Maragogype. I cold brew my coffee, and I've found darker roasts come out well. With so much less acidity, they sometimes come out more like chocolate than coffee. I've only been paying attention to the coffee I buy for about a year, so I'm open to suggestions. Some have generously donated this last week, so I'll be sure to share what I'm drinking!

Almost any bean from Hawaii kicks ass, though not sure about cold brewing.

Awesome update, the slight delay when opening the map is basically gone (not that I found it very bothersome in the first place). Looking forward to what the new grid code will bring.

[Psycix]

Thanks, that was a good read!

[RenatsMC]

Uh, yeah, hit the big building at KSC, choose the parts you want in the right, enter the name of your craft, save it, hit launch ;-)

Thanks man , no what i ment , where i can download pre-made space crafts ?

[Draft]

So, for example, you could have a level 5 grid (like the current Kethane map) and then pick a few cells to draw at level 8.

...

The recursive grid could allow for progressively refined scans, or individual cells could be broken down into "subcells" to get very detailed information about the surface.

So now you could, for example, have low-resolution scanners that can only determine the presence of a resource in a large area, shown on a less-sided grid, followed by more focused ones that work like the current ones and scan smaller cells within those larger ones?

That's a really nice hammer indeed.

[Majiir]

So now you could, for example, have low-resolution scanners that can only determine the presence of a resource in a large area, shown on a less-sided grid, followed by more focused ones that work like the current ones and scan smaller cells within those larger ones?

That's a really nice hammer indeed.

Yes, although rendering that could be tricky. It's certainly easy to compute and represent in memory. While it would be possible to have many levels of detail, it's probably easier if there are just two views, low- and high-detail, where each low-detail cell has its own high-detail view. This is similar to the "sub-hex scanning" concept that's been discussed before. The neat thing is that even if they're rendered in different views, the data can be stored in the same structure which opens options for querying high-detail data for the low-detail representation. If this is all a little vague, it's because there are a lot of options and it's not clear what would best enhance the game. I'd like to begin experimenting soon, especially with that mapping prototype I promised a while back.

[Litar]

Update is great, map loads way faster now, but theres one minor bug - under a certain angle of camera, the grid disappears.

Screenies:

http://imgur.com/rSU8zH8,XY8eRxT#0

Edited November 19, 2013 by Litar

[BigD145]

It's done that since at least 0.8.0

[Galane]

Will it now be possible to have a "wide angle" scanner that covers more than one cell at a time?

[Litar]

It's done that since at least 0.8.0

and could you view it from an inside of a planet since 0.8.0 as well?;p http://imgur.com/CVQvTRP

[Majiir]

Update is great, map loads way faster now, but theres one minor bug - under a certain angle of camera, the grid disappears.

I've fixed this on my end and it'll be in the next update.

Will it now be possible to have a "wide angle" scanner that covers more than one cell at a time?

Yes, in theory, but that's also true of the old grid. I'd like to make changes to scanning that make it a little more involved and a bit less waiting. It might become a two-step process where a high-altitude, wide-area scan is required in conjunction with a more local scan in order to efficiently locate deposits. It's all up in the air until I can finish new deposit generators. (Since the API is now open, I encourage everyone to experiment with those!) One key capability afforded by the new grid code is the ability to raycast sideways, so an airplane or low-orbiting scanner could sweep side-to-side and find cells. This wasn't really possible before. I don't think I want to make it easier to scan, but it should feel more like a game and involve more decision making. Again, it's hard to pin down specifics without experimenting. Something like a seismic charge that finds Kethane could be really fun (and it's possible now!) or it could be under/overpowered and boring.

[Tommygun]

Is the seismic charge something you fire like a ground penetrator from orbit or is it something you do on the ground?

[Superfluous J]

and could you view it from an inside of a planet since 0.8.0 as well?;p http://imgur.com/CVQvTRP

I'm not sure about versions, but yes. Yes you could

[Nemesis24]

When I start up the game, it says Kethane isn't installed correctly. I'm not sure what I'm doing wrong, but it says the plugin paths are incorrect. I don't know if this has been answered before, but can someone give me a hint with this one? I've got very bad luck with mods.

[Guest]

Something like a seismic charge that finds Kethane could be really fun (and it's possible now!) or it could be under/overpowered and boring.

IIRC you didn't want to do something like that with Kethane itself? Is the new system making you rethink that? Anyway, that'd be a great thing to see in the game.

[Majiir]

IIRC you didn't want to do something like that with Kethane itself? Is the new system making you rethink that? Anyway, that'd be a great thing to see in the game.

I certainly don't want to do it with the current scan system, and I'd prefer to do it with some other resource in order to keep Kethane consistent. But like I said: experimentation is key.

[Thourion]

...I'd like to make changes to scanning that make it a little more involved and a bit less waiting....It might become a two-step process where a high-altitude, wide-area scan is required in conjunction with a more local scan in order to efficiently locate deposits....

Its pretty hard to find the sweet spot between involvment and grind, but yeah i couldnt agree more with the involved part.

I also think that, the initial concept behind the two-step procedure, is a wanted thing for this mod, at least imo. It could prettify Game-flow, like for example you send a probe to search for traces of resources, more likely to determine if that body has the resources you need to see if its worth to plan a base for example.

And if found you initiate the more thorough scan, that obviously takes more time.

Anyway your stuff is solid, i cant wait to see how you going to implement them.

[KerbMav]

Hope I did not miss it while reading.

But did you take a look at the MAPscan mod and how it keeps scanning in the background as long as the active vessel has the scanning MODULE at least in passive mode?

[Majiir]

But did you take a look at the MAPscan mod and how it keeps scanning in the background as long as the active vessel has the scanning MODULE at least in passive mode?

SCANsat does nothing revolutionary. It's able to scan while unfocused because it doesn't consume electricity. It also doesn't interpolate between time steps. To solve the first problem, I've started working on a cross-plugin resource architecture to allow for offline resource consumption and high-timewarp resource handling. I'm cautiously optimistic about the potential for such a system. In any case, Kethane scanning will see some changes, but it probably won't have offline scanning until I can draw power or someone finally models that self-powered concept I wrote about a while ago.