Majiir

I've updated Kethane: release post

Kethane 0.7.4 has been released. The download link on the first post has been updated. This is a compatibility update for the KSP 0.21 release. It also makes miscellaneous fixes and improvements. See the 0.7 release notes for information on upgrading from any version other than 0.7 through 0.7.3. Warning: This is a CRAFT-BREAKING RELEASE. Crafts and save files with Kethane parts from previous versions are unlikely to work. Note: You must perform a clean installation of Kethane. You can copy previous Kethane deposit/scan files, but the old GameData/Kethane folder must be deleted and replaced with the new one. Changes in this version: Replaced the drilling effects on the KE-X130 with particle effects. The KE-J65 jet engine now works when it's started through the context menu. Detector altitude attenuation is now multiplicative instead of additive, and the attenuation factor was reduced from 0.5s/100km to 0.2/100km. The colors for empty and unscanned cells are now configurable in the settings file. Debugging functions are now available by setting Debug = True in the settings file. Debug options will appear in the resource selector window in the scan map. The debugger part is no longer necessary (and now has no function). Fixed the center of mass of the KE-X270 drill and the KE-G35 generator. Revised drill animation code to further unify the behavior of the two drills. Fixed an issue where a corrupted Kethane save file would break the game. Fixed category attribute on 2-meter Kethane storage tanks. Thanks nburns for the patch. Parts which previously had spaces in their internal names have been renamed. Made miscellaneous improvements to the geodesic grid code. This probably results in some performance improvement, but it hasn't been profiled. Added a generic detector animator module.

As far as I know, KSP doesn't reserve any rights like this with regard to mods, and KSP plugins are not considered derivative works. Even if they did, he could release a "spaceship simulator control pad" app that's paid, and a "spaceship simulator interface plugin" that's free.

New debugger UI, work in progress: I'm making a lot of miscellaneous improvements in preparation for 0.21, since I might have to release a hotfix anyway. Fair warning: I've fixed the center-of-mass issue on the heavy drill and generator parts, so those will probably break in craft files.

Here's a video of the pressure-fed engine I tested during my stream today:

Ialdabaoth, could you post license terms for creating and distributing derivative works? Your license currently only addresses distribution of the compiled assembly. Cheers, Majiir

Real spacecraft do this because pressure-fed engines are very common for orbital engines. (I believe the Apollo spacecraft had to use RCS in order to push fuel toward the back for the transfer engine.) Larger pressure-fed engines don't need another engine for assistance because gravity does the job, and we haven't launched big pressure-fed boosters into orbit yet.

I cast my vote for Bop because it's easy to lift fuel from and its terrain is much nicer than Pol. I've never actually landed there, but I found when tuning the grid radii that Bop was among the smoothest of the small moons. It has a lot of peaks, but there are many flat areas for landing. That's a significant advantage over Pol, and the lower surface gravity makes the higher transfer delta-V completely irrelevant, especially since you can use low-thrust, high-efficiency engines for the transfers. I wonder how this would work in practice. If you have MechJeb or happen to be good at precision landings, you can use a simple parachute lander and transfer fuel that way, but otherwise a reusable spaceplane might work best.

Re. engine concepts, I've written up a couple of my part concepts on the wiki: future part concepts

