Majiir

There will be a 0.7.3. So far, that's all that's in it. The following also may or may not make it in: Further cleaning up the UI, possibly with a side/top bar button. Third-party modding API enhancements, including the ability to collect water. Grid shader improvements, particularly for improving visibility of the planet surface in daylight and visibility of both the surface and the grid itself in shadow. Particle effect tweaks for performance while maintaining visual fidelity. (It's easy to improve performance by making them look like crap, but that's no fun.) Miscellaneous part improvements and balancing. I have no idea which (if any) of those will make it into 0.7.3. Some might get pushed to a 0.7.4 or to 0.8. I'm not really sure what the update schedule will look like or what coming updates will focus on. (Unfortunately, I don't have any half-finished code hanging around like I did for the grid. Gotta start something new!) I'm now quite happy with Kethane from a gameplay perspective, but I'm not satisfied with the flexibility of the code or the level of polish. If Keptin decided to model again, that might change my direction. So, you know, let him know if you see him.

Kethane deposits and scan maps will be preserved. If Squad makes dramatic changes to KSP then it might require a manual file move, but I can't imagine anything they could do that would completely break Kethane compatibility. My guess is no changes will be needed at all, at least not to the persistence code.

I profiled the mouseover routine (specifically, the part that converts a screen coordinate to a hex cell) and improved performance by a factor of 25. This should nicely resolve the stuttering issues some have observed. On my machine (i7-3770) the old routine peaked around 1.05ms per frame, and the new one runs in 0.04ms. The game only has one or two dozen milliseconds to render a frame, so a whole millisecond is a bit much for that routine, and lower-end hardware will have been spending even more time than that. Please provide your KSP/KSP_data/output_log.txt file. I can't do much without it.

Don't worry about it. I've written another mouseover optimization; it'll now only resolve the geodesic coordinates when the cell being hovered over changes. I might also play with reducing the floating-point precision on all the grid computations, since it's overkill for everything except initial subdivision, I think. [EDIT] Nevermind, that really won't work at all. Back to the drawing board.

Currently, unscanned cells only show up on the light side. I'm trying to change the shader so they're visible on the dark side, too.

I'm experimenting with the grid shader to see if I can't get empty cells on the dark sides of planets and moons to show up. Take a look: I'm not really happy with it yet, but I'll keep toying with it. Thanks for the video. In 0.7.1, did it perform much worse than what you recorded, or did it just do the same stuttering all the time? I'm trying to figure out how much of the performance hit is raycasting and how much is the vector->cell conversion. I have a couple ideas for optimizing the latter, but if it's the collider at fault, I'm going to have to get more creative.

Where is the source code as per plugin posting rules? Thanks for making this replacement. I hope you take it above and beyond what the author of its predecessor had done.

A dangerous assumption! Instead of scaling linearly with time warp, scanning speed scales with (one plus) the natural logarithm of the time warp factor. This means as you increase time warp, you scan slower in terms of game time but still faster in terms of real time. However, the returns on increased time warp are very much diminishing. I'd be careful about using such approximations. The geometry of the mesh isn't really suited to it. Your number comes somewhat close, but for the wrong reason. It takes five times the side length of each face on the icosahedron to traverse the equator, for a total of 160 cells. Thing is, it also takes that number all the way to +/- 26.6 degrees latitude, and the cells at those latitudes are much less distorted! The equatorial path is a little curvy since it passes through ten icosahedral faces.

My math says a single medium detector that's never idle requires 10242 * 0.9s / (1 + ln(1000)) = 19 minutes, 25 seconds to scan every cell. This is a lower bound; you'll basically never get a full scan with one detector in 20 minutes because the only way to avoid enough overlap is to make adjustment burns, and that requires dropping out of warp. The NRE is normal and not a problem. I still don't think this is a Kethane issue; it looks like the overlay object is instantiated just fine, and then KSP runs out of memory trying to load a texture. The map overlay starts right as you're switching scenes, so a LOT of stuff is being loaded at that time and there aren't usually debug messages printed for them. I think you're just running too many mods (particularly part packs) and need to remove some or lower your texture settings. [EDIT] I don't have that power, talk to the forum mods.

It might help to clean-install all your mods (being careful to keep files that store data). KSP loads EVERY texture, sound, model and config file it finds in GameData, regardless of whether it's actually been requested by a plugin. If you had a lot of seeds, you might have a lot of the old map textures hanging around, and KSP will be holding those in memory even though Kethane doesn't use them anymore. But I reiterate: there really isn't much in Kethane that uses memory. Even looking at all the vertex, triangle, UV, normal and color arrays, and all the cached position arrays, and all the scan masks, and all the deposits, you're still talking less than 2MB utilization. (For comparison, the old 2D map textures alone exceeded 2MB.) There are a bunch of miscellaneous things like GUI skins and PartModules on vessels, but nothing that should be using a whole lot.

