Papa_Joe

Thanks for that update. My understanding came from some PMs. I've not used texture replacer. Now, in the release,I have the Eva code off by default. On vessel change was requested by the authors of CLS and Extraplanetary launchpads and texture replacer I'll take a look the TR code so I better understand what is going on.

New version of SM out. the Enable CLS switch is now available from the settings window (among others).

Not yet. Coming in another release. codepoet is writing the soft dependency code. What I plan to do when it is available, is detect for it's presence, and if it is not there, then it will automatically work in cls=off mode. You will not be able to turn on CLS. If cls is detected, then it will be enabled by default, and can be turned off in the settings.

New version out. Someone let me know if Texture Replacer works with the EnableTextureReplacer Setting "off". Thanks! Version 0.23.5.3.2.2 - 2 May, 2014 - Realism Settings Love Edition.. - New: Changes to Settings Window to add previously hidden settings and tie them to the realism mode setting. - New: Crew Transfers should allow swapping Kerbals between parts. Swaps are possible within a part, but not between parts. - www.youtube.com/watch?v=I_TNxjnW234 - New: Added config file switch for Enable/Disable TextureReplacer eva event triggers. testing shows it conflicts with TACLS. - Bug: Highlighting behaves abnormally on resource changes from crew to another resource. Residual selected part highlighting... - Internally found, Post release of 0.23.5.3.2.1 - Bug: Highlighting behaves abnormally on part changes when moving away from source and target part being the same... - Internally found, Post release of 0.23.5.3.2.1a

Unfortunately not yet. After the last test we performed together, I've been wrapped up with RL work. I will be attacking that and the Science issue next. At least I can get a public release with the TACLS fix and get the CLS switch on the settings menu. that should help a lot of folks quickly and give me some time to think the inflatable hab issue thru. I'm thinking that I may have to refresh the values every frame. At least I will not have to destroy them repeatedly... I will try that before I release Edit: just talked with sumghai and was informed that SM works fine with SDHI parts, as well as FUSTEK. I will focus on fixing the inflatable now.

Hey DMagic, I've been so wrapped up in coding I've missed your parts! I was also notified on my SM thread that Science transfers do not seem to work with your parts. I want to get to the bottom of it, and I was told you were aware of the issue. If you would be so kind as to describe the problem I will see if I can correct it or work with you to ensure compatability. Thanks!

Wow, stay away for a day and what happens... Ok let me see if I can address the thoughts... 1. Stryth, Thanks for the heads up. I'll add that to the bug list and get cracking on it. 2. Phoenix: You are quite right, and I mentioned in my OP that I was going to rework the configuration. I agree that many of the "hidden" options should be on the Settings Window. I can link several of the realism options to the realism mode switch as a parent. Click Realism Mode on and then select the dependent options you want to change. However, it means touching a fair number of places, so I've put it off until I got to a more stable place after CLS. For the purists, they can set the vars in the window as well as setting a Realism Lock in the config, to prevent switching between real mode and standard. That should also satisfy the need for access by the less experienced and provide for those that do have the experience but prefer the convenience. 3. lextacy: I'm glad we got to the root of the issue! 4. acc: Agreed. Note 2 above. 5. Adampeay: You will find a few posts here talking about a config switch. I describe the config file in my OP. go there and see if you can make the change to turn off CLS. Finally, to everyone, I probably should have thought through the impact that CLS would have on SM more thoroughly. I didn't realize the confusion I caused because I did not adequately explain what CLS was and how it would change the way you play. My apologies. I will release a new version that includes the temporary fix for TAC Life Support. I added a switch to turn off 2 events that were causing a conflict. I'm hoping the other events I added with the last release will allow Texture replacer to work correctly, as the 2 events that get turned off are for that mod. I will also add the CLS switch to the settings window to make it easier to turn off if desired. Release to be coming soon.

