KevinCathcart

Hmm. I'm surprised it took me this long to notice, and that nobody else has complained, but stock crew transfer only works with the very first vessel you try to use it with. Here is what happens. On the menu screen the plugin gets loaded and it registers a delegate pointing to an instance method on the current instance. Then the scene changes to the space center, resulting in the instance being "destoryed" by unity. However, the actual .net object remains around because the registered handler holds a reference to it. When you finally try to to use stock transfer, it calls that old istance. The handler notices that it has no active vessel built, so it rebuilds it with the current active vessel. The transfer works as expected. Then I switch to some other ship, and try it again. That same original instance gets used again, but it now has a CLSVessel instance that is holding on to references to the "destroyed" parts of the original ship. The new transfer is not between parts of the the same space on that previous ship, so my new transfer gets denied, regardless of if it should be legal or not. The fix is to make the event handler static, and make use of the Instance static property. This guarantees that the event handler always looks at the current instance of the plugin. See my newer pull request for details.

Delayed reply: You are obviously right. I forgot the flip on mbm, and I always get the alpha value backwards. I think of alpha as "transparency", when it is actually "opacity". As for not specifing "with mipmaps", that was because it should be obvious, and that was already covered by previous posts. The exception being textures that get editited live like certain RasterPropMon textures, since re-calculating mipmaps each frame is too expensive. But it sounds like everything that needs to be said on this topic is now said.

The code will work fine if started at any time. As long as exactly one instance of the handler is registered at the time a transfer occurs. However, the best way to ensure that other mods that want to use the event can reliably be compatible, we need to be able to guarantee that the reverting handler comes first. Then depending on exactly what the other plugin wants to do with the event, they are either automatically compatible or can at least check to see if we reverted the transfer. If the CLS event came second then, for example, some The productivity calculations of Interplanetary Launchpads would break. It does not need to actually be extremely early though. I've submitted a pull request that show one reasonable way to handle this that in will work fine, without changing the startup timing of CLS. The proposed solution makes the handler static, and registers it exactly once (on the very first time Awake is called). In practice that will be the Awake of the Menu Scene, and most interested add-ons will wait until a later scene or at least until the Start event, to hook the event, so this will keep compatibility issues to a near minimum. Obviously I also incorporated the try catch block i mentioned above.

Hmm, I did not think it was Friday yet? Anyway, please let me know if any problems crop up, but as you saw it is pretty simple code, not really too much room for something to go wrong. Just be sure that only one copy of the handler is installed at a given time. One thing I really should have done in my example code, is wrapping the handler in a try/catch block that logs any thrown exception with UnityEngine.Debug.LogException and does not rethrow. The event handler should never actually throw an exception, but if for whatever reason it does, some minor glitching can occur. Better to just log the exception, and let the caller continue on. Also, this may cause be incompatible with future mods that also want to hook that event, in-so-far as they would not be expecting the transfer to be reverted. But the only two mods on GitHub currently using that event are both compatible, as long as CLS subscribes to the event extremely early, like my example code does.

Lilleman: The correct swizzling for mbm is RGBA=>RGBA (I.E. no swizzling.) That is because all mbm textures are RAW decompressed versions of DXT* textures dumped straight from the unity game engine. That is literally how part-tools creates them. Check the source code of an older version of part-tools, it is as simple as can be. All that is needed to to simply re-compress them. I repeat that again, because it is important: After the header, MBM files are RGBA dumps of raw texture data at mip level 0. Also since MBM are a dump textures, they should not need to be flipped in the conversion process, unlike the other formats. That is because unity already did the flipping relative to the original source format. So basically you have non-normal map: non-mbm: If 24 bit or 32 bit with all alphas zero, flip and convert to DXT1. If it has non-zero alpha values, flip convert to DXT5. mbm: If 24 bit or 32 bit with all alphas zero, convert to DXT1. If it has non-zero alpha values, convert to DXT5. normal maps: non-mbm: Swizzle RGBA (XYZ-) to GGGR (-Y-X) and convert to DXT5, resulting in DXT5nm. mbm: Do not swizzle, but convert directly to DXT5, resulting in DXT5nm

Your build process is basically correct, but a few notes: You need to have a reference to CLSInterfaces.dll, not to CLS.DLL, you need to have a reference to UnityEngine. You need to delete the autocreated AssemblyInfo.cs file, since I included the relevant attributes in my link. Compile in Release mode not debug mode, and copy the resulting dll and a copy of CLSInterfaces.dll into a new subfolder of GameData. (alternatively copy the result into the CLS's plugin folder which already has CLSInterfaces.dll)

Well that is rather easy. There is only one hook into the built-in crew transfer system, and it occurs after the member has already been transferred, and the transfer message queued for display, but the hook code runs in the very same frame, and it is very straightforward to undo the transfer, and fairly easy to suppress the existing message. So I check if the tranfer is within the same ConnectedLivingSpace, (or if it is a transfer to/from EVA) and if not, then it is reverted, an error message displayed, and the success message removed. There is one rather minor downside, which is that the failed transfer may change which seat that Kerbal was in, but it is totally not worth adding code that runs every frame to avoid that. Somebody who really cares about the specific seats should be using the Ship Manifest mod anyway. I've posted the code to the following gist: https://gist.github.com/KevinCathcart/92d7d7d80bac480df7d6 It works just fine, and will likely continue to work until the next KSP release (or possibly longer), but I don't really want to maintain it, so somebody please adopt it.