Papa_Joe

I'll take a look at the text and see if it is possible to add the additional info. I agree it would be nice to have that there... After looking at the code, I can add some info on part capabilities. However I got to thinking... I could also add tweakables to the Editor so that you could configure the part parameters when you build the vessel. If you wanted to change a part to allow surface mount passability, just click on the tweakable. Thoughts?

In the original thread for CLS, there was a fairly lively discussion centered around surface attached and passability. In the end, codepoet elected to "leave it as it is" in order to satisfy the greatest number of people. There are many that would argue that radial attached openings to some kinds of parts is not "realistic" and do not want it. I took a look at the "CLSStock alternative configs.zip", and do not see it there for the lab either. Possibly I could add it to the Freedom config... What I might also suggest is to create another folder under GameData, say "casper88", and add your custom Module Manager configs there. I have a folder such as this for that, and for custom parts I've created via part.cfg tweaks, etc. This way, you have the freedom to create any config tweak you wish, and when CLS is updated (or other mods you have tweaked) you do not lose your tweaks. See if that works for you.

As a general rule, radial attachments are not considered passable. However, it can be made passable by adding a passable attribute for the node in question If you can, please tell me the name of the parts you are connecting radially, and what mod pack they come from (or stock)? I can research to see if there is a Module Manager config for them and if not, we can certainly create one. Alternatively, you can actually do this yourself by taking a look here : https://github.com/codepoetpbowden/ConnectedLivingSpace/wiki/3.0-Module-Manager-Configuration. The wiki describes how the config files work and you may be able to simply add a "passableWhenSurfaceAttached" attribute to the existing config. Finally, there are alternative stock config packs that are in zip form that come with the distribution. If the parts in question are stock, possibly there is already a config file that supports it. If this is the part in question: Then the following would apply: Example: (Found in: ~\GameData\ConnectedLivingSpace\Plugins\CLSStock.cfg) Original: @PART[Large_Crewed_Lab]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } Altered: @PART[Large_Crewed_Lab]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true passableWhenSurfaceAttached = true } }

Interesting. I'll check it out. Update. I noted the following: I use a dual set of settings vars to allow for cancelling changes when in the Settings Window. These "memory" vars are loaded with the defaults on start. When you open the settings window they are supposed to be updated with the values loaded from file. I've noted the following issues with the methodology I've employed: 1. If you open settings window from the Space center, the "memory" settings (defaults) are not refreshed with the values loaded from file. If you cancel from this window without saving, the loaded values can be overwritten with default values. If you close without saving, while your current settings remained intact, the memory vars were then "out of sync". 2. If you change scenes, and then open the settings window, the issue in Item 1 above will again apply. To combat this, I've done the following: 1. I've added calls to refresh the memory vars immediately upon loading values from file. 2. I've also added the same call to refresh the memory vars when a save occurs. 3. Finally I've added the same call when the Settings Window is opened in Space center. IT was already being properly called when in flight. This way, the memory vars stay in sync with the loaded/altered values. This also addressed some "unusual" behavior I'd been noticing when I simply "exited" the game using Alt + F4 (Windows unconditional exit of an app). The above fix will be in the next release.

Thanks! I'll give that a whirl.. I poked around the CameraManager class, but didn't play too much with it.. Edit: Well, that did not seem to make any difference. The issue I'm trying to deal with is the ability of the user to click on the IVA button during a transfer and get to IVA camera view. I want to prevent this. First, I have the SM interface disabled during IVA, so a transfer cannot be initiated from IVA, so setting the camera to flight is not needed. I tried adding the deactivate all at the beginning of the process, and resetting them after the completion of the process. With these commands in place, the user can still select IVA on a kerbal portrait and still get to the IVA camera view. Either I need to fire some event to allow updating of the cameras, or it doesn't do what I think it should... Ideas? Update: Solved it. Instead of disabling and resetting all cameras, run the following check in the Transfer Process code (every update) when a crew transfer is active: if (CameraManager.Instance.currentCameraMode == CameraManager.CameraMode.IVA) CameraManager.Instance.SetCameraMode(CameraManager.CameraMode.Flight); This then reverts the view back to flight when a user attempts to click on the IVA button.... no flicker, just cannot go there Yay! Thanks for pointing me in the right direction!

Catching back up with this list... 1. Complete. Deployed 2. Complete. Deployed 3. I've looked over the object model, done some web research, and still have not found any means to access the kerbal portrait buttons. Still looking, but so far, no joy. 4. Complete. Deployed 5. Complete. Deployed. 6. Next on my list. 7. Next on my list. 8. Researching to understand needed means. (Learning RT) 9. Will follow RT. 10. Complete. Deployed. 11. Complete. Deployed. So, remaining items are: 6, 7, 8, and 9. 3 may not be possible, but I did add code to clean up errors when in IVA during transfer, so partially addressed.