Data export (cell location, scanned status and resource quantity) will definitely make it in. A 2D map export might make it in (I'm leaning toward no, but we'll see, and in any event someone could write a renderer with the data export). The old 2D map will not return as an in-game feature because it had technical problems and the code was a pain to maintain. I'm also working on opening up more of the Kethane API on the plugin itself. I worked last night with someone who was building a MechJeb module that automatically performs inclination changes to improve Kethane scanning. As posted earlier, I'm also working on the grid shader so it can illuminate night-side terrain. (I need to work on this a bit because the shader alone isn't going to do the job.) The new map uses more GPU and CPU time but less memory and disk space, the code is much easier to maintain, and the save format is much more portable and malleable. The GPU is only used when you're in the map view (which is a simpler scene anyway), and as of the 0.7.3 update, the CPU usage is quite light. In technical terms, the 3D map is a big improvement. Keeping the 2D map would be a big pain. It's maybe kinda possible that a new 2D renderer could be built, but it would probably have to work in a similar way as the grid (rendering geometry instead of drawing pixels to a buffer). I'd much rather support third-party utilities than clutter up the codebase. With a more open API, someone can write a plugin that interfaces with Kethane and draws the map itself. (Have fun getting it to work in real time!) Every change breaks someone's workflow, but I'm very happy with the new map now that performance issues have been resolved, and the overwhelming response has been in agreement. I think you'll find the changes coming to be helpful, and I hope you'll embrace more innovative ideas too (like illuminating the night side or overlaying altitude data on the globe rather than trying to view Kethane on a rectangle).

Open the heavy drill part config file and change the MaxEmission and MinEmission properties on both particle emitters.

I don't understand the use case. If something is obvious, wouldn't manual analysis find it? The potential for false alarms is high, and I don't see why there would be such a high volume of malware submissions to make it useful. Plus, automated analysis as a first stage could have a negative impact on the quality of the manual audits. You could check for a plugin using certain parts of the framework API, but this wouldn't save any time and can't automatically disqualify a submission either. (Even something suspicious like spawning another process might have legitimate uses.)

Automated testing is in the same category as sandboxing. There are all kinds of bad things it'll never pick up. You can make static analysis a part of the process, but that's a lot of work for very little payoff.

It's preemptive. Historically, efforts to protect against malware have actually been more problematic than malware itself.

I pay just as much attention to Github. As an added bonus, I get e-mails every time an issue is posted on Github, whereas I have to manually check the forums. Please follow the bug reporting guidelines I've posted; they're there for good reason. [EDIT] You may be running into this issue: https://github.com/Majiir/Kethane/issues/78 Yep, you got lucky. The deposit generator doesn't do anything for specific locations. Then again, a combined deposit under KSC is only very useful for testing. For actually launching rockets, you already have KSC right there.

What's the big deal about security, anyway? Protecting users from malicious plugins has been part of plugin posting policy since the introduction of the plugin loader in KSP 0.14, and in KSP 0.15 this was extended with the introduction of the System.IO and System.Xml namespace bans. While parts are fairly innocuous, plugins have the potential to do extraordinary damage to user systems since they are code executed as part of the game. At the time, these seemed like common-sense security measures, and plugins today have no less potential to be threats. However, the existing security framework has serious flaws which render it completely useless against an actual attacker. Source code required: Nobody verifies that plugin assemblies were actually built from the same source that's publicly listed. Namespace bans: There are a variety of mechanisms for bypassing these bans which allow full access and may even appear innocuous. Decompiling: Typically, plugins are only decompiled if the source is not available for some reason. For the purposes of security, this is exactly the wrong time. (Note: This refers to decompiling plugins, not the game.) Auditing: There's nobody auditing plugins for security issues at runtime. If strange behavior is encountered it is usually reported, but malware by its nature attempts to mask itself from the user. The most damaging malware will go completely unnoticed to someone not looking for it. To my knowledge, there have been no malware issues with plugins since the introduction of the plugin loader. Still, security should be preemptive, and the current system requires substantial revision in order to be effective. (In other words, we haven't had a problem; let's not wait until we do to start thinking about improving.) Multiple paths to the goal There are several ways to augment plugin security, and one or more can be implemented for some benefit. I will focus on a subset of these techniques in a moment, but first I'll give an overview. This is by no means exhaustive. Security as a convention. This is among the weakest forms of security, but it's the most effective currently in use for KSP. The modding community is fairly close-knit, and it's a crowd that values user security and satisfaction. This is basically "security through nobody trying to be bad." Sandboxing/API restrictions. Namespace bans and other kinds of static analysis fall under this category. It also includes more extensive measures like using interpreted languages, e.g. Lua. (There are many reasons this is a terrible idea, but it's a good example.) In some cases, these measures can provide good security, but they come at a high development cost, loss of modding capabilities or both. It's very difficult to create a sandboxed environment that doesn't make third-party development significantly more limited, and even a perfectly isolated environment can't protect against every attack. Auditing. In the context of KSP plugins, it's easy to inspect source code and determine whether a plugin might be acting as malware. This was the intent behind requiring plugin developers to post source code, but since assemblies themselves are rarely (if ever) inspected, this provides no actual security. Security audits could be feasible if there is some mechanism to verify that a provided assembly matches the given source code. Cryptography. Digital signing can be used to authenticate that an assembly comes from a trusted source. These signatures can be verified by the game at load time, and unsigned or incorrectly signed assemblies can be rejected or restricted. Cryptography offers powerful security guarantees that are contingent on proper implementation (which is often very challenging). Assembly signing is a widely used (your video drivers are probably signed) so in this particular case, implementation is not a roadblock. The greater challenge is determining what counts as a trusted source and how that source can efficiently verify and sign assemblies. Automated Build + Community Auditing + Assembly Signing This proposal uses a positive security approach. Sandboxing has benefits, chief among them that it applies equally to all plugins, even ones that don't exist yet. However, under a sandbox model a user doesn't necessarily have any way to know whether a particular plugin is secure. The process I propose works as follows: Plugin developer submits source code to an auditing group. This source should be organized in some standard way so there's no ambiguity about how it's to be compiled; an automated build system is ideal. Auditing group inspects the source code and makes a determination about whether the source is safe. This is clearly not a perfect process, but a well-selected group can provide excellent security guarantees. If the plugin is approved, the auditing group signs the assembly and returns it to the plugin author. Users can configure their game to authenticate plugins and reject or restrict any that are not signed. Alternatively, a third-party tool (distributed by the auditing team) can perform verification. There are important details to work out for each of these stages. For example, there needs to be some way to sign the assembly when a quorum of auditors has approved it, and no single auditor should be able to sign assemblies. A trusted individual could hold the keys, or there could be some cryptographic solution. I suggest this scheme be completely optional at first. Later iterations can enable signature verification by default or disable sandboxing restrictions for signed assemblies. In particular, the user should always have the choice to override the defaults. Please post your feedback! I want to emphasize that this is a proposal open to modification. It's also not specifically targeted at anyone; Squad could implement it as part of KSP, but the community could also do it independently.

Well, this is awkward. As far as I can tell, ISA does not have a license as required by the addon posting rules. There's nothing in the first post, any of the dev blogs, the download archive or the source code, and I could not find any mention of a license elsewhere in the thread.

Yeah, and I've been meaning to change this. I still need to consolidate some of the extractor code since currently the two drills have fairly different logic. Yes. This was requested long ago but the old scan format didn't facilitate exporting that kind of data. With the grid, it's a simple loop. It's not. The 2D map is for export only. I'm not sure why some of you think a 2D map is more useful. I can see that it's useful in conjunction with other 2D maps like ISA, but imagine if those same maps were projected on a 3D surface. It's not so much a shortcoming of the 3D format as it is a shortcoming of ISA. The export function is there to help people out but I have no plans to return to a two-dimensional format, and the raw image export might not make it in depending on how the deposit and scanning revisions turn out. I do aim to support at least some kind of data export, and per-cell data might be the more appropriate way to do that. (Rendering an image is really a gigantic pain. Go support this request if you want to make it a tad easier.)

KE-WAITNONOSTOP-01 Kerbal Unreconstitutionator.

The only sounds in that clip are open/close and cooling sounds. The actual conversion isn't played yet.

I've finally gotten around to integrating the sounds created by Volker. Here's a clip of the heavy converter with some of its sounds set up.

It's a 2D map export since some other mods haven't gotten on the 3D map bandwagon. Rendering it in a timely manner is proving to be a challenge. I've brought it from 60-90 seconds to about 11 seconds now, but that's still pretty long.

By popular request, I've been playing with something.

A middle ground between hardcoding and detection is to use a config file. That way, users can at least update config files without rebuilding the whole DLL. You can use PQS to find the terrain height at a given point. There are also some max altitude properties, but I'm not sure they're trustworthy. Experimentation is the name of the game.

I switched to fallback shaders to see if that's the issue, but everything looks fine to me. The logs indicate a texture isn't loading. Here's an illustration of what I think is happening: http://i4.minus.com/iRm1wltvuetQq.png Since someone confirmed this happens with Kethane versions prior to 0.7, and 0.7 was the first to do anything with the map view, and because this looks a lot like a generic out-of-memory issue, I'm going to conclude (again) that this issue is unrelated to Kethane.