Papa_Joe

Ok folks. a burst of productivity I read over the forum thread, and reviewed my bugs in Git, as well as noting a couple of things while testing. So changes/fixes are in place New version: v1.2.5.7 release v1.2.5.7 release date: 30 Jan 2018 - Changed: Color for "No" response in information displays changed from Maroon to OrangeRed to improve readability (contrast) - Fixed: Blizzy's Toolbar wrapper needs updating. Git Issue #77 - Fixed: Vessel data is not updated when creating/modifying/deleting a vessel in the Vessel Editor. Git Issue #85 - Fixed: Passable strings reversed. Git Issue #92. (thanks to @yalov!) - Fixed: Hatch status reporting error in tweakable. Git Issue #93. KSP AVC version file properly updated. SpaceDoc and Git Updated. Enjoy!

No problem, I'll do some digging. Update: After looking over my configs, and then examining TAC-LS configs, there are no default configs in place for them. Therefore, based on the logic used by CLS, it "attempts" to determine passibility based on Crew contents of a given part. I'm guessing that some of the 2.5 meter parts may allow crew? I'm good friends with the mod Author ( @JPLRepo ). I know he does not have time to consider CLS compatibility. If someone wishes to create a config file for TAC-LS, i'm sure he would appreciate it, or conversely, you can send it to me in a PR and I'll be happy to review and incorporate.

This may be simply that when CLS was created, there were no TAC-LS parts of different sizes. iirc, the mod auther did not create configs for these parts. So likely there are "compatibility" configs included in CLS. I will have to research the configs to see if this is the case. Alternatively, you can look at the TAC-LS mod folder to see if MM configs exists for the parts.

Sorry I;m late to this conversation, but yes indeed the behavior is by design. As was stated in the next response, when a part designer designs a part (or by extension most all stock fuel tanks and other resource only parts), inline passibility is not allowed, as this usually means that significant structural and internal changes are needed to support adding passibiliyt to these parts. You could assume that allowing passibility would involve added weight as well. this behavior is also by design. When a part designer designs a part (or by extension most all stock fuel tanks and other resource only parts), surface mount passibility is not allowed, as this also usually means that significant structural and internal changes are needed to support adding a port in the side of a part. You could assume that allowing passibility would involve added weight as well. Most in line parts that are batteries or fuel tanks are not designed for crew to pass through. CLS will prevent these from being passible by default or by Part designer direction. So for the Clamp o Tron, the Clamp o tron has passability, but the part it is attached to does not accept surface attached parts as passable. Now, with that being said, as you all know, I'm all about choices. SO there is an option in CLS to allow you to change this characteristic in the VAB for a part when it is added to a vessel. This is not a permanent change to the part, it is a "one off" for that vessel only. If you enable custom passibility in CLS (and restart the game), you will now be able to tweak passibility on your parts for a given vessel. Remember that Passibility is needed on both parts to make this work. so if you are combining two inline parts (side by side), you need to set passability from both perspectives. The two interesting parameters are: - Passable When Surface Attached: This means that when the part is attached to the surface of another part, you can pass through the part that you are attaching. - SurfaceAttachments Passable: This means that you allow parts that you have attached to this part to allow a pass through to this part. Think of it this way. there are 2 bulkheads involved. the part you are attaching, and the part that is accepting the attachment. both must be set to passable to allow a complete tunnel, per se. using simple symbols here is an example. Perentheses are closed bulkheads, and = is a tunnel cut through the part(s) when both parameters are false: you have essentially: )( (bulkheads separating each part). when one or the other is passable you have: =( or )= when both are passable then you have a complete tunnel: == Clear as mud, no?

New release. release v1.2.5.6 release date: 29 Jan 2018 - Correct errors in config files for Mod version, and KSP version supported. Should work with KSP AVC now. CKAN can now properly be updated.

I did miss the KSP version update. I updated the SM version but not the KSP version. Updating it now. Also I will be addressing some other errors noted and some additional work I have completed.

Interesting. I thought I updated. I'll check. Update. Yes the version file is out of date. I will correct and release a dot upgrade. I believe there is also a note in the issues about a reversed yes/no on the tweakables. Looking into that as well.

Ok. 1.2.5.5 final is ready.. New official release Incorporating changes by linuxgurugamer during my absence. 1.2.5.4 beta by linuxgurugamer, released under permission. 1.2.5.5 beta by linuxgurugamer, also released under permission. for these 2 releases go to his git repository. release v1.2.5.5 (official) release date: 03 Jan 2018 New: PR from linuxgurugamer for an Updated CLSB9.cfg: Thanks to @Mine_Turtle: linuxgurugamer has added CDP docking port(supposed to be used with s2 parts) to the list and made s2 crew parts passable, when surface attached. Reason: there is no inline s2 docking adapter, nor it is possible to attach stock docking ports to s2 modules and have crew transfers with CLS. release v1.2.5.4 release date: 28 Oct 2017 (beta by linuxgurugamer) New: Merged PR from @tyehle: Make kibble storage passable. Fixes #87 New: Merged PR from @yalov: Localizations New: Merged PR from @cake-pie: Refactor New: Merged PR from @Kerbas-ad-astra: Some new part configs Release is now on Github. Spacedock has also been updated.

Thanks!

Sorry for the delay. I've got my latest code running. @linuxgurugamer, Let me know what things you changed and I'll get them incorporated. I've not given up on CLS . Thanks for all your hard work!

Take a very close look at the bullet holes, you will notice initial heating and cooling of the metal after penetration. Very cool stuff...