Are you sure? If anything, the geodesic grid should use less memory than the old system. [EDIT] Ran some more numbers and it may use a little more, but we're talking a couple megabytes. [EDIT 2] Yeah, the more I run these numbers the more I think the grid actually saves memory. I didn't expect that, but I won't complain! It's definitely more CPU and GPU intensive than the old maps, but it's fairly lean since 0.7.2.

Kethane doesn't log anything about parsing bools or rendering lines. I know of a few people who run Kethane on Linux 64-bit and I haven't heard of any problems from them, so I'd assume it's another mod for now.

There was an impromptu stream yesterday. I was showing someone my silly plane design but I forgot to change the stream name, so a double dozen confused subscribers came looking for a dev stream. So I did some stuff. I was very sleepless and unprepared, so it wasn't much.

Nice work! The electricity number seems a little off. Do Kerbals not pack blankets? :-)

No, that shouldn't have happened. Do you have a backup of your deposits?

If the planet is added to FlightGlobals.Bodies, it will work with Kethane. (If it works with ISA, it's very, very likely it will work with Kethane.)

I like how you guys start trying to mine the star right AFTER I removed all the deposits there. By the way, those who had lag in the map view: how's it doing after 0.7.2? I know I made a few performance improvements, but without measuring I have no idea how much; it could be a lot or it could be completely negligible. (There's also the issue of what was improved. I reduced CPU load a bit but I did nothing to speed up rendering.) What do you mean by "punt"? The position->cell algorithm doesn't actually have any way to give up; it'll just loop infinitely if it can't find a cell (which shouldn't ever happen; every possible input yields a valid output). I'll experiment with a rover, but there shouldn't be anything special about borders that would cause that. Do you have screenshots? More detailed steps on how to make it happen? 1. Possible... but tough to read at a glance. 2. Luckily, the custom shader lets me blend colors manually, no UV interpolation necessary. I tested it on stream yesterday and it works well for Kethane+Ore, but it's not very attractive. 3. Hexagons are currently four triangles (one center triangle and three on the perimeter), not six. The problem is in getting the colors to show up. Each cell is six vertices, and I can assign a color to each vertex, but I can't assign two colors to each vertex. It's conceivable I could write a really fancy shader that resaturates the color as it interpolates between a resource color and a neutral midpoint vertex...but that limits color choices and it's really a very hacky solution. 4. I don't see how I could speckle it without building a texture on-the-fly. Maybe a custom shader? The real solution is to use an alpha-blended texture and an accompanying alpha blending shader (or, alternatively, to really lighten the multiplicative texture). I want to do a lot of tinkering with the shaders, which is why I didn't go into it too much on stream.

I explained earlier in the thread why splitting up hexagons into different colors is a technical challenge. Not impossible, but it would involve changing the mesh structure and that screws with things like cell<->vertex lookups. Another option would be to texture cells that contain other resources, like with a dot or something. It would be the same color as currently, but at least it would be an indication that "something's up" under that cell.

No worries, the thread moves fast. I just wanted to clear it up because some have said it was a bug that I decided to badge a feature. In truth it was intentional from the start, and during implementation I found (and fixed) some bugs with the main grid system. I could do some simple blending of the deposit colors where they overlap, which wouldn't look great but might work. But before you ask for that, consider this detail: scan masks are stored separately for each resource. Most people don't notice since the Kethane detectors currently scan all available resources, but the detectors were built to be configurable, and in the future I think at least the compact scanner will only find Kethane, not other resources. So if we blend colors, the question is: how do you indicate information about cells where there isn't a resource? Do you also blend the black/gray cells? If so, you'd get a strong gray when both resources are scanned (but none present) and a lighter one when only one is scanned. I suppose you could always hover to get detailed information, but it makes the visuals very confusing. You'd also have to decide whether it's best to blend gray/black from one resource with the deposit colors from another; it could have a real muddying effect most of the time. In short, I think a primitive, not-so-great version is possible without much effort, but making it look good and work well is sort of a design challenge.

Except it's not. There was no accident that resulted in this. It wasn't a bug that I decided to make into a feature. I sat down, decided I wanted to do it, and did it.

It's not a bug. It's a feature.

I believe proper credit for that goes to MechJeb.

Confirming sleep has not yet been acquired this cycle.

Kethane 0.7.2 has been released. The download link on the first post has been updated. This update makes fixes and improvements related to the geodesic grid overlay. See the 0.7 release notes for information on upgrading from any version other than 0.7 or 0.7.1. Changes in this version: Fixed an issue where the grid overlay would block sunlight from solar panels. The mouseover window no longer stays behind when exiting map view or disabling the overlay. The resource selector window no longer remains when the UI is hidden. Improved performance of cell mouseover detection. Adjusted the Minmus grid radius to fix a clipping issue. Moved plugin-wide settings from the PluginConfiguration system to a ConfigNode. Those settings now reside in KSP/GameData/Kethane/settings.cfg. The "show overlay" setting and resource selector window position are now saved to the settings file and persist between scenes. Added a settings option to disable the main menu overlay. But seriously, a lot of you guys complained way too hard about this. Disabled surface attachment for the KE-G35 generator.

Please, don't have this discussion here.