Papa_Joe

you can post them here or in github, your choice. And I appreciate the reports. Only serves to make SM better. In your reports, provide reasonable information on how to reproduce and describe the conditions of the error if possible. it is also helpful to provide the SM Debug Window log, if there are any errors there. I try to trap all SM errors there to make it easy to save. New release imminent.... Version 4.1.4.3 - Release 06 Apr, 2015 - RT bug, External crew bug and control display fixes. - Fixed: When using RemoteTech, not all RemoteTech antennas would display in Control window list. - Fixed: Sometimes when displaying part info in Antennas, Solar Panels, hatches and Lights, a null exception would occur and "unknown" would be displayed in part parent info. - Fixed: Crew in external seats were not properly handled in SM. Attempts to transfer will generate unhanded errors, and could possibly corrupt the game save, requiring the vessel to be deleted. Expect it in the next few hours, unless other bugs are reported that I can quickly fix.

Just an update: I've been performing tests on external crew transfers, and it appears it is not quite as easy as I had hoped. The process appears to encompass the following: 1. Kerbal goes EVA. This causes a Kerbal to become a "vessel", and becomes the active vessel. 2. Right clicking on an External seat and then "board" when in range causes the kerbal to become a "part" attached to the External Seat part's vessel and referenced in the seat's KerbalSeat Module as an occupant. 3. When leaving the seat, right clicking on the kerbal exposes the Leave seat action. Clicking this causes the kerbal to become a vessel again as the active vessel... 4. Finally, the user clicks on the board action of the next external seat. This causes the kerbal to again become a part, and the steps in 2 above occur again with the new seat part. To emulate this, I will have to fire the appropriate events, and allow unity to handle the callbacks. This means that I need to allow the frame to update as needed so that the callbacks are fired. So, I'm going to have to create a persist model for the kerbal event states when EVA, and track the activity to ensure proper operations. This also means the the transfer will cause the scene to "change" as the active vessel changes from ship to kerbal and back to ship... Something else I've discovered is that when a kerbal is sitting in an external seat, it will appear in the SM part list, when the ship to which the kerbal is attached is the active vessel. Attempting to transfer the kerbal cause "interesting issues"... The transferr appears to work to an internal part, but the kerbal's "body" remains, and now has a Kerbal count of "0". Switching away from the ship and back then generates repeating unhandled errors in KSP... I will have to fix that. I've not given up, but it will involve a fair amount of additional plumbing to make it happen and the addition of some handling code when the kerbal is the active vessel. Currently, my code causes SM to be hidden when a kerbal is the active vessel... Also, in reference to Remote Tech command queuing, I'm still looking at how to support that. Not forgotten, but deferred for the short term. Finally, I've made the necessary changes to correct the missing RT antennas, and a fix for the "Unknowns" sometimes displayed in the hatch list of the Control Window. I will be releasing that fix very soon. Expect version 4.1.4.3 within the day.

Is this the Blizzy toolbar or the stock toolbar where you are experiencing the issue? Is the vessel manned or unmanned? Are you using CLS or not?

I sent a pm earlier (week+ ago) via KerbalStuff, but got no response. I'm trying to add the CKAN icon to my mod's title in KerbalStuff, and don't know how. Can you assist? I'm listed in CKAN, and have been on KerbalStuff since very near the release, so I suspect CKAN detection / configuration was added after I set up my mod. Link: https://kerbalstuff.com/mod/261/Ship%20Manifest Thanks for any help you might be able to provide!

Thanks. I only added the part title, so I'll look to see if it is returning a null for some reason. You might look at the SM Debug window to see if you are getting any errors... Update. Duplicated error. Examining resolutions now. New Update: Resolved the issue. Thanks for reporting. This uncovered the cause of a potential issue with lights, Solar panels and hatches. If you recall I had some hatches showing up as "Unknown". I had error handling code in place to account for a null exception. I found the cause of the null exception and revised the method of extracting the part info. This got rid of the base cause. I've revised the code for the other module objects to reflect the discovery and fix. New release soon, with the bug fix.

Subscribed. Looking forward to seeing it released! Btw, per Climberfx's request, I'm adding external seat crew transfers to Ship Manifest. Work is in progress.

I've determined what needs to be done, and I am actively coding the necessary additions to support external seat Transfers. Initially, this will be a non CLS feature, as I'm going to have to see what the implications for spaces etc, will be for CLS. It may be that you can add a CLS Module Manager config to support external to external transfers within the same vessel... I will keep you posted. A great idea, and a long needed feature, given the fact that external seats and rovers have been around for awhile!

Good to hear from you! I've not taken a look at the external seats. The external seats are separate parts, so I'm going to have to take that into account. The current methods used to move kerbals use very much he same methods used over a year ago, with the minor exception of now triggering onVesselChanged (for proper portrait updating and support for TextureReplacer). Looking at the models (awesome btw!) I can where you will need to go from external seat to external and from external to internal and vis versa. I'll be happy to give that some consideration. I'll report back on what I find out. I suspect we can make it work.

Thanks for reporting the issue! Ok, starting to look at this now. I will report back on what I discover. Update: Ok, I now understand the issue. RT is intercepting the button press. I'm invoking the event that would result. I'll look into changing the behavior to account for that.

Interesting. Are you using CLS or not? I'm researching the issue now... The previous version is available on KerbalStuff or Git Hub.. Edit: Found the problem. both issues are related, and only occur if you do not have CLS installed, or have CLS disabled. I still had CLS checking code in front of the Control button (left over from when I changed the Hatch button to Control), that would disable the GUI. I will remove it and release an update. Change log for upcoming version: Version 4.1.4.2 - Release 29 Mar, 2015 - Control Window Tweaks Edition. - New: Added part name to description for Antennas, Solar Panels, and Lights in Control Window. - Fixed: If CLS is not installed, or CLS is disabled, Control Button is grayed out and Manifest Window is stuck in one position on screen. Update: 4.1.4.2 has been released.