Back on topic, the changes in this upcoming release have an interesting effect on vessel design. Since armor piercing shells can now penetrate, you may experience instances where the shells simply pass through the vessel and do no real damage. This is by design, and will necessitate new thoughts on vessel and aircraft design. the idea here is that armor is designed to protect "Something". so internal parts now become both desirable and vulnerable. This leads to interesting battles with degradation of the vehicle as a result of damage. SpannerMonkey has spent a fair amount of time taking advantage of this by building ships with fully realized internal systems. the results are pretty spectacular if you ask me...

Im back from my China Vacation, and settled back into work. I'll be going over my latest status on SM this weekend. The issue above with CLS is related to the beta version released by linusgurugamer. I will be sure to update both SM and CLS this weekend. The issue with the the large station will require a bit more work. I significantly refactored the vessel to vessel system and my vessel detection scheme. It is possible if have not taken all conditions into account. A log and game save would be very helpfull.

For a clear picture of what is going on, what has been accomplished and what is planned, take a glance at the Github repository Listed on the OP. We keep a transparent track of work ongoing and bugs. That will enlighten you.

I've responded to @linuxgurugamer. I'm currently on vacation in China and won't be back for a month. He has offered to create a temporary 1.3.1 recompile for me during my absence. Thanks man!

most likely, yes. I do not know which part, but it will need to be passable as well for CLS to allow them to be one space, and for SM to perform internal transfers when realistic transfers are enabled. if you look at the assembly in the VAB, CLS will allow you to visualize the space. CLS works in the editor, so you can then detect parts that are not passable. if a part in the chain is not passable, the spaces will be separated in the editor.

CLS by default, attempts to add hatches to a given part if it has a ModuleDockingPort contained in the part. When it detects such a part, it will automatically add a ModuleDockingHatch Module to the part, during part load via a Module Manager config. Hatch opening and closing is controlled via this module. I'm not (yet) familiar with BDB parts, so I cannot say what the issue is, but maybe this info will shed some light...

Sorry, not sure what your statement means. Science can be enabled and disabled from the settings window, so it is possible you have it turned off. If so, then Science will not show up in the Manifest window. However, if Science is enabled, and you are selecting science, are you seeing the parts that have science container, labs or experiments in the part selector? Finally, the Control window has a labs feature. If you have a lab on your vessel does the lab show up in the labs tab? As you can see, I need more info than provided to really assist you. Please provide steps to reproduce your problem and if possible screen shots of the bad behavior. Finally, include your output.txt file so that I can see if there are any issues with your installation or interactions with your other mods...

Understood. Latest available version compatible with the KSP version you are running against. and yes licensing must be the same as we distribute. The forum Mods are very particular about licensing, so be sure you include our licensing with the distribution. our distributions contain a license.txt, so that should be easy.

Answer is yes. I believe I had licensing all resolved with it after some research... but that was lost when our forum post got eaten... However, if you look on my Repo. there should be a license.txt somewhere. I know I did all the due diligence on that when we started.

The short answer is maybe. The Roster window has provisions for editing kerbals, but you may have to remove them from the vessel and put them back after you finish. Set the Realism settings to none, and you can do this. However, Roster Manager will do this much more easily. It works similarly to the Roster window of ShipManifest, but allows for complete control over your kerbals. Link is in my signature.

I'm sitting here in front of my computer, contemplating how to solve one of the issues I have with science transfers, and it occurs to me.... In the first place, one of the issues I had with vessel to vessel transfers was proper vessel detection. The possibilities can be very complex, as KSP keeps track of each docking with 2 objects. ModuleDockingNode.VesselInfo, and ModuleDockingNode.otherNode.VesselInfo. It is a very flexible way for KSP to keep track of vessels when they dock and undock. This makes reassembling the new vessel easy on undock, and allows for persistence to save file of docked vessel info However, because of this flexibility and "memory" of docking history, you can get some very interesting results when you try to traverse a vessel that contains several docked vessels. I suspect those that have assembled stations or depots from multiple launches are noticing this as we speak. I have not tested extensively with myriad combinations of multiple launches to assemble stations, but I suspect you end up with several vessels connected together in a hodgepodge. this got me thinking. Since I can detect the vessels, why not allow you to combine them? I wanted to be able to merge 15 different docked vessels into one vessel so vessel to vessel transfers are easier. Besides, in actuality, a station, base or depot usually takes many launches to assemble. So, I built it. In the Control Window, where Docked Vessels are displayed, I have added a toggle to allow selection of multiple vessels. The action buttons at the bottom gives you the choice of combining these selected vessels or clearing the selections. Now you can have a single vessel that represents your Station, Base or Depot. Since I added Docked vessel renaming in the last release, you should be able to name it and "make it one". Screen Shots:

May be a moot issue now. New release out. I suggest testing against that. Version 5.2.0.0 - Release 17 Jul 2017 - Vessel to Vessel Edition - New: Added Docked vessel to vessel Crew transfers. - New: Added Docked Vessels Control panel. View your docked vessels, Rename a vessel, and undock a vessel with a click of a button. - New: Added option to vessel to vessel Crew transfers to limit crew xfr list to tourists only. Space tourism awaits! - New: Added ability to create Tourists from Roster Window. - New: Spanish localization added. Thanks to Fitiales! - Misc: refactored vessel detection for vessel to vessel transfers, it was not behaving as exected. - Misc: A bit of refactoring on highlighting, as it was not behaving as expected - Misc: Increased base volume of crew movement sound files. Note: I'm in the middle of testing the changes to vessel to vessel science transfers. I've got it disabled until I have it working reliably. Also, the highlighting bug was fixed with the refactoring I did for highlighting in the change log above. As always, enjoy, and report any issue you may find.

Hadn't considered that. Space tourism... Hmm.. well to filter the kerbal list for just tourists is trivial, so I'll add an option to allow that. Now where to put that option..