Papa_Joe

There is one more option as well (assuming you haven't already done this ). You can take your fork, and perform a pull request. Then, assuming it is a small change, TaranisElsu need only perform a merge and release.

With the next release, I will be changing the Mod detection method to use .StartsWith(). This will give me more control over the name check. I'm also implementing a new tab called Mods in the Settings window, that lets you see what mods/assemblies are loaded in KSP. Useful for me, don't know abut anyone else...

In an upcoming release, it WILL make a difference, but at the moment it won't.. When it becomes important I will be implementing a version checker class that other mods are using built by iirc NathanKell. The mods needing it will use the correct version. New Release: Version 4.3.0.2 - Release 08 June, 2015 - Crew, Interfaces, & Refactoring Edition. - New: Cleaned up highlighting when undocking events occur to turn off highlighting on vessel parts/vessels that become detatched... - Fixed: Bug in settings. When disabling Crew in setting, if crew was selected, Highligting does not turn off. - Fixed: Bug in Settings. When in Highlighting Tab, "Highlight only Source/Target parts" and "Enable CLS Highlighting" should act like radio buttons but do not. - Fixed: Under certain circumstances, Highlighting woud not be completely cleared when turned off If crew was selected and CLS was enabled. - Fixed: RemoteTech detection was failing when multiple copies of the RemoteTech.dll existed.

I have a solution. My code currently looks for a single instance of the dll, and as result, errors when more than one copy is present (this was the spam in the KSP Debug log. Often mods will include a "tweaked version, or embed a copy of the dll to cover their integration needs (hard dependency). I will now change that method to check for the first occurrence and go from there. Since I'm not concerned if a "particular" version is present, only that it exists, I can safely change the search to be tolerant of multiple copies. My revised check no longer cares if more than one copy of the dll is present. Thanks for the help, and I'll have a fix out very soon.

Ok, what I discovered is that I revised the method for checking on the installation of RemoteTech with this release. I "think" it revovles around this check. If you have more than one RemoteTech.dll installed (for example if there is another mod that embeds the remotetech.dll for some purpose, this could cause the check to fail. I'm revisin git to test this case. Can you check your gamedata folder to see if more than one copy of RemoteTech.dll exists? This would help me confirm what I think is happening... Hmm... I thought I disabled the SM interface when you were in IVA mode... anyway, that is a known issue, as there is no place for the kerbals to go internally when I'm performing the transfer. I'm not sure I can disable the IVA button on the portraits, but I will look into that. Ok, Now I get it. With Enable Highlighting on, clicking on Highlight only Source/Target parts is a toggle. If you turn on highlight only Source and target parts, it automatically turns off Enable CLS Highlighting, but, clicking on Enable CLS Highlighting does not automatically turn off Highlight only Source/Target parts That may well be a bug. I know I've refactored those tabs, and I was thinking that cls and only source/target acted like radio buttons. I think that is what I put in my Wiki. I agree it would make sense for them to act that way, so I will alter the behavior in the next release. Note that CLS Highlighting only affects the behavior of highlighting Crew, as described in the Wiki. Maybe I should add that note in the settings window eg, "(affects Crew only)"? As for turning on/off highlighting for each feature (crew, science, resource), I've thought about it, but originally felt the existing options were sufficient. Most feedback has been to simply be able to turn off highlighting in general. If folks feel there is sufficient value in being able to turn it off for Crew and leaving it on for science & resources, or other such combinations, I could add that capability. I was just thinking I had it flexible enough. Did I understand you correctly?

Looking over the images that were provided (Thanks for that!), I noted errors with a logic check as well (IsPrelaunch). This also lead me to note that the issue was on a lander. Was the lander Crewless? meaning was is a probe? or was it crewed and all crew had exited the vessel? Just trying to narrow down the conditions. I know I have not tested landers properly, so I wlll create that condition in my test save and see what's what...

Gratz on the Release! Downloading it now.

My apologies for the confusing way that "radio" buttons are used, but it is a consequence of Unity and choices I made to try to keep the lag down as much as possible. To help with that, the Wiki describes the operation of the Realism tab in detail. Now for the tl;dr; Unity does not come with a checkbox by default. To create one I have to emulate it in code. I decided that this just adds unneeded "overhead" to the program, and just slows things down since they have to be rendered each frame (update / onGUI). The radio button as you call it is actually called a Toggle in Unity. So it is treated as a check box. If you look at what the control tabs look like, those are toggles as well, and any or all can be on or off. For the Settings window, what I did was to enable/disable options as other options are turned on/off to prevent you from changing settings that would have no effect. SOME of the options are treated like a radio button, such as the highlighting options. Source/Target only turns off CLS highlighting, as it is unneeded in that case. Now the special case for CLS is this: Since I detect whether or not CLS is installed, I automatically disable CLS in the settings if it is not installed. If it is subsequently installed, I cannot "assume" you want it and automatically turn it on, as you may have turned it off "intentionally" with CLS installed before the previous save. SM does not know if you had CLS before, so it has to "assume". To overcome this, I "could" create an "Is CLS Installed" flag in the settings to remember if it was installed or not. If it gets installed and I detect the change, I can automatically turn it back on as a "default" setting. I had also looked at creating color dropdowns for choosing the highlight colors (those are hidden settings editable in the config file), but dropdowns are not native to Unity either. So I have to create a chunk of code that then gets run for each dropdown and also "slows" things down. I'm hoping with Unity 5, and the new GUI tools, I can make improvements in the gui. I'm also looking at re-skinning SM to look more like Roster Manager or MechJeb for example.

Ok. thanks. I'm using direct X, I didn't really see OpenGL making a difference. I'll pour over the code. Thanks All!

Interesting. I have remote tech installed and I have no issues. I tested with and without Remote Tech installed, and I have a vessel with RemoteTech antennas installed... I'll look at the code with the errors you found in mind. Thanks for the feedback on this. What version of RemoteTech are you using?

Thanks for the props! Donation button... hmm... I could use donations... Rep is nice too.. Also, thanks for taking the time to characterize and report the bugs you find. Without it I cannot make SM better. I've long thought of mouse over highlighting of the part in the list, and possibly clicking on the part to select it in the Transfer window, but the code had not been sufficiently refactored to "make it clean". It is still on my radar, but lower priority atm. With the ability to highlight the part by mouse over of the list item, I kind of addressed it from the opposite direction, so you have the visibility... If you don't have edge lighting on in your KSP settings, I suggest you turn it on... makes finding the part very easy. This feature also works in the control window. Locating that docking port (CLS hatch feature) is MUCH easier with the edge highlight feature. As for the update rate... well.. Just released: Version 4.3.0.1 - Release 06 June, 2015 - Crew, Interfaces, & Refactoring Edition. - New: Refactored Resource transfers to improve overall transfer speed, flow & "feel". Lag was causing issues on larger vessels. - New: Refactored Vessel update methods to properly udate various part lists if vessel changes occur while SM windows are open (undocking, etc.). Now various windows properly refresh. - Fixed: Bug in multi-part transfers that allowed continued transfers when a transfer is initiated and then you undock a vessel from a station. - Fixed: Bug in Crew Transfers that allowed continued transfers when a crew transfer is initiated and then you undock a vessel from a station.

Thanks. Tbh, the issue does look SM related. I noted you are running realism mode and that CLS is not installed. So, the first thing I thought of was an error in creating the hatch list, causing the screen display code to cause errors. If you wish, you can turn on the Debug window in settings, and if there are errors, they should be listed there. That will help with tracking down the problem. It will indicate the error and the method generating the error.

Interesting. I've not seen it, but my testing may not have been complete enough. I'll go thru it again. I did however, add a more consistent refresh of all part lists, so this issue may already be resolved in the upcoming update mentioned above. Ok, I'm not able to duplicate the issue above. steps to reproduce would be helpful. I may have already corrected the issue with my refactoring. I'll be issuing an update in a few hours, so either you can provide me steps to reproduce the issue, or you can wait until the update to see if that corrects it.

Going to bed now, but most testing is complete. Proposed change: Version 4.3.0.1 - Release 06 June, 2015 - Crew, Interfaces, & Refactoring Edition. - New: Refactored Resource transfers to improve overall transfer speed, flow & "feel". Lag was causing issues on larger vessels. - New: Refactored Vessel update methods to properly udate various part lists if vessel changes occur while SM windows are open (undocking, etc.). Now various windows properly refresh. - Fixed: Bug in multi-part transfers that allowed continued transfers when a transfer is initiated and then you undock a vessel from a station, or the vessel is modified (detach a part). - Fixed: Bug in Crew Transfers that allowed continued transfers when a crew transfer is initiated and then you undock a vessel from a station, or the vessel is modified (detach a part..). Will release later Today (CDT US)

Okay, The slow transfer issue is related to the timing method I've been using. Originally, I was using Planetarium.GetUniversalTime(), and calculating the difference in this value each Update. However, since this is game time, lag (frame rate) can greatly affect it.. SO, I changed to using DateTime.Now, and calculating the difference in this value between Updates. Since this time value is more constant (computer system clock), I'm getting a better result. Now the flow "seems" more fluid, and runs a bit faster. It now feels right, at least to me. Now the vessel change. I'm going to cause the transfer to immediately stop if a Vessel change Event is fired (this happens if you undock a vessel from your station for example). What this also means is since you are trying to do 2 things at once I better check for crew in transfer as well... I added an abort, in the case a crew transfer is in progress and you decide to undock ... Since I added an abort to support the ICrewTransfer API, I already had it... New update will be out soon with these changes.

Hmm... that makes sense... I need to update the transfer list in the event of a vessel change. if the from or to part count end up zero, then kill it.... Thanks for that. As far as the slow transfer rate, I think I know what that may be. Let me get on those issues. Thanks!

I know of a couple of mods that provide docking adapters... B9 and KW... I believe that CLS comes with configs for both. You will need Module manager to make them work. Any others that anyone can think of? If you have a mod that does not work with CLS, let me know, and I'll look at creating the needed module manager configs to make them passable. Which reminds me. I have an update to the Alternative stock Freedom config that was submitted as a pull request that I've merged from mwerle. Let me look at getting a new version out with the new config. It added stackable1

Man, that IVA is going to be awesome. As far as the licencing, you are well within the boundaries of the license to continue the work "in your own direction". The license allows for that. As long as you provide due attribution, which you have made clear you will, you are good to go. I believe in choice, and even if the original author returns, this is a viable choice for the community. This is the greatness of the KSP community. We (at least from my perspective) help each other, and keep the fires burning (or freezers running)

Sounds like a plan. This work deserves a new OP! Edit: I also think your new OP should move from the dev forum to the Releases forum.

Update: New Version released: Version 4.3.0.0 - Release 04 June, 2015 - Crew, Interfaces, & Refactoring Edition. - New: Refactored Crew transfers into separate class to improve visibility and state management. - New: Crew transfers (part to part & seat to seat) now show both kerbals involved as moving, when a kerbal swap occurs. - New: Added DeepFreeze mod support for handling/viewing frozen kerbals. No more xferring frozen kerbals, and Roster Window now shows frozen kerbals. - New: Added SMInterface.dll for other mods to detect Crew xfers in progress and act accordingly. - New: Add onCrewTransferred Event trigger to be consistent with Stock Crew Transfers and to support KIS inventory movement when crew transfers occur. - New: Added Kerbal Filter for Roster Window: All, vessel, Available, Dead/Missing. Vessel filter is omitted when in Space Center. - New: Refactoring - moved window vars from Settings into window level code. - New: Refactoring - Added InstalledMods static class to centralize mod assembly detection and soft dependencies. - New: Refactoring - Altered Settings Save to segregate Hidden settings for ease of identification by users. - Fixed: Bug in multi-part transfers that lock transfer in run state, with no progress. Gave loops timeouts, and relaxed the resolution of the calculation to allow for rounding errors. - Fixed: Bug in Crew Transfer. When transferring a crew member to a full part with realism off, the crew member does not swap and disappears... - Fixed: Bug in Crew Transfer with CLS installed. First transfer works fine, subsequent xfers fail, and Transfer is stuck in moving...

Did you have realism off? Also, were your transferring to a full part? I noticed when I refactored the crew transfer code that this condition was possible if you transferred a kerbal to a full part with realism off.... poof gone. Crew transfers were significantly refactored for the new version to support DeepFreeze, so I fixed this issue in the Release candidate above. New "official" release soon. JPLRepo is nearing completion of his testing...

No. Thank YOU for the testing effort to make SM better.

Ok. Found the issue. It was indeed double var resolution. I divide the an amount that is calculated against a flow rate and an elapsed time counter (timestamp) by the number of parts to which I will be moving a resource. as a result, it can get numbers that are very small... if i divide an extremely small number, I exceed the resolution of the double, and end up with a zero as a result. So, I end up with an endless loop because I never actually move ALL of the amount I request. So I changed the equality statement looking for remainder = 0 to remainder < 0.0000001. This provides a reasonable resolution, and still provides reasonable accuracy. I also included a "timeout" feature to prevent deadlocking of the loops I run "just in case" . I've tested, and it is working. New release candidate is out at GitHub.

Well, I've refactored the Resource transfer system. (needed it anyway). also made some changes to the crew transfer interface and cleaned up Non Realism crew transfers (portraits were not updating properly...) I've beat the resource transfer to death, and cannot reproduce the error you are getting. Going to update the RC with the new code. When you get a chance, play with it and let me know. Thanks! Oops, spoke too soon. Duplicated the issue with a multi resource transfer... Back to the drawing board... Time to instrument it a bit differently and add a timeout feature to aid in troubleshooting. I'll let you know later today.. Time for sleep for me.

Thanks. This will help loads. Off to get it fixed...