Majiir

The technical limitation is that motion in KSP (and video games in general) is discontinuous. Your ship doesn't move smoothly from one position to another; it jumps in steps. Kethane scanners are coded to only scan a cell once per physics frame. I could change this, but it would be pointless; if more than one scan attempt were made in the same frame, you'd just end up scanning the same cell. It's theoretically possible to look at two on-rails orbital positions and find all the cells along the traversed path, but the mathematics are non-trivial. (Several hours of discussion in #kspmodders yielded only a greater appreciation for the problem.) For the record, if anyone does solve that problem in a complete way, I'd be happy to implement it and remove the logarithmic scaling so detectors work just as fast as expected at warp.

The drill animator just plays the animation in a loop, and it doesn't even do the looping itself (Unity handles that). I wouldn't worry about being conservative with keyframes; put in a dozen or two, and have the whole animation cover several rotations.

Perhaps you could elaborate? This discussion (and my participation in it) was much more active before SCANsat came about. It seems people are mostly satisfied with it. What would you rather see?

The policy applies to the general public, however I don't know that it's been communicated to anyone else. This. Geschosskopf, you seem to be operating under a definition of "mod" which presupposes that they're derivative of Squad's work. Consider my geodesic grid code. It was developed and tested in complete isolation from KSP. It's clear that this code is my own intellectual property. So because that code was at one point loaded by KSP, the rights to that code are transferred to Squad? Did you see the screenshot I linked in my last post? Displaying high-resolution data isn't as trivial as Kethane's overlay, but as that proof-of-concept demonstrates, it's certainly possible. My experimentation thus far has been in shader-driven heat maps, but a variety of shading techniques could be used for an overlay. Greys correctly points out that the geodesic grid (data structure) and the map overlay (visualizer) are separate things, and the organization of the code reflects that. The problem that's been (mostly) solved is: How do you store geographic data in a way that doesn't suffer distortion and seaming? Rectangular grids (which, as far as I know, SCANsat does use) have those problems, and geodesic grids do not. They're much more complex behind the scenes, but that work is already done. However, I should point out that there are all kinds of ways to visualize data contained in a geodesic grid, and the Kethane map overlay is just one. My work-in-progress overlay is another. The point I'd like to make here is that while gameplay is definitely important, there's a lot of room for more visualization work as well.

Nothing. Seriously, don't touch it. Not even if you're modding.

This section of the API documentation should help. In the KethaneDetector module, there's a Resource{} node; just copy that (not the whole KethaneDetector) so there are two Resource{} nodes, each with its own resource name.

...except Squad's lawyer directly contradicts you on this point. Even if that wasn't the case, the loosely coupled nature of KSP mods puts them into a different category than the mods you're talking about (which actually derive from game assets). If writing a program to be compatible with an interface gave ownership of that program to the owner of the interface, nearly all programs on Earth would be owned by Oracle, Intel or Microsoft. Give it up. You've pasted this rant over and over, and it's only becoming more wrong over time. ------- To get this thread back on topic: Kethane is mentioned here periodically, so I want to clear up a point of confusion. In Kethane (and probably also in SCANsat) the scanning mechanic is separate from the display mechanic. For users who prefer 2D maps, SCANsat could indeed display Kethane's data, and this is an addition I'd like to see (but it would need to happen from SCANsat's side). Making the Kethane scanner behave like SCANsat's is something that would happen on Kethane's end. Displaying SCANsat data in 3D is interesting. In theory, SCANsat should just do that, but Kethane already has a lot of the facilities in place (including some unreleased WIP stuff). If there's interest from damny, I think it would work nicely for the Kethane overlay to support displaying SCANsat data if the user so desires. Difficult problems like mouseover detection on non-spherical bodies have already been solved, and it would allow players to use either a 2D or 3D view for all the scan data they need to see. I hadn't planned to do much work on that in the near future, but damny could potentially change that.

