Papa_Joe

No. You must turn Realism mode off. The idea was that once assigned to a flight, there should be a cost for substitutions... This was based on player feedback. CLS will have no affect on crew assignment, only on crew movements within the spacecraft... I had debated whether or not to allow it in Pre-flight (on the pad), but the user feedback for realism folks was a no...

Thanks for the feedback everyone, I'll see if I can track it down. If you could, turn on the debug window, and see if you are getting errors... I trap most of my own errors, and that way you can save them to disk from the debug window. frame rate drops are usually associated with spamming my debug log... I'll see if I can duplicate myself as well. definitely something we need to squash and quick.

Please let me know what version you are using. I experienced this issue in an earlier version and was *sure* I corrected it. If you are experiencing this in the latest version I really need to know. Thanks for the report. Also, just released a new version: Version 0.90.0_4.1.3 - Release 12 Mar, 2015 - Better Behaviors Edition. - New: Revised SM original Crew transfers to delay the actual transfer of a kerbal to the end of the wait period. - New: Added support SM style Crew transfers when using the stock Crew transfer. You now get crew movement sounds, and the same delay for crewmember transfers when in realism mode. Can be disabled. - New: Better support for multiple resource transfers. If both previously selected source and target parts contain a newly selected resource, parts will now remain selected. - New: Revised resource movement duration algorithm. Now using a flow rate, based on source part capacity and max flow time setting. Now max time is based on pumping (pushing) a full tank. - New: More Refactoring. Removed redundant part lists (SelectedResourceParts), refactored & renamed FindKerbalpart method. Removed TextureReplacer event option (not aware of anyone needing this). - Bug: When in KSC & Roster Window, if you respawned a Kerbal (bring them back to life), Exception Detector would report errors from some other mods)

As a partial response to this, there is an API mod out there called KerbalStats. I was looking into leveraging this for my next mod Roster Manager. It adds a persistence file that is extensible, and provides modders with ways to "extend" kerbals. One of the issues I recently worked on was renaming and changing kerbal professions. KerbalStats manages this using "active managment", meaning that the kerbal's profession is stored in the persistence file, and then reloaded when the game save is loaded. I used a different method, or kind of a hack if you will, to add ascii 1s to the end of the name to "spoof" the profession generator by altering the hash of the name. I will be adding support for KerbalStats to maintain compatibility, and to allow for custom professions, as there are some mods now doing that. This may be a way to make some of what is discussed here possible. However, the points that codepoet raised here and in the other thread, are still valid... What would the result be? Anyway, my 2 cents...

Update: I've looked over the code, installed Exception detector and duplicated the issue. I made a change by removing the ProtoCrewMember.Spawn() method. This seems to get rid of the error, and the status of the Kerbal still changes. I'll include this change with the next release. Please note the second error does not involve SM at all. Thanks for reporting the issue! I've recently discovered there is a compatibility issue with KerbalStats, and other mods that add "non standard" or custom professions. I discovered this as I've begun work on Roster Manager. These mods actively manage the profession of a kerbal by separately persisting extra data for a kerbal and using it upon load. Kerbal stats, and other mods that use active Profession management "require" you to continue using their mods to retain changes made to kerbal professions. If you were to discontinue use of their mods, then your kerbals revert to the profession automatically assigned by KSP, based on the name. I wanted to provide a means of persisting the profession and name WITHOUT locking you into using SM "forever more" with that particular game save. With my method, if you later decided to discontinue using SM, the altered professions remain. SO, Ship manifest uses a "hack", if you will, by adding a series of Ascii "1"s appended to the name to alter the hash generated by KSP to get the desired profession. This also means that SM does NOT support custom professions when you use the renaming options. If you are using mods that use active profession management, I highly recommend you disable Kerbal Renaming and profession management in SM (it is disabled by default). If you already have some kerbals renamed using SM, you can remove the extra characters in the game save and you should be able to continue using the other mods. Iirc, they appear as "smiley faces" in a normal text editor. I'm looking into providing both methods in a later update, so as to maintain compatibility with these mods, and still provide you the user choice in how you want to persist profession changes. If this does NOT describe your issue, then I will need more information. I'm using kerbal renaming and profession management with no issues in my main game save and my test save.

Interesting. None of the errors are "directly" related to Ship Manifest. However, it may be that the other mods in question are "assuming" certain events will not be firing at this time. I will see if I'm firing an event that could possibly be causing the issue in this particular scene. That could account for the issue.

Update: I've looked over the code, and tested version 0.5 with 0.90 and it seems to work, with the exception of black portraits on certain transfers. So, it is useable in 0.90. If the mod author is okay with it I can clean up the portrait issue and bring the Module manager config up to date with better support for parts with crew capacities of greater than 10. Also, the current code is not as efficient as it could be and could experience issues with large vessels, tho I've not tested that to see if it impacts frame rate. If anyone out there is using this mod, please let me know if the frame rate is affected by this mod when you are preparing to transfer and both windows are open... For those unfamiliar with this mod (as I was) you first right click either the source or destination part, then ALT+right click the other part... the end result is you will have 2 Tweakable windows open at the same time. The crew members then appear in the tweakable windows...