Based on testing that JPLRepo has done, there is still one outstanding issue with integration to DeepFreeze. If you perform a stock crew transfer to a freezer, and the freezer is full, and the CrewTransferOvverride switch in SM is on (meaning that SM will handle Stock Crew transfers), it loses the kerbal. I have corrected this and released a new version of SM. Now when you perform a stock transfer under the above conditions, SM ignores the transfer and lets DeepFreeze handle the event and prevent the transfer from occurring. Release: Version 4.4.0.2 - Release 24 June, 2015 - Docked Vessel Transfers Edition. - New: Added StockCrewXferOverride flag to SMInterface. This is an informational flag to let other mods know that my Override code is active - New: Added check for full DeepFreezer when Stock Transfer Initiated and Override is On. Ignore event if Freezer is full, and allow DeepFreeze to handle it. Out on Kerbalstuff, Github, & Curse now.

My thought process was that the mod author could create the part, and then leverage your mod API to add the necessary module to enable freezing/thawing. Theoretically, that would be all that was needed. Now of course I don't fully understand the IVA implications, but even then that would be the responsibility of the mod author... Thoughts? We have identified the cause of the issue and I've passed code revisions to correct it to JPLRepo for evaluation. This should be solved very soon.

Yup, a hot fix to fix existing saves where a capsule had a heat shield.... and yes it will work in KSP from 1.0.0 and up. (probably works in 0.90 as well, but I'm not supporting that... )

And it works in KSP 1.0.4...

Awesome! Glad you like that feature. Update: SM works in KSP 1.0.4

New version out. Version 0.1.0.1 23 Jun 2015 - 1.0.3 and DeepFreeze compatability - Updated DFInterface.dll to latest version (0.16.0.2) - updated KSP assembly references to KSP ver 1.0.3 If you use DeepFreeze you will need the latest version to work with Roster Manager.

Thanks JPLRepo! If you are using ShipManifest, download the latest version, 4.4.0.1 to again allow freezing and thawing from Roster Window.

New version released. bug fixes: Version 4.4.0.1 - Release 23 June, 2015 - Docked Vessel Transfers Edition. - Fixed: When switching vessels while in MapView with Crew Selected and CLS installed and enabled, errors are generated in log during transition. - Fixed: With the release of DeepFreeze 0.16, freeze and thaw commands from Roster Window no longer work and cause errors. If you use DeepFreeze, you will need the latest release ver 0.16.0.2 or higher. Changes to the API provide support for 3rd party mod support of freezing and thawing kerbals.

Endurance is one very nice looking mod. with the new mod interface in DeepFreeze, I would think it "might" be possible...

Roster Manager works in KSP 1.0.3

CLS works in KSP 1.0.3

KSP Update Notice: SM works in 1.0.3

Considering the fact that the kerbal has actually been removed from the vessel and is in the state of "Dead", I'm going to guess that he/she could NOT earn any exp during the cryo phase. Upon thawing, xp would accrue normally from that point, as the state changes to "Assigned".

Ok, so I have found a couple of issues. Nothing serious, but I am addressing them. 1. If you have CLS installed and enabled, and you switch vessels in Map mode with Crew selected, you will get a few errors in the SM Debug window during the transition. I've corrected this. 2. With Deepfreeze 0.16 installed, and with a vessel containing a DeepFreezer part, attempting to thaw or freeze kerbals from the SM Roster Window fails with errors in the SM Debug window. I've contacted JPLRepo, and we are working a proper solution to my earlier hack. Will be corrected with the next release of DeepFreeze. You can still freeze and thaw, but only from the DeepFreeze interface, not from the Roster Window atm. So, not big issues, but they will be addressed soon.

Version 1.1.3.1 with some minor bug fixes and a small mm config change has been released. See OP for details.

The data is from the kerbal FlightLog.Entry. the first number is Flight, the second value is target, and the third is type. still working out what all this means. I'm a noob in this area atm. I'll post more of what I learn as I get more comfortable with the object model and what I can do with it... It looks like I can create my own entries, and I'm sure that some of the other mods I'm planning on integrating with will teach me LOADS...

NP. Okay, initial release of alpha on KerbalStuff. Version 0.1.0.0 xx Jun 2015 - Initial alpha release - Roster interface based on Roster window from Ship Manifest, but greatly enhanced (sorting, more detail) - In flight controls removed. These will stay in Ship Manifest. Roster Manager will not be visible in Flight scene. - Kerbal manager Tab buttons for various areas to manage. - Support for DeepFreeze cryo canisters. Frozen kerbals are displayed with assigned vessel. - Attributes Tab, contains kerbal editing found in SM. However, all kerbals can be edited. - Training Tab contains ability to edit kerbal skill and experience - History tab contains kerbal's flight history. - KSP-AVC aware and CKAN listed. Long way to go, like I said, but this much is working. Should I go ahead and make a release thread, or leave it here for awhile...?

Ok, I have the following in place: 1. Roster window with kerbal selection and a grid of data. Some action buttons. deepFreeze aware. 2. Various planned edit sections (tab based) with placeholder sections as I build out. 3. Training section allows you to alter the experience and skill of your kerbals. 4. History section contains the flight log found in the save file. Plans: As the OP suggests. I am now looking at the persistence model I plan to use to store the additional data that I will be generating / maintaining. I'm going to clean up the Roster Window action buttons, and then release an alpha (0.1) for folks to look at / play with. Long way to go to full completion, but some functionality there now.

I really appreciate the kind offer. However, I would prefer that you focus on your mod, as so many are anxiously awaiting your magic. I certainly will accept suggestions and I am always looking to improve ease of use.. So if you come up with an idea, please share, and I can make it happen.