ORS is analogous to the Kethane plugin API, and KSPI is analogous to Kethane itself. The issue with the upload in this thread stems from illicit use of Kethane art assets, not anything to do with the Kethane API. In other words, nothing in this thread that was disallowed by Kethane would be provided by ORS. I've seen no pull requests of that nature. Feel free to make one. [EDIT] Just to be clear: I did not request the link removal. However, stupid_chris did ask me to verify that the download contained infringing content before he removed the link.

Hi psyper, Firstly, I'm happy for people to use the Kethane API. However, part models and textures are not part of that API. Creating your own models (or having someone else do the same) will nicely increase the quality of your mod. Alternatively, you can augment existing Kethane parts with new behavior using ModuleManager. It looks like you're distributing full copies of Kethane config files, which is generally a bad idea for compatibility reasons (and it's not allowed by the license for that reason). I recommend you use ModuleManager to make changes to Kethane parts. It also looks like you've copy-pasted the Kethane resource distribution parameters. I won't stop you if you really want exactly those numbers, but I highly recommend you create your own distribution parameters. Cheers, Majiir [EDIT] For clarification: Part config files are protected by the Kethane license, so those cannot be redistributed. I don't think this will prevent you from doing anything, since you can use ModuleManager to accomplish the same changes. Additionally, it looks like the water_highGain and water_sensor_1m contain Kethane assets.

Care to explain the issue you're having in more detail? Kethane's animator simply plays Unity animations, so if you build your animations correctly, you shouldn't have problems.

While this specific instance is low priority, it possibly points to a more serious caching issue. That would be a fairly high-priority issue if that's the case.

I daresay you have no idea what you're doing. You've simply added a Kethane detector onto a part. That does absolutely nothing to integrate the two mods. Regarding integration: Kethane's API has exposed deposit and scan data for quite some time. As far as I know, SCANsat does not expose an API of its own, so until it does, Kethane integration will have to be done from SCANsat's end.

What? You're describing the old behavior. As of 0.4.6, there's an "Edit Container" button in each container's context menu.

KAS 0.4.6 has been released. The download on Spaceport (link in the first post) has been updated. This update contains fixes and improvements. Special thanks to angavrilov for contributing most of them. There are no expected compatibility issues, but it's difficult to test every change against the many possible KAS setups, so please take caution and back up your save files before updating. That said, this version should involve much less spontaneous explosion! Changes in this version: Parts can now be rotated around three axes while being attached. The default key bindings still rotate around the Z axis. Hold left alt to instead rotate around the X axis, and hold right alt for the Y axis. Part state is now preserved when parts are stored in containers. This means resource levels are stored as expected, and properties like whether solar panels have broken are also preserved. The mass of the container takes stored resource mass into account. Note that part statefulness must be enabled in the grab module config. Modules on parts retrieved from containers are now properly initialized. This means that, for example, solar panels will function properly when attached without reloading the scene. Containers are now opened through a context menu when in the editor. The small three-rung ladder can now be grabbed and stored. The medium dish antenna can now be grabbed and stored. Winch heads are now properly dropped when boarding a vessel. Tweaked rover wheel placement when held on EVA. Implemented CompatibilityChecker (version 2) warnings. Fixed an issue where pipe colliders would exist transiently. This removes the small camera jump when linking pipes, and it may prevent spontaneous base explosions. Fixed an issue where unlinking a pipe cycle would break things. The control state of the largest vessel is preserved when two vessels are connected. Fixed an issue where an internal position for grabbed parts would get stuck on a bad value. Fixed an issue where ladder parts were improperly initialized. Fixed an issue where KAS would instantiate parts with the wrong size. Fixed an issue where vessel control state could be reset when locking or unlocking a winch piece. Fixed an issue where a vessel's rigidbody could be in the wrong position after being on rails. Fixed an issue where attach parts like struts and pipes would not reattach on vessel load if they were not active (staged). Part names are no longer modified when parts are instantiated by KAS. Docked state is now symmetric (both modules know they are docked) and redundant docking events have been removed. Reduced the performance overhead of the grab module. Struts, pipes and winches now clean themselves up on part destruction. Keystrokes are ignored while an edit field is active. Unlocking winches now works with any joint type. Fixed an ID conflict between the winch and container windows.

This is untrue. That said, a large round of fixes is imminent, so keep your eyes out for that.

[0.23] This doesn't leave much room for descriptive information. v0.0.1 (2/12/14)

Word from Squad is that there will be an amendment to the EULA to officially allow this kind of usage, but that's been slow to arrive. It's been de facto allowed for quite some time.

It occurs to me that version compatibility goes both ways: we want to show a warning for a too-new KSP version and for a too-old version. The error message is currently not very helpful in that regard. I'd like to keep CompatibilityChecker fairly flexible, but would it be helpful to incorporate a sort of "expected version" value that could be reported to the user? Should that be decided on a per-mod basis?

Kermunist, I like the suggestion. How do you suggest handling mods using an old version of Compatibility Checker? A new version will override the old ones just fine, but it will need some kind of default way to fill in those fields. Version could be filled in with the AssemblyInformationalVersion, or a blank if that attribute is missing. Should the other field just be blank? "Unknown"?

Diazo, a few people seem to be going that route. You can still integrate with CompatibilityChecker in that case, since disabling functionality is implemented on a per-mod basis. Integrating will give users a more cohesive experience. If you choose not to use CompatibilityChecker, I'd be interested to hear why.

From my license guide: I think that's perfectly reasonable. I recommend a restrictive license by default, but I encourage people to consider a different license. I wrote my guide for the benefit of individual modders. Before that guide, modders were frequently coerced into releasing works under viral licenses like GPL without knowledge of the rights they were giving away. The "modding community" was frankly abusive to newcomers in that respect, and my guide aims to correct that. That said, the guide has made it much easier to enforce the licensing rule, and accordingly we see a lot of mods licensed under MIT or GPL where we used to see unlicensed (and thus unforkable) releases. My license guide references why CC is a bad idea for software. There are only two easy options: retain every right to your work, or give them all away. Anything in between requires more research and consideration.

Yes. For example, the Kethane drills can be deployed in the VAB. However, this functionality must be added to the underlying part modules (i.e. plugin code).

I think it's too early to start coding. There are still big questions to answer about how a security system should function at a high level. That said, I want to point out that signing and hashing are related but not the same thing. With hashing, the user must always download a list of approved hashes. Digitally signing an assembly means that the plugin comes packaged with cryptographic proof that the assembly was signed, and that proof can be verified by the client without contacting any servers. In other words, a plugin can be verified without the client having any prior knowledge of that plugin. The only prior knowledge that's needed is a set of auditor certificates to be trusted, and those will change infrequently. There are a few modes of operation that a user might be interested in. User chooses to run both signed and unsigned mods. Any valid signed mods are listed on startup so that if the user expects a mod to be signed and it isn't, he can complain. User chooses to run both signed and unsigned mods. Some mods are configured to require a valid signature, and others are not. If a mod that's supposed to be signed cannot be verified, it's disabled and a warning appears. User chooses to run only signed and verified mods. Any other mod is disabled. Along those lines, there are also several ways a user might want a mod to be signed. Some may want an assembly to be signed by at least two auditors, while others might want each mod to be signed by its respective author. In this discussion, we need to establish both which modes we aim to support and which modes we make default. For disabling mods before they execute, we have at least two options. Users could start a launcher instead of the KSP assembly, and that launcher could verify plugins before allowing KSP to start. This is easy to do, but it presents usability issues. A second option is to use IL injection, which would be more transparent to the user but would also be harder to maintain and potentially controversial.

As of KSP 0.23, we can once again override Part.RequestResource(). In other words, we can rewrite the resource handling code for any moduleâ€â€past, present or future. I recommend caution to anyone who feels like doing this, because it's a core part of the game and only one mod can reasonably override resource behavior at a time. That said, I expect that whatever solution comes out of this thread will use it.

Nothing to worry about. The main plugin was renamed from MMI_Kethane to Kethane, so the original name was replaced with an empty file to prevent issues when people upgrade from an old version without performing a clean installation.