Papa_Joe

Just curious, does the heatshield have a ResourceTransferMode? if it is set to "NONE", then it would be skipped in realism mode.

I'm not sure I would chastise SSSPutnik, but your point is well taken. I have spent a bit of time considering the balance between "cheat" mode and "realism" mode. With that thinking in mind, I recently added a user request for a "Realism Lock" switch in the config file for those that wanted to play in real mode and didn't want to be "tempted" by the ease in which you could change the mode. KSP has a great community, and there is a passionate following in the realism arena. I'm working hard to incorporate solid realism modes as best I can and make the mod a viable choice for realism style players. All feedback is greatly appreciated!

I'm soooo... embarrassed... :\ SpacePort has been updated. If your DL was missing the ShipManifest Folder, try downloading again. My apologies!!

OUCH!!!! New Upload coming.

In realism Mode it is restricted to the pad, and only those resources that can be moved. I'm thinking it should be OK, and "shouldn't" conflict with TAC. Jut my thoughts.

Version 0.23.3.1.3 12 Feb 2014 has been released.

Ok. So here is the latest: 1. Pre-Flight Mode Vessel Resource fill issue corrected. It prompted me to rewrite the entire process and I'm much happier with it. It now natively supports realism mode. 2. Added Dump Resource button to Resource list. Dumps a resource for the entire vessel. In Realism mode Dump buttons are available in Pre-Flight, but not available In-Flight. 3. Added Fill and Empty Crew buttons in Pre-Flight Mode. I promised I would 4. Added Mod Version number to Debug Window. Yep, another update coming soon. ( I don't like bugs... )

Hmm. I thought I had corrected that a long time ago. I'll look into it. Edit: I found the issue. Will be corrected in the next release. As far as will there "ever" be an option to dump fuel or mono-propellant, I'm not sure I had "ever" heard that request before, so I'm not sure of the "ever" reference. Perhaps you posted in the Crew Manifest thread? But, since you mention it, it is a good idea, and I could add that. I'm assuming you are referring to "in flight"? Also, in realism mode, dumping would be an issue, as venting would incur a thrust component (altering the flight trajectory) and have to be accounted for somehow. I can't just vent a part for free in realism mode. However, maybe with an event handler I could "simulate" it... Standard mode for sure. Realism Mode, I'll have to think about.....

Yay! I fixed the Science Xfer Bug! Dumb error, don't ask. Added Bi-Directional Resource Xfers too. Now you can go from source to target OR target to source. Convenient. New Version: 0.23.3.1.2, 11 Feb 2014 Toolbar 1.5.2 is with it. @heralo: Sorry, but in my excitement after fixing the Science bug, I whipped up the update and posted it to SpacePort. I'll add pre-launch crew management on the next update, I promise.

Sorry I missed earlier. Good catch on that 0/0 display issue, but unfortunately we aren't far enough in the transfer process to get to that check. When it attempts to getdata from the source partmodule, it returns null. Something is not getting properly created. sorting it out now...

Thanks! You are correct. You must be docked to transfer.

Not yet, but next update.

Thanks. I will have to set up a further progress career save than I currently have to properly test. This may be obvious, but Science transfers do not work in sandbox mode, as there is no data generated. I have looked at FScience, and the methods used are simple enough. My tool handles decision making differently, but only in the sense that I exclude experiments in the target part in advance, as there is know known way to transfer science into an experiment, and I don't want to give you a choice that will only give you warning after the fact that the target is incompatible with the transfer (llike FScience does). As simple as the code methods are to use, I'm confused as to why it is not working...

Can you describe what you are doing and what you see? I will be the first to admit that I did not get much testing on it. I play mainly in sandbox mode and my career mode save is early. If you would, please get to the point where you are ready to perform the transfer, and then go to settings, turn on the debug console, and clear the log. then turn on Verbose logging. Perform the transfer, and then turn off verbose logging. take a screenshot of the results in the debug console, and post it. That might help me to determine what is happening. I will also go thru the code again.

Multiple step processing I had not considered. I was thinking along the lines of single actions per step, with user input. However, chaining steps is an interesting idea... Very good to hear that!

I could do that, if I tie the manifest to the root part of an assembly. This would also allow checklists at the subassembly level... interesting... but now we are getting a fair amount of data stored on the local machine.... Could be worth it tho... In xml you could also edit them externally... hmmm... All resources work the same. Click on Crew, Science, or one of the resources. Click Transfer. The transfer window appears. Click on a source part, and then click on a target part. The details sections below show you what you can do. Crew: Xfer moves the selected kerbal to the other part. Science. Xfer moves the Data for the selected experiment/container to the target container. Resource. Xfer moves the resource to the target part. Pretty simple really, and the same interface for all. It won't let you do what cannot be done. For example. in a crew transfer you will not get an xfer button on a source crew member if the target part is already full.... No, it does not work like TAC. TAC is more robust than my tool's resource capabilities, and is used to balance a ship's COM using fuel transfers (in flight COM management). It also supports multi part feeds to a single part, drawing from each source equally. Ship Manifest does not yet support multiple part resource transfers. I will not ever support COM balancing or many of the other features of TAC. If you want the features of TAC, please use that fine mod. FScience is actually based on Crew manifest. So the two might work the same. I know I did not copy FScience code to do my work, tho I did look at it. I have heavily modified the original Crew Manifest code so it no longer looks much like it did originally. I believe this tool fits nicely as a general management tool, handling those things you would normally see on a ship's manifest (Crew/passengers), cargo lists, resources needed to operate the vessel, checklists and such. Yup, that would be good. Nice idea.

