[0.90] [Up for adoption] Connected Living Space v1.1.2.0 (27th Feb 2015) Hatches and Highlighting

[Pocketkid2]

Does this work on 0.25 without an update? If not, how soon might one be available?

[codepoet]

I am building it against 0.25 now. Hopefully I will have a release for you all soon.

[Ippo]

I am building it against 0.25 now. Hopefully I will have a release for you all soon.

Ninja'd, kinda

I had just tried rebuilding it against 0.25: it appears that it works with no change, but of course, an official update is better

[codepoet]

v1.0.9.0 for KSP 0.25 released. Also has config for lots more part packs.

[Starstrider42]

Sorry to tell you this, but Near-Future 0.3 has built-in CLS support, so your pack for that is redundant. :/

[codepoet]

Thanks for letting me know, I will take it out.

Part packs adding their own config is the preferred way forward, but in the meantime I am happy to add any configs that the community provide.

[biohazard15]

A question: does CLS support 0.25 stock crew transfer system, thus making crew transfer mods redundant?

[codepoet]

A question: does CLS support 0.25 stock crew transfer system, thus making crew transfer mods redundant?

CLS itself is not necessarily related to moving crew around, it just provides a framework to know what is connected to what. Therefore it has not interaction with the stock crew transfer system.

[S1gmoid]

CLS itself is not necessarily related to moving crew around, it just provides a framework to know what is connected to what. Therefore it has not interaction with the stock crew transfer system.

So... that means a new mod is in order, that uses CLS to disable the stock crew transfer between unconnected spaces? Or is there such a mod around already?

[codepoet]

So... that means a new mod is in order, that uses CLS to disable the stock crew transfer between unconnected spaces? Or is there such a mod around already?

I was thinking myself yesterday that that would probably be the best approach.

[KevinCathcart]

I was thinking myself yesterday that that would probably be the best approach.

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.

[marchingknight11]

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.

So to use this, do I just start a new VisualStudio project, add references to the KSP DLLs and CLS.DLL, then hit build?

[KevinCathcart]

So to use this, do I just start a new VisualStudio project, add references to the KSP DLLs and CLS.DLL, then hit build?

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)

Edited October 21, 2014 by KevinCathcart

[codepoet]

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.

You are awesome! Thanks for doing this. Next time I have a day off (Friday perhaps, or on a couple of weeks time) I will have a look and play with it.

[codepoet]

OK. I am persuaded. I have integrated this into CLS itself, and it seems to be working. I will add a config option to the GUI and then release it.

[KevinCathcart]

OK. I am persuaded. I have integrated this into CLS itself, and it seems to be working. I will add a config option to the GUI and then release it.

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.

Edited October 22, 2014 by KevinCathcart
fix spelling

[codepoet]

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.

Why is it necessary to subscribe really early. CLS is all uptight about how it starts up (something to do with hatches in the docking ports) and so I starts up every scene, and uses a custom KSPAddon attribute (although I am not sure if this is still needed.) Is your transfer abort code going to not work if I do not use Startup.Immediate?

[KevinCathcart]

Why is it necessary to subscribe really early. CLS is all uptight about how it starts up (something to do with hatches in the docking ports) and so I starts up every scene, and uses a custom KSPAddon attribute (although I am not sure if this is still needed.) Is your transfer abort code going to not work if I do not use Startup.Immediate?

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.

[codepoet]

Release v1.0.10.0 which has a bug fix that should make CLS work with more unconfigured parts. Also added support for stock crew transfers (thanks KevinCathCart)

[ev0]

Hi codepoet,

The Z-4K Rechargeable Battery Bank (the largest battery, 2.5m) isn't passable, despite there being what looks like a large docking port in the middle. Any idea how to make it passable? The names of the parts in the @PART[~] field in your CLSSquad.cfg don't all quite match up to the part names in Squad's Parts folder, so I'm not quite sure what to add to that file.

Thanks for the mod!

[S1gmoid]

I don't know if this helps, but you should be aware that Squad part folders, file names and actual part identifiers are totally all over the place. You'll have stuff like "elevon1.cfg" containing a part named "SmallCtrlSurf" or somesuch.

Find the battery pack, open the cfg file, look at the "name" field, that's what you need to give ModuleManager to apply changes to it.

[codepoet]

Hi codepoet,

The Z-4K Rechargeable Battery Bank (the largest battery, 2.5m) isn't passable, despite there being what looks like a large docking port in the middle. Any idea how to make it passable? The names of the parts in the @PART[~] field in your CLSSquad.cfg don't all quite match up to the part names in Squad's Parts folder, so I'm not quite sure what to add to that file.

Thanks for the mod!

http://wiki.kerbalspaceprogram.com/w/images/thumb/f/fb/Z-4K.png/190px-Z-4K.png

I can't remember it is included, but have you checked out the "alternative stock configuration"? It is in a zip file in the CLS/plugin folder. There is a text file that describes the thoughts behind the two configs. If it is not included let me know, but you can always modify the config yourself - it si not hard - look at the Config HOWTO file.

[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.

[codepoet]

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.

Thanks for catching this! It goes to show how much time I have for testing!! I will get a formal release out once I have finished writing my sermon for tomorrow.

[ev0]

I can't remember it is included, but have you checked out the "alternative stock configuration"? It is in a zip file in the CLS/plugin folder. There is a text file that describes the thoughts behind the two configs. If it is not included let me know, but you can always modify the config yourself - it si not hard - look at the Config HOWTO file.

Thanks! That did the trick. The ZIP file is there with the .cfg files. I'll be using the "Freedom" version from now on, it makes the battery and a few other parts passable.

I don't know if this helps, but you should be aware that Squad part folders, file names and actual part identifiers are totally all over the place. You'll have stuff like "elevon1.cfg" containing a part named "SmallCtrlSurf" or somesuch.

Find the battery pack, open the cfg file, look at the "name" field, that's what you need to give ModuleManager to apply changes to it.

You're right, the correct name to use is the "name" field in the part .cfg. Could be useful for the future.

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.

Yep, can confirm this. Found out when originally checking out my battery problem. Was going to check later which mod the problem lay with, guess I don't need to:)