I've seen this as well, but I've experienced no crashing. @codepoet: Since I made the last alterations in that part of the code I will also take a look, create steps to reproduce and see if I can see any errors in conditional logic I may have made. Update: After a quick look at the code, the error generated is managed. it will not cause any crashing. So, the source of the crash must be related to something else, as I'm seeing the error consistently ,and not experiencing any issues. I'm seeing the error on initial load of a vessel, so it looks like the vessel may not be instantiated at that point, so a quick check for the vessel != null should correct the cause of the exception. Testing a fix now. Ok, tested fix, and the issue goes away. Code below is the revised method: private void RebuildCLSVessel(Part newRootPart) { try { //Debug.Log("RebuildCLSVessel"); // Before we rebuild the vessel, we need to take some steps to tidy up the highlighting and our idea of which space is the selected space. We will make a list of all the parts that are currently highlighted. // We will use that list to un-highlight parts that are highlighted. Once the rebuild is complete we will work out which parts are still in the list and highlight those parts. uint flightID = 0; List<CLSPart> listHighlightedParts = new List<CLSPart>(); if (null != this.vessel) { try { foreach (CLSSpace space in vessel.Spaces) { foreach (CLSPart p in space.Parts) { Part part = (Part)p; if (flightID != part.flightID) { flightID = part.flightID; //Debug.Log("Part : "+ part.flightID + " found." ) ; } if (p.highlighted) { listHighlightedParts.Add(p); p.Highlight(false); } } } } catch (Exception ex) { Debug.Log("CLS highlighted parts gathering Error: " + ex.ToString()); } //Debug.Log("Old selected vessel had "+ listHighlightedParts.Count + " parts in it."); vessel.Clear(); } // Tidy up the old vessel information this.vessel = null; // Build new vessel information this.vessel = new CLSVessel(); this.vessel.Populate(newRootPart); } catch (Exception ex) { Debug.Log("CLS rebuild Vessel Error: " + ex.ToString()); } }

I would have to agree. While SM provides this capability, kerbal crew transfer is an elegantly simple solution without the "excess" features. @joed_: I'd be happy to fork and submit a pull request to bring it up to date with 0.90 if you don't have the time or inclination to do so. Otherwise, I'd be happy to take over maintenance if you approve.

Update: Ok, I've reexamined my code, and discovered that since implementing crew transfers in SM over a year ago, I actually did not delay the crew transfer in SM at all... All this time, the transfer was happening immediately, and I was delaying the portrait update until after the duration of the move timeout. So, when I tried to add support for the stock move, I was reverting the crew back to their original parts, and immediately moving them to back to their new locations... then waiting to update portraits... this caused some confusion for KSP, hence black portraits... So, I reworked the original SM crew transfer method to first play the sounds, and delay the actual move to the end of the wait period (currently set to 7 seconds in the config file), and then make the crew transfer and update the portraits. This allowed me to better manage the stock transfer revert and trigger an update BETWEEN the reversion and the actual SM move. Result is that now, whether or not you transfer a kerbal with the stock or SM method, the actual transfer does not occur until the end of the wait period, and the portraits properly update. YAY! I have some more refactoring I'd like to do, but things are looking good. We now have SM transfer support that overrides Stock transfers. Looking into creating a move button and adding it to the part's tweakable dialog now...

Update: During my implementation, I've noted an issue with refreshing the portraits. It seems the portraits end up blank. My investigations show that the currently used event handler GameEvents.onCrewTransferred, occurs after the completion of the stock transfer, so I spend effort undoing the change and re-accomplishing the task... However, the damage is done, and the portraits are updating even as I'm running the transfer again. I might be able to add a few seconds to the delay and get the desired results, but I'm still looking at whether or not I can trap the action "before" it starts...

I suggest you mention this to the other mod developers that "require" the stock toolbar. Ship Manifest has a means to "hot swap" between the stock and Blizzy's toolbar. I don't get rid of the "hard coded ones (sorry), but at least you get the choice. Other mod developers are free to examine my code to see how I did it. They are also free to use and alter the code to fit their needs. It is not very painful, and provides the best of both worlds. Just saying...

Point taken. I will evaluate this in light of your statements. Mine is indeed only "tricking" KSP into using the desired profession. Now that I'm looking at kerbals in more detail and considering using your API, I will evaluate my options. I may end up providing both means such as in a standalone vs Kerbalstats compliant, and let the user decide the path they choose.

I agree. I'm in principle against such hacks as well, including the Hack we are battling against from Squad. I'm surprised at the association of the profession to the name... you should never tie things like that together at all, first generation or not. Some other, more robust method should have been used. So, Squad has kind of forced our hand here. I wanted a means to persist it to the save, rather than relying on an external means, as that meant that removing the addon meant "losing" the changes. I didn't want such "loss" of critical data to happen, and I didn't want the user to be "Forced" to continue using my addon because I changed such critical data. This is also why I have the feature turned off by default. If you want to use it, you can, but with the above awareness. 5thHoresman has been testing it and it seems to be working good. I've heard no negative feedback as yet. Hopefully, Squad will address this and provide for a means to elegantly make such changes via the API.

Never feel bad that you don't know something. This is why the forums are here... to help each other with this awesome game.

I was looking at that in your code. I have working experience trait changes and renaming in Ship Manifest. I'm moving that over to Roster manager. It uses a trick passed to me by 5thHorseman where we add ascii 1s to the end of the name in order to "spoof" the hash algorithm KSP uses. I can then persist what ever Trait I desire, by adding ascii chars to the end of the name. They are non printable so it seems to work just fine. I've had it in the wild for a week or so or more. Only issue reported was that the chars show up in map view when a kerbal is on the surface... cosmetic only. I'm going to take a look to see if it impacts your mod in any way. Feel free to check out what I did. Works pretty nicely.

Squad built in kerbal transfers as a stock option. CLS provides for "space aware" transfers. You can click on the crewable part's hatch and a transfer option appears. click Transfer, and you get the highlighted parts that you can transfer to. Click on one of those parts. If it is in the same "space", then the transfer works. If not, then CLS will notify you that the transfer is not possible. This can be overridden in the CLS Window, so that you can transfer to any crewable part. CLS was designed to be an API, that allows other modders to use the info it provides. Finally, there are two mods that provide for crew transfers. The original is Crew Manifest. The other is Ship Manifest. Crew Manifest is fairly lightweight, and only moves kerbals. Ship Manifest is based on Crew manifest, but can move kerbals, science, resources, and offers some other CLS enhanced capabilities. Hope that helps.

No problem, and your English was good enough. I did understand you. (por nada. El gusto es mio) I'm only guessing at an appropriate language based on your name

With that being said. I'm developing such a mod: Roster Manager. I was turned on to this thread by enceos. I will look at leveraging this mod for my needs.

Interesting... a fatigue bar. They do limit EVAs for that reason at NASA. Very good question. I've not looked at KerbalStats. Sounds like I need to

Switch seat already exists in SM. Not sure of stock, I'll check. However, the code I put in place already will support it if the Stock buttons will pass that data. I'll test to see. If you want to switch seats in SM , you will note there is a button to the left of the kerbal's name. looks like this ">>". that will move a kerbal to another seat in the same part, and if needed swap places wit the kerbal already in the next seat. If you have tool tips on, it will show you when you hover over that button. Update: I've tested the stock transfer to the same part. KSP will not let you do it. SO, for the moment, at least, you can use the SM method. I'm going to continue my investigations to see if there is another way to trap for the transfer and "make it work". I will keep everyone posted on my results.

I've not used the stock transfer much. To painful to have to find the hatch, then click on the kerbal transfer button, then select the target part... etc... I've used my tool almost exclusively. However, I'm sure there are times when it "can" be convenient Anyway, I've implemented the change, and am testing it now. I should have an answer soon on it. If desired, I can add a config switch called "Override stock transfer" that will impose the delayed transfer and portrait update... Since the change I made uses my crew transfer system, it will also have the sounds... Update: The concept works. I have some cleanup to do to address highlighting when the manifest window is in a state other than crew, but should not be a big issue. I'll include this in the next release. You will now have SM style crew transfers, respecting CLS spaces and the realism mode time dealy with sounds...

No problem. Roster Manager is going to be like Astronaut Complex on steroids... Interesting. Not sure... let me take a look at the code and see if I can intercept the call... I like the idea. Update: Looks like it may be possible. CLS traps the move, reverts the transfer and overrides the screen message if the 2 parts are not in the same space. I can do the same only when the 2 parts ARE in the same space, and slow it down with my realism transfer call. The end result would be just as if you had made the transfer from SM... Implementing it now. I'll let you know how it goes.

Actually it makes more sense in the Ship Manifest thread, as that would be a function used while in flight. But to answer your question, I hadn't looked at that but I certainly can. Iirc, CLS disables the stock transfer behavior and makes it respect living spaces... I'll verify that. if it does not, I'll look into disabling the stock behavior when in realism mode and using CLS. Yup, I was right. With the release of CLS 1.0.10.0, Kerbal transfers from one part to another cannot be accomplished if the living space is not connected. I just verified in the code, and confirmed in flight. I closed a hatch to a capsule, and tried to move a kerbal from the capsule to a Hitchhiker storage container. it failed and gave the proper screen message message that the destination could not be reached. So, if you desire this restriction, I suggest you install CLS if you have not already done so. This can be overridden in the CLS window by checking "Allow Unrestricted Transfers" Interesting. I'm thinking that could be possible. KSP already has a mechanism for dead kerbals. There may be a way to make that happen. I'll investigate that as a feature as well... makes perfect sense... crew rotations...

Yup. I'm also thinking along the lines of those that broadcast via youtube and twitch. It would be nice to totally customize your kerbals for your broadcasts... (Yemo inspired me with his comment about twitch in his thread on SETI).