Someone else has requested multi-part transfers. I am considering this. However, given my plans with In-flight Checklists, I'm thinking this may actually fit into that better. My thoughts for checklists go like this: - They should be open and flexible, combining free text with some automation. - They should allow you to "program" an action or activity. One button press and the action is completed. - They should have check boxes to indicate completion - They should allow you to enter notes during flight - They should be persistent. You can quit the game and come back and your list is still there. This is where multi-part transfers might fit nicely. When creating the Checklist item, using a set of drop downs, Select the action (Transfer),select resource, select all source parts, select 1 or more target parts, and click ok. The checklist item is then ready for when you reach that part in the "program" as NASA used to call it in the day. Clicking the Go button in the checklist item performs the action, and checks the list item. Of course, any in-flight tweakable should be available from the checklist as well. Full control in an ordered (and repeatable) way. Maybe save as a template and you can add the list to the ship at launch or in assembly. This way you can save a Checklist for a craft, and have a "This is how you fly it" included with the ship. This is actually quite interesting, as I do not go anywhere near textures. What it DOES tell me though, is that the method i'm using for moving kerbals is wrong. I've patterned (and studied on) crew transfers after a couple of previous mods, and I've been troubled by the inability to properly instantiate the target internal view, which is why the portraits do not refresh correctly. I've been thinking about this, and the developers had no need to consider what I'm trying to do, as anytime a kerbal leaves it's seat it is to go EVA. So, I'm thinking I need to learn how to do an invisible EVA and simply board the vessel using the Board() function. I know this works, and causes the correct refreshing of the portraits. Now to figure out how to do it....

New Release: 0.23.3.1.1 Seat to Seat Transfers. See OP for details. Now you can move your kerbals around the cabin!

Update: With what I learned about internal views, I've now devised a way to not only move kerbals from part to part, but from seat to seat within the same part, as well. Cleaning it up now. Seat to seat works the same as part to part. You will see a "V" (could be an "S") button to the left of the kerbal's name for seat to seat. You still have to click "Update Portraits" to refresh the internal views. By clicking the V, the kerbal moves to the next seat (by internal index). If another kerbal is in the target seat, that kerbal swaps places with the original kerbal. You just click. Ship Manifest does the paperwork. Edit: Decided on ">>" for the button. I know I released just recently, but this is a cool enough feature to get it out right a way. Release imminent.

Version 0.23.3.1 Released. Science. Realism mode for this needs work still, so bear with me. That will take some smart persistence data management. Crew Xfer Portrait fix. Details in OP.

Well, I've spent the better part of this weekend trying to avoid using an "Update Portraits" button. It seems that I simply have not found a way to get the portraits to update automatically. I've learned a lot about internal models and seats and such, but I've not found a hook to get the internal views to update when crossing a part boundary. So, an Update Portraits button it is. For now... Anyway, with that said, I'm wrapping up the code and getting ready to publish an update.

Thanks for the questions! 1. Multi-part transfers are certainly possible (TAC does them), but as you said, I don't want to duplicate functionality. However, if you really look at it, I've been duplicating functionality all along, even if not in the same way... The other thing is: what about fuel/oxidizer? I was thinking of linking them, as it is not easy to transfer the correct amounts of either and respect the "1.1 - 0.9 mix. So, Let me look into multi part transfers. No promises. 2. I've been considering that for awhile. Not sure how to implement it "intuitively" yet, but definitely on my list. Others have found that if you simply use the built in transfer you can click a source and transfer to a destination. in my case, I had parts hidden behind fairings, and it was not easy to click on them, without some fancy zooming... 3. Zooming is another issue. I've found no mod that has overcome that issue (please correct me if I'm wrong), so not sure how to correct it. Even in KSP stock, this issue appears. It may take a fancy delegate function to override the mouse wheel event when certain conditions exist... Code update: Realism mode Lock is in place. Still working an issue with Crew move & missing portraits, and final testing on Science transfers. Update coming soon...

In fact, someone else also asked for the TransferMode=None rule to be respected. It is currently excluding solid fuels only. I have incorporated the new rule in the upcoming version I'm preparing for release. Another request has been for a flow path check for transfers as well. I'm considering that as well. I do understand your intent on the realism mode setting. With it outside the settings window, you are less inclined to "just this once " cheat. It would be possible to add a change lock to the config, and its relatively painless.

Somehow, double post. Sorry.

And this is the reason I did not want to presume I will take a look into that example test. I should be able to determine the cause. Thanks for taking the time to characterize this! Update. Science in place, in test now. Expect an update today or tomorrow.