Majiir

Resource generators handle placement and extraction of resources on planets. The current (read: old) deposit generator just places a bunch of polygons. I'm thinking the new default generator will use simplex noise and factor in terrain properties like altitude and slope. A generator could do anything, though; for example, Duna could have a generator that puts Ore everywhere except the poles, or Jool could have a generator that makes it an infinite expanse of Kethane. Generators are also responsible for handling state, so resources could shift or replenish over time. I'm hoping 0.8 will have the multiconverter, but it's not done yet so I can't be certain.

I've been working on some things for the 0.8 update. Deposit and scan data is now stored directly inside the persistence file as a scenario module node. This means Kethane data will be passed along with quicksaves/loads, and reverting a flight will also revert Kethane data. The game is handling all the actual saving and loading of data, so hopefully data integrity issues will be a thing of the past. You can also send someone your SFS file and they'll automatically have all your Kethane data without overwriting theirs. I'm now working on support for multiple deposit generators. Generator parameters will also be stored with the persistence file, so the default configuration can change without corrupting old data. I haven't built any new generators yet; the old generator code is a mess, so it will take some work to cleanly pull it out. The new generators should be much more interesting, so stay tuned for screenshots when I get to working on those.

I'm not sure how to estimate the probability of a decision Squad will make. NDAs typically cover source code, and I don't think the "attentant issues" are insurmountable. That said, the modding community is still taking baby steps; we only just recently got a namespace ban lifted, and we're working on engaging with Squad in smaller ways. If this does happen, it will be a while into the future. The next best after source code is decompiling (which is against the Squad EULA) and after that, documentation. Those concerned about a source release hurting commercial viability: there are some concerns, but "a build will show up on bittorrent" is not one of them. The source code is not enough to reconstruct the game; you'd also need all the Unity scenes, all the art assets, and probably a whole lot of proprietary tools and procedures. The bigger concern is that someone, say, rips the entire PQS (terrain) and patched conics system to make a game, but someone could have decompiled to do this anyway. It is a risk, but it's one that can be heavily mitigated and then sealed over with a legal document.

Why do you think this? The vast majority of modders I talk to agree that source code (through either NDA access or decompiling) is incredibly useful. It reveals how the game actually works, not how it's supposed to work or how the developers envisioned it would be used. It's an enormous task to write documentation that covers all the bases; for a project like KSP, that's just never going to happen. I'm not sure why this "the code is a constantly evolving work" objection keeps coming up. Modders are used to the codebase changing underneath. If anything, the rapid pace of change means that source code is even more useful, because it instantly reflects changes, whereas documentation must be updated manually.

I disagree. Access to source code would allow us to understand the underlying mechanics and communicate with Squad developers at a more sophisticated level. Squad's time is better used improving the API than documenting it.

That includes the plugin.

If anyone's wondering when someone might want to keep source closed, I can give an example. If it were up to me, I'd have made the code that generates the Kethane geodesic grid closed-source. Not the code that creates the overlay, just the code that crunches the numbers to figure out where the points on the sphere should go. Does this hurt development? Not at all; since nothing in that file is related to KSP, there are no lessons to learn about the API. Does it open the possibility of malware? Not at all; I've never heard of someone decompiling the Kethane assembly to check that it matches the source code. (I even accidentally released the wrong DLL once and nobody noticed.) Does it prevent people from writing their own programs using my geodesic grid code? Well, yes... but my license already prevents that. If I had the choice, I'd keep most of Kethane open source, but I might keep "proprietary" elements closed. The security argument is a gigantic red herring. The benefit of the open source rule is that it allows people to learn. It makes you wonder, then, why KSP's code must be so locked-down. (No, sal_vager, it has nothing to do with Unity being closed-source. We have documentation for Unity.)

No, it's a bug.