Hmm... let's answer 1 by 1. Unity does not really support this feature well (at least to my limited knowledge). if you will note, many mods exhibit this behavior and it is possible to "click thru" many windows... I have researched this as I do not like this behavior either. I will continue to research in hopes of coming up with an "elegant solution" SM "should" be saving window positions between game sessions. If you are referring to between Scenes (as in the settings window in KSC vs. Flight), that would be possible to do. I use no time delay with Remote tech. I fire the activate/deactivate just as if you had clicked it on the part itself. I'll look at Action groups extended, but it may be helpful if you describe the desired behavior. I can check for warp and prevent use of SM during those periods. I will likely make that a switchable setting as I have found it useful to be able to perform certain actions while in warp... Not sure why the Reflectron DP10 would not highlight... the code should work for all... I'll look into it.

I understand your point. I think the reason for the "resistance" is the notion that "losing reputation" as in spending it, denotes a certain negative connotation. If you were to treat it like a currency as you say, then as long as you don't go negative it would not be considered a bad thing? With that point of view, I can see "spending" rep.

KerbalStats does have a profession management ability, and that is only 1 step from name changes. I can see easily adding such support. I would be willing to collaborate. I'll fork your code and get familiar with it. We can then start talking about extending KerbalStats with taniwha to fit our needs. I don't have much for Roster Manager yet (other than some ideas, but do have the Roster portion of SM in place as a starting point. You can look at portion of SM's code if you wish to see where I'm at there.

I've been monitoring the forums for potential impacts to my addition of renaming, and this has provided me some insights as to next directions. Not much code progress yet, but much "brain storming". Rather than costing reputation for hiring, how about costing reputation for "losing" kerbals, flight faliures, etc? I don't know if reputation affects contracts, but I seem to recall something in that direction mentioned. I haven't played with the career mode yet, but it appears I will have to. Likely I will use SETI when I do, as it seems to be pretty cool as a balance mod. No worries. Everything we do is in an effort to improve the gaming experience for everyone . I can see where both mods can play together. Crew rotations is a definite need, and one you have already managed to solve it seems Now based on reviewing your thread, it seems we will need to "work together" to make sure that Roster Manager and Crew Rotation continue to work together. I will be removing Roster feature from SM and moving it to Roster Manager, as it really does not belong in SM anymore with its current focus on the Vessel and flight. Crew renaming and profession management are both features will need to be supported, and we may well can work out a framework to allow it for all. As I mentioned in your thread, KerbalStats may be the solution, as it provides an API framework and persistence model to work from...

I agree. There really needs to be a better way of tracking kerbals then by their name. Kerbalstats uses a persist file to manage name changes, and professions based on their names. Based on what testing I've done, changing the name does not "break" their experience, as that seems to be persisted in the save. SM uses a hack to change the name with "non printing" characters to spoof the profession generator at load to assign the correct profession. It saves with no issues, and does not seem to cause any loss of experience, but I've not confirmed that with any of my users... The fact that it is kind of a hack is why I have kerbal renaming disabled by default and warn users to use at their own risk I'm looking at integrating KerbalStats with Roster Manager to better handle persistence, but want to allow users the option of either using Kerbalstats or not. @enneract, you may want to look into Kerbalstats as a possible means to solve your issues. I could see compatibility being improved with the use of that mod, along with my mod and yours... They could then all "play" together nicely...

Here are 2 samples with different spacing. I word wrap the part name and the parent part name as it is easier to read. check out the spacing and let me know which seems better. 40 pix spacing... 50 pix spacing...

Yup, I was looking at that. When I implemented hatches... all parts were docking ports... kinda boring, and it made more sense to identify the part it was attached to... however, with panels, lights and antennas, the name can actually be helpful. I'll make that change in the next release. Thanks!~

I have issued a pull request with code revisions to correct this issue. It is tied to Issue #52 at the GitHub repository.

I would not say that. I would say I have to do a better job releasing so you don't have these issues in the first place...

I noticed from your screen shot that you are using an earlier version of SM (a few versions back). I suspect it is a version I inadvertently left my window settings in, so my guess is that the window is is off the screen. I suggest you update to version 4.1.4.1, and your issue will go away

That sounds like a CKAN issue. I can do a pull request on the meta, but I'm not sure that it won't happen again... Edit. I checked the meta and it shows the correct link. Don't know where or when the "mod" portion of the link disappeared...

I support both AVC and CKAN. I simply have to do a better job of releasing

I can do that. I do aim to please OP updated to reflect change to bug notation. Now shows "Fixed" for all bug entries in Change history.

Bugs posted in change notes are bugs fixed. I simply identify what the bug was in the text. For your personal reference, I added a check to test for extend/retract event states. With solar panels, if both event.active states are false, then it is an undeployable panel. @Chonner: I've bumped the KerbalStuff upload to v 4.1.4.1, removing the KSP version reference in the front of the version name. No other changes have been made. If you downloaded v 0.90.0_4.1.4.1, you have current code. Going forward, I will no longer include the KSP version in my version naming. (I keep screwing it up...)

dang it.... Murphy's law. The easiest fix is to publish a new version without the 0.90. and make it simply 4.1.4.1. This will eliminate the error and siimplify the naming convention. I had been including the KSP version as part of the version naming to make it easy to see what version of KSP it was built to, but that seems to be causing more issues than it solves... Thanks for the heads up.