CodePoet, I noticed the same thing with my test environment. At first I thought it was my plugins, as I had made some changes, but I managed to get it back to a working state from backups, and tested again with the latest dev version you released. I experianced it again. I would lose all SDHI. clampotron parachue Docking ports. Really messed up the game save. fortunately I had good backups for test, and I was able to recover. I hadn't responded yet as I'd been under 2 heavy deadlines at work and released new Reports for customers. I just got finished, and came here first. (I know, I'm a geek, I code for pay and for play) My apologies, as we could have addressed it sooner. }(

The reason this is true, is the fact that CLS endeavors to determine which parts are "connected", meaning they are connected to each other via an internally navigable path (tubes, hatches, etc.) if an EVA is required, then you will not be able to Xfer. CLS is very robust, and provides a lot of capability determining if a part can be reached, but it relies on Module manager config additions to maintain this "knowledge" of your ship. Therefore, you need to be sure the parts you use will allow crew to "pass". CLS achieves this by adding a passable flag to the part. It does this when it "Knows" the part is passable (crewCapacity>0), or via the MM configs (many of which are included with CLS) However, it is not omniscient. Therefore, you will need to go thru your ships to determine what parts are currently not passable and should be, or you want them to be, and then to add some custom configs for yourself. This may well be beyond the level of effort most folks desire, so I included a disable switch in the config file. I did not include it in the interface, as that would allow "cheating", and the realism purists are opposed to those kind of "conveniences". so, if you just want to move from part to part, and you don't care if the part can be reached "internally" (without an eva), then turn off CLS. Otherwise, spend a bit of time customizing your experience, and reap the benefits that CLS can provide. I love to let people "play their way". I considered setting the flag off by default, but then, how would anybody know about CLS integration? @lextacy: Is this behavior "the failed crew transfers" you were talking about?

I got it. I will look it over around 10:00 PM GMT

This would be the first time I've heard of any "failed crew transfers"... In the OP, I have a complete change log at the bottom of the post. You can take a look there, or you can describe your issue, along with the version you are using and the version of KSP.. Thanks!

Thanks so much for your testing, it is invaluable. I will take this info and go back to the drawing board....

Thanks! That helps with understanding the Issue. Edit: If you would continue to be so kind, try this: https://github.com/PapaJoesSoup/ShipManifest/releases/download/0.23.5.3.2.1b/ShipManifest.23.5.3.2.1b_04262014.zip This has added onVesselChange Detection and changes to creating CLS based Part list. Let me know if it notices the change in crew capability. Edit again. realized I may have left debug on, so the debug window may appear. when you get to the flight scene, select settings and turn off the debug window. save and it will stay gone. Sorry.

Upon review of my code, I noticed that you you have a habitable flag. I updated my code to use clspart.habitable as a test instead of part.CrewCapacity > 0. We can test to see if that catches it...

Thanks for the clarification. As you see in the thread, we are all in agreement on that point, so I think it is safe to say it will be addressed. I considered the desire not to use it with a config File switch, but it is true that it should not require you to install yet another plugin. I do appreciate you using Ship Manifest.

You can instantiate an object at the scene level and "do things" at the frame level. (amongst many other hooks into the engine) This is the scope I describe. When I started with Crew manifest, the code to generate the part lists used was instantiated at the frame level, refreshing every frame. Makes things convenient, but chews up memory as you are creating and throwing away objects at ~60 frames a sec. So, to reduce the garbage collection, and any potential memory creep, I moved them to instantiate at the Scene level, taking care to update them only when needed, not every frame. I would indeed need to do what you describe. I'm currently grabbing the list at the creation of the scene and checking part.CrewCapacity. I update when events occur. I will have to consider the method that CLS is using, or use CLS as my source for creating the Part List. I may also not be capturing the Vessel.OnVesselChange Event correctly...

Good catch. I do not refresh the part list as often as i previously did, in an effort to conserve memory and processing time. However, that means that changes to the characteristics of the part may not be recognized. Do you know if this behavior is exhibited in 3.1.5? If not, then I need to rethink portions of my scope for parts... Another thing to try. If you change scenes (or move a kerbal) after the inflation, does it now show up in the list? In any case, I'm going to have to spend a bit more time with CLS, as there are some things I want to try...

You are of course, correct, and I'm a proponent of choice for the community. I still have to learn how to do it, and with codepoet already into that, I'll be grateful to benefit from his efforts. I'd planned on adding space awareness to Ship Manifest. I had seen it as a long term goal, as there was a bit of work to do to better understand parts. codepoet saw the need from a bigger picture and acted. I'm grateful for that as well. As folks see the potential, and it is gradually realized, the dependency issue will become moot, even as I implement support for it being optional. Mech Jeb is "optional" as well, right? While CLS is not MechJeb (and neither is SM), living space IS at the heart of space exploration, is it not? Imagine this scenario... ".. Jeb's kethane storage unit attached to the lab sprang a leak and is spewing kethane into the lab. Doomla living space atmosphere sensor units pick up the change in the space's atmosphere, and trigger alarrms. it also commands the closing of hatches to the lab, sealing it off from the rest of the station. Jeb is alerted..." That sounds very cool to me... Potential Mods from that little scenario: - LS stmospheres - LS Disaster Emulator - LS Emergency Automation. - ... Hmm... got some ideas....

Okay. https://github.com/PapaJoesSoup/ShipManifest/releases/download/0.23.5.3.2.1a/ShipManifest.23.5.3.2.1a_04252014.zip I added a config file switch to enable/disable the Texture Replacer code. It is disabled by default. Also, since I was mid update, you now have the ability to transfer crew members into a full Part. Crew members will swap places, just like when you move a karbal within a part. That will be included in the official 3.3 release as well. Give it a whirl. Not a problem. There are options for those that have "heartburn" with it atm.

If you are willing to help me troubleshoot, I will be glad to release a "revised" version to see if it helps. Then at least we will have narrowed the issue and I can see about correcting it.

-1 for the dependency, or for the integration? if for the integration, you can set a switch and turn it off. If for the dependency, I understand, and am considering some reflection code (thanks codepoet), to make CLS "optional". Finally, the previous version 0.23.3.1.5, does not have this dependency and can be found on my Github repository http://github.com/PapaJoesSoup/ShipManifest, along with other previous releases. Thanks for the feed back!

It is also possible that recent changes are manifesting this. It was reported in the first version with CLS. I thought I may have corrected it, but I don't use TACLs. In order to support Texture Replacer, I've added an eva and a board action to the kerbal to facilitate proper texture updates. I'm thinking that this may be causing the conflict. I will examine the TACLS code to see if I can notice anything.

I want to correct this statement. There IS a way to Add a Kerbal in the current version and likely a few versions back. 1. When in Pre-flight, Open Ship Manifest. 2. Then Open the roster and go to your available kerbals. 3. Select Crew in the Ship Manifest Window, and open the Transfer window. 4. Select the source part in which you want to place your Kerbal. 5. The Roster window "..." button text for the available kerbals will change to "Add" (if there is room in the part). 6. Add your kerbal.

I just read here that FusTek has just added CLS integration: http://forum.kerbalspaceprogram.com/entries/1441-FusTek-Station-Parts-Expansion-X0-04-3-DEV-BUILD-released-%280-23-5%29

You can edit the toolbar config to re-enable it in that scene. \GameData\toolbar-settings.dat Also, Blizzy78 likely has answers to these questons in his thread. that thread is linhked in my OP, near the top. and here: http://forum.kerbalspaceprogram.com/threads/60863