The license allows you to do whatever you want for personal use. (As long as "my friends" doesn't mean the whole forum, I don't need to know or care.) That said, why don't you just edit the Kethane heavy converter config to include the rocket parts conversion? If you use ModuleManager, it's very clean since you don't have to directly modify the Kethane files. (Technically using ModuleManager like this violates the Kethane license, but I think Modular Fuel System is the only one actively doing it, and they're using it quite responsibly. I don't really care unless it does something disruptive like modify the original conversion stats.) Interfect, on the legality of referencing: GPL prohibits linking to non-GPL code, and videos on YouTube can be embed-restricted. Just because I distribute the models freely (as in beer) doesn't mean anyone else can pick them up and use them. (There's also the bit where HeatSinkAnimator is a restricted module.) But all that aside, you didn't make the model, and tagging yourself as the author is really in poor taste. I appreciate your swift response, and I'm glad we didn't have to involve moderators, but let's be clear that it's not kindness on either of our parts that leads us to this conclusion.

The devs use source control, so unless they're using it very poorly, they already have an authoritative list of changes between versions. Source control logs are usually a bit cluttered and don't make a lot of sense to people not familiar with the codebase, but it doesn't take much to comb through and produce a changelog for public consumption. Make writing changelogs the responsibility of whoever submits a feature branch for merging and all that remains is the fixes and minor changes on the integration branch.

Many have requested that I open a donations box. (Captain Skunky even suggested as much on KSPTV.) I haven't, mainly because it's yet another thing to set up, but I'm also not certain it's something I'd want to do. I could use the money, but I'd hate to see people expecting anything more than what they already get. I suppose that's all up to the individual modder, though. I don't think you'd be putting yourself in a legally precarious position, especially if you use a donation service that takes care of some of the basic legalese for you.

Hi Interfect, First, let me say I'm very happy you're still maintaining OC. This and Extraplanetary Launchpads have the potential to provide the demand for a larger mod-based resource tree. However, I must ask that you remove the reference to the heavy Kethane converter model. The Kethane license should probably make things a little more obvious in this regard, but I think this qualifies as "use [of] models, animations, textures or other assets from Kethane", even though the model is not being distributed directly. You're free to make use of the KethaneConverter part module to power your own converter part, but please do this with other part assets (e.g. a stock model). Cheers, Majiir

Your drill needs to be higher up; my apologies for the confusion caused by this change. Please post your output log somewhere. If you're encountering this issue without MechJeb installed, it could point to other mods that cause the problem, or it could indicate the bug is in the stock game.

Please direct all posts related to the map jittering/stuttering/jumping issues at the support thread HERE. This is not a Kethane bug. It is not a Kethane/MechJeb or Kethane/stock incompatibility. Thank you.

No. That's MJ2 code that does that, and it has nothing to do with ScaledSpace.

MechJeb actually interacts with the map view much more than Kethane does, so it makes sense. Kethane just has more obvious symptoms. You can see this kind of thing in the stock game if you focus on the sun and quickly rotate your camera; the glowing texture around the sun jitters in the same way. This is all because of how ScaledSpace works. It could be MechJeb breaking the whole system, but there's some growing evidence that it's a stock bug.

The problem is that the entire map starts jittering. It's quite noticeable even without the Kethane grid. The same ScaledSpace exceptions appear. No, it's not a Kethane bug, although it may be a MechJeb bug; I've narrowed it down to either MechJeb or stock. Since it's not a Kethane bug, there's really nothing I can do to fix it.

The grid jittering/zooming issue is not a Kethane bug. BloodyRain2k helped me reproduce the issue by providing a save file and a procedure which reliably causes the bug. With the Kethane plugin removed, the issue still occurs. I narrowed the list of possible mods at fault to MJ2, ORDA and Quantum Struts, but others have encountered the bug without any of those mods so at this point I'm going to hesitantly say this is a stock bug. In any event, I've confirmed it's not a Kethane issue, so please direct support requests for this bug elsewhere. [EDIT] There's a support thread here: link

Kethane extractor code was changed in 0.7.4 and the EL auger needs to be updated. In the meantime, it won't work at all. Kethane will see enhancements to its API over the coming updates, too.

Subversion is primarily source control software, and it's sub-par at that. Many mods use some kind of source control, usually Git but sometimes Mercurial or SVN. Typically this is for source code only because source control systems are ill-suited for distributing binary assets. (Changes in text are easy to identify, store and compress, but changes in binaries will inflate the repository.) Source control systems often require downloading the entire repository history, too. It's the wrong tool for the job. Since 0.21 enabled System.IO access, we might see more auto-update or check-for-update schemes.

The PSystem is what made Kethane a head-scratcher to update, mainly because I don't fully understand what the changes did. It seems some scenes have been merged, but there are edge cases where objects still get deleted or where scenes are still cleared. If HarvesteR did a dev blog with details, it wouldn't go unnoticed!

All the settings he wants are actually in the settings.cfg file. ColorFull and ColorEmpty are for Kethane itself and shouldn't normally be changed. None of the keys you need are already there, so you have to add them. The keys you want for colors are ColorEmpty and ColorUnknown.

You can, but there are very few situations where you'd want to. The UI will be duplicated if you add multiple detector modules, and there's no way to rename the button labels. However, a single detector can work for multiple resources, and since altitude attenuation is now multiplicative, you can set the detector period very low and get fast scanning. If you want the appearance of some kind of merged mega-detector, you can have multiple detector animators all controlled by the same detector.

I forgot to mention a couple things I added in the 0.7.4 update: The resource selector window has a little collapse/expand button in the upper-left corner. When in debug mode, there's an Export Data function which produces a CSV export with information on all the geodesic cells of every body. The export will only contain deposit data for cells you've scanned unless you run the export with Reveal All Cells checked. This is a side effect of the extractor code refactoring. I can add a fudge factor to the raycasting code, since that drill wasn't designed with this kind of raycast in mind. I did test them before deploying the release, and the new entry point looked fine to me, but I'll take another look.

To all reporting bugs: you MUST follow the BUG REPORTING GUIDELINES or I cannot help you. The vast majority of "bugs" reported in the last few pages are the result of incorrect installations. There are a few that look like real bugs, but I can't help without more information. "Thumb down" for not reading the release notes and deciding to blame it on me. No, because KSP made API changes between 0.20 and 0.21.